1. 1 May 2010 CCSDS INFORMATION SERVICE ARCHITECTURE CONCEPTS

2. Overview In October, a request was made by the CESG to develop a concept paper on a SOA-style information architecture IA, IPR and SM group met to discuss initial concepts at ESTEC Development of an initial concept paper as closely paralleled the effort to define a reference architecture for CCSDS –The Information Service Architecture is a specialization of the CCSDS reference architecture –A white paper draft is in place 2

3. Definition of Information Service Architecture CCSDS Information Service Architecture –an architectural pattern that decouples common information services, models and middleware from applications to improve reuse and interoperability between applications –Prescribes: Common information services and components Common meta models Common information model Distributed middleware –promotes several goals for the composition of information systems based on CCSDS standards including Constructing systems through well-defined standard interfaces Enabling agency autonomy in their implementations Supporting federation of space data system services across agencies Supporting service discovery between organizations and agencies Enabling loose coupling of services and their implementations –coordination on several fronts Shared messaging infrastructures Common data definitions of the contents of messages Common services behaviors Common service interfaces and methods Information services to support service registration and discovery Explicit methods for secure access of services and exchange of information 3

4. SOA Concept 4 1. How can the Consumer dynamically discover the existence of a Provider, which can provide the services being requested? 2. Assuming the Consumer knows of the Provider’s existence, how can it locate the Provider? 3. Assuming the Consumer has located the Provider, how can the two describe how to connect to each other, in a standard format which can be understood regardless of their IT platforms? 4. Assuming they have described themselves, how can they exchange messages in a common messaging format which is independent of their underlying platforms? 5. Assuming they have agreed upon a common messaging format, what data format can they use to exchange data independent of their underlying database technologies? Application 1 “Service Consumer” Application 2 “Service Provider”

5. Related work Service-oriented Architecture –Different viewpoints from different domains Scientific domain perspective - Geospatial Portal Reference Architecture [4] Web domain perspective - four-model perspective of a web services SOA [5] Software industry-oriented perspective - IBM nine-layer SOA reference architecture [6] –OASIS SOA RM Information Modeling –Domain-specific information models for describing information objects Planetary Data Systems Healthcare –Health Level Seven (HL7) –Systematized Nomenclature of Medicine (SNOMED) –the International Classification of Diseases – 9 th Revision (ICD9) –A variety of different methods to express an information model Entity-Relationship Model [7] OMG Unified Modeling Language (OMG UML) [8,9] Ontology - Web Ontology Language (OWL) [11] –Little effort to develop common models for sharing of information across the end-to-end space data system 5

6. Architecture Definitions ISO/IEC 42010:2007 (formerly, ANSI/IEEE 1471-2000) Recommended Practice for Architecture Description of Software- Intensive Systems –“the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” [1] Information Architecture Emphasis –explicitly define its information architecture using a well-specified information model –interfaces and the content that is exchanged across these interfaces is governed by explicit information models –Open Archival Information System (OAIS) [2] –A Reference Architecture for Space Information Management (RASIM) [3] 6

7. Mapping to a CCSDS Reference Architecture With an Information Service Architecture, we consider three viewpoints to be critical –Service These are the services and their interfaces necessary to support CCSDS activities and may be domain specific. Functions are used to implement services. –Functional These are the functions necessary to implement services. Within a distributed service architecture, a set of standards functions that are cross cutting can be useful for implemented interoperable systems (registry, repository, messaging, etc) –Information These are the domain and meta model standards used to implement the information architecture. Within a distributed architecture, the objects that are exchanged between services should use well defined information objects 7

8. Relationship between services, information, etc Services –allows for definition of services, particularly domain-specific services –Domain-specific services built from functions (assume components=functions are equiv for the moment) –Layering domain-specific services on top of an information service architecture allows for moving domain services into a distributed, information-driven architecture –Services should promote common interfaces that share common information objects 8

9. Decomposed Architecture Functional View –a set of standard components and infrastructure services that allow for construction of distributed systems –component: any modular element of a software system –service: an application that is constructed from a set of components that is deployed within a distributed system Decomposition of information and functional elements of an information system in a distributed environment showing interoperability at each layer 9

10. Information Architecture definition Information Architecture: a set of data models where each model defines what is needed to describe the meaning of the data and how it is organized and structured. –a set of classes, class attributes, and class relationships. Each domain within CCSDS maintains and publishes their own models, but they are also related to a broader CCSDS information model –Schemas developed with CCSDS WGs should be derived from a set of information models 10

11. Capturing domain models for CCSDS A domain model, which may be governed by a meta model that prescribes it structure and organization, is used to specific the information object. The domain model includes the dictionary of data elements along with their semantic relationships which is captured in a schema, or with more specificity, in a complex model such as an ontology. Derivation of information objects from the domain model is critical to supporting interoperability. Domain model can be further described by standard metamodel 11

