Web services nirvana? Coming soon since 2000
Chapters 1 and 2 of ''Service-Oriented Architecture'' by Thomas Erl [1] introduces the idea of enterprise level applications built using web services. Web services are the basis of a strategy for doing distributed computing. The commercial sector showed great interest in web services from the start. But unlike Erl, who limits his book to applying web services to integration initiatives within the enterprise (where judging from the remainder of the book, complexity can still be found in great quantities), the "craze surrounding Web services revolv[ed] around this nirvana of inter-organizational distributed computing (supply chains being integrated across enterprises and across continents with applications built out of small parts that are supplied on demand by many distinct vendors)" [3, p. 2]. By 2005, researchers were beginning to see that that world had not yet arrived, and was not likely to do so for years. "Cross-company implementations [...] are still comparatively rare." [4] What happened?
Web services are encapsulated chunks of functionality (which may be small or large) which communicate over the web (using HTTP) using a standard messaging protocol (SOAP). SOAP, in turn, is built out of XML. Organizations can create new applications by integrating SOAP enabled web services, possibly using XSLT to translate data between different web services. For legacy applications that are not SOAP enabled, organizations can write web service wrappers which translate between legacy native data formats and SOAP/XML.
A stack of languages, services and protocols -- XML, SOAP, WSDL, and UDDI -- were first associated and termed "web services" by Microsoft in 2000. SOAP itself was developed "by Dave Winer, CEO of Userland Software, Microsoft engineers Bob Atkinson and Mohsen Al-Ghosein, and Don Box, co-founder of DevelopMentor Incorporated" in 1999 [2].
Web services makes integrating applications easier, but even with web services, integration is still far from easy. Both technical and organizational issues slowed the advance of web services within the enterprise, and stopped it from leaving the enterprise. Technically, there are very real issues of "security, intellectual property exposure, and performance that follow from exposing web services outside the enterprise" [3, p. 8]. There is also fundamentally that "any two applications are virtually guaranteed to contain dissimilar data and execute dissimilar business processes. [...] Before any systems integration can take place, these dissimilarities need to be resolved. There is no magic bullet in the Web services toolkit that does this automatically or quickly." [4] Organizationally, service and data ownership, data definitions, access, acceptable use, business process definitions and more must be agreed upon among stakeholders within an enterprise -- this itself is difficult: "This might not seem like the kind of work that leads to disputes, but it is." [4] For two enterprises to agree upon these things is even more difficult.
As the difficulties of integrating applications once again revealed themselves, firms looked inward, focusing on wrapping legacy applications to free its data, and enabling integration across functional silos, and generally realigning business processes to enable web services internally. We are beginning to see the first steps towards true realization of cross-organizational computing as companies like Google, Yahoo, eBay and services like del.icio.us, Flikr, CiteULike, Twitter, etc. publish APIs (albeit based on REST instead of SOAP) for their services that are being used in mashups (combining data from several web services to produce something more than the sum of its parts) across the Internet. Will firms follow suit with their own private data?
