Section 1.4. Service-Oriented Architecture

1.4. Service-Oriented Architecture

SOA is a specific architectural style that is concerned with loose coupling and dynamic binding between services. Some critically important factors at the heart of SOA are necessary to make it work effectively.

1.4.1. Bind/Publish/Find

The basic principles that underpin SOA are illustrated in Figure 1-4. First, it is necessary to provide an abstract definition of the service, including the details that allow anyone who wants to use the service to bind to it in the appropriate way. Second, those people who are the providers of services need to publish details of their services so that those who want to use them can understand more precisely what they do and can obtain the information necessary to connect to use them. Third, those who require services need to have some way to find what services are available that meet their needs. Also, to make this bind/publish/find approach work well, standards must be defined to govern what and how to publish, how to find information, and the specific details about how to bind to the service. Web services technology is at the heart of addressing these questions and is the subject of this book. It also forms a basis for the notion of a service bus (infrastructure) that supports SOA.

Figure 1-4. The SOA Triangle.

The provider of a service describes its semantics, that is, the functions it supports in addition to its operational characteristics and required details about how to access the service. This descriptive information (or metadata) about the service is published to a directory or registry. A requester uses a discovery facility that is associated with the registry to find services that he is interested in and selects the one that is required. Based on the access information published about the service, the requester can bind to the selected service.

Descriptive information about a service, as indicated earlier and described in detail later, is based on WSDL and policy. At one end of the spectrum of service publishing and discovery is a separate registry or directory, such as UDDI, which holds WSDL and policy information about registered service and additional information such as business data about the service provider. This information is queried for services that match the requester's criteria. At the other end of the spectrum, more rudimentary mechanisms can provide access to and retrieval of metadata about a service, the existence of which is known to the requester perhaps by private means. However, after a service has been chosen, the information regarding how to access the service is used next to actually bind to it and send requests to it.

Figure 1-5 illustrates the various steps and artifacts that dynamically discover and bind a service. First, the requester describes the service needed via functions required and nonfunctional properties. Based on this input, the discovery facility produces a list of candidate services that satisfy those needs. From this candidate list, the requester chooses a service. The selection facility shown for that purpose can be as simple as performing a random selection or as sophisticated as considering additional criteria such as cost of use. After the requester has chosen the service, he determines its address and binding details, such as which protocol to use and which message format is required. This information is either already returned within the candidate list details or is retrieved in a separate step.

Figure 1-5. Selecting and binding services.

This processing looks cumbersome. However, middleware called a service bus (see [Voll 2004], for example) can simplify the process and make it more transparent. As illustrated in Figure 1-6, the requester simply passes to the service bus the description of the service and the data that the request message expects to be sent. Next, the requester gets the response to his declarative request. Based on this request, all services that qualify under the service description are undistinguishable for the requester, and the bus can unilaterally select from all candidates. The bus virtualizes these candidate services from the requester's perspective. For this purpose, the bus implements the shaded area in Figure 1-6. In other words, the bus takes the service description and uses a discovery facility to find the list of qualifying services, selects one of them, retrieves the necessary binding information, binds the service accordingly, transforms the input data from the requester properly, sends the corresponding request message to the service, receives the response, and passes this response in the proper format to the requester. A service bus provides a significantly improved ease-of-use experience for a Web servicebased implementation of SOA.

Figure 1-6. The role of the service bus in SOA.

The functionality that a service bus provides goes beyond virtualizing application functionality. Not only can application functions be described via WSDL, but also the usage of resources such as processing power (CPUs) or storage (disks) can be considered as services thus being described via WSDL. Thus, a requester might describe his need for processing power and storage to the bus, and the bus will make this available. Of course, this requires much more sophistication, including scheduling features and extensions of the Web service model. Nevertheless, the service bus is a major enabling technology for a distributed computing environment called Grid (see [Fost 2004], [Czaj 2004]). You can think of it as service-oriented middleware.

Note that CORBA already had some aspects of the SOA in it based on its Trader services. However, from an overall SOA perspective, these trader services were incomplete. Often, they were not implemented, and they certainly weren't universal in the sense of being platform neutral.

1.4.2. Framework for SOA

Web service technology is a base for implementing SOA, and the service bus is the centerpiece of this implementation. Thus, we want to sketch the high-level architecture of a service bus.

Figure 1-7 depicts the high-level architecture of the service bus as a stack of SOA capabilities. The bottom layer presents its capabilities to cope with various transport protocols to communicate between a service and a requester. The messaging layer on top of the transport layer enables the bus to deal with messages, both XML and non-XML. The latter is important, for example, if a requester and the service needed reside in the same J2EE application server and the bus can simply transport the data in its Java rendering, avoiding unnecessary transformations. The next layer of the bus facilitates and deals with the description of services in terms of functions supported, quality of services of these functions, and supported binding mechanisms. The actual quality of services that the bus enforces based on appropriate parameterization via polices resides in the layer that follows. This layer copes with security aspects such as message integrity, confidentiality, and nonrepudiation, but also with reliable transport of messages and various kinds of transactions. The top layer represents the various kinds of virtual components that Web services represent. This layer has atomic services that are not composed as far as a requester's experience with the service is concerned. Composed services that the service bus inherently supports are choreographies and societies of services that cooperate following an agreement protocol to decide on the success of the cooperation at the end of the cooperation. Finally, another layer provides features for discovery of services and their descriptions and to agree on a mode of interaction between a requester and a service.

Figure 1-7. The SOA stack: High-level architecture of the bus.

Chapter 3 revisits this topic and describes how various specifications fit into this SOA stack, with special focus on Web service specifications.