SOAP: Simple Object Access Protocol

William Bordes, R&D Consultant (wbordes@techmetrix.net)
and
Johann Dumser, Junior Consultant (jdumser@techmetrix.net)

Printer Friendly Version

The evolution of IT

Over the space of a few years, the Web has completely revolutionized the way we use information technology, and as a result, our way of working has been completely transformed. The arrival of the new economy made waves which were felt all the way to the core of our information systems.

Internet businesses now have to meet two escalating needs: satisfying new demands (mainly due to clients' growing appetites), and integrating heterogeneous information systems. It is clear that customers today want richer, more finely honed services with increased customization and proactivity — in other words, services which bring greater added value to their professional and private lives. What they want are services that will work for them, save them time and money, and ease their burden of problems. After the static Web came the dynamic Web, and this is now evolving towards an interactive Web (or "Web services"), completing tasks with many stages of execution, between different players connected to the network.

The current problem involves the integration of these services and coordination of the stages between Web services. The components to be integrated are often of different types, while the tools and common conventions required to interconnect these components are lacking. The solution resides in one simple, lightweight protocol: a protocol like the Simple Object Access Protocol (SOAP). Indeed, SOAP was designed with these issues in mind: by relying on standards, it offers a way for programs to communicate regardless of the systems used. The first implementations of SOAP are based on HTTP and XML.

Where did SOAP come from?

The idea to create this sort of rich inter-application communication system is a relatively recent one. Among the most widely used Remote Procedure Calls (RPC), we can cite Microsoft's DCOM, or Object Management Group's Internet Inter-ORB Protocol (IIOP). But when it comes to making services communicate via Internet, these technologies reveal their limitations. This is mainly due to the richness of the DCOM and IIOP protocols that tend to complexify the implementations and applications that use them (see our report:Intranet Architectures and Performance). Internet cannot guarantee what kind of client and server will be operating at either end of the connection — it can only guarantee that they are both communicating in HTTP. We can therefore see how useful HTTP is as a communication protocol between Web services.

SOAP was originally developed by Microsoft, DevelopMentor, and Userland Software and was then submitted to the Internet Engineering Task Force (IETF), who eventually made it an official recommendation. The basic specification was drawn up in spring 1998 by Dave Winer of UserLand Software. His XML-RPC specifications, on which SOAP is based and which are available on http://www.xmlrpc.com/, are almost identical to the original SOAP specifications. With SOAP 1.1, IBM and Lotus joined DevelopMentor, Microsoft and Userland Software, along with a group of partners including ActiveState Tool Corp., Ariba Inc., BORN Information Services Inc., Commerce One Inc., Compaq Computer Corp., DevelopMentor Inc., Extensibility Inc., IBM, IONA Technologies PLC, Intel Corp., Lotus Development Corp., ObjectSpace Inc., Rogue Wave Software Inc., Scriptics Corp., Secret Labs AB, UserLand Software and Zveno Pty. Ltd. This battery of IT firms is clear proof that SOAP has all the makings of a promising protocol.

What has SOAP got that the others have not?

SOAP provides a solution for connecting Web sites and applications in order to create "Web services" (as coined by Microsoft in its new platform .net). The specification's authors decided to keep SOAP as a low-layer system. They clearly stated that they did not want to define an entire distributed object system specification (that is, no "distributed garbage collection," for example).

Internal project interoperability

Systems as different as Windows and UNIX often coexist within an enterprise. It can often seem very difficult to readjust projects in order to base their information system on one technology. To enable RPC-type communication between heterogeneous systems, all that is required is to base this communication on mutually intelligible languages and protocols: HTTP and XML. As these disparate environments are often able to communicate via HTTP, SOAP offers a way to make "incompatible" systems interoperate, while keeping development and deployment to a minimum.

Filtering - security

The whole principle, which involves clearly differentiating between information transport (HTTP) and message content (XML), offers the possibility of filtering information before and after and viewing it freely. This is mainly due to the extensible nature of XML and the send structure of SOAP messages, in which the message parameters are specified in the XML header. Caution is required, though, because HTTP and SOAP headers do not play the same role: the former is used to take the packet to its destination, while the latter defines who processes the information and how.

Service syndication or Web Services

In its most recent version (1.1), SOAP adds clear rules for supporting new transport protocols like SMTP or FTP, making it a global exchange protocol. But it also introduces the concept of intermediaries (stops between a SOAP call and the endpoint that do not affect the contents of the message, useful for information routing). This notion of endpoint means a SOAP message can send a piece of information all the way along a chain of intermediaries to a final recipient. The information concerning the various intermediaries and the data dedicated to them is found in the header of the SOAP message. The information in the body of the SOAP message is destined for the message end-user.

Proceed with caution...

The problem of immaturity
At the moment, interoperability is not totally feasible. Firstly, SOAP's version 1.1 was only the subject of a Note from the W3C, while version 1.0 only led to a recommendation from the IETF. In addition, current implementations do not yet meet the reliability and workload constraints encountered in enterprises. Anyone wishing to use SOAP for an enterprise project at the moment will need to go about it very cautiously. It will still be some time before implementations are optimized and able to act as a gateway between different languages. However, one rare, noteworthy event is the W3C's announcement that a working group is to be set up with the aim of standardizing XML-based protocols and SOAP in particular, with results due within a year. In addition, the OMG has set itself the task of making CORBA compatible with the communication protocol.

Security is one thing, but…
Soap's ability to cross firewalls without any hindrance could well cause problems. Firewalls generally guarantee security by authorizing or blocking remote calls on specific ports. Monitoring HTTP flows could become more complex since security solutions do not only have to check the format of network messages, but also their content. To do this, new verbs have been introduced in an HTTP protocol extension proposal. The verbs, such as M-POST, are designed to simplify administration of firewalls and proxies.

Onto Page II

Printer Friendly Version

TechMetrix Research is a technically focused analyst firm focused on e-business application development needs. Based in Boston, Mass., the firm publishes comparison reports and product reviews designed to aid enterprises with decision making and to keep pace with the fast-moving e-business market.

TechMetrix is a U.S.-based subsidiary of SQLI, a European company that offers on-site development services to international organizations. SQLI specializes in e-business project development.