Category Archives: Service

C1-S1 Capability to Service Mapping

NAF v3: NSOV-3 MODAF: SOV-3

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 Capability to Service Mapping View (C1-S1) depicts which services contribute to the achievement of a capability.

Background

If network enabled capability is to be delivered by the orchestration of loosely couple services (i.e. a service-oriented architecture), it is important to know which services have the potential to support particular capabilities. An C1-S1 presents a simple mapping of services to capabilities, showing which services contribute to which capability.

Usage

Representation

c1s1-example-1

Detailed View Description

Key Elements and Their Relationships

Meta-Model

The detailed meta-model for C1-S1 can be viewed here

S3 – Service Interfaces

NAF v3: NSOV-2 MODAF: SOV-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 purpose of the S3 is to define the interfaces presented by a service. A service presents one or more interfaces to consumers (a “consumer” being any agent capable of using the service – a person, an organisation, a system or another service). In this case, the architect specifies provided interfaces. A service may also be capable of using interfaces exposed by other services, and the architect may specify these as used interfaces.

Background

Specifying the interfaces that a service provides and uses defines which services are compatible with which other services. If Service A provides an interface, X and Service B can use Interface X then Service B can call upon at least some of the functionality of Service A.

Usage

Representation

Detailed View Description

s3-example-1

Key Elements and Their Relationships

s2-hlmm

Meta-Model

The detailed meta-model for S3 can be viewed here

S4 – Service Functions

NAF v3: NSOV-3 MODAF: SOV-5

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 Functions View (S4) defines the behaviour of a service in terms of the functions it is expected to perform.

Background

S4 is the key behavioural specification for services. Equivalent in nature to L4 (Logical Activities) and R4 (Resource Functions), it specifies a set of functions that a service implementation is expected to perform.

Usage

Representation

Detailed View Description

s4-example-1

Key Elements and Their Relationships

s4-hlmm

Meta-Model

The detailed meta-model for S4 can be viewed here

S5 – Service States

NAF v3: NSOV-4b MODAF: SOV-4b

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 purpose of the Service States View (S5) is to specify the possible states a service may have, and the possible transitions between those states.

Background

It is generally considered good practice to make services stateless – i.e. consumers of a service are not aware of what state the service is in. However, in specifying a service, it is often necessary to specify the allowable states so as to constrain how implementations of the service will behave. S5 is a specification of those states, and the possible transitions between them.

Usage

Representation

Detailed View Description

s5-example-1

Key Elements and Their Relationships

s5-hlmm

Meta-Model

The detailed meta-model for S5 can be viewed here

S6 – Service Interactions

NAF v3: NSOV-4c MODAF: SOV-4c

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 purpose of the Service Interactions View (S6) is to specify how a service interacts with external agents, and the sequence and dependencies of those interactions.

Background

An S6 product does not specify the sequencing of an orchestrated set of services (see L6 – Logical Sequence). Its purpose is to specify the general sequence of interactions that are possible for a given service.

Usage

Representation

Detailed View Description

s6-example-1

Key Elements and Their Relationships

s6-hlmm

Meta-Model

The detailed meta-model for S6 can be viewed here

S7 – Service Interface Parameters

NAF v3: NSOV-2 MODAF: SOV-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 S7 identifies all the parameters used in Service Interfaces (see also S3).

Background

Usage

Representation

Detailed View Description

s7-example-1

Key Elements and Their Relationships

s7-hlmm

Meta-Model

The detailed meta-model for S7 can be viewed here

S8 – Service Policy

NAF v3: NSOV-4a MODAF: SOV-4a

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 purpose of the Service Policy View (S8) is to specify constraints that apply to implementations of services.

Background

To better enable consistency and re-use of service specifications, it is important to set constraints on how a service should behave. An S8 product specifies constraints against services to which implementations of must conform.

Usage

Representation

Detailed View Description

s8-example-1

Key Elements and Their Relationships

s8-hlmm

Meta-Model

The detailed meta-model for S8 can be viewed here

Sr – Service Roadmap

No equivalent NAF 3.1 or MODAF view

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 purpose of Sr is to show versions (and version history with dates) of Service Specifications.

Background

Usage

Representation

Detailed View Description

Key Elements and Their Relationships

sr-hlmm

  • Service Specification
  • Project Milestone
  • Service Level
  • Service Specification Version Succession (relationship)

Meta-Model

The detailed meta-model for Sr can be viewed here

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