Non-Agnostic Context

How can single-purpose service logic be positioned as an effective enterprise resource?

Problem Non-agnostic logic that is not service-oriented can inhibit the effectiveness of service compositions that utilize agnostic services.
Solution Non-agnostic solution logic suitable for service encapsulation can be located within services that reside as official members of a service inventory.
Application A single-purpose functional service context is defined.	Impacts Although they are not expected to provide reuse potential, non-agnostic services are still subject to the rigor of service-orientation.
Principles Standardized Service Contract, Service Composability	Architecture Service

Table 7.4 – Profile summary for the Non-Agnostic Context pattern.

Problem

When applying service-orientation, there is a great deal of emphasis on abstracting and positioning solution logic that is agnostic to business tasks and parent business processes. This forms the very basis of the Service Reusability principle and associated patterns.

The result is that non-agnostic logic gets filtered out and often relegated to encapsulation within software programs that are not part of the service inventory but instead exist peripherally as dedicated service consumers or composition initiators. In this case, service-orientation is not applied to non-agnostic solution logic. This limits its potential to ever become an effective enterprise resource and, more importantly, it compromises the quality of the service compositions the logic may be responsible for controlling.

Figure 7.16 – The highlighted unit of logic (Unit 5) was deemed suitable for service encapsulation as per the Service Encapsulation pattern, but was not considered agnostic as per the Agnostic Context pattern.

Solution

Suitable non-agnostic solution logic is encapsulated by a service with a correspondingly non-agnostic functional context. This positions the logic as part of a service inventory. A secondary benefit is that, as a service, this logic is further available for any potential unforeseen involvement in service compositions.

Figure 7.17 – The non-agnostic service logic is encapsulated within a service based on a correspondingly non-agnostic service context (E).

Application

Non-agnostic service logic is shaped via the same governing design principles as agnostic services with the exception of Service Reusability, and with a lesser initial emphasis on service contract design.

This pattern is most commonly applied in combination with the Process Abstraction pattern to establish the task service model. However, it is not limited to encapsulating parent business process logic. Other custom, single-purpose service models can be created and based on the non-agnostic functional context established by this pattern.

There are no rules as to whether this pattern should be applied before or after the Agnostic Context pattern. The mainstream service modeling process described at SOAMethodology.com suggests identifying agnostic service candidates prior to non-agnostic candidates so that multi-purpose logic can be filtered out first, but it is really up to your preference and whatever methodology you end up using.

Either way, the end result of completing both the Agnostic Context and Non-Agnostic Context patterns is that all of the solution logic considered suitable for service encapsulation ends up organized into a set of well-defined service contexts (Figure 7.x).

Figure 7.18 – Service contexts A through E established by the Agnostic Context and Non-Agnostic Context patterns essentially establish services as containers for all of the previously identified service logic.

Impacts

Because service-orientation still needs to be applied to the underlying solution logic of a non-agnostic service, its initial delivery will be more expensive and more time consuming (than if it were to simply exist in a program external to the service inventory). The ultimate return on this investment can therefore be significantly lower than with agnostic services.

Relationships

When studying the Non-Agnostic Context pattern it is important to remember that it is being applied subsequent to the Service Encapsulation pattern. Even though the context is specific to one purpose, it is still considered a service.

The types of services that most commonly require the application of the Non-Agnostic Context pattern are those based on task-centric service models. This explains the relationship with the Process Abstraction and Process Centralization patterns, which are associated with the task service and orchestrated task service models respectively.

A key relationship also defined in Figure 7.x is that between Non-Agnostic Context and Capability Composition. The single-purpose nature of the logic encapsulated by services based on non-agnostic contexts is generally associated with composition logic required to automate a business task. Therefore, this pattern fully supports and even enables the Capability Composition pattern.

However, notice the absence of the Capability Recomposition pattern. Even though a non-agnostic service will almost always compose capabilities from agnostic service, its focus is always on one specific task. Therefore, Capability Recomposition is more associated with the Agnostic Context pattern.

Figure 7.19 – The Non-Agnostic Context pattern establishes a service context that is intentionally single-purpose and very much related with patterns that address parent process design issues.

Case Study Example

Case study content is not available on this Web site.