S1 – Service Taxonomy
The S1 Service Taxonomy View specifies a hierarchy of services. The elements in the hierarchy are service specifications (rather than service implementations) and the relationships between the elements are specialisations – i.e. one service is a special type of another.
Concerns Addressed
- Cataloguing Service Specifications.
- Defining attributes used to measure Service Levels.
- Specialisation of Service Specifications.
Background
The purpose of the S1 View is to provide a governance structure for a Service- Oriented Architecture. Along with S3, Service Interfaces, it specifies a standard library of service specifications for an enterprise, to which service implementers are expected to conform.
Usage
- Service-oriented architecture governance.
- Identification of services.
- Service planning.
- Service audit.
- Service gap analysis.
- Providing reference services for architectures.
- Tailoring generic services for specific applications.
Representation
- Tabulation.
- Hierarchical (connected shapes).
- UML class diagram.
Detailed View Description
In NAF terms, a Service is an implementation-independent specification of a packaged element of functionality and/or capability. There is potential for confusion between services and capabilities. The key indicator of a service is that it provides a standard interface to consumers. This means that services may be used as “wrappers” for one or more capability in order to provide a standard method of access to the capability. A well-designed service taxonomy provides a set of specifications for capability providers to adhere to when exposing their capabilities as services.
An S1 depicts service specifications, specialisation relationships between service specifications, service attributes and service policy (i.e. constraints). A service taxonomy persists over time (an architect may wish to specify historical, current or future service specifications) and may be referenced by multiple architectures.
In S1, services are only defined in the abstract, i.e. S1 does not specify how a service is to be implemented. An S1 is structured as a specialisation hierarchy of services, with the most general at the root and most specific at the leaves, using only specialisation relationships between elements (super-subtype). Any service that specialises from another must implement all the functionality of its parent, and provide all the same input and output interfaces of its parent; in other words, any specialised service shall be entirely compatible with its parent (however, it may add functionality and interfaces). For example, if a service, “Printing”, requires input of paper size and ink colours, a service, “Hi-Resolution Printing” that specialises from it must also accept these parameters and produce equivalent behaviour when initiated – see Figure 3-16.
Figure 3-16
Service specifications may have attributes and constraints (service policy) defined against them. Attributes are inherited by specialised service specifications. Where an attribute is specified for a service specification, implementations of that service are to specify their values for the attribute. The example in Figure 3-17 shows an availability attribute defined against the top service specification. All other service specifications inherit that attribute, and the Warfighting Service sets a constraint (service policy) that the availability shall be greater than 95%. This policy is then inherited by the three situational awareness services. Note that policy may be overridden in specialised service specifications.
Figure 3-17:
Figure
Key Elements and Their Relationships
Figure
Meta-Model
The detailed meta-model and element list for S1, Service Taxonomy, is at paragraph 4.3.2.