12. Decomposing the architecture N-tiered, service-style architecture helps to decouple systems Services should be built from well-defined functions Across CCSDS, proper layering should be achieved, with reuse of standard functions as we move from domain specific and application layered standards to common infrastructure and communications As such, space domain functions can be mapped to use standard infrastructure services (information management, messaging, etc) in a SOA style deployment 12

13. Mapping of space domain functions to an ISA 13 Decoupling of applications/space domain functions from services is key to a developing SOA style architecture The messaging layer accommodates multiple patterns and approaches for tighter and looser coupling (e.g., Request- Response, Pub-Sub) Use of common models is key to interoperability and reuse

14. Messaging patterns (Pub/Sub and Request/Response) Information Services Connected to a Software Bus Client/server (e.g., REST, SOAP, etc) distributed architecture with information services on the backend 14

15. Representing the Information Service Architecture (ISA) Logical Stack a layered view of the CCSDS- related services abstracting out the messaging middleware, from the information infrastructure allows us to understand the overlaps CCSDS is involved in the development of standards at each of these levels standards efforts should fit together and CCSDS should be mindful when standards effort cross multiple boundaries in the architectural model to ensure interoperability remains as a critical architectural tenet 15

16. Layers Application – These are clients that leverage and use services and standard models. They include domain specific models necessary for interoperability. Application Services – These are CCSDS domain specific services which are deployed into a SOA-style deployment. These include domain specific models necessary for interoperability. Infrastructure Services – These are standard information services and models which support discovery and deployment of application services, information management services, etc. Messaging Services – This is the messaging layer which identifies protocols and message structure necessary for applications to be deployed into a distributed service architecture. Network Layer – This is the communication layer. Construction of higher order messaging and information/infrastructure services should be built on top of this layer. 16

17. CCSDS mapping A potential mapping between the layers in the logical stack and the CCSDS standards areas The goal for CCSDS should be reuse as the information infrastructure and messaging layers and specialization as the application and application service layers Security is cross-cutting 17 CCSDS StandardsLayer SM+C, Nav, SM, SANA, etcApplication SM+C, SM, etcApplication Service Registry-Repository, Data Archive, etc Information Infrastructure AMS, SM+C(MAL),.etcMessaging Middleware Transfer, DTN, IP over CCSDS, etc Network

18. SM&C/CCSDS Mapping from Super-BOF in October 18 Application Layer Messaging Technology Messaging Abstraction Layer Generic Interaction Patterns, Access Control, Quality of Service Mapping of the MAL to encoding and transport Abstract messaging infrastructure Message Abstraction Layer Transport Layer MO Services Layer Common Object Model Identify, Definition, Occurrence, Status Common Services Directory, Login, … Abstract service specification defined in terms of the COM & MAL Functional Services Core, Automation, Scheduling, Time, … Generic service specification defined in terms of the MAL Mapping to implementation language Consumer/Provider Security & SOA / SANA Services (SEA) Messaging Services SIS AMS & SOIS MTS Application Services Time, File,

19. Recommendations for CCSDS Develop a cross CCSDS WG for Information Service Architecture –Adopt, adapt and develop architecture, interfaces and models Standardize common information services and components –Much of this is being done right now in SEA and MOIMS and these efforts should be brought together and harmonized –Define standard interfaces –Higher order/application layer standards should be built on lower level standards –Define what is a service (constraints, QoS, behavior, …) and related architectural principles Adopt common meta models that prescribe CCSDS interface to CCSDS services Develop a cross CCSDS information model that is derived from the CCSDS Reference Architecture –WG models/schemas should be derived from this Select a set of distributed middleware standards for use within CCSDS to support service deployment Show SOA pattern differences between ground and flight 19

20. References [1] Recommended Practice for Architectural Description of Software-intensive Systems, ISO/IEC 42010:2007. [2] Reference Model for Open Archival Information System, CCSDS 650.0-B-1, January 2002. [3] Consultative Committee on Space Data Systems. Information Architecture Reference Model. CCSDS 312.0-G-1, Green Book, 2006. [4] Geospatial Portal Reference Architecture. Open Geospatial Consortium Inc. 2004- 07-02. [5] Web Services Architecture. W3C Working Group Note 11 February 2004. [6] Design an SOA solution using a reference architecture. IBM. 28 Mar 2007. [7] Chen, Peter Pin-shan. The Entity-Relationship Model: Toward a Unified View of Data. ACM Transactions on Database Systems, 1976. [8] OMG Unified Modeling Language (OMG UML), Infrastructure. Version 2.2. OMG Document Number: formal/2009-02-04. February 2009. [9] OMG Unified Modeling Language (OMG UML), Superstructure. Version 2.2. OMG Document Number: formal/2009-02-02. February 2009. [10] ISO 10303-11:2004 Industrial automation systems and integration -- Product data representation and exchange -- Part 11: Description methods: The EXPRESS language reference manual. [11] Patel-Schneider, Peter F.; Horrocks, Ian; Patrick, Hayes (10 February 2004). "OWL Web Ontology Language Semantics and Abstract Syntax". World Wide Web Consortium. http://www.w3.org/TR/2004/REC-owl-semantics-20040210/syntax.html. April 2010. 20