Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Digital Library
Subscribe
Home

January 1, 2002

Keeping Promises

Web services deliver on the promise of interoperability

By Bill Howerton

How many times have you heard about a new technology, such as DCOM, CORBA, or enterprise JavaBeans (EJB), that offers unlimited interoperability by letting a client access a piece of distributed functionality that operates between heterogeneous systems. It didn't matter whether these systems spanned across platform and operating system boundaries or the implementation languages differed. You then gleefully went to your nearest technical bookstore, and after spending more than $100 on books and countless hours learning this new technology, you discovered that you still had to make adjustments in your application code to accommodate implementation idiosyncrasies.

Unfortunately, we've all been there. Although a number of technologies have offered the promise of interoperability, after a substantial investment, companies discovered they failed to deliver the expected benefits upon implementation. Whether due to vendor-specific structural mechanisms such as CORBA's interoperable object reference (IOR), implementation-dependent deployment requirements such as client-side Java archives (JARs), or vendor-specific Java Naming and Directory Interface (JNDI) syntax associated with EJBs, the result was a technology that was inextricably tied to a particular vendor's solution, thus denying true interoperability claims.

In this column, I describe yet another technology that will once again make that familiar promise: Web services. Although you may be skeptical (after all you have a right to be), allow me to explain why this time is different. Web services simply extend a technology that's itself truly universally interoperable — XML — combined with a universally interoperable protocol — HTTP.

INDUSTRY RECOGNITION

Industry and business leaders have long touted the advantages of using XML for obvious reasons: XML is character-based data that's universally readable. XML documents can be logically organized into schema thereby producing a standard data lexicon that all stakeholders can readily share. Combining XML with HTTP renders unimportant the incompatibilities created by vendor-specific solutions, as well as operating system and platform dependencies that plague other technologies.

The simple object access protocol (SOAP) is a technology that uses this notion of an XML schema to facilitate remote method invocation. SOAP is little more than a series of standardized XML schemas developed for the purpose of creating a universal lexicon. These schemas define the contents, syntax, and allowable data elements found in a valid SOAP envelope. Furthermore, they define the syntax associated with the mechanisms for invoking methods on a targeted remote object.

Using these schemas as a standard, vendors have successfully developed SOAP servers that will accept and correctly interpret properly formatted SOAP envelopes that adhere to those schemas. These SOAP servers are usually tied directly to an existing application server. The Web services made available in this manner are thus exposed as interfaces against a given server. The SOAP server parses the SOAP envelope and extracts the name of the object to be instantiated, the method to be invoked, and the parameters to be passed to that method. It then activates a specialized "provider," which is essentially a facilitator designed to invoke methods on specific types of objects deployed against that server. For example, one provider invokes a method within a Java class while another provider might invoke a method exposed within an EJB or COM object.

The transport mechanism associated with Web services is equally universal. In the overwhelming majority of cases, that mechanism is a standard HTTP "post" message. The SOAP envelope is simply placed within the message's payload and transmitted to a given server. Although SMTP as well as FTP protocols are available, HTTP is by far the most commonly used for transporting SOAP, mainly because HTTP is a protocol specially designed for text message transportation. Being text-based, the SOAP envelope is passed the same way as any other text-based message. Additionally, HTTP offers a rich set of services specifically designed for a text-based request/reply conversation. Using these inherent services, the data that results from the remote method's invocation may be packaged within the SOAP envelope's content, which is then placed into the payload section of an HTTP response message transmitted back to the client. The response envelope is returned to the client application in exactly the same manner as if it were any other HTTP message response.

PUBLISHING THE SERVICES

The only remaining required portion of the Web services puzzle is the publication of the services themselves. A Web service is really nothing more than a piece of functionality, such as a Java class, an EJB, or COM object, that has been deployed on a Web server and contains an externally visible interface, making it eligible for remote invocation. Once deployed, however, publishing that externally visible interface is a common practice. This publication can be via a static vehicle, which is then viewable using a tool such as WebSphere's SOAP administration tool, or dynamically within the context of a "contract document," which describes the interfaces associated with the Web services available on a given server.