The release of the SOAP 1.1 specification at the end of April was met by tremendous interest from the media, analysts and developers. Since IBM was a coauthor of the document (along with Microsoft, Lotus, DevelopMentor and UserLand), we were naturally pleased by the response. The SOAP4J toolkit that we put on the IBM alphaWorks Web site ( www.alphaworks.ibm.com) two days after the release had over 6,000 downloads in its first month. This encouraged us to donate the toolkit to Apache in June. After that, SOAP (Simple Object Access Protocol) picked up Sun Microsystems as another important endorser. By my count, over two dozen SOAP articles have appeared in the press. Why has this technology been attracting all this attention?

Messaging protocols aren't new. If you want an envelope format to send your invoice from one server to another, you have a number of choices. SOAP represents a distillation of the basic features that are considered necessary to build messages using XML. It's straightforward and includes an optional header and a required message body. It's extensible in the sense that neither the header nor the body need to follow a particular schema, though you must specify the ones you use via namespaces. To avoid total chaos, the SOAP specification provides a recommended encoding style for the message body and a usage pattern for doing RPC via HTTP. The body encoding builds on the soon-to-be-recommended (I hope) W3C Schema language datatypes.

SOAP represents a real chance for the standardization of an important building block in the stack of technologies needed for B2B interchanges. You must realize, however, that it's not meant to be a total solution for the XML infrastructure required for e-business. We must address security issues - encryption, authorization and nonrepudiation. The XML security experts at the IBM Tokyo Research Laboratories are investigating these and other issues, and have shared many of their ideas on the SOAP mailing lists.

Furthermore, we must deal early on with reliable messaging so we know messages get delivered - and get delivered only once. The W3C recognized these issues in their response to the SOAP submission. The work of the ebXML initiative ( www.ebxml.org) covers just such requirements for messaging; I hope they have an active role in the further development of SOAP.

As I write this in mid-July, the W3C hasn't announced what they'll do with the submission. Assuming they move ahead, there'll likely be a name change since SOAP will only be the starting point for their work. We'll also have to wait to see how the final standard differs from the original submission. Nevertheless, I think the SOAP 1.1 specification is enough to start building implementations. Get the code from Apache ( xml.apache.org) to start enabling your clients and Web application servers.

How SOAP Will Enable Web Services
I expect SOAP will be widely used for transporting XML messages, and RPC via SOAP will be part of the next important model for bringing some order to the explosive growth of B2B. At IBM we've referred to this as service oriented architecture or, more recently, web services.

One of the ideas behind Web services is to expose the functionality of your commercial or enterprise applications by providing XML APIs. For example, suppose you run a B2C retail company and want to provide a way for customers to tell if their packages have been delivered. You could provide customers with the name of the shipping company and the tracking number, then send them off to the delivery company's Web site to look up the information. However, if the delivery company exposed the "what is the delivery status" functionality as a service, you could send the company a SOAP message asking for the status. This and the response would be an XML message. You could then incorporate the information into your database and onto the Web page for your customers. You've now provided important information and kept your customers on your site. The communication with the delivery company was invisible to the customers.

If your delivery company is doing a good job, it'll likely move to a larger, more sophisticated computer operation. Because you're using SOAP and XML messages, this scaling up won't require any changes to your application. Conversely, if the company is providing poor service, you may decide to switch. If the new company is using the same "what is the delivery status" service definition, change only the URL used to retrieve that data. Otherwise your application remains the same.

To invoke or create other services to complete your e-commerce solution, you may do catalog look-ups, inventory verification and credit card purchase validations. If SOAP and XML messages are used for this, programmers need to know fewer technologies to get their jobs done. Their skills are more useful, and so are they! The more we simplify and standardize, the easier it'll be to create sophisticated applications and add value to what we already give our customers.

Note that we didn't need to talk about programming languages or environments in any of the above. You may use Java to write your server-side e-commerce application, while the delivery company might use CORBA or DCOM. It doesn't matter because all you want is to ask a question and get a response. The world isn't going to be pure Java anymore, just as it will never be pure CORBA or DCOM. These immensely powerful and useful technologies will grow in use, but XML messaging is the way to bridge the gap between them. SOAP isn't meant to replace true distributed object systems. It can connect such systems when the full richness and complexity isn't needed or isn't practical across the Internet.

Industry Standards: The Next Round
In the e-commerce delivery example I mentioned changing shipping companies if the quality of service dropped. Changes could also occur if you get a better price elsewhere or simply add another company to handle all your packages. You can switch or add companies without drastically recoding your application if they use the same service descriptions. Clearly, this is to your advantage. It's also to their advantage if they can entice you to start using them with a minimum of fuss.

I believe that agreement around service descriptions in XML will be the next phase of e-business industry standardization. Just as the auto, insurance, health care, pharmaceutical and other industries are actively creating XML standards, I think they'll come together to provide common service descriptions. How will they be specified? In May Microsoft released its Service Description Language (SDL), and in June IBM introduced the Network Accessible Services Specification Language (NASSL). There's hope for a convergence of these two and subsequent official standardizations. Once that begins to happen, the vertical industries can get involved and move B2B forward in a more orderly manner.

As an exercise, I encourage you to think about the services you might provide as gateways into your applications. Think about how you might use SOAP for application integration across the Internet. I think we'll find that enabling enterprise legacy applications with services' front ends will prove to be both a practical and lucrative activity for companies large and small.