Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

January 1, 2002

Keeping Promises

Web services deliver on the promise of interoperability

By Bill Howerton

Continued from Page 1

By using this technique, you can publish the dynamic contract to make it available for downloading by a client application. The dynamic contracts are often described using the Web services description language (WSDL). The W3C defines WSDL as "an XML format for describing network services as a set of endpoints operating on messages containing either document- or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (or services)." A WSDL document will describe the services available on a server and the parameters those services require. Thus, users wishing to use the services on a given server need only request the WSDL document and select the desired Web service. To invoke that service, they insert the parameters into a SOAP envelope, which is transmitted to the server via HTTP.

Because the communications medium is plain text and the transport mechanism is standard HTTP, SOAP has become the de facto standard for interfacing with Web services for obvious reasons. By using SOAP interfaces, Web services developers can simply publish their interfaces without concern for the application's implementation. Similarly, the client application doesn't require knowledge of the implementing technology that's providing the Web service; it needn't be concerned with the platform upon which the service resides, the operating system under which the server is executing, and if you use WSDLs, it doesn't even need to have prior knowledge of the interface parameters.

Another advantage of using HTTP as a transport mechanism is that it facilitates the use of a Web browser as well as a standalone application for invoking those Web service methods. This benefit further illustrates the flexible nature of Web services and their SOAP interfaces. Developers need only code their applications to meet the syntactical requirements of the published interfaces. For communication purposes, the calling application must only be able to form and transmit an HTTP message that contains a SOAP envelope — a relatively trivial task.

PROS AND CONS

You can see why Web services that employ SOAP interfaces hold so much promise. Before you rush out to the bookstore, I should mention that SOAP has some inherent deficiencies: namely, performance. SOAP is little more than formatted XML. As such, it must be parsed. Anyone familiar with the mechanisms associated with XML parsing knows that this process requires you to dissect and analyze the text for syntactical and semantic correctness. You must then analyze it to determine both intent and purpose. Depending on the implementation, this parsing may occur all at once or in stages. Either way, the result is the same: It will take time. Depending on the parser, this time may be significant. Furthermore, HTTP as a transport mechanism is also inherently slow when compared to other protocols. Combined, these performance penalties may be so expensive that a SOAP-based solution may not be appropriate for a high-performance system.

Rate This Article

Comments:

Optional e-mail address:

Nonetheless, for all of its performance concerns, a SOAP-based Web services solution offers by far the best possible answer to the age-old interoperability dilemma. The notion of being able to interoperate between heterogeneous platforms has now truly become a reality. The ability to exploit the functionality of components that implement widely different technologies is also a reality. Five years ago, who could have imagined an application that invoked the methods on a COM object, an EJB, and a Java class, all within the execution space of the same application? But with Web services and SOAP, that notion is now a reality. For so long we were told that the latest technological evolution would solve our interoperability woes, but with SOAP, that promise is finally realized.

Bill Howerton [bhowerton@blueprinttech.com] is a software architect for Blueprint Technologies, a software architecture firm based in Falls Church, Va. His current work includes developing Web service-based systems for various clients including Galileo International and Trip.com He holds a master's degree in software engineering, and has more than 10 years of professional experience developing distributed applications for organizations including the Department of Defense.

RESOURCES

SOAP 1.1 envelope schema: schemas.xmlsoap.org/soap/envelope

World Wide Web Consortium XML Schema: www.w3.org/1999/XMLSchema-instance, www.w3.org/1999/XMLSchema