Agnostic Sub-Controller

How can agnostic, cross-entity composition logic be separated, reused, and governed independently?

Problem Service compositions are generally configured specific to a parent task, inhibiting reuse potential that may exist within a subset of the composition.
Solution Reusable composition logic is abstracted by an agnostic sub-controller capability, allowing that subset of the composition to be recomposed.
Application A new agnostic service needs to be created or a new sub-controller capability needs to be added to an existing service.	Impacts The addition of the service or sub-controller capability can increase the size and complexity of a composition.
Principles Service Reusability, Service Composability	Architecture Composition, Service

Table 6.1 – Profile summary for the Agnostic Sub-Controller pattern.

Problem

Services are typically assembled into a composition in order to automate a specific business task. This is the reason non-agnostic logic is traditionally isolated within task services that represent the parent business process.

In larger, complex service aggregates there is an increased likelihood that bodies of composition logic may in fact be agnostic and reusable. Even though this may be the case, the composition itself may still be configured for a single purpose, inhibiting the potential to actually reuse the agnostic logic.

Figure 6.1 – A subset of the parent process logic is deemed reusable but is trapped among the other non-agnostic process logic encapsulated by the task service.

Solution

The composition is designed to incorporate nested, agnostic composition logic represented by agnostic sub-controller task services.

Figure 6.2 – The agnostic process logic is physically separated into its own service and capability, allowing it to be reused within other compositions.

Application

As illustrated in Figure 6.x, the aforementioned single-purpose composition is often configured in a two-tier hierarchy, with all of the composition logic residing in the parent task service. Alternatively, the composition can be structured into additional tiers so that the composition is comprised of a parent controller service and one or more nested compositions represented by sub-controller services.

These nested compositions may be necessary to carry out the parent task, but individually they can also provide logic that can be used independently to automate a smaller task or they may have logic that can be used to automate other larger tasks. Either way, they can be structured to represent and abstract agnostic logic for reuse purposes.

Impacts

The introduction of additional sub-controller task services can increase the size and complexity of service compositions and can further add corresponding performance demands.

Furthermore, from a service modeling perspective, it can be argued that an agnostic task service is an oxymoron. If a service does encapsulate agnostic functionality, then there you should be able to identify one or more entity or utility services in which this logic should be located instead. This may be a valid point, but it really comes down to the service design conventions an enterprise is based on and also when this agnostic task service logic is discovered.

Most commonly this design pattern is applied when the task logic in question composes multiple service capabilities so that the logic as a whole does not cleanly fit into any one agnostic service boundary. Instead, it is located into a task service that itself becomes agnostic and therefore reusable.

Relationships

The Agnostic Sub-Controller pattern is applied to service logic that is likely to have previously been non-agnostic, which is why this pattern has relationships with Process Abstraction, Process Centralization, and Agnostic Context patterns.

The Service Façade pattern is often employed to help structure the internal logic of an agnostic sub-controller service, and Contract Centralization is important and relevant to the successful long-term usage of this type of service (as with any service).

Figure 6.3 – The Agnostic Sub-Controller pattern is in the unique position of having relationships with patterns focused on non-agnostic and agnostic logic.

Case Study Example

Case study content is not available on this Web site.