Part I: SOAP - Disrupting the Balance of Power
By Annrai O'Toole
The Simple Object Access Protocol (SOAP) is making profound changes to the communications and interactions landscape. In the truest sense of the phrase, SOAP is a disruptive technology. SOAP is not only being adopted and endorsed by rivals such as Sun and Microsoft and standards bodies such as the United Nations (ebXML), but is also being actively used to solve real-world problems. As the baseline technology for Web services, SOAP is leveraging pervasive Internet technologies to deliver two much spoken-about paradigms: the delivery of software as services and, as a corollary, the integration of online businesses.
The characteristic that distinguishes SOAP as a disruptive technology is that it delivers a tried and trusted paradigm in a new and more accessible packaging. The messaging paradigms behind SOAP, both in terms of Remote Procedure Call (RPC) and store-and-forward messaging, are well understood and widely deployed in technologies such as J2EE, CORBA, and MQ Series. SOAP takes these well-understood concepts and packages them using the ubiquitous protocols of the Web, namely HTTP and e-mail, while also using flexible yet simple XML technology to describe the actions and the data payloads.
In this combination, SOAP achieves what J2EE, CORBA, and MQ have never achieved. Today you can visit http://www.xmethods.com to see and use real, live, Internet-accessible Web services. In the same way that smaller disk drives changed the storage industry, SOAP is already creating fundamental changes to the ways in which business publish their business processes on the Web and how these processes integrate with one another.
To clarify this disruptive change, let's take an example. Today there are SOAP interfaces to two basic Web services. One is the Barnes and Noble book-pricing engine, which will return the price of a given book in U.S. dollars. The second is a currency converter. With a minimal knowledge of XML I can write an application that will find the price of a book in any currency you care to mention. Both pieces of functionality in my (somewhat contrived and trivial) application are hosted on the Web, as Web services. They are implemented in systems I don't know about-all I know is the interface to them. However, in a matter of minutes I can create a new application, which combines functionality from two diverse sources. This easy composition of applications is precisely what is so disruptive about SOAP.
Today I can easily create a custom Web page for myself using sites such as http://my.yahoo.com. These allow me to clip together information from diverse sources. This is a first step in web personalization. In the near future, people will be able easily to clip together application functionality from diverse sources to create new customized applications.
The Company of the future
The company of the future will pull a piece of stock out of a virtual inventory. Requesting the stock will fire a chain of SOAP messages on the Internet that causes the stock item to be assembled and delivered seamlessly. The entire transaction will appear as if it ran on an in-house system, as if the stock was stored on a shelf in a local storeroom.
What makes this different from the EDI promises of the past?
Firstly, the software applications of the future that support this sort of interaction will comprise many elements of software. They will be loosely coupled, and accessible over the Internet using SOAP, rather than monolithic integrations.
In the example above, the inventory supplier will use SOAP to expose a Web-service interface that any customer can access to place an order. The supplier will access other Web services, for example those of delivery agents. These standalone Web services are a key element of the business Internet.
Secondly, composing these Web services together will create the application. The composition will be as simple as generating a Web page is today.
Copyright 2001, Cape Clear. Reprinted by permission.
FOR MORE INFORMATION: