Nato Architecture Framework (NAF) - 3.4 - NATO Service-Oriented View
Jump to navigation
Jump to search
NSOV, NATO Service-Oriented View
What is a service?。
- A service is: a well defined way to provide a unit of work through which a provider provides a useful result to a consumer
- A web service is one way of implementing services
- A web service is a piece of software capable of processing XML documents, and which provides operational functionality to users or other applications through the internet
- The 'useful result' may be 'real world effects' or 'information'.
- In essence, a service is a set of strictly delineated functionality, restricted to answering the what-question, independent of construction or implementation issues
- Consequently, services can be interpreted as a requirements model
- In addition, services also must define quality requirements (non-functional requirements)
- A service‘s responsibilities should ideally be mutually exclusive and highly cohesive
- Services are independent and self-contained (no service 'wiring' at the conceptual level)
What is a service?。
- In contrast, the implementations of services may be wired
- Services at the implementation level must be loosely coupled
- Services form a layer, decoupling operational processes and activities from organisational arrangements of resources, such as people and information systems
- Services abstract from distribution, interoperability and implementation issues in the system-layer; while also abstracting from the current, incidental, and ad-hoc arrangement of operational activities and organisational resources
- Services that can be orchestrated in support of operational processes
- These orchestrations may be reconfigured in an ad-hoc arrangement to suit new or changed operational needs
- The above described inherent qualities of a service make services particularly well suited to design an information system:
- that is more adaptive towards the operational domain‘s new and continuously changing operational requirements
- that consists, at the implementation level, of systems less likely to be stovepipes and more likely to be interoperable with other systems
- that abstracts from interoperability issues at the system level, since NATO and its member Nations, in striving to follow the NNEC-paradigm, typically operate dispersed and heterogeneous systems requiring seamless interoperability
NSOV-1, Service Taxonomy。
The purpose of the Service Taxonomy subview is to organise knowledge according to the service perspective, and to facilitate harmonization of services across multiple domains (or across multiple architectures).
Example
NSOV-1, Service Taxonomy。
Definition
- The general purpose is to organise one‘s knowledge of something into categories of similar things, in order to understand something better through comparison with other similar things
- In the Service-Oriented View, the service taxonomy represents the operational domain‘s knowledge, as described in the Operational View, in terms of services, structured in some useful way
- For the taxonomy to be efficient and useful, it needs to classify services according to some classification criterion
- This criterion should reflect the purpose of the taxonomy itself
- For example, if the purpose is to reduce design complexity, then services could be classified according to architecture aspects, views, perspectives or levels of abstraction, if these are the mechanisms used to reduce complexity (e.g. distinguishing application services from infrastructure services)
- If the purpose is to support programme management, then services could be classified according to organisational aspects (e.g. distinguishing functional services from core services)
- Criteria of purpose may also be combined (e.g. resulting in, using the previous two examples, functional application services and core infrastructure services)
- The NNEC Service Framework is a good example of a service taxonomy
NSOV-1, Service Taxonomy。
Definition
- The NNEC Service Framework is a taxonomy of NNEC services that classifies NNEC services according to NNEC C4ISR objectives
- This particular taxonomy is structured according to NNEC service areas, NNEC service groups and NNEC service categories, consecutively
NSOV-1, Service Taxonomy。
Development Guidance
- A taxonomy can be represented by a hierarchy, a tree, a network, or even a loose set of groups (such as an alphabetical listing)
- In the case of a hierarchy, generalization-specialization (inheritance) relations are included
- For the Service-Oriented View a loose group structure or an inheritance hierarchy seems most applicable
Running Example
NSOV-1, Service Taxonomy。
Supporting NNEC Architecture Elements
- Service (Operational, Information and Application service)
Nato_Architecture_Framework_(NAF)_-_4.5_-_NATO_Meta_Model_-_NSOV#NSOV-1_Service_taxonomy
NSOV-2, Service Definitions。
The purpose of the Service Definitions subview is to strictly delineate and define services in order to understand the operational domain in terms of services supporting operational activities.
Example
NSOV-2, Service Definitions。
Definition
A definition of a service is broken apart into distinct segments:
- service outcome: defining the intended real world effects or information provided by the service
- service identification:
- identifying and uniquely naming a service
- describing the set of functionality offered
- describing responsibilities
- identifying the service‘s consumers and the information consumed and provided
- service properties: identifying specific properties of a service that may differ from one instance or implementation of a service to another. This includes quality of service properties, such as performance, security, availability, reliability, maintainability, latency, confidentiality, and integrity.
- service interfaces: specifying the interfaces through which the service consumer may exchange information with this service
- service policies: specifying the policies regarding security, commercial conditions, applicable laws, etcetera, under which the service is provided.
The services in this subview are referenced in the NCV-7 and NSV-12 products.
NSOV-2, Service Definitions。
Development Guidance
- The NSOV-2 product is a list of service definitions
- Services seem best defined using natural text, preferably in a standard way through the use of a standard service definition template
- If more rigour is required, a formal language may be used, especially when specifying interfaces
- Preferably describe services in terms of elements captured in other subviews, such as NOV-4 (users/ service consumers), NOV-7 (information objects), and NOV-3 (constraints on information exchanges)
- Verify service definitions by checking whether information needlines (NOV-2), information exchanges (NOV-3), and operational activities (NOV-5) are adequately supported
- The NSOV-2 subview is also suited to include the NNEC-concept of a Service Interoperability Point (SIOP)
- A SIOP is a logical or physical reference point within an architecture where one or more key interfaces for international interoperability are physically or logically instantiated
- Within NSOV-2 a SIOP can be depicted as a higher-level service interface
- The detailed technical specification of a SIOP is contained within a Service Interoperability Profile (SIP)
- SIPs are addressed in NTV-1 Technical Standards Profile
NSOV-2, Service Definitions。
Supporting NNEC Architecture Elements
- Actor
- Information
- Information requirement
- User
- Service (Operational, Information and Application service)
Nato_Architecture_Framework_(NAF)_-_4.5_-_NATO_Meta_Model_-_NSOV#NSOV-2_Service_definitions
Exercise - Defining simple services。
- Design a service called CurrentTimeService with operation getCurrentTime
- (optional) design Escrow service
- getCurrentTime
NSOV-3, Services to Operational Activities Mapping。
The purpose of the Services to Operational Activities Mapping subview is to provide traceability by illustrating which services support which operational activities.
Definition
- The NSOV-3 subview shows which operational activities are supported by which services through the use of a mapping matrix
- This subview is similar to other mapping matrices in the NAF v3. Refer to NCV-5 (Capabilities x System Deployments), NCV-6 (Capabilities x Operational Activities), NCV-7 (Capabilities x Services), NSV-5 (System functions x Operational activities), and NSV-12 (Systems x Services)
- Together, with these mapping subviews, NSOV-3 forms a line of reasoning that interrelates capabilities, operational activities, services and systems, through the use of traceability links
NSOV-3, Services to Operational Activities Mapping。
Development Guidance
- NSOV-3 forms the traceability link between the Operational View and the Service-Oriented View
- Consequently, the matrix must contain all Operational activities defined in NOV-5, cross linked with all services as defined in NSOV-2
- Verify the mapping by checking whether there are services that do not support any operational activities
- Not every service is utilized in direct support of an operational activity. E.g. an infrastructure service typically is utilized to support the maintenance and operation of one or more functional services, rather than directly supporting operational activities
- By contrast, it depends on the type of operational activity, whether it must or should be supported by a service
- Not every operational activity must necessarily be supported by a service
Supporting NNEC Architecture Elements
- Process
- Service (Operational, Information and Application service)
NSOV-3, Services to Operational Activities Mapping。
Running Example
NSOV-4, Service Orchestration。
The purpose of the Service Orchestration subview is to identify and describe how services in general, and web services in particular, are utilized in the execution of operational activities, and how services are used, in conjunction, to support operational processes.
- NSOV-4 Example
Example of a simple service orchestration at conceptual level.
NSOV-4, Service Orchestration。
- NSOV-4 Example
Example of a web services orchestration, taken from Chris Peltz, Hewlett-Packard Company, ‘Web Services Orchestration and Choreography’, published by IEEE Computer Society in Computer magazine, 2003. In this example the ‘Buyer’ represents the service consumer, whereas the ‘Agent’ and the suppliers denote service providers.
NSOV-4, Service Orchestration。
Definition
- A service orchestration, in general, is a set of services, used in conjunction, capable of satisfying certain operational objectives that cannot be achieved by any of the services alone
- At the construction level, a web service orchestration is the set of interactions between web services at message level
- Depending on purpose, it may not be enough to only determine which web services are used
- It may also be necessary to resolve timing issues, semantic misunderstandings, and quality of service discrepancies, which may appear at the construction level when web services interact
- On a construction level the orchestration of web services, requires the various composing systems to collaborate in a controlled (orchestrated) manner
NSOV-4, Service Orchestration。
Definition
- Orchestration is commonly controlled from the perspective of one of the parties involved
- The orchestration then essentially creates an operational process internal to that party, through the utilization of services
- When orchestration is elaborated across organisation boundaries, involving multiple parties, control becomes more dispersed across the participating parties and focus shifts more to the consumer and the transaction that this consumer wants to execute
- In that case, the term service choreography is used
- Orchestration is controlled by utilizing some form of scripting, e.g. using some formal language
- Scripting can benefit from the power of a formal or programmatic language, e.g. addressing sequential, conditional and parallel execution of services in general, or web services specifically, among many other flow controls
- Orchestration leads to the emergence of higher order services, where the combined use of services serves to deliver a higher order functionality or effect
- In the case of web services this creates a composite web service
NSOV-4, Service Orchestration。
Development Guidance
- Approaches to model service orchestration are currently focused on web services
- The two primary approaches are:
- Web Services Definition Language (WSDL) in combination with Business Process Execution Language for Web Services (BPEL4WS)
- Semantic Webs, using ontologies in combination with goal inference engines (e.g. DAML-S in combination with Golog)
- Both approaches allow web service orchestration.
- Web service orchestration can be modelled graphically using a sort of 'service flow diagrams', similar to the diagramming techniques used in NOV-5 and NOV-6, but utilizing web services instead of, or in addition to operational activities
- This includes typical behaviour type diagrams, such as IDEF0 and UML 2.0 sequence and activity diagrams
- A diagramming technique similar to process flow diagrams seems appropriate, but it might be necessary to employ state machines, event-trace diagrams or Petri nets
- Note that web services orchestration can also be modelled in NSV if the focus is on the component collaborations that construct the web service
- At a conceptual level, orchestration of services (i.e. operational services) does not address interactions between services, but only between service and service consumer
- Orchestration at this level focuses on the combined use of services, by service consumers, in support of the execution of operational activities and processes
- A very powerful representation for such an orchestration can be attained by combining NOV-5 (and/or NOV-6 diagrams) with services (such as defined in NSOV-2) to show where these services are used in the various steps that make up operational processes.
NSOV-4, Service Orchestration。
Supporting NNEC Architecture Elements
- Actor
- Process
- Service (Operational, Information and Application service)
- Component
- Component collaboration
Nato_Architecture_Framework_(NAF)_-_4.5_-_NATO_Meta_Model_-_NSOV#NSOV-3_Service_orchestration
NSOV-5, Service Behaviour。
The purpose of the Service Behaviour subview is to specify the function and behaviour of individual services.
Definition
- Behavioural views under NSOV-5 include detailed activity models as well as state charts and sequence diagrams to model the sequencing and timing of interactions between services
- The products of this subview are similar to the behavioural subviews of NOV-6 Operational Activity Sequence * Timing Description, and NSV-10 Systems Rules, Sequence & Timing Description
- The approach taken in NOV-6 and NSV-10 is applied to the NSOV-5 subview to offer a behavioural view on the concept of services
NSOV-5, Service Behaviour。
Development Guidance
- Guidance to the development of an NSOV-5 Service Behaviour subview is given in the form of an example
- The example in this section builds on the example of the NSOV-4 Service Orchestration subview presented in the previous section.
- In this example the way that three web services shown in the example NSOV-4 view must interact with each other is indicated through a sequence diagram
NSOV-5, Service Behaviour。
Development Guidance
- The Target Image 'message' connecting the TargetTracking service to the ImageAnalysis service represents a match between one of the outward interfaces for TargetTracking and one of the inward interfaces for ImageAnalysis.
- The management of the orchestration between these three web services (to actually enable the support to the operational activities indicated in the NSOV-4 example) needs to be aware of these behavioural characteristics
- Run time governance of the service orchestration is needed to ensure that services can legitimately and safely be combined
NSOV-5, Service Behaviour。
Development Guidance
Figure 4-22, Example of a diagram depicting the relationship between services and more fine grained system level services
NSOV-5, Service Behaviour。
- Development Guidance
- Extending the example, the first step is to recognize that a number of system-level functions are required to be delivered in order that the three web services used in earlier examples can be realised (hence, via the orchestration of those services, the operational activities can be supported)
- The TrackTarget, Identify Friend or Foe and Fire Decision Support functions are needed
- The first of these have two constituent sub-functions: Scan Location and Generate Image.
- System functions are addressed in NSV-4 and, as such, NSOV-5 links directly into the NATO System View, through NSV-4 System Functionality Description
- Note, that for services in general (e.g. for operational services), interactions are described between service consumers and service providers. In the case of web services, a service consumer can be another web service
- In the case of operational services, the service consumer is an actor, without consideration of how this actor is instantiated in the real world
NSOV-5, Service Behaviour。
Supporting NNEC Architecture Elements
- User
- Service (Application service)
- Component
- Component collaboration
