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.
|