- Web Services Are Here, But What Are They?
- SGML Roots
- XML Schemas to the Rescue
- Transport Protocol Not Part of the Web Service Equation
- Adding Traditional Middleware Features
- Different Strokes for Different Folks
- Not Ready for RPC
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Transport Protocol Not Part of the Web Service Equation
For traditional or existing distributed computing technology, the transport layer, or the way in which data gets from one computer in the network to another, is usually defined within the scope of the technology. CORBA has IIOP, DCE had its RPC, and COM also had the DCE RPC. The transport protocols and distributed computing APIs and services were designed to work seamlessly together. If you needed to pass a security token for an authorization check, for example, or a transaction context to the transaction service, the transport knew how to handle it because the relationship between transport and APIs was part of the coherent distributed computing environment. Coherent, but finite.
For Web services, on the other hand, the default transport protocol (HTTP) already exists and is in widespread use, although for a different purpose. HTTP was designed to transfer hypertext documents, not invoke objects or pass messages via queues, as Web services can.
Web services create a generic way to connect programs to each other across the network, including (perhaps first and foremost) across the Internet. But the Internet was developed for the purpose of transporting hypertext, not for program-to-program communication, at least not in the same sense as existing distributed technologies would think of it.
Actually, Web services are defined to use the Web, which is a huge application on top of the Internet. HTTP and HTML are already application layers on top of the Internet transport TCP/IP. So Web services end up being defined as applications on top of applications, and huge debates ensue about the propriety of this. But it seems like there's no other way to accomplish the goal of "non-human" interaction over the Web. The Web is out there, and adapting distributed concepts to it represents the best way of achieving the goal. At least, that's what the distributed computing community says.
With CORBA, for example, the IIOP protocol was developed within the context of the CORBA architecture to provide interoperability specifically for applications defined within that domain. CORBA, like the other existing distributed computing environments, consists of a finite set of application programming interfaces and associated transport protocols. In many cases, the APIs and protocol are linked—for example, to register callbacks and establish communication sessions.
With Web services, because XML is inherently extensible, flexible, and derives from a markup language world in which the meaning or interpretation of content is driven by an associated style sheet or schema, the possibilities are completely open-ended. There is no restriction to what you can and cannot include within a Web service, just as there is no restriction over what tags you can define within an XML document.
Some folks in the markup community will say that Web services already exist in CGI scripts popular at Web sites. And that many existing Web sites already offer Web services for purchasing books, getting stock quotes, purchasing travel tickets, and so on. Often, these primitive Web services work via embedding parameters in the URLs:
http://www.google.com/search?q=Skate+boots&btnG=Google+Search
This example shows the result of entering a search at the popular Google service. The words Skate boots were entered into the HTML form displayed when you typed in the Google URL: www.google.com. The form was displayed as the result of an HTTP GET on the URL. After the text is typed into the very simple form, the URL is returned to the host server containing the "search" keyword, along with the input parameters to the service.
There are obvious limitations to this approach when trying to send large amounts of data or when trying to interact directly with programs. The existing Web infrastructure is fine for human-driven interaction via browsers, but in order to achieve the ultimate goal of Web services—automatic program-to-program communication, without browsers and human intervention—the problem of mapping Web services technologies to underlying programs has to be solved. And these underlying programs very typically represent CORBA objects, J2EE classes and beans, and .NET classes. The tension starts to rise in the Web services community when the discussion turns toward mapping Web services onto these kinds of existing software systems. Should the RPC-oriented interaction style be optional or mandatory for SOAP? Should SOAP define how to correlate requests and replies? SOAP explicitly forbids many of the established distributed object-oriented computing concepts in order to keep it simple and map it more naturally to HTTP.