SESAR FAA logos

Service Description Conceptual Model (SDCM) 1.0

SESAR CP 2.1 Working Draft March 28 2014


Editors:
Mark Kaplun (FAA)
Peder Blomqvist (SESAR NORACON)
Carol Uri (CSSI, INC.)
Niklas Haggstrom (SESAR NORACON)
Contributors:
Paul Jackson (FAA ret.)
Tord Pola (SESAR NORACON)
Lars Helleblad (SESAR NORACON)
Oliver Krueger (SESAR DFS)
Friedy Pietrus (SESAR DSNA)
Antonio Strano (SESAR SELEX)


Table of Contents

1 Introduction

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).

1.1 Objectives

The objectives of the SDM are:

The SDM adheres to the following design principles:

1.2 Background

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].

At the same time, SESAR has concentrated on the development of a Service Interoperability Standards & Profiles Framework (SISPF). SISPF is a key enabler for the standardization of information exchange between the U.S. and Europe and, in the longer term, on a global scale. Its goals are to provide a common set of references and standards along with their relationship to the architecture processes, and to describe the logical and physical interfaces of the services provided in the context of the European Air Traffic Management (ATM), including the transatlantic services.

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.

1.3 Terminology

Abstract ClassA class that cannot be directly instantiated. [ISO-19501]
AggregationA special form of association that specifies a whole-part relationship between the aggregate (whole) and a component part. [ISO-19501]
Class DiagramA diagram that shows a collection of declarative (static) concepts, such as classes, types, and their contents and relationships. [ISO-19501]
CompositeA class that represents the "whole" in a composition (whole-part) relationship. [OMG-UML]
CompositionA 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]
ConceptA unit of knowledge created by a unique combination of characteristics. [ISO-11179]
Conceptual ModelA representation of concepts (entities) and relationships between them, described by using various notations such as UML.
DependencyA relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. [OMG-UML]
ModelA visual representation of concepts that is created by using a set of graphic notation techniques.

1.4 Diagrammatic Symbolism

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.

Cardinality
Figure 1. Cardinality Notation


2 Model

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 Service Profile, Service Interface and Service Implementation classes shown in Figure 2 are composites, and the classes that each contains are shown in Figures 3, 4 and 5 respectively.

The UML representation of this model is also available as a set of Enterprise Architect modeling platform artifacts contained in a single downloadable ZIP file.

2.1 Service Description

Service Description
Figure 2. Service Description Diagram


2.2 Service Profile

Service Profile
Figure 3. Service Profile Diagram


2.3 Service Interface

Service Interface
Figure 4. Service Interface Diagram


2.4 Service Implementation

Service Implementation
Figure 5. Service Implementation Diagram


3 Concepts

3.1 Service Description

DefinitionThe information needed in order to use, or consider using, a service. [SOA-RM] [SWIM-CV]
NotesThe service description is the concept being modeled.

3.2 Service

DefinitionA 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] [SWIM-CV]
NotesThe Service class is not shown in the Service Description Conceptual Model diagram.

3.3 Normative Document

DefinitionA document that provides rules, guidelines, or characteristics for activities or their results. [ISO-20944]
NotesThe Normative Document class is not shown in the Service Description Conceptual Model diagram. Normative Document is an abstract class. The Normative Document class is a subclass of Document class, and thus the attributes for this class are the attributes identified for the superclass, Document.
PrototypeDocument

3.4 Document

DefinitionAny medium with information recorded on or in it. [ISO-20944]
NotesThe Document class is not shown in the Service Description Conceptual Model diagram. Document is an abstract class.
Table 3.4-1 Document Attributes
NameDefinitionNotes
titleThe name by which the document is formally known. [DCMI] http://purl.org/dc/terms/title
alternative titleAn alternative name for the document.http://purl.org/dc/terms/alternative
publisherThe entity responsible for making the document available. [DCMI] http://purl.org/dc/terms/publisher
date issuedThe date of formal issuance (e.g., publication) of the document. [DCMI] http://purl.org/dc/terms/issued
versionThe current version or revision level of the document.
creatorThe entity primarily responsible for making the content of the document. [DCMI]http://purl.org/dc/terms/creator
locationThe address or Web location where a copy of the document can be obtained.

3.5 Taxonomy

DefinitionA controlled list of well-defined concepts organized into a hierarchical structure.
NotesThe Taxonomy class is not shown in the Service Description Conceptual Model diagram. Taxonomy is an abstract class.

3.6 Organization

