Forward DMS design and implementation in OWS-9

3

1.5 Forward

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights. Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

1.6 DMS design and implementation in OWS-9

OGC Interoperability Program IP projects such as the OGC Web Services Testbed Phase 9 OWS-9 bring together a range of independent participants – from both the public and private sector - to respond to sponsor requirements. This was also true for the design and implementation of the Data Management Service DMS in OWS-9. Both ATM-TGS and Harris collaborated on defining the technical specification of the DMS component, supported by other OWS-9 participants, primarily client developers such as Luciad. The resulting DMS specification as well as investigation results represent the consensus achieved between the relevant stakeholders within OWS-9. All results of the OWS-9 work on Data Transmission to Aircraft Management are documented in this OGC Engineering Report ER, which is open and publicly available. This allows everyone who is interested to review the results and to provide feedback, thus creating valuable input to improve the specification. This process – the ability to provide continuous feedback and to incorporate it in the specification - will ultimately lead to a DMS specification that is based on broad industry consensus. OWS-9 laid the foundation by creating the first version of the DMS specification. Future work on DMS will lead to further review of the DMS specification as well as new or updated requirements, and thus possibly revisions and extensions. That the results – and thus the DMS specification – are publicly available especially allows other component providers to implement DMS compliant products as well. Because the DMS specification defines a common service model to satisfy data transmission to aircraft requirements, both vendors and customers can rely upon that model to build interoperable systems. Vendors of service andor client components that support DMS functionality have access to a bigger customer base. Customers that need DMS functionality have a wider range of products to choose from. All because there is a common and publicly available, open DMS specification that defines how DMS functionality can be realized. For customers, it is especially important to base the DMS products they buy on open specifications to prevent vendor lock-in. If the key DMS functionality is realized by multiple products, a customer can migrate or switch to a new product if necessary. For vendors, this provides an opportunity as well, allowing them to bundle added-value features and strong support with their DMS products. Finally, by 4 using a common DMS specification to realize DMS functionality in distributed systems, this functionality will be realized in an interoperable way. The OGC Standards as well as Interoperability Programs provide a platform for discussion and development of technical specifications – such as the DMS – between interested stakeholders. Product providers can report and discuss their implementation experience and request clarifications as well as changes to be applied to the specifications. Also, new requirements can be brought in to ultimately enhance the specification baseline and eventually also compliant products. The OGC processes to manage and support this specification development have proven themselves in the development of specifications that are now international standards supported in many products and deployed in many application domains. This represents a profound way of maturing the DMS specification in the future. In fact, as OGC specifications such as the DMS are scrutinized through review and implementation by many stakeholders, the danger of not supporting specific technical requirements is minimized. This provides safety for vendors that implement compliant products. It does not require such products to be open source. It just means that these products comply with the open OGC standardsspecifications. Speaking of compliance, the OGC also has a program to certify that a given product complies with an OGC specification: the Compliance and Interoperability Testing Initiative CITE. This provides a way for product providers to prove that their products comply with given OGC specifications. It also provides a way for end users to more easily integrate the requirement for standards compliant products in procurements. As the DMS specification matures, compliance test scripts can be developed to include the DMS in the certification process. 2 References The following documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies. [OGC] OGC 06-121r3, OpenGIS ® Web Services Common Standard OASIS Web Services Reliable Messaging WS-- ‐Reliable Messaging Version1.2, http:docs.oasis-- ‐open.orgws--‐rxwsrm200702 ISO 19142: Geographic information Web Feature Service, 2010-04-26, OGC document 09-025r1, http:www.opengeospatial.orgstandardswfs X.891: Information technology ‐ Generic applications of ASN.1: Fast infoset – 2007-01- 30 W3C XML Information Set second edition http:www.w3.orgTRxml-- ‐infoset 5 [EE] J. Saltzer, D. Reed and D. Clark: “End-to-end arguments in system design”, ACM Trans. Comp. Sys., 24:277-88, Nov. 1984 [OASIS-WSRM] Web Services Reliable Messaging WS-ReliableMessaging, Committee Draft 04, August 11, 2006 [IETF-MIPv6] D. Johnson, C. Perkins, J. Arkko: Mobility Support in IPv6, RFC 6275, June 2011 [ICAO-ATNIPS] Aeronautical Telecommunication Network ATN - Manual for the ATN using IPS standards and protocols Doc 9896, Draft Version 19, April 2011 [IETF-SIP] J. Rosenberg et al.: SIP: Session Initiation Protocol, RFC 3261, June 2002 [SANDESHA2] Sandesha2 User Guide, online at http:axis.apache.orgaxis2javasandeshauserGuide.html [OGC 08-133] OpenGIS® Sensor Event Service Interface Specification proposed [OGC 11-097] OGC® OWS-8 AIXM 5.1 Compression Benchmarking In addition to this document, this report includes several XML Schema Document files as specified in Annex A. 3 Conventions

3.1 Abbreviated terms