Service-Orientated Views (SOV)

SOV-1 Service Taxonomy v1.2

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

NAF V3 Equivalency

The equivalent NAF v3 view to SOV-1 is NSOV-1

Background:

The purpose of an SOV-1 is to provide a governance structure for a Service-Oriented Architecture. Along with SOV-2, it specifies a standard library of Service specifications for an enterprise, which Service implementers are expected to conform to.

Usage:

Data objects:

The data in an SOV-1 can include:


Relationships Between Key Data Objects (Simplified from M3)

Representation:

Detailed Product Description:

An SOV-1 depicts Services, specialisation relationships between Services, Service Attributes and Service Policy (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 MODAF terms, a Service is an implementation-independent specification of a packaged element of functionality. In SOV-1, services are only defined in the abstract i.e. SOV-1 does not specify how a service is to be implemented. An SOV-1 is structured as a specialization hierarchy of services, with the most general at the root and most specific at the leaves.

Like AV-2, SOV-1 is related to MODAF Ontology.

In contrast to AV-2, an SOV-1 is structured using only one type of specialisation relationship between elements: sub-supertype. A sub-supertype relationship is a relationship between two classes with the second being a pure specialisation of the first. 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 (it may add functionality and interfaces, however). 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.


Example of a Specialisation Relationship

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 is based on an early NATO Service taxonomy and 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


Sample Service Hierarchy

UML is a good modelling language in which to develop service taxonomies as the object oriented approach naturally includes the concept of generalisation-specialisation.


UML Sample Service Hierarchy

Page version 1.2, dated 20th June 2008

Top of Page