Object Technology: Web Services

ACM has just shipped the premier issue of Queue, billed as not just another magazine, but one that "deals directly with the challenges ahead for software engineers and developers involved in the critical design and planning decisions most likely to affect product directions and operational practices for years to come." The first issue is on web services which is the object technology du jour, component engineering wrapped up in a new package.

I just reviewed a paper for a conference where the authors advocated defining web services using a language designed for intelligent agents. The authors presented a well reasoned and clearly articulated case. However, they did not show how to get from the stuff the average developer writes today, to an environment with interoperating, interacting, goal seeking agents play.

The first question that came to mind it, "What is a web service." Well, an interview with David Bosworth in the premier issue of Queue answers the question:

Kirk McKusick (Queue): People sure talk a lot about Web Services, but it's not clear they're all talking about the same thing. How would you define "Web Services?"
Adam Bosworth: The term Web Services refers to an architecture that allows applications to talk to each other. Period. End of statement.

So we are in the Alice in Wonderland phase of the hype cycle. Web Services means whatever I want it to mean in the current conversation, which may change in the next conversation depending on how I am feeling.

Bosworth was a senior manager at Microsoft responsible for XML industry standards definition and is now the Chief Architect and SVP of Advanced Development at BEA Systems. So his definition is as good as any.

My critique on approaches to web service architectures is that proponents should clearly define what a web service is, and make the case that definition is reasonable given the confusion that exists in the industry. They they should then clearly lay out a layered architecture like the following:

1. Define how objects are useful for creating components.
2. Describe how an enterprise component architecture can be used to expose APIs that do useful stuff.
3. Show how these API's can be exposed to the world as callable XML components, the lowest level of web service stuff.
4. Describe how distributed internet workflow can be layered on a group of heterogeneous low level web services to execute a business process that includes multiple business partners.
5. Show how a Real Web Service can be defined that executes a clearly defined workflow that completes a useful business process.
6. Describe how an external request can search for such a workflow, understands its inputs, outputs, and constraints, and contract with the workflow service provider.
7. Then tell me how to build intelligent agents that can converse with one another, and execute goal directed behavior that seeks out appropriate workflows that get useful stuff done.
8. Make sure any legacy technology can be wrapped and used in this architecture.

And don't just tell me that defining web services as intelligent agents solves the problem of "Web Services." We haven't even defined what a web service is yet.