J2EE Design Pattern : Business Tier Patterns : Application Service Design Pattern

• Application Service Design Pattern?
• Example for Application Service

Application Patterns centralizes business logic across several business tier components and services.

Problem

In J2EE applications some business-tier components such as Business Objects and other services are implemented as POJOs, though these objects are local objects, we still want to avoid exposing them directly to the clients because that exposure introduces coupling and dependencies between the clients and these business tier components. And in applications that do not use Business Objects, we still want to encapsulate business logic in the business tier instead of embedding it in facades or clients.

Context

You want to centralize business logic across several business-tier components and services. Business objects exposes an interface by encapsulating cohesive behavior that is specific to a set of related business operations.

Solution

• Application Service provides a central location to implement business logic that encapsulates Business Object and services, it is a one way to reduce coupling among Business Objects. With an Application Service, you encapsulate this higher-level business logic in a separate component that uses the underlying Business Objects and services.
• Application Services provides that intermediary function between the two tiers-business tier components such as Business objects and other services.
• Application Services provides the background infrastructure for service facades. These facades become simpler to implement and contain less code as they delegate the business processing to Application Services.

Participants and Collaborations

Client

Client is a role that is typically fulfilled by a service facade, implemented as a POJO or a Session Façade. The Client can also be another Application Service or a POJO helper object.

ApplicationService

ApplicationService represents the main role in this pattern and encapsulates the business logic required to provide a specific service. It can encapsulate a variety of business logic types, such as common logic acting on several BusinessObjects, use case-specific business logic, or logic specific to a particular kind of client or channel type. An ApplicationService can invoke a business method in a BusinessObject or another ApplicationService. Implementing Application Services as POJOs is more common because it enhances reusability of the control logic across different clients and facilitates easy layering of Application Services.

BusinessObject

BusinessObject represents instances of Business Objects that the ApplicationService can access to perform a service. Typically, an ApplicationService accesses multiple BusinessObjects in order to fulfill a service request.

Service

Service represents an arbitrary component that provides any service in the applications. These can be common functions or utilities that are frequently used to aid the processing of a business-tier service request.

DataAccessObject

DataAccessObject represents instances of Data Access Objects for those scenarios where the ApplicationService directly accesses the business data without using a BusinessObject.

Implementation Strategies

• Application Service Command Strategy
• GoF Strategy for Application Service Strategy
• Application Service Layer Strategy