THE SERVICE-ORIENTED ARCHITECTURE

Over the past 40 years, we can clearly identify four distinct architectural paradigms. The earliest paradigm being the monolithic architecture, implemented on early mainframe systems, followed by the client-server architecture, and then the distributed or component architecture. Now, as we move into the new millennium, the fourth architectural paradigm—the Service-Oriented Architecture—is beginning to emerge. Figure 7.2 illustrates the progression from the monolithic architecture to the SOA during the past 40 years.

Figure 7.2: Evolution of systems architecture.

As discussed, most organizations have heterogeneous business systems that utilize significant elements of monolithic, client-server, and distributed architectures, which are extremely difficult to support and maintain within the context of enterprise architecture. The emergence of SOAs, implemented using Web services, will make it significantly easier for organizations to implement and maintain an enterprise architecture while also ensuring that the enterprise architecture has the much-needed flexibility to adapt to rapidly changing business needs and market dynamics. Figure 7.3 illustrates the key constituents and relationships within an SOA.

Figure 7.3: Constituents of a service-oriented architecture.

This discussion brings up a logical question: “What is the relationship between an SOA and Web services?” The concept of SOA is not specific to the technology used for implementation. Conversely, Web services are a specific set of standards and technologies that can be used to implement an SOA. As discussed in earlier chapters, an SOA implemented using Web services does not require a “rip ’n replace” approach. Web services can be used to implement an SOA in which functionality from legacy systems can be exposed as “virtual services,” and in which systems are integrated using Web services standards.

As illustrated in Figure 7.3, an SOA has three key constituents:

• A Service Requester —The service requester is a software component in search of a service to invoke. The service requester finds the service by discovering—through the service registry—the set of available services that meet pre-defined criteria. Once a suitable service has been discovered, the service requester binds to the service publisher to invoke the service.

• A Service Registry —The service registry is a centralized services repository that facilitates service discovery by service requesters. The service registry brokers the relationship between the requester and provider. If the requester and provider have a pre-existing relationship (For example, they are trusted partners), the requester can obtain the service description directly from the provider. In this case the service registry can be considered an optional component of the SOA as it is by-passed by the requester and provider.

• A Service Provider —The services provider, typically the owner of the service, submits a service description to be published in a service registry. The service registry brokers the relationship between the requester and provider, but it is important to note that services are typically hosted and executed by the service provider.

To facilitate interaction between the service requester, service registry, and service provider, three key operations are required:

• Publish —The service provider publishes a description of the service. The description details the necessary information for requesters to find and interact with the service. The description includes the information required by a requester to bind—meaning to connect—with a service. Typically the description includes the network location of the service, transport protocols to be used (for example, HTTP), and message formats for input and return parameters.

• Find —The find operation is initiated by the service requester and submitted to a service registry. The requester might be an end user or another service. In response to a find operation, the service registry locates the matching service(s) and returns the service description to the requester.

• Bind —Once the service requester has found the requested service, the service can be directly invoked at runtime, using the binding information provided in the service description.

It is important to be aware that the service requester, service registry, and service provider constituents of an SOA can all exist within the context of a single organization, or could equally as well be distributed across the Web. As discussed in Chapter 3, “Web Services Adoption,” early implementations of SOAs using Web services will undoubtedly operate within the boundaries of a single organization, but once the SOA is in place the model can easily be extended to leverage services published by third parties over the Web.

Services versus Components

The following section takes a closer look at the attributes of an SOA, but before we dive into the details of SOAs, we will examine the key attributes of a service architecture versus a component architecture. It is not uncommon to hear the terms “service” and “component” used interchangeably. However, components and services should be considered distinct. Components and services can be thought of as being at different levels in a system implementation hierarchy, as illustrated in Figure 7.4.

Figure 7.4: System implementation hierarchy.

As illustrated, components are typically fine-grained, meaning that they implement low-level technical functions (for example, user login functions for security and authentication), whereas services are coarse-grained and implement business level services (for example, a user administration service). As illustrated in Figure 7.4, the logistics management application uses a number of services, including the coarse-grained user administration service. The user administration service is itself composed of a number of fine-grained components, including the “User Login” component used to manage security and authentication.

Figure 7.5 illustrates the key differences between the implementation of services and components and the following sections discuss the characteristics of services and SOAs in more detail.

Figure 7.5: Component versus service.

Service-Oriented Architecture Characteristics

Chapter 2, “Standards, Concepts, and Terminology,” introduced many of the key concepts of an SOA within the specific context of the Web services enabling, evolving, and emerging standards. This section takes a step back from the Web services specifics and examines the characteristics of an SOA in general, but ties the characteristics back to Web services standards to clearly show how Web services can be used to implement an SOA.

