Chapter 18. Services
Services and service-oriented architectures are broad and much-discussed topics. This chapter touches on some of the highlights, looking at the concept of a service and why services cost more than traditional implementations. Given that an investment is required to create services, it explores the conditions under which services make sense and provide a return on that investment.
Traditional Approach
A service is a reusable unit of functionality with a standardized (abstracted) interface. Without services, as seen in Figure 18-1(a), a component wishing to use some functionality is tied to the provider of that functionality in a variety of ways. It is tied to the technology of the provider. If the function is a COBOL mainframe transaction, then the using component needs to know how to invoke a COBOL mainframe transaction. If the function is a piece of Java code, then the using component needs to know how to invoke that.
Figure 18-1. Contrasting Traditional and Service Approaches
Beyond the technology dependency, a traditional using component needs to understand the semantics of the data structures required to use the native interface. For example, if the component is using the BAPI interface of SAP, the designer had better understand the structure and organization of IDOC data structures.
There are similar ties to native operation semantics as well. For example, placing an order in SAP using the BAPI interface requires two operations: The first takes the order and places it in a staging table; the second retrieves the result from another table. Furthermore, you need to wait some time after calling the first operation before you can expect to find the results with the second operation.
Service-Oriented Architecture (SOA) Approach
Services bring some level of standardization to this interface. Almost always you want to standardize the access technology so that whether the service provider is running on a mainframe, a Unix box, a Windows box, or some other platform, you are able to access the interface from whatever platform the service consumer happens to be running on. Platform neutrality is achieved through the use of platform-agnostic standards, and the platform-specific implementations of those standards are usually acquired.
Beyond standardizing the access technology, you may or may not want to standardize the data semantics and operation semantics. In contrast to the access technology, which you generally acquire, standardized data structures and operations (with some exceptions) generally need to be engineered and implemented. This requires investment, and consequently each service requires an investment decision as to whether the cost of standardizing the data and operation semantics is warranted. And it is perfectly appropriate for the decision to be different for different services.
Standardized Data Semantics: Common Data Models
The argument concerning the standardization of data semantics is really the decision as to whether a common data model should be created for the information being exchanged between the service consumer and the service provider. The argument usually boils down to determining how many parties will use the resulting data model. If there are only two parties involved (one service consumer and one service provider), there is usually little benefit in designing a data structure that is foreign to both parties. On the other hand, if there are three or more parties involved, a well-engineered data structure can go a long way towards simplifying the exchange of information between the parties.
Standardized Operation Semantics
Standardizing operation semantics means defining operations that make sense to both the provider and consumer of the service. Using the earlier SAP example, from a service consumer perspective it might make sense to define a single operation for placing an order, hiding the underlying pair of interactions with SAP.
However, standardizing operation semantics, like standardizing data semantics, requires engineering effort. If there are only two parties involved, it may be difficult to justify the investment. However, when three or more parties are involved, the investment is frequently justifiable.
Benefits of Services
If you look into the volume of literature surrounding SOA and services, you will encounter four commonly cited benefits:
• Platform neutrality: Regardless of the platform upon which the service consumer and service provider reside, they can interoperate.
• Isolation: The service consumer and service provider implementations are separated by the service interface. This isolation allows each to evolve independently, shrinking the scope (and hence the cost) of projects requiring change.
• Reuse: For each new service consumer, rather than building a new interface to the service functionality, the existing service operations can be used. This avoids development work, lowering cost and shortening schedules.
• Flexibility: Services can be combined in new and unique ways to create new business processes. This is really an extension of reuse, with the expected benefit primarily being a reduction in the amount of time it takes to implement the new process.
Most SOA Benefits Require Service Interface Stability
It is significant that three of the four commonly cited SOA benefits stem from one single property: interface stability. Isolation, reuse, and flexibility all assume that the service interface does not change, or at least does not change very often.
This observation is important because you do not get interface stability for free. The level of stability you obtain reflects the level of effort you put into the analysis of how the service will be used.
Interface stability is a relative thing. You will never obtain the perfect service: You can’t afford either the time or the effort required to strive for perfection. The good news is that you don’t need perfection—you just need interfaces that change more slowly than the implementations on either side of them.
Having said this, you must plan for the changing of interfaces. In a practical sense, this means that you need the ability to deploy two or more versions of the same interface simultaneously. This will afford service consumers the flexibility to migrate to the new version over some period of time. The alternative, a “big bang” simultaneous upgrade of the service and its consumers, is an expensive and risky proposition that is to be assiduously avoided.
Where Do Services Make Sense?
Building a service requires investment. Time and effort must be put into crafting an interface that will remain relatively stable over time. Documentation must be prepared to help first-time users understand what the service is for and how to use it. Mechanisms must be in place for finding appropriate services. Higher levels of testing will be required, since more components will depend on the service. All of these things take time and effort.
For the purpose of this discussion, the point-to-point interfaces that happen to use the technologies providing platform neutrality but do not strive for interface stability will not be considered services. A common example of a non-service is the use of a JMS transport to move an application-specific data structure between a pair of applications.
Recognizing that building a service requires investment raises the question as to when such an investment is warranted, that is, when there will be a return on the investment. Two sets of circumstances are indicators of a return. The first arises when there are two or more different consumers of the service’s functionality (Figure 18-2). Here the return on the service investment stems from avoiding the need to build additional interfaces for the additional clients. Instead, the existing service interface is reused. This situation often arises in practice with the addition of new channels for reaching customers and business partners.
Figure 18-2. Multiple Service Clients
The other pattern providing a return on the investment is one in which there are two or more providers of essentially the same functionality (Figure 18-3). This situation frequently arises as a result of mergers and acquisitions. The payback here is to hide from the client the logic needed to determine which of the service providers to use in a given situation. This allows this logic to evolve (as information and responsibility is migrated from one provider to the other) without impacting the client.
Figure 18-3. Multiple Service Providers
Combining these two patterns, the general pattern providing a service return on investment (ROI) is shown in Figure 18-4. When you are counting clients and providers, be sure to take future plans into consideration. It may be that today you only have one client and one provider. However, in the near future you may be planning to add a new client (new channel), or you may be planning to replace the present provider with another. Also count a significant modification as a new system. These situations also warrant the investment in developing the service.
Figure 18-4. General Pattern Providing Service ROI
Service Granularity
The granularity of the service—the amount of work encapsulated by each service operation—is an important consideration when conceptualizing a service. Remember that a service generally runs in another operating system process, and potentially on another machine. This means that there is some overhead involved in invoking the service. Therefore, you want to ensure that this overhead is relatively small compared to the work being performed by the service. For example, it would not make sense to abstract arithmetic operations (addition, subtraction, multiplication, and division) into a service: The overhead of invoking each operation would vastly exceed the computational cost of performing the operation.
On the other hand, the more functionality encapsulated into a service, the more specialized the service operations become. Highly specialized operations are less likely to be reusable. So, in conceptualizing your services you want to strike a balance—large enough so that the overhead can be ignored, small enough that it can be reused.
Summary
Services bring some level of abstraction to the interface between a service consumer and a service provider. Almost always, this means standardizing the technology of the interaction so that the service consumer and service provider can communicate regardless of the platform on which each is running. The technologies to accomplish this are generally acquired by the enterprise.
In addition, you may want to standardize the data and operation semantics. Unlike the acquired standardization of the access technology, standardizing data and operation semantics generally requires engineering effort on the part of the enterprise. In other words, an investment must be made.
There are four common benefits attributed to service-oriented architectures: platform neutrality, isolation of service consumer and provider, reuse of services, and the flexibility to build new business processes from existing services. Isolation, reuse, and flexibility all depend on the relative stability of service interfaces.
Achieving interface stability requires an investment in their conceptualization. A return on this investment is realized when the interface is reused or when there are multiple service providers. The granularity of service operations needs to be considered as well. If the work being performed is minimal, the overhead of invoking the service is not warranted. If a lot of work is encapsulated in the operation, it tends to become very specialized and therefore unlikely to be reused.