Example: Single Operation Service Component Pattern
This is an example of a Single Operation Service Component Pattern that can be used to structure a service component, either as a starting framework or a specific pattern to address particular policy requirements.
Relationships
Main Description

In some cases where services are identified in the Service Model with multiple operations, it is more appropriate to implement the operations individually as stand-alone services separating the logical service and physical service views. Such a pattern has advantages in terms of flexibility of sourcing, high availability, versioning, and evolution but does lose the notion of an interface to a service as a set of related operations.

Modeling service components according to this pattern has a single <<Service Component>> realizing a single interface with a single operation, all named according to common conventions and demonstrated below.

Figure 1.  Realizing the Single Operation Service Component pattern

 

In this case, as we mentioned, there is no direct realization of the original service specification by any one element in the pattern above. Therefore, it seems worthwhile to introduce an element in the model that can provide traceability back to the service specification. In the example below, we have introduced a component, stereotyped <<subsystem>>, that is noted as implementing the service specification and also owning the elements described above.

Figure 2.  Introducing a <<subsystem>> to own all the components that collectively implement the original service specification

 

This pattern also does not introduce the <<facade>> component because consumers of the services are responsible for identifying the services they use.

More Information