Section 6.3. Networked SOA

6.3. Networked SOA

The next expansion stage is called networked SOA, and it deals with backend complexity in addition to technical and conceptual integration. It includes a layer of intermediary services that can include façades, technology gateways, adapters, and functionality adding services.

We start our discussion with façades. As we discussed in Chapter 5, "Services as Building Blocks," façades can serve various needs. Most importantly, they encapsulate some of the complexity of underlying basic services by providing an aggregated API that enables clients to more easily utilize the functionality of the basic layer. In Chapter 8, "Process Integrity," we will discuss one aspect of this complexitythe challenges of achieving process consistency. Introducing a façade is one possible solution to this issue. Figure 6-6 provides an example of the booking and the billing services that must update their databases in a coordinated manner. Depending on the detailed requirements and the concrete technology upon which the booking and the billing services are built, it is not always simple to guarantee consistency. Actually, you will want to shield client developers from this kind of complexity. It is often necessary to apply particular skills in server-side development to master the challenges of the design and implementation tasks. Moreover, if multiple clients require similar functionality, there should be no duplication of workload. Thus, in our example, this complexity is encapsulated by the intermediary service "BookAndBill."

Figure 6-6. The intermediary service BookAndBill encapsulates the handling of distributed transactions that span the services Booking and Billing.

Utilizing technology gateways is a handy technique to enable one service to be used in different technical environments.^[3] In Figure 6-7, we describe a scenario in which the flight service that is implemented on CICS is exposed to EJB, .NET, and MQSeries environments by technology gateways. This enables developers to specify, design, develop, test, operate, and maintain exactly one instance of the flight service, including live data, and reuse it in many heterogeneous environments at the same time.

^[3] Note that from a purely technical point of view, there is no difference between a technology gateway and an additional interface to the underlying basic service. Thus, it is possible to add some Java classes to an existing PL/I based service in order to provide an additional interfacing technology. The communication between the Java code and the PL/I code would become an internal matter of the service. The main difference between these two approaches is at the project management and team organization level. Most often, it is advisable to separate these technically different artifacts. In practice, you will find different subteams working on the different areas anyway. Separating their work by means of a service contract, configuration management, and distinct entries in the service repository is generally preferable. The same discussion applies to the adapters discussed in the following paragraphs.

Figure 6-7. Technology gateways expose the functionality of services in technologically different environments.

The perfect world does not need technology gateways. In the first place, you would not encounter heterogeneous technologies. Secondly, given that the clients are heterogeneous in the real world, you would choose a single uniform bridging technology to integrate all clients. In our example, you might want to implement a type of XML RPC interface directly as part of the CICS-based service and use this interface in all client environments. Unfortunately, the ongoing evolution of technology can raise many unforeseen issues and new requirements. You might want to adopt current improvements without reimplementing existing services. Furthermore, you cannot predict which technologies you will need to integrate in the future. It is also unclear which political or commercial constraints will have an impact on a technology decision at a specific point in time. As a matter of fact, the SOA paradigm enables the creation of clear designs that cope with this kind of heterogeneity. Although it is not desirable to have multiple technology gateways that provide access to the same service, these technology gateways do no real harm to the architecture.

Figure 6-8 depicts a typical chronology. It shows the major milestones of a check-in application after its launch in 1986. The first milestone was the integration with partner airlines. Besides other requirements, the partner airlines needed access to flight data. This integration was accomplished by extending the dialog control layer that previously supported only the 3270 presentation. After integration with the partner airline, the dialog control layer also had to communicate with message queues that integrate the partner airlines. The integration code between the dialog control and the message queues simulated terminal sessions. This resulted in the fact that every change in the control flow of the applicationsuch as new masksrequired a change in the integration code. Although this dependency reduced agility, it was still acceptable. The next milestone was the launch of an online portal. This was implemented in Java and also required access to flight data. The integration with the existing message queues seemed to be the easiest and cheapest solution. However, this decision was rather short-sighted because any change in one system had a potential impact on other systems, and maintenance became a nightmare. It was at this point that a new requirement was specified. A graphical user interface was needed to replace the 3270 representation. Because this GUI required a completely new dialog control, the new project turned out to be infeasible. Driven by the requirement to implement a modern user interface, an SOA was put in place. Based on the SOA and technology gateways, the GUI became feasible and the maintainence costs could be significantly reduced. Finally, it provided the base for future developments such as mobile integration.

Figure 6-8. The typical lifecycle of an enterprise application traverses different development stages.

Adapters are useful in integration scenarios. They bridge conceptual gaps between a service and its clients. In the simplest case, an adapter maps signatures and transforms parameters. You must not underestimate the importance of such adoptions. As a matter of fact, much of the complexity of enterprise architectures results from small differences in how similar entities are handled in different parts of the architecture. Although many of these differences do not result from logical considerations, they are constraints that you must accept in real-world projects. For example, the booking application can regard any person that has registered at the Web site as a customer, whereas CRM might require that a person have purchased at least one ticket in the last three years in order to be considered a customer.

Figure 6-9 depicts three different scenarios in which you can operate a booking and CRM application in parallel. The first scenario represents the traditional architecture. Two distinct applications are integrated through nightly batch runs. As a result, two separate databases contain redundant data that is synchronized overnight. The second scenario is service-enabled. Although this might already have several benefits, two separate databases are still involved, along with the associated issues. The final scenario abolishes one redundant database. The CRM application utilizes the Customer service of the Booking application using an adapter. This is the scenario of choice because it provides the simplest structure, abolishes batches, enables live data sharing, reduces maintenance costs, and guarantees data consistency.

Figure 6-9. Adapters bridge conceptual gaps between services and their clients, and they map signatures and adopt semantics. Adapters are a very powerful tool for enabling application integration according to the SOA paradigm.

There are various situations in which functionality-adding services can be very useful. Let's consider three different examples (see Figure 6-10). In the first example, a new client uses an existing legacy application. It is a common requirement that the legacy application remain untouched while the functionality is expanded. In our example, an additional service maintains add-itional attributes for data entities stored by the legacy application. Similar to database views, the data of both sources is transparently joined by a functionality-adding service in the intermediary layer. From the client's perspective, a single service delivers all the data. The second example involves a packaged application. Because you typically have no source code available, any changes or enhancements to existing functionality must be done by the vendor of this package or by an intermediary service. The third example uses a traditional client/server application. This application has a client that requires a specific communication protocol to be functional, which suspends the possibility of simply changing the existing server application. If a new client requires additional functionality, you either must modify the existing client or add this functionality with an appropriate service in the intermediary layer.

Figure 6-10. Three different examples for the usage of functionality-adding services in the intermediary layer.

The introduction of a networked SOA represents the second step toward the evolution of an SOA-enabled enterprise. The following summarizes the main characteristics and scope of a networked SOA:

• Application frontends can be more lightweight when compared to a fundamental SOA. However, they remain complex because they must cope with the business processes.

• Intermediary services bridge technical and conceptual gaps.

• The application frontends are shielded from the complexity of backend systems.

• A networked SOA enables the enterprise to flexibly integrate its software assets independently of underlying technology.