The Service Description Conceptual Model (SDCM) provides a graphical and lexical representation of the properties, structure, and interrelationships of all service metadata elements, collectively known as a Service Description.
The SDCM is a product of the U.S. Federal Aviation Administration (FAA) System Wide Information Management Program (SWIM) and the Single European Sky Air Traffic Management (ATM) Research Programme (SESAR) Joint Undertaking (SJU).
The objectives of the SDM are:
- To define a conceptual model of a Service Description based on consistent application of Service-Oriented Architecture (SOA) principles;
- To establish adequate and consistent semantics for concepts used in documentation for SOA-based services;
- To advance a common and shared understanding of SOA concepts among international partners;
- To promote a technological means for describing all relevant aspects of a service in a manner suitable for both human-readable and machine-processable representations.
The SDM adheres to the following design principles:
- It shall be based on widely-used industry service description standards and models (e.g., OWL-S, WSDL, OASIS SOA Reference Model);
- It shall be extensible to allow deriving and adding more elements to address organization-specific tasks;
- It shall be neutral to any organizational governance model (e.g., in SESAR or FAA SWIM programs);
- It shall be service technological solution agnostic (e.g., it shall not be tailored to method, message or resource oriented implementations);
- It shall be vendor neutral (e.g., it shall not support any proprietary implementation of UML and/or vocabularies).
The rapid proliferation of SOA-based systems has led to a reevaluation of existing documentation practices by IT communities. One piece of documentation in particular, the Service Description, is integral to establishing resource-to-resource interoperability among SOA components and critical to supporting various aspects of SOA governance.
Because the Service Description plays such an important role in SOA, both academia and industry have invested significant efforts in developing different realizations of the concept. The most fundamental and recognizable standard in this area is the Web Services Description Language (WSDL) specification [WSDL] set forth by the World Wide Web Consortium (W3C). Other notable developments include the Open Geospatial Consortium (OGC) Web Services Common Standard [OGC-STD], W3C's Web Application Description Language (WADL) specification [WADL] and W3C's OWL-S: Semantic Markup for Web Services [OWL-S]. In addition, services are often a main element of architecture description frameworks, such as the NATO Architecture Framework and Unified Profile [UPDM], in which the services are described in the wider context of an enterprise or multi-actor federation.
The FAA has also applied considerable effort toward the development and utilization of its own version of a Service Description. It was recognized that for this document to be used effectively in FAA, it had to be aligned to established FAA system engineering practices as well as to consistent application of SOA principles, common standards, methodologies, and best practices. To address these concerns, FAA developed a standard for Preparation of Web Service Description Documents (WSDD) [STD-065A]. This standard has been successfully deployed in FAA's SOA-based implementations and has been followed by two related standards, Preparation of Web Service Requirements Documents (WSRD) [STD-070] and Preparation of Java Messaging Service Description Documents (JMSDD) [STD-073]. To provide a means for describing all relevant aspects of services in machine-processable format (as opposed to the human-readable documents based on the FAA standards), FAA also developed a Web Service Description Ontological Model (WSDOM) [WSDOM], an ontology conceptually similar to W3C's OWL-S and the OASIS SOA Ontology [OASIS-RO].
SESAR also uses a SOA approach in SWIM and has developed an Information Services Reference Mode (ISRM)[ISRM] that provides a common framework for the design and implementation of services in European ATM. Based on standards and best practices, it specifies the required service attributes and design rules that enable organizations to improve consistency and agility in their implementation of services. The ISRM framework promotes the design and description of services from a platform-neutral perspective, enabling their reuse and adaptability by organizations that do not have similar infrastructure requirements and capabilities. Once a service has been allocated to a particular technology platform, its description is captured as a Service Technical Design Description (STDD) that will become available in the SWIM Registry.
Under the umbrella of SJU CP2.1, FAA and SESAR agreed on the need to develop a shared conceptual vision of a SOA Service Description. Analysis of existing bodies of work conducted by both organizations indicated that this objective would be promoted by developing and agreeing on a common conceptual model of a service description with shared semantics.
| Abstract Class | A class that cannot be directly instantiated. [ISO-19501] |
| Aggregation | A special form of association that specifies a whole-part relationship between the aggregate (whole) and a component part. [ISO-19501] |
| Class Diagram | A diagram that shows a collection of declarative (static) concepts, such as classes, types, and their contents and relationships. [ISO-19501] |
| Composite | A class that represents the "whole" in a composition (whole-part) relationship. [OMG-UML] |
| Composition | A form of aggregation which requires that a part instance be included in at most one composite at a time, and that the composite object is responsible for the creation and destruction of the parts. [ISO-19501] |
| Concept | A unit of knowledge created by a unique combination of characteristics. [ISO-11179] |
| Conceptual Model | A representation of concepts (entities) and relationships between them, described by using various notations such as UML. |
| Dependency | A relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. [OMG-UML] |
| Description | A statement or short passage that describes a concept. |
| Identifier (ID) | A sequence of characters, capable of uniquely identifying that with which it is associated, within a specified context.[ISO-11179] |
| Model | A visual representation of concepts that is created by using a set of graphic notation techniques. |
| Name | A word or phrase used to designate or identify a concept. |
The SDCM uses the class diagram defined by the Unified Modeling Language (UML), v2.4.1 standard [OMG-UML].
A cardinality shown for all associations has default value one. When cardinality is not shown, the default value should be assumed and the allowable number of instances of the described element should be read as "only one". See the following figure for the other values for cardinalities used in this model.
Figure 1. Cardinality Notation
This section presents a conceptual model for Service Description. The diagrams are split due to space constraints and should be considered together as one complete diagram. The Profile, Model and Grounding classes shown in Figure 2 are composites, and the classes that each contains are shown in Figures 3, 4 and 5 respectively.
Figure 2. Service Description Diagram
Figure 3. Profile Diagram
Figure 4. Model Diagram
Figure 5. Grounding Diagram
| Definition | The information needed in order to use, or consider using, a service. [SOA-RM] |
| Notes | The service description is the concept being modeled. |
| Definition | A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. [SOA-RM] |
| Notes | The Service class is not shown in the Service Description Conceptual Model diagram. |
| Definition | Any medium with information recorded on or in it. [ISO-20944] |
| Notes | The Document class is not shown in the Service Description Conceptual Model diagram. Document is an abstract class. |
| Definition | A controlled list of well-defined concepts organized into a hierarchical structure. |
| Notes | The Taxonomy class is not shown in the Service Description Conceptual Model diagram. Taxonomy is an abstract class. |
| Definition | A unique framework of authority within which a person or persons act, or are designated to act, towards some purpose. Any department, service, or other entity within an organization which needs to be identified for information exchange. [ISO-6523] |
| Notes | Organization is an abstract class. |
Table 3.5-1 Organization Attributes
| Name | Definition | Notes |
|---|
| name | The full name (and acronym, if any) of the organization. | |
| description | A description of the organization. | |
| web page | An accessible reference (e.g., URL) for the Web page that supplies information about the organization. | |
| Definition | A person or group within an organization, suitable for making a human contact for any purpose. |
Table 3.6-1 Point of Contact Attributes
| Name | Definition | Notes |
|---|
| name | The name of the point of contact. | |
| function | A designation of the position or responsibilities of the point of contact. | |
| phone number | A telephone number used to communicate orally with the point of contact. | |
| e-mail | An electronic mail address used to correspond in writing with the point of contact. | |
| Definition | The part of a service description that advertises the service to potential consumers by describing the parties responsible for providing the service, what is accomplished by the service, and limitations on service applicability. |
Table 3.7-1 Profile Attributes
| Name | Definition | Notes |
|---|
| service name | The full name (and acronym, if any) of the service. | |
| service id | The identifier by which the service is uniquely referenced. | |
| service description | A description of the service. | |
| service version | The current version or revision level of the service. | |
| service category | A classification of the service that could be based on various criteria; e.g., type of service provided, technological or architectural solutions, etc. (See Service Category class) | Service categories are described as taxonomies, usually established by the implementing organization. |
| Definition | A taxonomy used to classify a service by the type of service provided or by some other technological or architectural solution. |
| Notes | The Service Category class is a placeholder for one or more taxonomies. Because of ongoing efforts to either update existing or create new service categorization taxonomies, this class is defined as an abstract class. |
| Prototype | Taxonomy |
| Definition | An organization that offers the use of capabilities by means of a service. [SOA-RM] |
| Notes | Every service has one and only one service provider. The attributes for this class are the attributes identified for the prototype class, Organization. |
| Prototype | Organization |
| Definition | An organization that seeks to satisfy a particular need through the use of capabilities offered by means of a service. [SOA-RM] |
| Notes | The Service Description Conceptual Model asserts that all service consumers are organizations. |
| Prototype | Organization |
| Definition | A type of activity describing the functionality of a service. [NAF] |
| Notes | Every service function usually (but not always) can be mapped to an operation defined as a part of the services interface; i.e., service functions provide a business view and operations provide a technical view of a particular service activity. |
Table 3.11-1 Function Attributes
| Name | Definition | Notes |
|---|
| description | A description of the function. | Each service function description is associated with the real world effects that result from invoking the function. |
| real world effect | An ultimate purpose associated with the interaction with the service. It may be the response to a request for information or the change in the state of some entities shared between the participants in the interaction. [OASIS-RO] | |
| Definition | A process (or a device incorporating such a process) that is utilized or implemented by the service in order to address a security threat. [RFC-2828] |
Table 3.12-1 Security Mechanism Attributes
| Name | Definition | Notes |
|---|
| name |
The name of the security mechanism. |
Examples include: authentication, authorization, etc. |
| description |
A description of the security mechanism. |
|
| Definition | A parameter that specifies and measures the value of the provided service. |
Table 3.13 1 Quality of Service Attributes
| Name | Definition | Notes |
|---|
| name |
The name of the QoS parameter. |
Examples include: capacity, response time, etc. |
| value |
The value or range of values that the QoS parameter is expected to meet or possess. |
|
| description |
A description of the QoS parameter. |
|
| calculation method |
A description of how the QoS values are measured or calculated. |
|
| unit of measure |
The unit of measure in which the QoS values are expressed. |
|
| Definition | A constraint governing one or more services. [NAF] |
| Definition | A characteristic of the environment or larger system within which the service operates. |
| Notes | Examples include: capacity of existing enterprise network, firewalls, physical computing resources, etc. |
Table 3.16-1 Environmental Constraint Attributes
| Name | Definition | Notes |
|---|
| description |
A description of the constraint. |
|
| Definition | The part of a service description that tells a service requester how to construct an invocation message and interpret a response message. |
| Definition | A named set (logical grouping) of operations. [WSDL-0] |
| Notes | The Model part of the service description may include one or more Interfaces. This layout is similar to the component model deployed in [WSDL] in which the high level Description component contains zero or more Interface components. |
Table 3.18-1 Interface Attributes
| Name | Definition | Notes |
|---|
| name |
The name of the interface. |
|
| description |
A description of the interface. |
|
| Definition | A named set of messages related to a single service action. [WSD-REQ] |
Table 3.19-1 Operation Attributes
| Name | Definition | Notes |
|---|
| name |
The name of the operation. |
|
| description |
A description of the operation. |
|
| synchronicity |
A value that indicates whether the operation is "synchronous" or "asynchronous". |
|
| idempotency |
A value that indicates whether the operation is "idempotent" or "non-idempotent". |
|
| precondition |
A description of the state or condition that should be true before the operation can proceed. |
|
| input |
The name of the input message that initiates interaction with the operation. |
Sometimes there is no input, e.g., in notification scenarios. |
| output |
The name of the output message produced in response to a service request. |
Sometimes there is no output, e.g., in solicitation scenarios. |
| effect |
A statement or short passage that describes the state or condition that exists after the operation is completed, assuming no error has occurred. |
|
| message exchange pattern |
A value that indicates the pattern of message exchange between interacting components. [WSDL-2] |
|
Table 3.19-2 Synchronicity Permissible Values
| Name | Definition | Notes |
|---|
| synchronous |
A type of operation whose message exchange pattern describes temporally coupled or "lock-step" interactions, e.g., remote procedure call (RPC)-style request-response interactions. [WS-GLOSS] |
|
| asynchronous |
A type of operation whose message exchange pattern allows messages to be sent without precise sequencing, e.g., a flow of sensor event messages which need not be individually acknowledged. [WS-GLOSS] |
|
Table 3.19-3 Idempotency Permissible Values
| Name | Definition | Notes |
|---|
| idempotent |
A type of operation in which receiving duplicates of a given message will not cause any undesirable effect. |
|
| non-idempotent |
A type of operation in which receiving duplicates of a given message may cause an undesirable effect. |
|
Table 3.19-4 Message Exchange Pattern Permissible Values
| Name | Definition | Notes |
|---|
| in-out |
Indicates the operation where input message is sent to the service first and output message (or a fault message) is generated in response. [WSDL-2] |
|
| in-only |
Indicates the operation which has only an input message, that is, a message is sent to the service and service does not produce any output message. [WSDL-2] |
|
| out-in |
Indicates the operation where the service generates the output message and in return the input message (or a fault message) is received. [WSDL-2] |
|
| out-only |
Indicates the operation which has only an output message, that is, the service generates the output message but does not expect to receive any response message or fault messages. [WSDL-2] |
|
| Definition | A step or action that is required to be taken on data received as part of a service request (input) in order to produce the desired output or change of internal state. |
| Notes | A set of processing steps or activities described in plain language. |
Table 3.20-1 Processing Consideration Attributes
| Name | Definition | Notes |
|---|
| description |
A description of the action to be taken. |
Examples include: data transformations, business rules (e.g., data is invalid after a certain period), etc. |
| Definition | A basic unit of communication from one software agent to another sent in a single logical transmission. |
Table 3.21-1 Message Attributes
| Name | Definition | Notes |
|---|
| name |
The name of the message. |
|
| description |
A description of the message. |
|
| direction |
A value that indicates whether the message is "input" or "output". |
|
Table 3.21-2 Direction Permissible Values
| Name | Definition | Notes |
|---|
| in |
Message data is entered into the system. |
|
| out |
Message data is transferred out of the system. |
|
| Definition | The part of a message that precedes the message body; typically contains message identification and routing information. |
| Definition | A predefined name-value pair that provides information about how the message should be processed or interpreted. |
| Notes | In JMS, the set of Header Fields is called "Message Properties." |
Table 3.28-1 Header Field Attributes
| Name | Definition | Notes |
|---|
| name |
The name of the header field. |
|
| description |
A description of the header field. |
|
| permissible values |
The set of allowable values of the header field. |
|
| Definition | The actual (business) data transferred by a message. |
Table 3.29-1 Message Body Attributes
| Name | Definition | Notes |
|---|
| payload type |
A value that indicates the nature of the actual (business) data transferred by the message. |
|
Table 3.29-2 Payload Type Permissible Values
| Name | Definition | Notes |
|---|
| text |
The payload contains text, i.e., data is stored as a string. |
|
| stream |
The payload contains a stream of primitive values that are written and read sequentially. |
|
| map |
The payload contains a set of name-value pairs, where names are strings, and values are primitives. |
|
| object |
The payload contains a serialized object. |
|
| byte |
The payload contains an array of primitive bytes. |
|
| Definition | A message that is returned as a result of an error that prevents a service from implementing a required function. |
| Notes | The attributes for this class are the attributes identified for the prototype class, Message, with the proviso that the message direction value is always "out". An additional attribute, "fault id", specifies an identifier. |
| Prototype | Message |
Table 3.25-1 Fault Attributes
| Name | Definition | Notes |
|---|
| fault id |
An identifier used to designate or identify the fault. |
|
| direction=out |
A value that indicates fault data is always transferred out of the system. |
See Message attribute "direction". |
| Definition | A basic unit of identifiable and definable data. |
Table 3.26-1 Data Entity Attributes
| Name | Definition | Notes |
|---|
| name | The name of the data entity. | |
| description | A description of the data entity. | |
| Definition | A resource that defines and describes the meaning, structure, inter-relationships, permissible values, format and other aspects of a data entity. |
| Notes | Possible examples are an XML schema file, a data model diagram, a common information exchange model such as AIXM, or some other resource that describes the data entity. |
| Prototype | Document |
| Definition | The part of a service description that describes the means by which the service is invoked, including the underlying technology protocols and network locations of the service. |
| Definition | A specification of the protocol and data format to be used in transmitting messages defined by the associated interface. [WSD-REQ] |
Table 3.29-1 Binding Attributes
| Name | Definition | Notes |
|---|
| name |
The name of the binding. |
|
| description |
A description of the binding. |
|
| Definition | A formal set of rules governing data encoding and coordination for data exchange among service-oriented architecture components. |
| Notes | The attributes for this class are the attributes identified for the prototype class, Document. An additional attribute, "protocol type", specifies the type of document. |
| Prototype | Document |
Table 3.30-1 Protocol Attributes
| Name | Definition | Notes |
|---|
| protocol type |
A value that indicates the type of interactions addressed by the protocol. |
|
Table 3.30-2 Protocol Type Permissible Values
| Name | Definition | Notes |
|---|
| data |
A type of protocol covering conventions for data encoding and coordination for data exchange. |
|
| message |
A type of protocol covering conventions for procedure calls and responses. |
|
| transport |
A type of protocol covering conventions for message transmission and port handling. |
|
| other |
A type of protocol covering such combinations as data definitions with messaging conventions or messaging and transport governing conventions that cannot be unambiguously classified as strictly a data, message, or transport protocol. |
|
| Definition | An association between a fully-specified binding and a physical point (i.e., a network address) at which the service may be accessed. |
Table 3.31-1 End Point Attributes
| Name | Definition | Notes |
|---|
| name |
The name of the end point. |
|
| description |
A description of the end point. |
|
| network address |
A physical point at which the service may be accessed. |
|
| Definition | An externalized and accessible service description, written in a machine-processable format using a common XML grammar, which defines and describes the services interface and invocation bindings. |
| Notes | The attributes for this class are the attributes identified for the prototype class, Document. |
| Prototype | Document |
| [DCMI] | DCMI Glossary, Dublin Core Metadata Initiative, User Guide Committee, 23 April 2004.
http://dublincore.org/documents/usageguide/glossary.shtml |
| [ISO-11179] | ISO/IEC 11179-1, Information technology Metadata registries (MDR) Part 1: Framework, Second edition, 15 September 2004
http://metadata-standards.org/11179/#A1 |
| [ISO-19501] | Unified Modeling Language Specification, Version 1.4.2. formal/05-04-01, January 2005. (This version (1.4.2) has been formally published by ISO as the 2005 edition standard: ISO/IEC 19501.)
http://www.omg.org/spec/UML/ISO/19501/PDF/ |
| [ISO-20944] | ISO/IEC CD 20944-002, Information Technology - Metadata Interoperability and Bindings (MDIB) - Part 002, Common Vocabulary, 12 April 2004.
http://jtc1sc32.org/doc/N1101-1150/32N1105T-CD20944-002.pdf |
| [ISO-6523] | ISO/IEC 6523-1, Structure for the Identification of Organizations and Organization Parts, 1998.
http://www.iso.org/iso/catalogue_detail?csnumber=25773 |
| [ISRM] | Information Services Reference Mode (ISRM)
http://www.sesarju.eu/sites/default/files/documents/swim/SESAR-Factsheet-2015-ISRM.pdf |
| [OASIS-RO] | OASIS Reference Ontology for Semantic Service Oriented Architectures, Public Review 1, 5 November 2008.
http://www.oasis-open.org/apps/group_public/download.php/29909/Reference Ontology for Semantic Service Oriented Architectures_Public_Review_1.doc |
| [NAF] | NATO Architecture Description Framework, Version 3.0.
https://nhqc3s.hq.nato.int/ |
| [OASIS-RO] | OASIS Reference Ontology for Semantic Service Oriented Architectures, Public Review 1, 5 November 2008.
http://www.oasis-open.org/apps/group_public/download.php/29909/Reference Ontology for Semantic Service Oriented Architectures_Public_Review_1.doc |
| [OGC-STD] | OGC Web Services Common Standard, Version 2.0.0, Open Geospatial Consortium Inc., 7 April 2010.
http://www.opengeospatial.org/standards/common |
| [OMG-UML] | OMG Unified Modeling Language TM (OMG UML), Infrastructure, Version 2.4.1, August 2011.
http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF |
| [OWL-S] | OWL-S: Semantic Markup for Web Services, W3C Member Submission 22 November 2004.
http://www.w3.org/Submission/OWL-S/ |
| [RFC-2828] | RFC 2828, Internet Security Glossary, Network Working Group, May 2000.
http://www.ietf.org/rfc/rfc2828.txt |
| [SOA-RM] | OASIS Reference Model for SOA 1.0, 12 October 2006.
http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf |
| [STD-065A] | FAA-STD-065A, Preparation of Web Service Description Documents, 1 July 2013.
http://www.faa.gov/nextgen/programs/swim/governance/standards/ |
| [STD-070] | FAA-STD-070, Preparation of Web Service Requirements Documents, 12 July 2012.
http://www.faa.gov/nextgen/programs/swim/governance/standards/ |
| [STD-073] | FAA-STD-073, Preparation of Java Messaging Service Description Documents, 29 January 2014.
http://www.faa.gov/nextgen/programs/swim/governance/standards/ |
| [UPDM] | Unified Profile For The Department Of Defense Architecture Framework (DoDAF) And The Ministry Of Defence Architecture Framework (MODAF), Version 2.1.
http://www.omg.org/spec/UPDM/ |
| [WADL] | Web Application Description Language, W3C Member Submission 31 August 2009,
http://www.w3.org/Submission/wadl/ |
| [WSDL] | Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Recommendation, 26 June 2007.
http://www.w3.org/TR/wsdl20/ |
| [WSDL-2] | Web Services Description Language (WSDL) Version 2.0 Part 2: Message Exchange Patterns, W3C Working Draft 26 March 2004.
http://www.w3.org/TR/2004/WD-wsdl20-patterns-20040326/ |
| [WSDOM] | Web Service Description Ontological Model (WSDOM), latest version.
http://www.faa.gov/nextgen/programs/swim/governance/servicesemantics/ |
| [WSD-REQ] | Web Services Description Requirements, W3C Working Draft, 28 October 2002.
http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/ |
| [WS-GLOSS] | Web Services Glossary, W3C Working Draft, 14 November 2002.
http://www.w3.org/TR/2002/WD-ws-gloss-20021114/ |
| [WS-POL] | Web Services Policy 1.5 - Framework, W3C Recommendation, 04 September 2007.
http://www.w3.org/TR/2007/REC-ws-policy-20070904/ |
