Untangling the Web

SOAP uses XML as a simple and elegant solution that automates B2B transactions

By Greg Barish

Continued from Page 1

Intricate Integration

An alternative to all of these issues is to use an existing distributed object technology, such as DCOM or the CORBA-equivalent, IIOP. Although this technology solves some problems, it ends up creating others. Foremost among these difficulties is the need to rely on special network ports for communication. Because IIOP and DCOM traffic is not encoded as HTTP requests and is not communicated between Web servers, specific unused network ports must be dedicated on both the client and server side. Thus integration is nonstandard and more complex than in the Web case. Also, IIOP/DCOM traffic wastes many important built-in benefits of HTTP-based communication, such as persistent connections and some of the network-level Web caching or content distribution optimizations built around HTTP-based communication.

Still more troublesome are the problems caused by firewalls. Organizations that have firewalls are often limited to exchanging HTTP traffic only. Using a proprietary port introduces a security risk, not to mention causing a bureaucratic and integration headache. In some cases, IT managers may simply not be able to bridge component systems together because network administrators simply refuse to allow the security risk (and with good reason). As if all of these issues were not enough, there can still be headaches caused by the integration of back-end systems that speak disparate languages (for example, integrating a CORBA and a DCOM system)

The SOAP Solution

SOAP simply and elegantly solves the major problems with both the HTML-based and DCOM/CORBA approaches by using XML over existing HTTP technology. Use of XML yields three important benefits:

• XML makes the data self-describing and easy to parse.
• Because XML and XSL separate data from presentation, useful data is distinguished from the rendering metadata. Thus, pages used as data sources for software agents can be reused for human consumption, eliminating the need for redundant data views.
• XML enables complicated data structures (such as lists or lists of lists) to be easily encoded using flexible serialization rules.

Using XML for encoding data also represents an alternative to ANSI-based Electronic Data Interchange (EDI). While EDI has been successfully used for years, it does have its problems. For example, it is cryptic and difficult to debug. Also, it is more expensive and requires the server and client to have special software installed to handle the format. What's more, EDI over HTTP is problematic: It doesn't completely support important HTTP encryption and authentication standards, and thus secure transactions are limited or simply not possible.

In contrast, SOAP keeps things simple. It's extensible, the data is self-describing, simple to debug, and it can enjoy the benefits of HTTP-based security methods. While a SOAP message requires more bandwidth than an EDI message, bandwidth has become less of a concern as the Internet itself becomes faster - particularly between businesses that can afford high-speed network access.

Finally, you can deploy SOAP over a number of protocols, including HTTP. This capability is important because it allows the firewall issues to be avoided and retains the optimizations that have been built into HTTP.

How SOAP Came to Be

Although it is not explicitly referenced as an inspiration, there is no doubt that previous attempts at Intranet component standardization - most notably COM and CORBA - have greatly suggested the need for an Internet-based standard as well. The battles between COM and CORBA for the foundation of back-end Web applications are well known. While both have their merits in terms of being scalable component-based solutions to application development, they both have their baggage as well. COM has been seen as the typical Microsoft-only, take-no-prisoners approach to component development, while CORBA has looked good on paper but has suffered from the classic problems with overstandardization (committees for everything) and an inability to command a leadership role in the component turf war.

The battle took a major turn when Remote Method Invocation (RMI) and Enterprise Java Beans (EJBs) were let loose. All of a sudden, COM and CORBA got pushed to the back burner. Java already solved the platform incongruency issues; RMI and EJBs defined an RPC and component infrastructure over that virtual operating system. While engineers applauded these more recent technologies that made scalable components easy to develop, they suffered from being an all-Java solution. In particular, RMI is a binary protocol that does not obey an open standard. Also, as Sun Microsystems itself cannot decide what to do as far as independent control of Java standardization, EJBs and RMI-based applications have been doomed to meet resistance as the type of open protocol that could be proposed for applications across the Internet.

An Open Protocol

SOAP avoids trying to declare a winner in this war for component design behind the firewall. Instead, it advocates a simple, open solution for application communication between firewalls. It also updates the priorities of components. Developers rarely laud the platform-independent features of CORBA these days. It was only a few years ago that development managers talked about how they linked together old AS/400 COBOL components with C++ components. This result is not because back-end legacy integration is no longer an issue: It still is and technologies like CORBA work fine for that need.

But the focus has shifted to integration among Internet systems. This shift does not mean that COM and CORBA camps did not prepare for that eventuality. DCOM and IIOP were attempts to address that issue. But, at the same time, IT managers have realized that the Internet itself has enforced a de facto form of platform independence. Now, all you need is a standard on top of that platform - and here is exactly where SOAP steps in.

In all of this raving about SOAP, I should be clear that SOAP obviously does not address component technology itself. You still need CORBA or EJBs or COM objects on the server side to do the actual processing. Instead, SOAP merely defines an interoperability standard between them.