Application service layer

The application service layer establishes the ground level foundation that exists to express technology-specific functionality. Services that reside within this layer can be referred to simply as application services (Figure 9.3). Their purpose is to provide reusable functions related to processing data within new or legacy application environments.

Figure 9.3. The application service layer.

Application services commonly have the following characteristics:

• they expose functionality within a specific processing context
• they draw upon available resources within a given platform
• they are solution-agnostic
• they are generic and reusable
• they can be used to achieve point-to-point integration with other application services
• they are often inconsistent in terms of the interface granularity they expose
• they may consist of a mixture of custom-developed services and third-party services that have been purchased or leased

Typical examples of service models implemented as application services include the following:

• utility service (explained in Chapter 5)
• wrapper service (explained shortly)

When a separate business service layer exists (as explained in the Business service layer section), there is a strong motivation to turn all application services into generic utility services. This way they are implemented in a solution-agnostic manner, providing reusable operations that can be composed by business services to fulfill business-centric processing requirements.

Alternatively, if business logic does not reside in a separate layer, application services may be required to implement service models more associated with the business service layer. For example, a single application service also can be classified as a business service if it interacts directly with application logic and contains embedded business rules.

Services that contain both application and business logic can be referred to as hybrid application services or just hybrid services. This service model is commonly found within traditional distributed architectures. It is not a recommended design when building service abstraction layers. Because it is so common, though, it is discussed and referenced throughout this book.

Finally, an application service also can compose other, smaller-grained application services (such as proxy services) into a unit of coarse-grained application logic. Aggregating application services is frequently done to accommodate integration requirements. Application services that exist solely to enable integration between systems often are referred to as application integration services or simply integration services. Integration services often are implemented as controllers.

Because they are common residents of the application service layer, now is a good time to introduce the wrapper service model. Wrapper services most often are utilized for integration purposes. They consist of services that encapsulate ("wrap") some or all parts of a legacy environment to expose legacy functionality to service requestors. The most frequent form of wrapper service is a service adapter provided by legacy vendors. This type of out-of-the-box Web service simply establishes a vendor-defined service interface that expresses an underlying API to legacy logic.

Another variation of the wrapper service model not discussed in this book is the proxy service, also known as an auto-generated WSDL. This simply provides a WSDL definition that mirrors an existing component interface. It establishes an endpoint on the component's behalf, essentially allowing it to participate in SOAP communication. The proxy service should not be confused with a service proxy, which is used by service requestors to contact service providers (as explained in Chapter 18).

Case Study

TLS has a well-defined application services layer. Of the TLS services we've discussed so far in our case study, the following are considered application services:

• Load Balancing Service
• Internal Policy Service
• System Notification Service

Each is a utility service that provides a set of generic, reusable features, and each is capable of acting as a composition member, fulfilling a specific task within a larger unit of automation.

All of the following RailCo services incorporate processing akin to application services:

• Invoice Submission Service
• Order Fulfillment Service
• TLS Subscription Service

Both the Invoice Submission and Order Fulfillment Services are somewhat hybrid, in that each also contains embedded business logic (as described further in the Business service layer example). The TLS Subscription Service can be classified as a pure application service, as it performs a simple, application-centric task. It's questionable whether any RailCo services would be considered utility services because none were designed with any real reusability in mind.

SUMMARY OF KEY POINTS

• The application service layer consists of application services that represent technology-specific logic.
• Typical incarnations of application services are the utility and wrapper models.
• Application services are ideally reusable utility services composed by business services, but also can exist as hybrid services that contain both business and application logic.