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:
Typical examples of service models implemented as application services include the following:
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).
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:
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:
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
Part I: SOA and Web Services Fundamentals
The Evolution of SOA
Web Services and Primitive SOA
Part II: SOA and WS-* Extensions
Web Services and Contemporary SOA (Part I: Activity Management and Composition)
Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)
Part III: SOA and Service-Orientation
Principles of Service-Orientation
Part IV: Building SOA (Planning and Analysis)
SOA Delivery Strategies
Service-Oriented Analysis (Part I: Introduction)
Service-Oriented Analysis (Part II: Service Modeling)
Part V: Building SOA (Technology and Design)
Service-Oriented Design (Part I: Introduction)
Service-Oriented Design (Part II: SOA Composition Guidelines)
Service-Oriented Design (Part III: Service Design)
Service-Oriented Design (Part IV: Business Process Design)
Fundamental WS-* Extensions
Appendix A. Case Studies: Conclusion