SOAP, the Simple Object Access Protocol

As we've observed in previous articles, Web sites are becoming more like applications and vice versa. At the same time, the trend toward hosted applications is gathering steam. But many Web applications still depend on scripting languages that were designed to work within the limitations of HTML and slow dial-up connections. And much existing data interchange depends on proprietary, Web-unfriendly technology.

A group of vendors that includes Microsoft is hoping to clean up the situation with the proposed Simple Object Access Protocol (SOAP) standard. This XML-based protocol lets you activate an application, or even an individual object or method within an application, across the Internet. SOAP could revolutionize the whole process of developing Web applications (as well as providing plenty of opportunities for cute puns). Will SOAP scrub away the friction that inhibits cross-enterprise applications, or will it be a washout? We'll try to explain how SOAP fits in to the complex world of online computing, and why it represents such an important milestone.

At first glance, SOAP may seem like nothing to get into a lather about. After all, it's not even a new technique — it merely codifies the existing practice of combining XML and HTTP to invoke methods (in an object-oriented programming language such as C++ or Java, a method is a bit of computer code that performs a specific action) across networks and across platforms. And even that is merely another way to do something which has been possible for some time using other methods (such as DCOM or CORBA/IIOP).

However, SOAP is significant because it represents a major step forward in the process of moving applications (and eventually the entire Universe!) to the Web and XML. Boosterism aside, the XML- based Web represents openness, extensibility and true platform independence, so moving business processes thither has to be a good thing.

To translate for the less technically-inclined, what we're talking about here is sending a request from one computer to an application on another computer (and possibly a completely different platform), instructing that application to do something. There are several ways of doing this, but the XML/HTTP combination is far more Internet-friendly, and that's the significance of SOAP.

Not Bubble Bath, but Business to Business

One much-touted application of XML is business-to-business integration. "B2Bi" is the latest teen idol in the business world, much as "e-commerce" was a couple of years ago. The basic idea is that a business can integrate its computer systems with those of its business partners (suppliers, vendors, customers), eliminating redundant data entry, speeding up order turnaround times, and generally reducing the "friction" involved in business-to-business transactions.

For example, under the old-fashioned way of doing things, a clerk might receive a purchase order by mail or fax, then have to key the information into the computer network. In a more modern scenario, the supplier company maintains a Web site (a so-called "extranet") which lets workers at the buyer's company enter purchase orders online. But in the absence of true integration, the workers still have to key the information again to put it into their own accounting or ERP program. B2Bi software lets the supplier's and buyer's applications talk to each other, so that the information goes automatically to both. It also lets workers at one company run queries to applications at another, so that (for example) the availability and price of an item can be checked before placing an order.

Of course, companies have been doing things like this for years by means of EDI ( Electronic Data Interchange). EDI is a standardized way of exchanging various types of data among applications, using the ANSI X.12 (United States) and EDIFACT (international) standards (Confusingly, the meaning of "EDI" has expanded, and some writers now use the term to refer to all forms of data interchange, including those based on XML). But traditional EDI, developed for a world in which proprietary applications talked to each other over private networks (sometimes called Value Added Networks or VANs), is looking a bit elderly in the more open world of XML and the Internet. By all accounts, it can be complicated and expensive to implement.

EDI messages must follow rigid formats, and the companies on either side of the transaction must have EDI software installed. EDI code was optimized to conserve bandwidth, so it's cryptic and hard for humans to read. XML is a far more flexible standard that requires no proprietary software. Furthermore, EDI has not proven to be very easy to implement over the Internet, as it doesn't fully support popular Internet security technologies such as SSL and HTTP Authentication. For some early ruminations on EDI vs XML, see XML: Evolution or Revolution?. For an in-depth discussion of the differences, see XML and EDI: Peaceful Co-Existence.

Companies Prepare to Clean Up