Tim Berners-Lee’s World Wide Web has revolutionized the way businesses and individuals access and organize knowledge and information. Its impact on aspects of daily life from purchasing books to accessing personal data to political discussion are profound and far-reaching.
Today a revolution of similar proportions is happening in the world of organization-to-organization interaction over networks and the Internet. Although there have been middleware platforms for many years that enable “business interaction” over networks (e.g., DCE RPC, CORBA and COM), these platforms have suffered from a lack of compatibility and the fact that they were really designed for accessing services over local area networks. Platforms for enterprise integration have suffered from a lack of compatibility in the operations being coordinated, leading to the need for adaptors for message brokers that mediate between the different applications being integrated. These adaptors tend to be expensive, error-prone and costly to maintain.
The Web showed how relatively uniform but simple standard interfaces and protocols (HTML and HTTP) could unleash a potential for information sharing and seeking, on a truly global and historic scale. Today a similar revolution is going on in the world of business-to-business, and more generally organization-to-organization, interaction. The popular term for this is service-oriented architecture (SOA) and the current enabling technology is Web Services. As an example of the wide-spread use of Web services to support interactions among organizations, Amazon’s data storage capabilities, and Google mail, export application programming interfaces (APIs) to third party vendors using Web services.
Web services can sometimes refer generically to any service accessible via a URL, i.e., available on the Web. Wikpedia more specifically follows the W3C definition of a Web service as “a software system designed to support interoperable machine-to-machine interaction over a network.” To motivate Web services, consider the following picture showing an example of organization-to-organization interaction, a manual supply chain using web servers (alternatively it could be emails or faxes) as the communication points along the supply path.
An enterprise integration strategy uses message brokers and adaptors to automate the interactions between the parties:
However this approach requires a single trusted middleware for all parties to rely upon. More commonly the parties use point-to-point communications and adapters between their (mutually untrusted) middleware. The problem with this approach is the rapid increase in the number of brokers, and complexity and cost of the interaction support, as the number of potential parties involved in interactions increases:
Web services are intended to leverage the widespread adoption of Web standards such as HTTP and XML to develop a common lingua franca that avoids this proliferation of different middlewares and adapters:
Organizations such as OASIS and W3C are playing the role of standards organizations, much in the way that much of the Web was standardized, to ensure that the problem of incompatible middleware platforms is not repeated for Web services. These standards are also avoiding the mistake that was made in earlier approaches of assuming a single trusted centralized middleware. For example, there are now standards for coordinating interactions between organizations communicating using Web services, including failure handling. An organization may now offers its operations as Web services to other parties:
Taken to its logical conclusion, this leads to a view of software as services, where a service object is a piece of software with a stable published interface (contract for users) that can be invoked by any other software object. This service-oriented architecture (SOA) view of software does not rely on Web services, but the latter is a particularly popular enabling technology. We see this for example in the way various Google services are now provided as Web services. For example, a mobile device used by emergency providers might very well use Google maps to plot the best path to the site of an emergency. Rather than using a Web browser to enter the location, the address could be obtained automatically from a 911 emergency service. Putting together such a service would not be terribly difficult using the current technology.
There have been some complementary approaches emerging for situations where not all of the complexity of the emerging Web services standards are warranted. Some of these approaches include for example the representational state transfer (REST) architecture, which harkens back to the simplicity of the original Web protocol, and lightweight messaging toolkits such as Asynchronous Javascript and XML (AJAX). All of these approaches are part of the mix of capabilities that are expected of a graduate of the proposed program.