Home | Sitemap | ABC | Contact

A.4. Service and Interoperability Points

19. This section deals with service and interoperability points connecting domains under separate management and control, such as National or NATO Systems. In a platform oriented environment two parties agree "a priori" on the services and standards at static interoperability points. In A SOA environment provider parties advertise a service with a public interface which may be discovered by a consumer requiring the use of that service.

A.4.1. Platform Centric Service and Interoperability Points

20. A typical example of a service and interoperability point implementation in a platform centric environment is the Information Exchange Gateway (IEG) shown in Figure A.6 [3].

NATO IEG Concept

Figure A.6. NATO IEG Concept


21. The IEG Concept is designed to satisfy information requirements by providing information exchange capability between different CIS communities, while protecting the same CIS communities. The IEG Concept provides:

  • Information Exchange Services (IES) for the exchange of information between NATO and other CIS communities, and

  • Boundary Protection Services/Boundary Protection Component (BPS/BPC) to protect NATO and national CIS communities by implementing the stated security principles like self protecting node principle and defence in depth to support the security objectives of confidentiality , integrity and availability.

22. The Interoperability Point depicted in Figure A.6 may be considered both a SIOP and a SIP. The services at this interface point are taken form the services described in the NTRM. Example services are messaging and document exchange. These services are initial services supported by the IEG. Interoperability for these services is obtained by using the mandatory protocols (e.g. SMTP) and profiles contained in Volume 2 (the NISP profiles can be considered equivalent to SIPs).

23. The communications SIOPs and SIPs (e.g. tactical data links, IP) described in the NNEC FS are compliance with the NTRM.

A.4.2. SOA Service and Interoperability

A.4.2.1. SOA Characteristics

24. One of the highlights of a SOA is the degree of documentation and description associated with it. The use of a service without the service consumer needing to know the details of the service implementation, the service description makes available critical information that a consumer needs in order to decide whether or not to use a service. In particular, a service consumer must possess the following items of information:

  • That the service exists and is reachable;

  • That the service performs a certain function or set of functions;

  • That the service operates under a specified set of constraints and policies;

  • That the service will (to some implicit or explicit extent) comply with policies as prescribed by the service consumer;

  • How to interact with the service in order to achieve the required objectives, including the format and content of information exchanged between the service and the consumer and the sequences of information exchange that may be expected.

25. The service description is part of the service contract depicted in Figure A.5. A service contract needs to have the following components[4]:

  • Header

    • Name - The service name. Should indicate in general terms what it does, but not be the only definition

    • Version - The version of this service contract

    • Owner - The person/team in charge of the service

    • RACI

      • Responsible - The role is the person/team responsible for the deliverables of this contract/service.

      • Accountable - Ultimate Decision Maker in terms of this contract/service.

      • Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision.

      • Informed - Who must be informed that a decision or action is being taken. This is a 1-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.

    • Type - This is the type of service to help distinguish the layer it resides.

      • Data

      • Process

      • Functionality

      • Presentation

  • Functional

    • Functional Requirement (From Requirements Document) - Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished.

    • Service Operations - Methods, actions etc. Must be defined in terms of what part of the Functionality it provides.

    • Invocation - Indicates the invocation means of the service. This includes the URL, interface, etc. There may be multiple Invocation paths for the same service. We may have the same functionality for an internal and external clients each with a different invocation means and interface. Examples:

      • SOAP

      • REST

      • Event Triggers

  • Non-Functional

    • Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc. and which invocation mechanism they can invoke.

    • Quality of Service - Determines the allowable failure rate.

    • Transactional - Is this capable of acting as part of a larger transaction and if so, how do we control that?

    • Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions.

    • Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service.

    • Process - Describes the process, if any, of the contracted service.

26. SIOPs and SIPs for SOA be compatible with Figure A.5 and will have to be compliant with NATO agreed standards for service descriptions and contracts. Since it is expected SOA services will be implemented with web services, SIOPs and SIPs will be implemented with web service standards (e.g. WSDL, UDDI, XML, SOAP).

A.4.2.2. Recommendations

27. To clarify the meaning of service interoperability in platform centric and SOA centric environments it is recommended that:

  • For platform centric environments the terms Interoperability Point (IOP) and Interface Point (IP) be used, and

  • For SOA environments the terms Service Interface Point (SIP) and Servcie Interoperability Point (SIOP) be used.



[3] AC/322-D(2005)0054

[4] Wikipedia

Copyright © NATO - OTAN 1998-2010 | Disclaimer