1 May 2010 CCSDS INFORMATION SERVICE ARCHITECTURE CONCEPTS.

1

May 2010

CCSDS INFORMATION SERVICE ARCHITECTURE CONCEPTS

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

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

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”

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

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

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

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

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

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

Metadata ObjectData Object

Information Object

Has a Has a

describes

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

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

Mapping of space domain functions to an ISA

13

Decoupling of applications/space domain functions fromservices is keyto a developing SOA stylearchitecture

The messaging layer accommodates multiple patterns and approaches for tighter and looser coupling (e.g., Request-Response, Pub-Sub)

Use of common modelsis key to interoperability and reuse

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

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

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

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 Standards Layer

SM+C, Nav, SM, SANA, etc Application

SM+C, SM, etc Application Service

Registry-Repository, Data Archive, etc

Information Infrastructure

AMS, SM+C(MAL), .etc Messaging Middleware

Transfer, DTN, IP over CCSDS, etc

Network

SM&C/CCSDS Mapping from Super-BOF in October

18

ApplicationLayer

Messaging Technology

Messaging Abstraction Layer

Generic Interaction Patterns, Access Control, Quality of Service

Mapping of the MAL to encoding and

transport

Abstract messaging infrastructure

MessageAbstraction

Layer

TransportLayer

MO ServicesLayer

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 / SANAServices (SEA)

Messaging ServicesSIS AMS & SOIS MTS

Application ServicesTime, File,

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

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