Solid SOAP and its buddy UDDI
According to a recent agreement, eBay will make its underlying auction capabilities available to Microsoft's developers through the Simple Object Access Protocol (SOAP). This isn't proof of the SOAP pudding, just one more indication that SOAP is a durn important puddin', even more so with the advent of UDDI. It means that Microsoft's CarPoint site, for example, would be able not just to link to eBay.com but to use eBay's auction services to run auctions on the CarPoint site. And that's just for starters (well, also for distributors and carburetors): SOAP and UDDI head us towards a Web that knits together not just content but also applications.
SOAP is a way for one site's application to expose its capabilities to another site's applications through an API (Application Programming Interface). An API gives acess to the functions that make up a program. For example, eBay's programmers obviously have written a function that checks whether a proposed bid meets the minimum required increment for a particular auction. Let's say the name of that function is IsBidHighEnough. If another part of the eBay program hands this function an auction's ID number and the proposed bid amount, it will hand you back a yes or no. If one of eBay's developers wants to add a new capability to eBay that requires checking whether a bid is high enough, she'll simply use (or "call") IsBidHighEnough. Why rewrite code that works? Within eBay, the developer's program will be compiled and linked to establish the connections among the pieces. An API makes these functions available to other programs not written by eBay without eBay having to link those programs in; eBay can allow other programs to integrate with their auction engine just by calling IsBidHighEnough and the other functions required. So, if an online market wanted to use eBay's auction engine, it would have an easy way to integrate at a low (i.e., efficient) level.
SOAP is far from the first attempt at making it easier for applications to interoperate in deep ways. In fact, SOAP started out as XML-RPC, a protocol designed by Dave Winer for his UserLand platform. Before then, Microsoft's DCOM and the Object Management Group's CORBA required both applications to be running the same standard. The Web being the free-for-all that it is, you can't count on that, or that the two apps will be running in the same operating system or written in the same programming language. Just about all you can count on is that both sites will communicate via HTTP, the Web's communication protocol. So SOAP extends HTTP. A SOAP message (which should have been called a "bubble" but did they ask me?) consists of an HTTP header and then a request, in XML, to start up a function with whatever additional information is needed. For example, the XML might say that it wants to start up IsBidHighEnough for a particular auction at a particular price. The recipient app sends the result of the function back also via a SOAP message.
Obviously, for this to work the recipient application has to have a function by the name of IsBidHighEnough and the right type of information has to be provided. That's where UDDI (Universal Description, Discovery and Integration) comes in. UDDI provides a standard for creating a directory of businesses. Within an UDDI registry, a business -- using yet another standard, WSDL (Web Services Description Language) -- can list what functions it's making available over the Net. The canonical example is a site that offers to provide a stock quote to another app that sees that function listed in a UDDI registry. And here's where eBay could list "IsBidHighEnough," although it might instead want to bundle this function with a few others to present a higher-level function such as "MakeABid." UDDI is being backed by the Big Boys; IBM has even "open sourced" its UDDI registry code.
SOAP and UDDI are making it possible to knit together all the cooperating applications on the Web with a minimum of integration work. That's called "distributed computing" -- a web of functionality not just of content -- and it has the potential to be remarkable.
SOAP vs. Biztalk: