Service layer configuration scenarios

So far we've established a relatively clean service layer model for SOA, in which logic is clearly abstracted through three distinct layers that establish a well-defined composition hierarchy. Unfortunately, real SOAs rarely resemble this state.

Many variations can exist, as the various types of services we've discussed so far can be combined to create different SOA configurations. We provide here some sample configuration scenarios and briefly discuss the characteristics of each.

Just to recap, we will explore scenarios based on the use of the following types of services:

• hybrid application services (services containing both business process and application logic)
• utility application services (services containing reusable application logic)
• task-centric business services (services containing business process logic)
• entity-centric business services (services containing entity business logic)
• process services (services representing the orchestration service layer)

Note

In this section we qualify application services with the terms "hybrid" and "utility." However, in future chapters, utility application services simply are referred to as application services.

9.7.1. Scenario #1: Hybrid application services only

When Web services simply are appended to existing distributed application environments, or when a Web services-based solution is built without any emphasis on reuse or service-oriented business modeling, the resulting architecture tends to consist of a set of hybrid application services (Figure 9.7).

Figure 9.7. Hybrid services encapsulating both business and application logic.

9.7.2. Scenario #2: Hybrid and utility application services

A variation of the previous configuration establishes a Web services-based architecture consisting of hybrid services and reusable application services. In this case, the hybrid services may compose some of the reusable application services. This configuration achieves an extent of abstraction, as the utility services establish a solution-agnostic application layer (Figure 9.8).

Figure 9.8. Hybrid services composing available utility application services.

9.7.3. Scenario #3: Task-centric business services and utility application services

This approach results in a more coordinated level of abstraction, given that business process logic is entirely represented by a layer of task-centric business services. These services rely on a layer of application services for the execution of all their business logic (Figure 9.9).

Figure 9.9. Task-centric business services and utility application services cleanly abstracting business and application logic.

9.7.4. Scenario #4: Task-centric business services, entity-centric business services, and utility application services

Here we've added a further layer of abstraction through the introduction of entity-centric business services. This positions task-centric services as parent controllers that may compose both entity-centric and application services to carry out business process logic (Figure 9.10).

Figure 9.10. Two types of business services composing application services.

9.7.5. Scenario #5: Process services, hybrid application services, and utility application services

In this scenario, a parent process service composes available hybrid and application services to automate a business process. This is a common configuration when adding an orchestration layer over the top of an older distributed computing architecture that uses Web services (Figure 9.11).

Figure 9.11. An orchestration layer providing a process service that composes different types of application services.

Note that although the hybrid service is being composed by the process service in Figure 9.11, the hybrid service still contains embedded business logic and therefore indirectly represents some of the business logic layer. Note also that the orchestration layer also may compose utility application services directly.

9.7.6. Scenario #6: Process services, task-centric business services, and utility application services

Even though task-centric services also contain business process logic, a parent process service can still be positioned to compose both task-centric and utility application services. Though only partial abstraction is achieved via task-centric services, when combined with the centralized business process logic represented by the process services, business logic as a whole is still abstracted (Figure 9.12).

Figure 9.12. A process service composing task-centric and utility application services.

9.7.7. Scenario #7: Process services, task-centric business services, entity-centric business services, and utility application services

This variation also introduces entity-centric business services, which can result in a configuration that actually consists of four service layers. Sub-processes can be composed by strategically positioned task-centric services, whereas the parent process is managed by the process service, which composes both task-centric and entity-centric services (Figure 9.13).

Figure 9.13. Process and business services composing utility application services.

9.7.8. Scenario #8: Process services, entity-centric business services, and utility application services

This SOA model establishes a clean separation of business and application logic, while maximizing reuse through the utilization of solution and business process-agnostic service layers. The process service contains all business process-specific logic and executes this logic through the involvement of available entity-centric business services, which, in turn, compose utility application logic to carry out the required tasks (Figure 9.14).

Figure 9.14. A process service composing entity-centric services, which compose utility application services.