Web Services and the Drive Toward Interoperability

It's always interesting to start a discussion on distributed computing with a quote attributed to Leslie Lamport: "A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." Although Lamport said this several years ago, the concept still applies.

It is clear that interoperability has been one of the major themes in software engineering in general, and in Enterprise Application Integration (EAI) in particular, for the past decade.

Unfortunately, the seamless interoperability vision is still a dream. Brittleness in all current architectures is preventing software from achieving this vision. This brittleness comes from tightly coupled systems that generate dependencies at every level in the system. One of the most important lessons we learned as developers and architects is that systems need to be able to find resources software or otherwise automatically, when and as needed, without human intervention. This frees up business people to concentrate on their business and customers, not worrying about IT complexities, and frees up system developers to concentrate on enabling their business and their customers, not dealing with interoperability headaches by writing glue code and patching systems together. More than any technical consideration, this concept of implicit, seamless integration as a major business benefit is one of the main drivers for Web services. In other words, the time has come for just-in-time integration!

On the technical side, as a response to the demands of business, major shifts have taken place toward flexibility and interoperability, through open and widely accepted standards. The first major shift happened a long time ago with the advent of TCP/IP as an open platform for networking. This major step enabled such important and pervasive architectures as client/server computing. It took the advent of the Web for the next major shift, with HTML and HTTP providing the first truly universal open and portable user interface. Next, Java gave us truly open portable programming. Finally, XML brought with it open portable data exchange.

Integration

The next step in this evolution of open standards is the integration step. How do all these ingredients come together to facilitate the next evolution of e-business? We will see how and why the Web services concept is the answer to this question. As is becoming clear from the computing trends described in this book, distributed computing integration and interoperability is essential.

Enabling all these trends has been a realization that interoperability is really best served by a set of open standards that are accepted and agreed upon by all parties who want to interoperate. It can be argued that TCP/IP was one of the first significant enabling standards to make possible the current Internet as we know it. The Web revolution was enabled by HTML and HTTP, which was built on top of TCP/IP. HTML led us to the necessity of XML, and the original combination of XML and HTTP led to SOAP.

In the early days of the Object Orientation (OO), the general question was "What can Smalltalk (or C++, or Eiffel) do that I can't do with C?" It took some time to realize that this was the wrong question to ask. Not until the definitions of Object Orientation started being formulated (inheritance, encapsulation, polymorphism) and the corresponding benefits started being clarified did OO start to gain serious acceptance as a valid approach. The Web services concept finds itself at a similar stage in its development. In other words, "What can I do with Web services that I can't do with COM or CORBA or Jini?"

To get to an answer, we need to start articulating clear definitions of what constitutes a Web service and formulate the corresponding benefits of the approach. To this end, if we start thinking of software as a utility that is constantly available, we can start envisioning a system or an ecology of software components that live on the network, perform various tasks, conform to a set of declared interfaces, and can be found and invoked interchangeably as needed. This is essentially a fuzzy description of Web services.

For a clearer definition, we can say that a Web service is a platform- and implementation-independent functionality that can be

• Described using a known service description language;

• Published to a known registry;

• Discovered through a known standard mechanism;

• Invoked through a declared API; and

• Composed with other services.

While we're on the topic of definitions, one important point to keep in mind is that a Web service need not necessarily exist on the Web. This is an unfortunate historical naming issue. A Web service can live anywhere on the network, Internet, or an intranet. Another important point is that a Web service implementation and deployment platform is irrelevant. A service is available through its declared API and invocation mechanism. This set of definitions are the requirements that make Web services a system of loosely coupled services.

Web services intend to build on current accepted specifications such as XML and SOAP, while defining an additional set of specifications to complete the general Web services architecture.

Service-Oriented Architectures

Web services belong to a set of architectures called Service-Oriented Architectures (SOA). A SOA recognizes three simple roles services requester, services provider, and services registry and three simple operations publish, find, and bind (see Figure 11.1). These roles and operations are self explanatory and can be performed by any entity at various times. For example, a networked calendar application might provide its calendaring capability as a service; at the same time, it might request the services of a networked messaging system to send an alert to a user.

Figure 11.1. Roles and operations in a SOA.