Service layer abstraction

In our familiar enterprise model, the service interface layer is located between the business process and application layers. This is where service connectivity resides and is therefore the area of our enterprise wherein the characteristics of SOA are most prevalent. To implement the characteristics we just identified in an effective manner, some larger issues need to be addressed.

Specifically, we need to answer the following questions:

• What logic should be represented by services?
• How should services relate to existing application logic?
• How can services best represent business process logic?
• How can services be built and positioned to promote agility?

Typically, these questions are studied and eventually answered during the service-oriented analysis phase, where services are carefully modeled in accordance with and in response to external business and project drivers. Before we delve into specific recommendations on how to succeed at the art of service modeling (as explained in Chapters 11 and 12), let's first provide some preliminary answers to these questions.

9.2.1. Problems solved by layering services

What logic should be represented by services?

In the previous chapter we established that enterprise logic can be divided into two primary domains: business logic and application logic. Services can be modeled to represent either or both types of logic, as long as the principles of service-orientation can be applied.

However, to achieve enterprise-wide loose coupling (the first of our four outstanding SOA characteristics) physically separate layers of services are, in fact, required. When individual collections of services represent corporate business logic and technology-specific application logic, each domain of the enterprise is freed of direct dependencies on the other.

This allows the automated representation of business process logic to evolve independently from the technology-level application logic responsible for its execution. In other words, this establishes a loosely coupled relationship between business and application logic.

How should services relate to existing application logic?

Much of this depends on whether existing legacy application logic needs to be exposed via services or whether new logic is being developed in support of services. Existing systems can impose any number of constraints, limitations, and environmental requirements that need to be taken into consideration during service design.

Applying a service layer on top of legacy application environments may even require that some service-orientation principles be compromised. This is less likely when building solutions from the ground up with service layers in mind, as this affords a level of control with which service-orientation can be directly incorporated into application logic.

Either way, services designed specifically to represent application logic should exist in a separate layer. We'll therefore simply refer to this group of services as belonging to the application service layer.

How can services best represent business logic?

Business logic is defined within an organization's business models and business processes. When modeling services to represent business logic, it is most important to ensure that the service representation of this logic is in alignment with existing business models.

It is also useful to separately categorize services that are designed in this manner. Therefore, we'll refer to services that have been modeled to represent business logic as belonging to the business service layer. By adding a business service layer, we also implement the second of our four SOA characteristics, which is support for service-oriented business modeling.

How can services be built and positioned to promote agility?

The key to building an agile SOA is in minimizing the dependencies each service has within its own processing logic. Services that contain business rules are required to enforce and act upon these rules at runtime. This limits the service's ability to be utilized outside of environments that require these rules. Similarly, controller services that are embedded with the logic required to compose other services can develop dependencies on the composition structure.

Introducing a parent controller layer on top of more specialized service layers would allow us to establish a centralized location for business rules and composition logic related to the sequence in which services are executed. Orchestration is designed specifically for this purpose. It introduces the concept of a process service, capable of composing other services to complete a business process according to predefined workflow logic. Process services establish what we refer to as the orchestration service layer.

While the addition of an orchestration service layer significantly increases organizational agility (number three on our list of SOA characteristics), it is not alone in realizing this quality. All forms of organized service abstraction contribute to establishing an agile enterprise, which means that the creation of separate application, business, and orchestration layers collectively fulfill this characteristic.

Abstraction is the key

Though we addressed each of the preceding questions individually, the one common element to all of the answers also happens to be the last of our four outstanding SOA characteristics: layers of abstraction.

We have established how, by leveraging the concept of composition, we can build specialized layers of services. Each layer can abstract a specific aspect of our solution, addressing one of the issues we identified. This alleviates us from having to build services that accommodate business, application, and agility considerations all at once.

The three layers of abstraction we identified for SOA are:

• the application service layer
• the business service layer
• the orchestration service layer

Each of these layers (also shown in Figure 9.2) is introduced individually in the following sections.

Figure 9.2. The three primary service layers.

Note

The next three sections reference service models established in previous chapters and also introduce several new service models. Appendix B provides a reference table for all service models covered in this book, including information as to where individual models are discussed.