DefinitionA 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][SWIM-CV]
NotesOrganization is an abstract class.
Table 3.6-1 Organization Attributes
NameDefinitionNotes
organization nameThe full name (and acronym, if any) by which the organization is commonly referred to or recognized.
organization URIThe unique organization identifier presented using syntax described in [RFC-3986], and assigned by a registration authority.
organization descriptionA statement or short passage in plain language that describes the organization.
organization Web pageAn accessible reference (e.g., URL) for the Web page that supplies information about the organization.

3.7 Point of Contact

DefinitionA person or group within an organization, suitable for making a human contact for any purpose. [STD-065A]
NotesEvery organization may have zero or one points of contact. The values of the Point of Contact class attributes can be defined at the service description implementation level.
Table 3.7-1 Point of Contact Attributes
NameDefinitionNotes
point of contact nameThe name by which the point of contact is recognized or addressed.
point of contact job titleA designation of the position or responsibilities of the point of contact.
point of contact phone numberA telephone number used to communicate orally with the point of contact.
point of contact e-mailAn electronic mail address used to correspond in writing with the point of contact.

3.8 Service Profile

DefinitionThe 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.8-1 Service Profile Attributes
NameDefinitionNotes
service nameThe full name (and acronym, if any) by which the service is commonly referred to or recognized.
service URIThe unique service identifier presented using syntax described in [RFC-3986], and assigned by a registration authority.
service descriptionA statement or short passage in plain language that describes the service.
versionThe current version or revision level of the service.
service categoryA 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.

3.9 Service Category

DefinitionA taxonomy used to classify a service by the type of service provided or by some other technological or architectural solution.
NotesThe 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.
PrototypeTaxonomy

3.10 Service Provider

DefinitionAn organization that offers the use of capabilities by means of a service. [SOA-RM] [SWIM-CV]
NotesEvery service has one and only one service provider. The attributes for this class are the attributes identified for the prototype class, Organization.
PrototypeOrganization

3.11 Service Consumer

DefinitionAn organization that seeks to satisfy a particular need through the use of capabilities offered by means of a service. [SOA-RM] [SWIM-CV]
NotesThe Service Description Conceptual Model asserts that all service consumers are organizations.
PrototypeOrganization

3.12 Service Function

DefinitionA type of activity describing the functionality of a service. [NAF]
NotesEvery service function usually (but not always) can be mapped to an operation defined as a part of the service's interface; i.e., service functions provide a "business view" and operations provide a "technical view" of a particular service activity.
Table 3.12-1 Service Function Attributes
NameDefinitionNotes
service function descriptionA statement or short passage in plain language that describes the service function.Each service function description is associated with the real world effects that result from invoking the function.
real world effectAn 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][SWIM-CV]

3.13 Security

DefinitionA set of collective measures (security mechanisms) that enable the service to provide protection against security threats such as unauthorized access to service information; unauthorized disclosure, modification and destruction of information; unknown status and repudiation in execution; and denial of service. [STD-065A]

3.14 Security Mechanism

DefinitionA 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.14-1 Security Mechanism Attributes
NameDefinitionNotes
mechanism name A word or phrase used to designate or identify the security mechanism. Examples include: authentication, authorization, etc.
mechanism description A statement or short passage in plain language that describes the purpose of the security mechanism.

3.15 Security Protocol

DefinitionA standard protocol or specification document that describes and governs the implementation of a security mechanism, or, if the mechanism is delegated to an external security service, a document that specifies that service.
NotesThe attributes for this class are the attributes identified for the prototype class, Normative Document.
PrototypeNormative Document

3.16 Quality of Service

DefinitionA parameter that specifies and measures the value of the provided service. [SWIM-CV]
NotesQuality of Service, as defined in the Service Description Conceptual Model, presents only QoS which are not associated with any specific service consumer. The QoS that the service provider is obligated to provide to a specific service consumer are usually captured in a Service Level Agreement (SLA) and are outside of scope of this model.
Caption
NameDefinitionNotes
parameter name A word or phrase used to designate or identify the QoS parameter. Examples include: capacity, response time, etc.
parameter value The value or range of values that the QoS parameter is expected to meet or possess.
parameter definition A statement or short passage in plain language that describes 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.

3.17 Service Policy

DefinitionA constraint governing one or more services. [NAF]

3.18 Policy

DefinitionA protocol or specification document that describes and governs a service policy.
NotesA policy document can be both human-readable and machine-processable (e.g., a WS-Policy compliant document; see [WS-POL]). The attributes for this class are the attributes identified for the prototype class, Document.
PrototypeDocument

3.19 Environmental Constraint

DefinitionA characteristic of the environment or larger system within which the service operates. [STD-065A]
NotesExamples include: capacity of existing enterprise network, firewalls, physical computing resources, etc.
Table 3.19-1 Environmental Constraint Attributes
NameDefinitionNotes
constraint description A statement or short passage in plain language that describes the constraint.

