What we're witnessing in the industry these days is the introduction of new frameworks. It's not that we're seeing new technologies but rather the leveraging of existing products and protocols. J2EE(TM) is a prime example. Sun took the Apache webserver/JServ model and created a complete framework incorporating these elements as well as JSPs and some other goodies to create a "component transaction monitor." You can still "roll your own" but integrated products such as IBM's WebSphere provide advantages to organizations wanting a complete solution from a single vendor.
The latest specification in this vein is Web Services. This is an attempt to address a set of issues for which previous technologies have promised solutions. Does anyone remember the Distributed Computing Environment (DCE)? I get the sense that there is a core set of perceived requirements which gets trotted out every couple of years. The "new" technology is going to provide solutions, save money and lead us into a idyllic future. To read some of the marketing hype, you might confuse it with the second coming.
So what is Web Services really? A directory a protocol and a standard. That's it! And we've already seen the global directory model in any number of incarnations. Apart from the directory and the specification language (based on XML) there is nothing really new here. The protocol for accessing the services is initially going to be SOAP (Simple Object Access Protocol,) which has been around for a while. I see Web Services as more of an effort to standardize the publishing of service specifications, whether locally or globally.
Let's look at the various elements and how they fit together. As mentioned, the protocol which will be used to access the services is SOAP. Built on XML, SOAP provides a standardized way to atomically access object methods. It uses a request/response model and is typically carried over HTTP using the POST method. Using POST over HTTP to send and receive XML documents is something I've been doing for years. It's an obvious solution for interacting with a database, for example, since the result set from a query can be so neatly mapped to an XML document.
SOAP is merely an XML dialect which "wraps" the object access in an "envelope", similar to X12 in EDI. An agent in the webserver maps the request to the local object and wraps and returns the response to the caller. This removes some of duplication of effort involved with writing servlets which have to interact with the HTTP request and response streams. Object classes with no knowledge of HTTP can thus be made network-accessible through the services of SOAP. This can be a significant benefit to companies which wish to expose previously written code.
And here we have our first philosophical divergence. People who have been writing servlets for years have built up their own libraries of methods which incorporate a lot of the functionality of SOAP. Plus they are probably more efficient since they don't have to be "all things to all people." In other words, SOAP must be able to handle a wide range of object types while a servlet which knows exactly what to expect need only implement the subset of code required. You can either spend more time developing a servlet which will offer higher performance or create simpler objects and incur the overhead of SOAP.
We now arrive at the specification language, another XML dialect called Web Services Description Language (WSDL.) Examining WSDL documents is an illuminating experience. Arguments types, for example, are specified according to the XML Schema format. The dialect is somewhat verbose since it is designed to be flexible. In the future, protocols other than SOAP will be supported. Again, nothing we haven't seen before. The binding section uses a URL to define the service location, for example.
WSDL is aimed at providing the same lingua franca as Interface Definition Languages (IDLs.) It serves as a "contract" insofar as describing the services available and the argument and return types. Some authors have strenuously objected to the comparison to IDLs but the intent is the same. Depending on the toolkit used, the development workflow can be similar. If the WSDL document is created first then both developers and clients can work from the same specification. Tools are also available for generating WSDL documents from existing object classes.
WSDL serves the same purpose as an Interface specification in Java and provides the same flexibility. It is possible to completely revamp an implementation with no impact on subscribers as long as compatibility with the WSDL document is maintained. Location independence can be facilitated using existing methods such as URL forwarding or load balancing hardware (routers) or software. Finally, WSDL is really no more complex than the deployment XML files described by the J2EE 1.1 specification.
That only leaves Universal Description, Discovery and Integation (UDDI.) Global registries have been tried before and the supposed benefits sound eerily familiar. The idea is that a customer creates a WSDL template and searches for matching services in UDDI. With some help of the other facilities provided in the Web Services framework, particularly metering and accounting, a contract is negotiated and voila! Instant outsourcing of non-core business.
But that's not how business really works. Once you find a likely service provider then you have to do a lot of research. How long have they been in business? Who are the principals? How much experience do they have? What's their financial situation? How are you going to contact them when the inevitable glitches occur? Do they have a toll-free number manned 24/7? Do they charge for technical support? Is it a flat rate or is it on a per-call basis? Important questions all.
So is UDDI just a pipe dream? Not at all, but it certainly wouldn't pay to be an early adopter, at least on the global scale. Internally, however, it's a different story. CORBA directory services were designed to provide the same kind of search capabilities. Being able to locate services and re-use them is a philosophy I embrace fully. In fact, it is entirely consistent with the Java language design, what with reflection and introspection.
Considering the continued popularity of mergers and acquisitions, being able to locate businesses providing complementary services is certainly convenient. But it's still only the first step in a long process. The marketing hype would have you believe that you will be able to find an appropriate vendor and have the freedom to dynamically adjust to changing conditions. Again, not the way the real world works. Account set-up fees, termination fees, usage fees and fixed-term contracts are the norm.
Web Services is an interesting framework. It builds on the right foundations and has some pretty lofty goals. It also extends what is already deployed. Experienced practitioners should have no difficulty exposing services via WSDL and UDDI. In fact, I'm going to spend the next couple of days doing just that. I'll take some stateless session EJBs and build out the Web Services visibility. I'll be adding the resultant files to an article in the Technology section of my website so look for an update soon.
April 11th, 2002
Copyright © 2002 by Phil Selby