From the author of

From the author of

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.