S1 – Service Taxonomy

NAF v3: NSOV-1/NAV-2 MODAF: SOV-1/AV-2

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
C1-S1 (NSOV-3)
Service
Specifications
S1
Service Taxonomy
NAV-2, NSOV-1
AV-2, SOV-1
S3
Service Interfaces
NSOV-2
SOV-2
S4
Service Functions
NSOV-3
SOV-5
S5
Service States
NSOV-4b
SOV-4b
S6
Service Interactions
NSOV-4c
SOV-4c
S7
Service I/F Parameters
NSOV-2
SOV-2
S8
Service Policy
NSOV-4a
SOV-4a
Sr
Service Roadmap

The Service Taxonomy View (S1) 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.

Background

The purpose of an S1 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, which service implementers are expected to conform to.

Usage

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

An S1 depicts services, specialisation relationships between services, service attributes and service policy (i.e. constraints). A service taxonomy persists over time (an architect may wish to specify historical, current or future services) 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.

An S1 is structured 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.

s1-example-1

Services may have attributes and constraints (service policy) defined against them. Attributes are inherited by specialised services. Where an attribute is specified for a service, implementations of that service shall specify their values for the attribute. The example below shows an availability attribute defined against the top service. All other services inherit that attribute, and the WarfightingService 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 services.

s1-example-2

Key Elements and Their Relationships

s1-hlmm

  • Service Specification (was <<Service>> in NAF 3.1)
  • Service Generalisation (super-subtype relationship between Service Specifications)
  • Measure Category
  • Measure

Meta-Model

The detailed meta-model for S1 can be viewed here

Leave a Reply