3.20 Machine-Processable Service Description

DefinitionAn externalized and accessible service description, written in a machine-processable format using a common XML grammar, which defines and describes the service's interface and invocation bindings. [STD-065A]
NotesThe attributes for this class are the attributes identified for the prototype class, Document.
PrototypeDocument

3.21 Machine-Processable Service Description Specification

DefinitionAn open standard that specifies the format and rules for developing a Machine-Processable Service Description.
NotesThe attributes for this class are the attributes that identified for the prototype class, Normative Document.
PrototypeNormative Document

3.22 Service Interface

DefinitionThe part of a service description that tells a service requester how to construct an invocation message and interpret a response message.
NotesThis class should not be confused with the Service Interface class. Service Interface is one of the three major parts of the Service Description, which 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.

3.23 Interface

DefinitionA named set (logical grouping) of operations. [STD-065A]
Table 3.23-1 Interface Attributes
NameDefinitionNotes
interface name A word or phrase used to designate or identify the interface.
interface description A statement or short passage in plain language that describes the purpose of the interface.

3.24 Operation

DefinitionA named set of messages related to a single service action. [WSD-REQ]
Table 3.24-1 Operation Attributes
NameDefinitionNotes
operation name A word or phrase used to designate or identify the operation.
operation description A statement or short passage in plain language that describes the pattern and goals of the actions constituting 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 statement or short passage that describes 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.24-2 Synchronicity Permissible Values
NameDefinitionNotes
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.24-3 Idempotency Permissible Values
NameDefinitionNotes
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.24-4 Message Exchange Pattern Permissible Values
NameDefinitionNotes
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]

3.25 Processing Consideration

DefinitionA 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. [STD-065A]
NotesA set of processing steps or activities described in plain language.
Table 3.25-1 Processing Consideration Attributes
NameDefinitionNotes
processing description A statement or short passage in plain language that describes the action to be taken. Examples include: data transformations, business rules (e.g., data is invalid after a certain period), etc.

3.26 Message

DefinitionA basic unit of communication from one software agent to another sent in a single logical transmission. [SWIM-CV]
Table 3.26-1 Message Attributes
NameDefinitionNotes
message name A word or phrase used to designate or identify the message.
message description A statement or short passage in plain language that describes the message.
direction A value that indicates whether the message is "input" or "output" .
Table 3.26-2 Direction Permissible Values
NameDefinitionNotes
in Message data is entered into the system.
out Message data is transferred out of the system.

3.27 Message Header

DefinitionThe part of a message that precedes the message body; typically contains message identification and routing information. [SWIM-CV]

3.28 Header Field

DefinitionA predefined name-value pair that provides information about how the message should be processed or interpreted. [SWIM-CV]
NotesIn JMS, the set of Header Fields is called "Message Properties."
Table 3.28-1 Header Field Attributes
NameDefinitionNotes
field name A word or phrase used to designate or identify the header field.
field description A statement or short passage in plain language that describes the purpose of the header field.
field value The set of allowable values of the header field.

3.29 Message Body

DefinitionThe actual (business) data transferred by a message. [SWIM-CV]
Table 3.29-1 Message Body Attributes
NameDefinitionNotes
message body type A value that indicates the nature of the actual (business) data transferred by the message.
Table 3.29-2 Message Body Type Permissible Values
NameDefinitionNotes
text The message body contains a text, e.g., XML.
stream The message body contains a stream of primitive values that are written and read sequentially.
map The message body contains a set of name-value pairs, where names are strings, and values are primitives.
object The message body contains a serialized object.
byte The message body contains an array of primitive bytes.

3.30 Fault

DefinitionA message that is returned as a result of an error that prevents a service from implementing a required function. [STD-070]
NotesFault messages are considered to be messages.
Table 3.30-1 Fault Attributes
NameDefinitionNotes
fault name A word or phrase used to designate or identify the fault.
fault description A statement or short passage in plain language that describes the purpose of the fault.

3.31 Data

DefinitionRe-interpretable representation of information in a formalized manner suitable for communication, interpretation, or processing by human or by automatic means. [ISO-11179]

3.32 Structured Data

DefinitionData that is organized in well-defined semantic "chunks" or units that are variously called fields, elements, objects, or entities. Individual units are often combined to form larger, more complex units. [STD-065A]
NotesExamples of structured data include XML documents.

3.33 Data Entity