There are four primary characteristics of an SOA that together differentiate it from previous architectural paradigms:

• Interoperability —Open interface standards, as opposed to systems or vendor specific standards

• Coarse Grained —Business level services, as opposed to fine-grained code or components

• Loosely Coupled —Flexible, loosely coupled services, as opposed to tightly coupled units of code

• Dynamically Discoverable —Distributed services that are dynamically located at run-time, as opposed to hard-wired references

From the context of Web services, some of these characteristics are basic capabilities, while others are either design principles or are attained through the use of additional evolving standards. The following sections discuss the four SOA characteristics in more detail.

Interoperable A basic characteristic of an SOA is the ability to deliver greater system interoperability. As previously illustrated in Figure 7.3, a service provider publishes a service description, which provides information regarding where to locate and how to invoke a service. This invocation information informs the service requester of the information the service requires and the information it will return. In effect, this function makes the service a “black box,” where knowledge of its inner workings is not needed.

As long as the service is trusted and you believe that the service will do what it describes, then the details of how the service has been implemented are unimportant. The physical location of the service, the programming language used to implement the service, and the hardware that the service runs on are all implementation details that can be hidden in an SOA.

Although the implementation details of a service are hidden, that is not to say that they are unimportant. In fact, as an organization’s SOA evolves, it will be critical to closely monitor and manage the availability of system resources, including the following:

• Network Bandwidth —An SOA can significantly increase network bandwidth requirements. The use of XML can increase bandwidth requirements by three to four times; as such, it is important to monitor network usage as the SOA is implemented.

• Load Balancing —From a Quality of Service (QoS) perspective, it is important to monitor the peak loading of machines that are running services to ensure that performance bottlenecks do not appear. For example, as systems come online, one single service might experience very heavy usage. This service could become a system bottleneck due to either network or processor bandwidth limitations.

• Identity and Security —Even when implementing an SOA within the enterprise, it will be increasingly important to ensure that appropriate identification and security is implemented to ensure that access to services is secure and authenticated. Logging information regarding who is running which services and when will provide an important audit trail should a service be accessed without authorization.

Coarse-Grained As previously illustrated in Figure 7.4, at the lowest level object-oriented languages such as Java, COM, and CORBA expose their interfaces as fine-grained components. These components are then aggregated into larger, coarse-grained services that more closely resemble real business functions. A coarse-grained service might itself be further aggregated into other services, or incorporated into an application or coordinated business process.

The decision to create a coarse-grained service rather than a fine grained service is primarily a design and implementation decision. As such, it is quite possible to create fine-grained services; however, componentbased architectures are better suited to this task.

Loosely Coupled Traditionally, systems are integrated using hard-coded connections in which the call parameters, interface name, network location, and so on are all hard-wired when an application is implemented. This approach creates tightly coupled systems which are highly sensitive to even minor changes in system configuration. For example, changing something as simple as a server’s network address could cause a number of systems to no longer operate correctly. This concept is illustrated in Figure 7.6.

Figure 7.6: Loose coupling versus tight coupling.

From a Web services perspective, loose coupling is achieved through three progressive levels of abstraction. These are:

• Services Communication —SOAP provides the first level of abstraction. At this level, the details of which development language the service was implemented in is hidden. For example, a service implemented in Java can work hand-in-hand with a service implemented in Microsoft .Net. However, the service parameters and network location of each service must still be specified manually.

• Services Description —WSDL provides the next level of abstraction. At this level, the service description contains the details of the service parameters and network address. The service description must itself be manually located, but once located, it can be manipulated programmatically to determine the additional information required to locate the service and run it.

• Services Publishing and Discovery —UDDI provides the final level of abstraction. At this level, the service description is published in a UDDI registry, from which it can be dynamically located using the registry’s search capabilities. At this level of abstraction the only information required is access to the UDDI registry and enough information to search for the service (for example, the service’s name, or type of service to be performed).

The third level of abstraction, provided through service publishing and discovery capabilities, is discussed further in the following section.

Dynamically Discoverable In an SOA, services are published in a services registry. Services registries are central repositories, either within an organization or on the Web, which can be used to dynamically discover services. From a practical sense it is more than likely that business users will already know that the service they are looking for already exists, but the services registry provides an additional level of abstraction, allowing the service description to be dynamically retrieved when the service is run.

By publishing a new service description, an application or another service-can download the updated description to determine if the service locationor parameters have changed. For example, a service physically located on a server in San Francisco could be relocated to a server in London. As long as the published service description is updated with the new location, any applications using the service will be able to determine its new network location when they perform a look-up for the service.