The Universal Concept

Meeting the universal requirement is a somewhat daunting task, especially when the applications we want to connect run on different hardware, different operating systems, and different platforms. After all, each hardware type, operating system, and platform can have its own type system, memory management scheme, transports, and protocols. When viewed in the light of the accidental architecture of most organizations, we need a way to connect applications in a vendor-neutral manner. Over time, the industry has attempted several times to standardize type systems, memory management schemes, transports, and protocols across hardware, operating system, and platform boundaries. These include CORBA, DCE / RPC, RMI, COM+ and DCOM. For the most part, each of these efforts has failed to gain industry-wide acceptance in the long-term..

However, the industry has universally embraced the Internet and its accompanying standards. Without exception, modern hardware, operating systems, and platforms are able to communicate over the Internet. The acceptance of Internet standards results from the universal nature of HTTP, HTML, and XML. In essence, communicating over the Internet requires the ability to send or receive data that adheres to these standards and does not require a proprietary type system, memory management scheme, or internal protocols. To put it simply, Internet communication focuses on the data that is transmitted rather than focusing on a particular type system, operating system, or platform.

This underlying principle can be abstracted to provide a conceptual model for application-to-application and application-to-enterprise connectedness. The name for this concept is service orientation. The universal concept of service orientation holds the promise of addressing both forms of the universal requirement of connectedness. Applications built with a service-oriented paradigm are concerned with sending or receiving messages that adhere to a specific structure, much in the same way that a Web site sends and receives HTTP and HTML. Applications that receive these messages are typically called services.

Note 

The term service is extremely overloaded, and it might conjure up any number of different ideas for the reader. In this book, a service is functionality exposed via a structured messaging scheme. The structure of the messaging scheme can be virtually anything (SOAP, XML, JavaScript Object Notation, and so on), and the transport those messages are sent over can be practically anything (HTTP, TCP/IP, UDP, SMTP, CD/DVD, or even carrier pigeons).

For now, it is permissible to think of a service as being something conceptually similar to the Microsoft Virtual Earth Services.

From a business perspective, the universal concept of service orientation promises to simplify and streamline the work required to connect, version, and replace applications. Internal development work can be reduced through reuse of existing application functionality exposed as a service. Furthermore, the implementation of the service can be versioned (given some constraints) without any consuming application knowing about the change, or having to update itself. For example, if an application is required to plot delivery routes, would it be cheaper to develop a mapping solution internally or to use an existing service like Virtual Earth? Certainly the specific situation dictates the answer, but for most business applications, I assert that using a service like Virtual Earth would be a cheaper, more functional, and reliable alternative. Conceptually, it is easier, cheaper, and more reliable to reuse services that someone else has developed, tested, and exposed rather than redevelop and test the same set of functionality internally. In addition, as long as the messages and contracts remain compatible, the service can be versioned without coordinating the changes with applications that consume the service. These benefits, however, are paired with a new dependence on that service. A service consumer becomes beholden to the service provider for functionality. If the service provider goes out of business or their service is interrupted, that functionality will no longer be available to the service consumer. Furthermore, some service providers limit the ways in which their service can be consumed.

To be fair, this story is similar to the one told when components first arrived on the scene. Components offer a tremendous leap forward when compared to their predecessors, but component architectures have limitations, especially when viewed in the light of the universal requirement of connectedness. For example, component architectures need a common platform and operating system, and distributed applications built with component architectures usually have to version simultaneously. The tight coupling found in distributed component architectures makes versioning components and their underlying platforms extremely difficult. While this model might work for application-to-application connectedness, it does not work at all for application-to-enterprise connectedness. As you’ll see later in this book, service-oriented applications are able to version in a more flexible manner and are good candidates for meeting both forms of the universal requirement of connectedness.

From the perspective of the developer, the concept of service orientation focuses on the message rather than the implementation, platform, or runtime of the service itself. Sending a message from one application to another might not seem like a big deal and, at first glance, might not seem to be the answer to the universal requirement of connectedness. After all, applications of all shapes and sizes have sent messages to other like-minded applications since the reign of the mainframe. The barrier to the widespread adoption of this concept has traditionally been a lack of agreement on a message structure. Software vendors have traditionally developed their own proprietary message structure for use within a vendor toolset, but these message structures were never universally adopted. As a result, interoperability was practically unattainable. But what if a messaging structure could be agreed upon to the extent that it is considered a universal structure? If a message structure is globally adopted, any application that adopts that message structure can communicate with any other application that also adopts it. The key to the universal requirement of connectedness is the development of a standard message structure and the widespread adoption of that structure.

How then can there ever be agreement on a message structure? Well, one possibility is for software vendors like Microsoft, IBM, BEA, Sun Microsystems, and others to work together to create an interoperable message structure. Given the complexity of the task at hand, they would probably have to conduct years of research, several meetings and, my personal favorite, meetings about meetings. After enough research, meetings (and of course, meetings about meetings), a standard message structure should emerge, or a fight should break out. Either way, it would be interesting to watch.

You might have heard the term WS-* (pronounced “W-S-star”) recently. WS-* is a family of specifications that define, among other things, universal message structures and messaging choreographies. This family of specifications includes WS-Addressing, WS-Security, WS-Trust, WS-SecureConversation, WS-Federation, WS-ReliableMessaging, WS-AtomicTransaction, WS-Coordination, WS-MetadataExchange, WS-Policy, and WS-PolicyAttachment. Together, these specifications represent a vendor-agnostic way for applications to communicate reliably, securely, and in a transacted manner. These specifications use message structures based on XML and SOAP; they were written by representatives from most major software vendors and are the product of years of open consultations and meetings. These specifications are gaining widespread adoption because many of the major software vendors have participated in the creation of these specifications. Practically speaking, the major software vendors have agreed upon a de facto standard message format.

Before the ink dried on these SOAP-based specifications, other message structures appeared on the horizon. JavaScript Object Notation (JSON) is the most notable example. JSON is heavily used by Asynchronous JavaScript and XML (AJAX) Web applications as a means for a Web browser to send messages back to the Web server without forcing a page refresh. JSON completely diverges from XML-based message formats. It is based on JavaScript Eval function calls and does not fit the same mold as the WS-* specifications. In the purest sense, however, JSON interactions between the browser and the Web server are still service-oriented interactions. The important point here is that a service must have an agreed upon message format. Over time, the message formats used in applications will undoubtedly evolve to meet the requirements of the day.