Section 5.2. Layers on the Enterprise Level

5.2. Layers on the Enterprise Level

In this chapter, we have already discussed different service types. Now we take a first look at the overall structure of an application landscape and how the services relate to each other.

Traditionally, software layers provide important levels of abstraction. You can assume that layers are sequentially ordered, where layer N is above layer N+1. Code segments within one layer N can use other code segments with the same layer in addition to code segments of the layers N+1. In a distributed environment, the concept of tiers exists, where a tier is a set of contiguous layers that can be deployed separately. Although layers and tiers are extremely useful abstractions for the construction of single applications (or services), neither is suited as an abstraction at the enterprise level. Service-Oriented Architectures provide application frontends and services that are much more suited to this purpose.

SOA layers, which you must not confuse with these traditional software layers, and tiers provide a conceptual structure at the enterprise level that organizes the application frontends and services (see Figure 5-9). Each layer contains distinct types of services and application frontends:

Enterprise layer. The top layer of SOAs contains application frontends and public enterprise services, which are the end-points that provide access to the SOA. These endpoints facilitate both the communication between end users and the SOA (application frontends) and enable cross-enterprise (or cross-business unit) integration (public enterprise services).

Process layer. The process layer contains process-centric servicesthe most advanced service type.

Intermediary layer. The third layer contains intermediary services. These services act as façades, technology gateways, and adapters. You can also use an intermediary service in order to add functionality to an existing service.

Basic layer. The bottom layer contains the basic services of the SOA. Basic services represent the foundation of the SOA by providing the business logic and data. The basic layer also contains proxies for other companies' public enterprise services.

Figure 5-9. No 1:1 relationship exists between traditional tiers and SOA layers. These concepts actually are largely independent.

As we will see in Chapter 6, "The Architectural Roadmap," many problems can be solved with two or three SOA layers. In these cases, there is no benefit to artificially introducing additional layers simply to have a "complete" SOA. Recall that an SOA is about simplification. As long as a problem can be solved with simple measures, it is best to do so.

Although we will not discuss this matter in great detail, we must briefly consider the deployment of SOAs and the resulting system architecture in order to prevent a common misunderstanding: SOA layers do not correspond to physical tiers. It is not necessary for services, which originate from different SOA layers, to be deployed at different tiers. Nor must all services of one SOA layer be deployed at the same location. The system architecture is driven by matters such as available hardware and system software, system management requirements, and compatibility. These issues are largely independent of requirements such as maintainability or simplicity that drive the design of the services.

Actually, the design of the SOA and the system architecture are largely independent aspects of the application landscape, which is the remarkable strength of the SOA paradigm.

Decouple System and Software Architecture

A major benefit of the SOA paradigm is to be able to design the system and the software architecture largely independently of each other. This results in a high level of flexibility regarding the deployment of the SOA. Do not introduce unnecessary technical dependencies and rules for short-term benefits!

SOAs enable a largely independent design of the system and the software architecture. This results in a high level of flexibility regarding the deployment of the SOA. Do not spoil these benefits by introducing technical "short-cuts" and design rules for short-term benefits!

Figure 5-10 shows an example of how a system architecture and SOA layers can relate. It depicts three tiers at the system architecture levelthe Web server, application server, and host. You can see that the SOA layers do not map directly to these tiers.

Figure 5-10. The deployment of an SOA is largely independent of the SOA layers.