Exposing Systems with SOAP

One of the most intriguing applications of XML in the corporate programming world is the Simple Object Access Protocol. SOAP is essentially an XML-based Remote Procedure Call (RPC) protocol that piggybacks on the existing Hypertext Transfer Protocol (HTTP) supported by every existing Web server.

In operation, a SOAP request consists of an XML message that includes an object, a method, and a set of parameters to invoke on the server URL. The HTTP POST method is used to transmit this information to the SOAP server. The request is then processed by the server, and the results are sent back to the client in XML format as the body of the HTTP response message.

Compatibility

Tightly coupled technologies (such as COM and CORBA) complicate the process of linking different IT systems. Even platform-independent binary protocols, such as the Interface Definition Language (IDL) defined by the Object Management Group (www.omg.org), don't provide the flexibility required to easily combine systems based on different object technologies. Figure 8.3 shows how two companies using different technologies cannot utilize one another's IT systems over the Internet.

SOAP, on the other hand, is a much looser protocol. By leveraging the portability of Unicode and the wide availability of both HTTP servers and XML parsers, new SOAP server implementations are being introduced at a rapid pace. And because most large companies have enabled seamless Internet access throughout their networks, a SOAP client can run almost anywhere within an organization.

Originally, the HTTP protocol was intended only for use by Web browsers and human users. It was designed to be easy for Web browser and server writers to implement. As the Internet and the World Wide Web became more popular, corporate IT departments deployed Web servers and Internet access within the enterprise.

Most large companies now have production Web servers deployed on the Internet. The required procedures, policies, and network infrastructure for integrating HTTP traffic into corporate IT systems are very mature. As a result, implementing SOAP server functionality requires very little adjustment to existing systems. Figure 8.4 shows how adding a SOAP client and server implementation enables two organizations to link their IT systems. Note that the system based on COM/Visual Basic can now communicate freely with the Unix/Java system. This platform independence functions between any systems that implement SOAP.

Implementation details of the platform (Windows, Unix, Linux, and so on) object broker architecture, and programming language are hidden from consumers by the XML messaging layer. Server processing can occur in any language, using any resources necessary, and the client is never exposed to the internals of the server system.

Reliability

Factors affecting Web server reliability and performance are well understood and documented. The same techniques that are used to improve the reliability and performance of Web sites (clustering, load balancing, and so on) can be applied to SOAP servers.

Data Integrity

SOAP requests are executed as normal object method invocations on the server. Transactional support, if any is required, is provided by the host system, and transaction results are reported as the body of the HTTP/SOAP request.

Security

Secure communications can be provided using normal Web server technologies: HTTPS, basic authentication, client certificates, and even NT challenge/response. SOAP version 1.1 makes no special provisions for message security or encryption, but future releases will address message authentication issues.

The same security techniques used to secure Web-based applications can be used to secure server processing of SOAP requests. On Microsoft Windows NT and 2000–based servers, user security and impersonation can be used to limit access to system resources, files, and database content.