The world is not Java. The world is not RPG. Nor is the world Visual Basic, COBOL, C++, or Prolog. In the world of networked computers, one needs to be able to integrate the applications of dissimilar platforms that have been written with dissimilar languages. In my article "Distributed Components: EJBs, CORBA, and COM" (www.midrangecomputing.com/mc), I discussed the competing strategies of Enterprise JavaBeans (EJBs), Common Object Request Broker Architecture (CORBA), and Common Object Model (COM). Each of these strategies provide a different approach to distributed object computing.
But EJB is language-specific, CORBA is complex and costly, and COM is platform-specific. What your Web applications need-rather than the heavyweight protocols of EJB, CORBA, and COM-is a lightweight protocol for exchanging data in a decentralized, distributed environment. The Web needs Simple Object Access Protocol (SOAP), an Extensible Markup Language-based (XML-based) protocol developed by Microsoft that provides a simple mechanism for invoking procedures across the Internet. Eduardo Ross, in his article "Doing E-business with XML Schemas and SOAP" (page 82), says that "you can think of SOAP as the ability to call programs, passing parameters across programming languages, machines, and even operating systems."
What's in SOAP?
The idea of using an XML language to encapsulate the information required to make a remote procedure call is not new. IBM's Java Toolbox for the AS/400 (JT/400) has had the XML Program Call Markup Language (PCML) since OS/400 V4R3. But, unlike SOAP, PCML does not contain data (the values for parameters, that is); it merely describes the name and location of AS/400 programs, along with descriptions for each program's parameter data types.
When using PCML, the Java client application must set the required parameter values for the remote program call. And that's a point in itself: PCML requires the use of Java, whereas SOAP can be used with any programming language. That's because the SOAP "XML file," as I call it, contains all the information required to make the procedure call. The SOAP XML file doesn't have to exist on a hard disk. Typically, clients generate the SOAP file dynamically, in-process. The SOAP file is then transmitted over the Internet via standard HTTP. The system that hosts the remote procedure receives the HTTP data, sees that it is a SOAP request, and forwards the handling of that request to a SOAP server.
The SOAP server invokes the appropriate procedure, builds a response into an HTTP packet, then forwards the packet to the HTTP server, which, in turn, sends the packet back to the client. Note that SOAP requests and responses can also be sent and received over Simple Mail Transfer Protocol (SMTP).
Sun and IBM Wash Their Mouths Out with SOAP
When Microsoft first announced SOAP in October of 1999, IBM didn't like it. Neither did Sun Microsystems. IBM's executives originally said SOAP was designed to favor Microsoft technologies rather than industry standards. It also thought a protocol such as SOAP should have originated from a standards organization, not from Microsoft. Sun's executives were a little nastier than IBM's in their disclaimer about SOAP, saying it was "useless" because Java already had communications protocols. Sun's executives even said that SOAP was all "hype." But, as I said in the beginning this article, the world is not Java any more than it is RPG, Visual Basic (VB), or COBOL. An IT world with all-Java clients and servers will never exist. Applications are, and always will be, multilingual.
In April, however, IBM announced that it had changed its opinion on SOAP. Perhaps the biggest reason for IBM's change of heart was that Microsoft had just released an updated version of SOAP that included the work of both IBM and its subsidiary Lotus Development Corp. Then, at this year's JavaOne conference, Anne Thomas Manes, Sun's director of business strategy, said, "We think SOAP is a good starting point for XML messaging. You need a standard messaging system because it makes life easier."
To test the viability of SOAP, IBM developed SOAP for Java (SOAP4J) and made it freely available from its alphaWorks Web site (www.alphaworks.ibm.com/tech/soap4j). IBM's SOAP4J is a SOAP server that is written in Java; it runs on any Java server. The SOAP4J engine accepts requests via HTTP, invokes the Java procedure declared in the SOAP XML request that was embedded to the HTTP packet, and returns an HTTP response to the initiating client.
To call it "IBM's SOAP" is no longer accurate, since IBM recently turned over the rights to SOAP4J to The Apache Software Foundation (xml.apache.org/soap/index.html). SOAP is now one of five subprojects under the Foundation's Apache XML Project. The Apache XML Project has three goals. The first is to provide commercial-quality, standards- based XML solutions. The second is to provide feedback to standards bodies, such as the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C). The third is to focus XML-related activities within Apache projects. The SOAP project is based on, and supersedes, the IBM SOAP4J implementation. (Note that Apache's SOAP is an implementation of W3C's draft SOAP.) The point is that SOAP is here to stay, and it is free.
Where can you get SOAP? One obvious place to go is Microsoft, whose Visual Studio 6.0 comes with the SOAP Toolkit. But you can also get SOAP implementations from the DevelopMentor Web site (www.develop.com/soap). DevelopMentor has SOAP implementations available for Perl, Java, C++, and COM.
Or you can get it from The Apache Software Foundation. For more information on SOAP and XML in general, visit the W3C Web site (www.w3.org/XML).