XML for Communication

It was realized quite early on in the history of XML that it could be used to act as an envelope for information as it passed between different computing systems, which otherwise would be unable to communicate. This required the definition of an XML-based enveloping technology. Simple Object Access Protocol (SOAP) was defined by Microsoft and DevelopMentor to provide this functionality. Seen in terms of a service-oriented architecture, SOAP allows for applications to bind to other applications in order to make use of their functionality. SOAP has since been submitted to the W3C and is a W3C recommendation. Visit the W3C site (http://www.w3c.org) for more details on the specification.

SOAP is used to send data from one application to another application, so it is sometimes seen as a messaging protocol as well as a means of using functionality that is published by a remote application. These two aspects of SOAP—messaging and remote procedure calls (RPCs)—are both important.

Other technologies have been developed in order to fill out the vision of an XML-based service-oriented architecture. Web Services Definition Language (WSDL) enables an organization to define a Web service so that a Web Service broker can formulate a SOAP message to bind to it. Universal Description, Discovery, and Integration (UDDI) allows a Web Service provider to publish information about a Web Service so that a Web Service requester can find that Web Service. In a moment we’ll look at how these technologies work together, but first let’s look at where these new technologies fit in the history of Web-based applications.

SOAP: Third Generation of Web-based Applications

This use of XML for application integration represents the third generation of Web-based applications. The first generation of Web-based applications involved Web servers running CGI applications for dynamic content and people using Web browsers to interact with Web sites. This enabled the B2C (Business To Consumer) revolution. The second generation of Web-based applications also involved Web browsers interacting with Web servers. However, the Web servers now existed as part of a multiple-tier architecture, using an application server in the background, which may in turn connect to an organization’s internal systems. This enabled businesses to connect their supply- chain management (SCM) and enterprise resource planning (ERP) software to the Internet. This was intended to create a B2B (Business To Business) revolution to rival the B2C revolution seen some years before.

Tip

SOAP’s main advantage is loose coupling. SOAP can either be used for Remote Procedure Calls (called “RPC SOAP”) or for messaging between applications (called “Document-based SOAP”). In most cases, messaging is preferable to RPC, since it means that applications do not have to share an object model, or rely on a synchronous always-on connection. When thinking about SOAP, try not to think of it as “glue between applications,” but rather as “e-mail between applications.”

The bad news, though, was that the deployment of Web-based B2B projects did not turn out to be as dramatic as expected. The reason for this was that most B2B communications are machine to machine, not person to machine. The second generation of Web-based applications still involved people connecting to Web servers using Web browsers. B2B communication between machines, with no people involved, has been around for a long time. EDI networks have been used for many years to send large quantities of information between businesses. But, as we saw earlier in this chapter, EDI is not an ideal solution. Now that SOAP is defined as an enveloping protocol, with XML generally acknowledged as the de facto means of representing structured data, EDI may be implemented using XML. This holds the promise to finally enable the B2B revolution to take off, by allowing software across organizations to communicate using a flexible, open framework. The business-level aspects of EDI, which involve “choreographing” the flow of documents to match a business process, are being addressed by groups such as ebXML (www.ebXML.org).

At this stage, it should be obvious that the prospect of software from different companies communicating together, while powerful, is fraught with security concerns. In fact, without a convincing security model, the Web Services framework we’ve outlined would be next to useless.