9.1 Simple Object Access Protocol (SOAP)

---

Out of all the acronyms that pervade the computing industry SOAP must be one of the most bizarre and a testament to the resourceful nature of the protocol inventors. That aside, SOAP is set to change the way in which applications are written for the Internet.

9.1.1 SOAP-A Historical Perspective

Before Microsoft discovered the Internet and did one of the smartest threepoint turns in its history, the world of Microsoft distributed applications was very COM shaped. In fact, COM and its sister, distributed DCOM laid out a pretty compelling architecture used by many developers building some fairly complex systems.

9.1.2 COM and DCOM

COM is a component software architecture, standardizing the way in which objects interoperate. By providing a mechanism that allows objects to communicate, developers can build applications using constituent elements from different vendors in the knowledge that the components should interact to an agreed standard.

COM provides a component software architecture that is

• Programming-language-independent

• A binary standard for component interoperability

• Extensible

It also allows applications to communicate across process and network boundaries, share memory, and provide a mechanism to manage errors and the dynamic loading of components.

COM is available on platforms other than Microsoft Windows, including Apple Macintosh and UNIX, but the main demand for COM applications is within Windows applications.

With the advent of the Internet, COM developers immediately tried to apply COM mechanics on top of HTTP. It was soon evident that COM was not Internet friendly and caused a number of problems, especially since firewalls immediately stripped out any non-Internet protocols or procedure calls, leaving nothing of use behind (see Figure 9.2).

Figure 9.2: Distributed Applications-DCOM versus SOAP.

An alternative had to be found that was language-neutral, was scalable, and would gain broad support in the same way as other Internet protocols such as HTTP.

So, along came SOAP.

Although very active in its promotion, Microsoft did not invent SOAP; the credit for the original work is spread among a number of engineers, including Don Box (now of Microsoft) and his Developmentor colleagues, IBM and Lotus. The original specification for SOAP was submitted to the Internet Engineering Task Force and announced publicly at a Microsoft conference in 2000.

SOAP is a protocol specification that defines a way of accessing or invoking remote services across HTTP, the standard Internet wire protocol. SOAP defines the structure and format of remote procedure calls and uses XML to represent the parameters and any returned values. Since SOAP is built on top of HTTP, it is firewall-friendly and has inherent scalability (see Figure 9.3).

Figure 9.3: SOAP in action.

It's important to remember that SOAP does not kill off COM; all it does is provide a way for objects to communicate across the Internet. What SOAP does do is compete head to head with DCOM and, in fact, will replace DCOM as the mechanism of choice for building distributed systems in any scenario other than dedicated corporate networks.

Due to its inherent simplicity, SOAP does have some downsides. By relying on XML to package data, large messages are often created-with associated performance costs. Neither does SOAP have an inherent security model or support for the more powerful RPC features found within such technologies as COM. This is the consequence of designing a simple, crossplatform protocol designed for mass acceptance.

The lack of a security model often worries IT professionals reviewing SOAP. Surely this is a huge flaw in the design of SOAP? No, not really. SOAP merely provides the transport mechanism; unless you have a service capable of receiving the incoming messages, they will just fall off the edge of the planet into obscurity. In addition, the standard SOAP headers allow firewall administrators to turn off SOAP packets if they so wish. In fact, you would always put a security layer in your system and that would be HTTPS or SSL or any other standard security model, all of which work quite happily with SOAP.

One aspect of computing that is not addressed by SOAP is bidirectional communication. This does severely limit the use of SOAP for transactional usage, although there is an existing RFC transactional protocol called Transaction Internet Protocol (TIP) that is slowly gaining recognition and does add this functionality to the SOAP protocol.

---