Service Encapsulation

How can solution logic be made available as an enterprise resource?

Problem Solution logic designed for a single application environment is typically limited in its potential to interact with or be leveraged by other parts of an enterprise.
Solution Solution logic can be encapsulated by a service so that it is positioned as an enterprise resource capable of functioning beyond the boundary for which it is initially delivered.
Application Solution logic suitable for service encapsulation needs to be identified.	Impacts Service-encapsulated solution logic is subject to additional design and governance considerations that can increase cost and effort of its delivery.
Principles n/a	Architecture Service

Table 7.2 – Profile summary for the Service Encapsulation pattern.

Figure 7.7 – A subset of the decomposed monolithic solution logic is identified as being suitable for service encapsulation (as represented by the highlighted blocks).

Problem

A collection of related solution logic units that represent a larger, decomposed body of solution logic can continue to exist within a siloed application boundary. In fact, many past distributed systems were built this way. The decision to partition the solution logic into smaller software programs was often motivated by the following considerations:

•     increasing scalability by separating the parts of the system more subject to high volume and concurrency

•     improving security by isolating specific parts of the system with special access and privacy requirements

•     increasing reliability by distributing critical parts of a system across multiple physical servers

•     achieving nominal reuse within the system boundary (or within a limited part of the enterprise)

Figure 7.8 – An enterprise comprised of distributed, yet still siloed solutions.

An enterprise comprised of siloed (or quasi-siloed) distributed solutions has historically encountered many design and governance challenges, such as:

•     significant amounts of waste and redundancy

•     inefficient application delivery

•     bloated, oversized technical environments

•     complex infrastructure and convoluted enterprise architecture

•     complex and expensive integration

•     ever-increasing IT operational costs

Details regarding these issues are documented in the Life Before Service-Orientation section of SOA: Principles of Service Design and also at SOAPrinciples.com.

Solution

Solution logic suitable for classification as an enterprise resource can be encapsulated by and exposed via a service. This essentially means that the logic itself may form the basis for a new service – or – the logic may be encapsulated by an existing service (most likely as a new capability).

Figure 7.9 – An enterprise wherein individual solutions use logic encapsulated as services and vice versa.

Application

The first required step is to identify and filter out solution logic that is actually suitable as an enterprise resource. Not all solution logic falls into this category. There will be bodies of logic that are tailored for individual distributed applications and for which other design approaches may be more appropriate.

Below are some guidelines:

•     Does the logic contain functionality that is useful to parts of the enterprise outside of the immediate application boundary?

If it does, the logic has increased value potential that may warrant its classification as an enterprise resource. This type of logic generally forms the basis for an agnostic service, as per the Agnostic Context pattern.

•     Does logic designed to leverage enterprise resources also have the potential to become an enterprise resource?

This form of logic emerges after evident agnostic logic is initially separated. It may be required for service-orientation to be applied to this type of logic so that it remains uniform with agnostic services – and – so that some or all of its functionality can also be positioned as an enterprise resource. This option is further explored in the Non-Agnostic Context pattern description.

•     Does the implementation of the logic impose hard constraints that make it impractical or impossible to position the logic as an effective enterprise resource?

Regardless of whether the nature of the logic makes it suitable as an enterprise resource, there may be real world limitations that prevent it from being effectively encapsulated by a service.

For encapsulated solution logic to become an effective member of a service inventory it needs to be further shaped by other patterns and principles so that it is designed to support the strategic goals associated with service-oriented computing.

A solid knowledge of the service-orientation design paradigm is often necessary in order to best determine when a solution is and is not suitable for service encapsulation. As a rule of thumb, if service-orientation design principles cannot be applied to a meaningful extent, the logic will not likely warrant service encapsulation.

As previously stated, how this logic is determined is based on the methodology being used and the maturity of the existing service inventory. Logic identified as being suitable for service encapsulation may be assigned to an existing service or it may form the basis of a new service.

Impacts

Because the application of this pattern results in the identification and filtering of logic (in preparation for other patterns), there is no immediate impact.

Relationships

Logic deemed suitable for service encapsulation is subsequently grouped into single or multi-purpose services, as per the Non-Agnostic Context and Agnostic Context patterns.

Figure 7.10 – The Service Encapsulation pattern determines what logic will eventually comprise services. 

Case Study Example

Case study content is not available on this Web site.