Section 5.1. Service Types
|
5.1. Service TypesAn important feature of a software architecture is that it breaks down the overall structure of a software system into smaller components. These components are intended to be flexible building blocks. 5.1.1. MOTIVATIONBeing able to classify service types is a precondition for the effective design of SOAs.
5.1.2. CLASSIFICATIONWe differentiate between four classes of services: basic services, intermediary services, process-centric services, and public enterprise services. Figure 5-1 introduces a basic notion we will use throughout this book. Figure 5-1. We distinguish basic, process-centric, intermediary, and public enterprise services.
In the remainder of this book, we will also use the terms participant or SOA participant. These terms comprise both application frontends and services. Table 5-1 provides an overview of the different service types and their key characteristics.
We now examine the elements of Table 5-1. 5.1.3. BASIC SERVICESBasic services are the foundation of the SOA. They are pure servers in the SOA and maintain no conversational session state. Basic services cut into data-centric and logic-centric services. However, in practice, there is often a smooth transition from a data-centric service to a logic-centric service. As a matter of fact, many services deal with both data and behavior. Thus, we cannot classify them as either purely data-centric or logic-centric. Fortunately, the mix of data and business logic does not render the SOA unsound. Services that provide both data and business logic can be as agile and reusable as "pure" services. Let's consider, for example, a contract administration service. This service typically stores data sets that represent contracts. In this respect, this service is data-centric. But this service also needs to provide plausibility checks that decide whether any data set represent valid contracts. In the second respect, this service is logic-centric. 5.1.3.1 Data-Centric ServicesIt is the purpose of a data-centric service to handle persistent data. This includes the storage and retrieval of data, locking mechanisms, and transaction management. A data-centric service also handles (and utilizes) a physical data storage facility such as a relational database, file system, or tape library. In this respect, a data-centric service behaves similarly to the data access layer of a traditional application. The major difference is the vertical layering of data-centric services. Whereas a traditional data access layer manages data for the entire application, a data-centric service deals with one major business entity only. Furthermore, a data-centric service strictly encapsulates its data entities. Any other service that requires access to this data needs to use the service interface of the corresponding data-centric service (see Figure 5-2). Consequently, an application requires several coordinated data-centric services. Figure 5-2. The SOA strictly defines the ownership of data.
One of the most important tasks of the SOA architect is to identify the relevant business entities that are represented by data-centric services. This task is similar to traditional analysis of the business domain. Methods that are based on entity relationship models (ER) or object oriented-design provide a sound base for the design of services. Notice that these techniques are primarily used for designing the data objects that are either managed by services or that serve as input and output data structures. It is important to understand that cross-service relationships are not allowed, and as such, no cross-service navigation exists as in distributed object technology. This means that the complex value objects managed by the services must be sufficiently self-contained or must contain unique identifiers that enable them to relate one complex value object to another. Similar to the design of objects or abstract data types, a data-centric service can also encapsulate data behavior. In this respect, SOAs provide many of the benefits of object orientation. However, SOAs do not require object-oriented programming languages for their implementation. The independence of programming languages and the underlying technology is one of the greatest strengths of the SOA approach. In practice, you will often find that programming languages such as COBOL, C, or PL/I and traditional transaction processing monitors are used for the implementation of mission-critical services. However, the usage of SOAs and data-centric services raises certain issues. Although the vertical layering that is leveraged by SOAs is worthwhile, especially for big applications, benefits such as flexibility and reusability are not without cost. Traditional applications typically access one monolithic data store that has no vertical substructure even if the application is horizontally layered. The functionality of the underlying database or transaction monitor is fully leveraged. Physical transactions often span all parts of the data model and, from the developers' perspective, this is very convenient. There is no need for explicit considerations of data integrity. This is achieved in a transparent fashion by the database or transaction monitor. The downside is a resulting monolithic structure with many implicit and explicit dependencies. The issue of data ownership gains tremendous importance with the vertical layering of applications. Although data ownership has been on the agenda since the very first days of data modeling, it was not really relevant for the implementation of traditional applications due to the monolithic structure of the data access layer. So, this aspect of data modeling was mainly of academic concern and was reflected in naming conventions for database tables and access modules. With the vertical slicing of SOAs, the assignment of entities to data-centric services becomes a design decision with a major impact on many characteristics of the resulting applications. In such a case, explicit efforts are required to overcome these dependencies (see Chapter 8, "Process Integrity"). 5.1.3.2 Logic-Centric ServicesLogic-centric services encapsulate algorithms for complex calculations or business rules. In traditional applications, this type of functionality is often encapsulated in libraries and business frameworks. A very instructive example for a logic-centric service is an insurance product engine. This is a service that encapsulates the knowledge, terms, and conditions of the products of an insurance company. It is capable of computing fees, payments, or refunds and can validate customer applications, suggest new offers, or simulate fee adjustments. This type of functionality is generally part of the back office system for insurance contract/policy management. Consequently, only a back office clerk can provide legally binding information. This is very unfortunate for up-to-date business processes of sales and claims. Traditionally, people have taken a number of approaches to resolve this problem. The first deals with approximations. In this approach, the front office application provides an approximation of the real value to be validated by the back office using a manual process. Although the front office processes of insurance companies have had to cope with approximations in recent decades, customers nowadays expect accurate data and rapid processing. Particularly for the sales of new contracts, legally binding data that is instantly available is increasingly mandatory. The second approach is based on duplication of the relevant business logic. On one hand, this approach satisfies the needs of the sales and claims departments, while on the other hand, it can raise many technical issues in traditional environments. Most importantly, you must cope with the deployment of the appropriate functionality and regular updates to potentially thousands of PCs and laptops. You will also encounter heterogeneous technology in front and back office implementations. While back office environments are mostly based on centralized mainframes, the front office systems are usually based on PC techno-logy. This means that every new version of the calculation rules also requires a porting effort before deployment, a process that is both costly and risky. In the third approach, the users of the front office applications are provided with access to the back office applications. Although this might look like a solution of striking simplicity at first glance, it is not an option for most insurance companies. Many insurance companies have no desire to grant access rights to their back office applications to front office personalparticularly if independent agencies are involved. A logic-centric service providing the functionality of the product engine would overcome many of the aforementioned challenges. The insurance company could operate this service centrally (see Figure 5-3). Its functionality could also be integrated both with the internal IT systems of the different departments and with business partners. Furthermore, façades (discussed later in this chapter) can be utilized to provide different "views" for different types of users (e.g., independent agencies versus claims department). Figure 5-3. An insurance product engine encapsulates the knowledge of the insurance company's products.
5.1.4. INTERMEDIARY SERVICESIntermediary services can be classified as stateless services that bridge technical inconsistencies or design gaps in an architecture. They are both clients and servers in an SOA. They cut into technology gateways, adapters, façades, and functionality-adding services and act as stateless mediators when bridging technological or conceptual gaps. Although many intermediary services seem to be rather technical, we can distinguish them from technical infrastructure services because they provide a business-oriented API, whereas purely technical services provide a technical API. Many intermediary services are highly project-specific. 5.1.4.1 Technology GatewaysTechnology gateways bridge technological gaps (see Figure 5-4). They therefore incorporate two or more technologies for communication or data encoding. Technology gateways act as proxies for their business services and represent the functionality of the underlying services in an environment that is technologically different from the original business service's runtime environment. Figure 5-4. A technology gateway bridges the gap between different technologies.
They are particularly useful for legacy integration projects where one often encounters the conflicting demands of a need to extend existing legacy application with a requirement not to "contaminate" new components with legacy technology. There are good reasons for both requirements, and a technology gateway can be very useful in such cases. A typical scenario provides a good illustration of the problem. Assume that a terminal-based legacy application contains valuable business logic. Due to its outdated user interface, a reengineering project is planned for the near future. However, a more urgent project requires the business logic of this application before the reengineering project is completed. The new project is implemented based on a Service-Oriented Architecture and up-to-date technology for distributed computing. In such a case, a technology gateway can act as a mediator between the legacy application and the components of the new project. The new project accesses the technology gateway using a modern technology such as a Web service. The technology gateway translates the Web service requests to terminal data streams in order to communicate with the legacy application. Although it is a monolithic application that serves all requests, it is advisable to distinguish between different services according to service-oriented design principles. It is an irony of enterprise IT that you never know whether the reengineering project of the legacy application will ever take place. However, even if this is the case, the design of the existing services will be very useful. For these services, you only must replace the legacy implementation with the reengineered basic services. 5.1.4.2 AdaptersAn adapter is a special type of intermediary service that maps the signatures and message formats of one service to the requirements of a client. We can illustrate the concept with an airline booking example. Assume that airline A merges with airline B and that both airlines already have an SOA in place. Apart from other services, both airlines have an established customer service. More than likely, one of the first business requirements after the merger will be to enable access to customer data across the borders of the two former corporations. For the sake of customer service, this feature should be put in place as soon as possible. It is also a very typical requirement that the existing applications of both airlines should remain largely unaltered. A simple solution to this problem is based on two adapters. One maps requests of application 1 to service 2, and the other maps requests of application 2 to service 1. 5.1.4.3 FaçadesThe purpose of a façade is to provide a different view (probably aggregated) of one or more existing services (see Figure 5-5). As such, façades often act also as technology gateways and/or adapters. Figure 5-5. A façade service provides a high-level view of one or more basic services.
An in-depth discussion of façades is found in Gamma, et. al. [GHJV95]. Although Gamma describes the encapsulation of object-oriented subsystems, the entire concept is widely transferable to SOAs. Gamma defines a façade as ". . . a unified interface to a set of interfaces . . . that makes the subsystem easier to use." Façades can be used to provide a specific view of a set of underlying services. As such, a façade can act as a simplifying access layer for a project. It can hide functions that are not needed by the project, aggregate services, or add standard parameters. Furthermore, a façade can hide technical complexity and heterogeneity. Façades can also be very useful in a rather unexpected waythey can serve as a single point of coordination between a project's development team and a maintenance team that is responsible for the SOA. Contrary to the project-specific view, a common service access layer provides uniform access to the complete functional infrastructure of the organization. Creating one is a very tempting idea because such a layer could provide easy access to the entire functional infrastructure for all projects. You could also add specific value to this layer, such as support for distributed transactions and the capability to hide their complexity from projects. It also would make the development and deployment of services easier because there would be exactly one unified and mandatory process to make the services available. In particular, some current J2EE-based enterprise architectures tend to employ this type of access layer (see Figure 5-6). Figure 5-6. From the project's point of view, a service access layer is a convenient way to access the functional infrastructure of the organization. However, at the enterprise level, these layers have some severe disadvantages. Due to their monolithic nature, they tend to spoil many of the benefits of an SOA.
In spite of these benefits, the idea of a common service access layer has certain disadvantages. Many similarities exist between service access layers and traditional data access layers. As we have already discussed, a data access layer spans the entire data model of an application. It is very convenient for the development of this particular application, but it results in a monolithic structure that makes reuse or standalone usage of vertical subcomponents difficult. The technology of the data access layer is also a very strong constraint for the development and for service access layers. Though a common service access layer is very well suited to the development of single projects, it also has many unwanted characteristics at the enterprise level. Introducing a binding design rule that leverages a common service access layer will probably lead to exceptions, which will outweigh many of the benefits of the access layer. Eventually, these exceptions will establish an uncontrollable shadow architecture that reflects the necessities of real-world heterogeneities. Because the shadow architecture is "officially forbidden," the architecture team cannot openly discuss many important design decisions. This ultimately leads to solutions that are driven by short-term political feasibility rather than by long-term design goals. A common service access layer impacts both backend and frontend integration. The possible consequences are illustrated in the following example. Assume a large organization has a traditional application landscape based on mainframes, transaction monitors, and COBOL. New applications are required as part of a new J2EE-based strategy. The COBOL application should be reengineered and reused as functional backend services. In this scenario, one generally needs to design vertical slices of previously monolithic mainframe subsystems to create services of reasonable granularity. In practice, the integration of new services becomes a major challenge for the new SOA. As a result of the "common service access layer" design strategy, all aggregations must be performed in the J2EE container at a layer above the service access layer. Although this might look reasonable at first glance, the integration with the Java layer is not acceptable in many cases due to complicated technical designs, maintainability requirements, transaction security issues, development costs, and performance issues. More often, a mainframe-based intermediary service is much more efficient in all these respects. One will also encounter difficulties at the frontend due to different technologies. The enterprise benefits greatly when it can choose the best of breed products from a functional perspective rather than from a technical perspective. For applications based on nonJava-technology such as .NET, the Java layer provides no value. At the same time, it introduces a new element of complexity. While all business logic is implemented in C# and COBOL, the Java layer only passes the calls and parameters from the frontend to the backendthe Java layer adds no value.
5.1.4.4 Functionality-Adding ServicesIn many cases, you want to add functionality to a service without changing the service itself. In this case, you would establish a functionality-adding service that provides the functionality of the original service and adds the required new characteristics. There could be several reasons for such a design. If the original service is a third-party product for which there is no source code available, a functionality-adding service can be extremely helpful. The functionality-adding service can also serve as an evolutionary step. If the original service is currently under construction by a different development team, one can decouple both developments with the functionality-adding service. Consequently, a second step is required to reintegrate both development efforts into one service in order to achieve a clean design. The functionality-adding service could also be the first step for reimplementing the original service. This is a particularly good strategy if the original service is of poor quality, if you need the additional functionality as soon as possible, or if you intend to improve the quality of the original service. In this case, you would create a pure façade in the first step. In the second step, you would add the new functionality. Finally, in the third step, you would reengineer all the functionality of the original service and migrate it in small portions to the functionality-adding service until it implements the entire functionality, and then the original service could be decommissioned. 5.1.5. PROCESS-CENTRIC SERVICESProcess-centric services can encapsulate the knowledge of the organization's business processes. They control and maintain their state. From a technical viewpoint, process-centric services are the most sophisticated class of services. They require careful design and deliberate efforts to achieve an efficient implementation. Similar to intermediary services, a process-centric service acts as a client and server simultaneously. A major difference from intermediary services is the fact that process-centric services are stateful because they must maintain the state of a process for their clients. As with every additional element of an architecture, process-centric services introduce some complexity. However, there are certain benefits:
It is noteworthy that properly designing process-centric services and achieving the aforementioned benefits is not an easy task. Many traditional designs suffer from an inaccurate encapsulation of the process logic. You'll rarely find applications with a clear distinction between business logic and process control, and you'll seldom find a clear distinction between process control and dialog control. Individuals must have much experience to design these layers properly. The same holds for process-centric services. Chapter 7 gives an in-depth discussion on this issue and provides valuable design guidelines. Notice that process-centric services are mostly project-specific. In the airline booking example, the required business logic and data is largely independent of concrete usage. A travel agent requires far more processes than the customer, but both are concerned with the same business entities. Therefore, and despite all obvious benefits, one must bear in mind that process-centric services do not contribute to the functional infrastructure of the SOA due to their marginal reusability. Process-centric services are not mandatory for an SOA. Because it is highly advisable to keep an architecture as simple as possible, you must carefully consider the trade offs when considering implementing process-centric services. Figures 5-7 and 5-8 illustrate two different approaches. In Figure 5-7, the application frontend makes use of a process-centric service. As an alternative to process-centric service, the application frontend can encapsulate the processes in its process control layer (see Figure 5-8). Process-specific objects or subroutines represent the process definition and control the entire workflow that is initiated by the application. Although this approach appears to be very simple, it can be appropriate for many real world cases. Figure 5-7. The application frontend can delegate the entire process control to a process-centric service that executes the process on behalf of the application frontend.
Figure 5-8. In many cases, the application frontend controls the entire process. Process objects or subroutines in the process control layer encapsulate the process definition and invoke the actors of the process.
5.1.6. PUBLIC ENTERPRISE SERVICESWhereas most of the service types described previously are only for use within the boundaries of a particular enterprise, public enterprise services are services that an enterprise offers to partners and customers. For example, a shipping company can offer services that enable large customers to track their shipments as part of their own just-in-time management systems. In another example, a telecom carrier might offer an SMS (Short Messages Service) service, enabling customers to easily add SMS functionality to their systems. Because the consumers of public enterprise services are usually not known in advance and the relationship between consumer and provider is much looser, these services have very specific requirements:
|
|
EAN: 2147483647
Pages: 142