DefinitionA unit of data for which the definition, identification, representation, and permissible values are specified by means of a set of attributes. [ISO-11179]
Notes"Data Entity" is synonymous with FAA term "Data Element".
Table 3.33-1 Data Entity Attributes
NameDefinitionNotes
namespaceA URI that is used together with the element name to identify the element uniquely and unambiguously.
element nameA word or phrase used to designate or identify the element.
element definitionA statement or short passage in plain language that describes the element.
permissible valuesThe set of allowable instances of the element.May be a range of numbers, a list of individual values, a reference to a source that lists the values, or a textual description.
unit of measureA single or multiple word designation of the measurement framework, e.g., feet, kilograms, etc., associated with quantitative values.
datatypeA set of distinct values, characterized by properties of those values and by operations on those values; defined in section 3.2 of [SCHEMA-2] (e.g., bitmap, string, etc.).For primitive elements, i.e., elements that are not composed of other elements.
maximum lengthThe element's maximum length together with units of length (e.g., characters, bytes, etc.).
format stringThe arrangement of bits or characters within the element; denoted using regular expressions defined in Appendix F of [SCHEMA-2].
obligationA value that indicates whether the element is always or sometimes required to be instantiated (i.e., to contain a value) in the context of its underlying information model.
multiplicityThe occurrence of the element in the context of its underlying information model (e.g., 0, 1, ..., unbounded).
Table 3.33-2 Obligation Permissible Values
NameDefinitionNotes
required The element must always be instantiated.
optional The element may or may not be instantiated.

3.34 Data Model

DefinitionA graphical and/or lexical representation of data, specifying their properties, structure and inter-relationships. [ISO-11179]
NotesThe attributes for this class are the attributes identified for the prototype class, Normative Document.
PrototypeNormative Document

3.35 Unstructured Data

DefinitionData that does not follow any hierarchical sequence or any relational rules. [STD-065A]
NotesExamples of unstructured data include audio, video, and unstructured text such as the body of an e-mail or word processor document.
Table 3.35-1 Unstructured Data Attributes
NameDefinitionNotes
type The nature or genre of the content of the data. [DCMI] http://purl.org/dc/terms/type
format The file format, physical medium, or dimensions of the data. [DCMI] http://purl.org/dc/terms/format
data description A statement or short passage in plain language that describes the data.

3.36 Service Implementation

DefinitionThe 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.

3.37 Binding

DefinitionA specification of the protocol and data format to be used in transmitting messages defined by the associated interface. [WSD-REQ]
Table 3.37-1 Binding Attributes
NameDefinitionNotes
binding name A word or phrase used to designate or identify the binding.
binding description A statement or short passage in plain language that describes the binding.

3.38 Data Protocol

DefinitionA formal set of rules governing data encoding and coordination for data exchange among service-oriented architecture components. [STD-065A]
NotesThe attributes for this class are the attributes identified for the prototype class, Normative Document.
PrototypeNormative Document

3.39 Message Protocol

DefinitionA formal set of rules governing procedure calls and responses among communicating service-oriented architecture components. [STD-065A]
NotesThe attributes for this class are the attributes identified for the prototype class, Normative Document.
PrototypeNormative Document

3.40 Transport Protocol

DefinitionA formal set of rules governing message transmission and port handling among communicating service-oriented architecture components. [STD-065A]
NotesThe attributes for this class are the attributes identified for the prototype class, Normative Document.
PrototypeNormative Document

3.41 Other Protocol

DefinitionA 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. [STD-065A]
NotesThe attributes for this class are the attributes identified for the prototype class, Normative Document.
PrototypeNormative Document

3.42 End Point

DefinitionAn association between a fully-specified binding and a physical point (i.e., a network address) at which the service may be accessed. [STD-065A]
Table 3.42-1 End Point Attributes
NameDefinitionNotes
end point name A word or phrase used to designate or identify the end point.
end point description A statement or short passage in plain language that describes the end point.
network address A physical point at which the service may be accessed.

4 References





[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
[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
[RFC-3986] RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, Network Working Group, January 2005.
http://www.rfc-editor.org/rfc/rfc3986.txt
[SCHEMA-2] XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, 28 October 2004.
http://www.w3.org/TR/xmlschema-2/
[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/about/office_org/headquarters_offices/ato/service_units/techops/atc_comms_services/swim/governance/standards/
[STD-070] FAA-STD-070, Preparation of Web Service Requirements Documents, 12 July 2012.
http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/techops/atc_comms_services/swim/governance/standards/
[STD-073] FAA-STD-073, Preparation of Java Messaging Service Description Documents, DRAFT.
http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/techops/atc_comms_services/swim/governance/standards/
[SWIM-CV] SWIM Controlled Vocabulary, 3 May 2013.
http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/techops/atc_comms_services/swim/vocabulary/
[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/about/office_org/headquarters_offices/ato/service_units/techops/atc_comms_services/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/