CCSDS Service Architecture_20100410

Document Sample
CCSDS Service Architecture_20100410 Powered By Docstoc

                 Draft White Paper

                     15 March 2010

CCSDS Information Architecture, Information Packaging and
   Registries, and Service Management Working Groups
Table of Contents
I. Introduction ................................................................................................................................. 3
II. Background/Material .................................................................................................................. 4
    A. Service-Oriented Architectures .............................................................................................. 4
    B. Information Modeling ............................................................................................................ 7
III. Decomposed Architecture Model ............................................................................................. 8
IV. Services and Patterns .............................................................................................................. 10
V. CCSDS Deployments ............................................................................................................... 16
VI. Information Models and Information-Driven Architectures .................................................. 18
VII. Recommendations ................................................................................................................. 20
I. Introduction

The movement towards distributed services architecture has several implications
for the Consultative Committee for Space Data Systems (CCSDS). Primary benefits
include the ability to isolate systems and improve interoperability between
components of a system through loose coupling. Service-Oriented Architectures
(SOA) have become a regularly used name to describe such systems, however, the
critical point is that SOA generally describes an architectural style for composing
such systems. It is the natural progression of systems towards interoperability of
applications and systems across a distributed network.

An information service architecture promotes several goals for the composition of
information systems based on CCSDS standards including:

   1.   Constructing systems through well-defined standard interfaces
   2.   Enabling agency autonomy in their implementations
   3.   Supporting federation of space data system services across agencies
   4.   Supporting service discovery between organizations and agencies
   5.   Enabling loose coupling of services and their implementations
   6.   Supporting reusability and development of common agency product lines

At the same time, development of such system requires coordination on several
fronts including:
    1. Shared messaging infrastructures
    2. Common data definitions of the contents of messages
    3. Common services behaviors
    4. Common service interfaces and methods
    5. Information services to support service registration and discovery
    6. Explicit methods for secure access of services and exchange of information
Within CCSDS, the CCSDS Information Service Architecture is defined as an
architectural pattern that decouples common information services, models and
middleware from applications to improve reuse and interoperability between
applications. It prescribes:
         Common information services and components
         Common meta models
         Common information model
         Distributed middleware

Much of CCSDS standards development can be directly mapped to such an
architecture. However, it is important that CCSDS explicitly embrace and promote
such architecture styles to ensure that its standards and architectural models
embrace the benefits of an information service architecture and move towards
greater interoperability, efficiency and service-reuse both within and across agency
data systems.

II. Background/Material

The standards community has published a number of documents related to both
SOAs [2, 12, 13] and Information Architecture [15]. These standards include
definition of architectural patterns, interfaces and messaging. Much of the patterns
in an information service architecture have existed in various standards over the
years. The Common Object Request Broker Architecture (CORBA), for example,
emphasized the importance of developing standards for the access and invocation of
distributed objects. This standard included mechanisms for describing interfaces
between distributed objects known as the Interface Description Language (IDL).
Such mechanisms have become popular in modern standards such as
REpresentational State Transfer (REST), SOAP (a lightweight protocol for exchange
of structured information over distributed systems), and the Java Message Service
(JMS). Each of these standards provide mechanisms for the exchange and/or
invocation of remote objects and more specifically services. Each provides
mechanisms for describing interfaces. REST and SOAP provide the Web Application
Description Language (WADL) and the Web Services Description Language (WSDL),
while JMS provides a set of standard Application Programming Interfaces (APIs).

From an information services architecture perspective, architecture models for
distributed services are developed and implemented using the distributed
computing protocols. Architectural models such as Reference Model of Open
Distributed Processing (RM-ODP) [9] have been useful for representing distributed
systems in viewpoints that allow for demonstrating the movement towards a
service architecture.

A. Service-Oriented Architectures

Different SOA reference architectures may take different points of view based on the
domains they originate from. We describe three reference architectures from three
different domains (scientific, web, and large-enterprise industrial) that are
particularly relevant for understanding how an SOA-based reference architecture
might be useful for CCSDS. First, the Geospatial Portal Reference Architecture [12]
is an SOA for sharing data in a scientific domain. Second, the World Wide Web
Consortium (W3C) takes a four-model perspective of a web services SOA [13].
Lastly, the IBM nine-layer SOA reference architecture [14] describes a software
industry-oriented perspective of SOA reference architectures.
The Geospatial Portal Reference Architecture [12] specifies an SOA for sharing
geospatial contents, maps, and metadata across organizations over the Internet.

                  Figure 1: The Geospatial Portal Reference Architecture [12]

Figure 1 depicts the major services of the Geospatial Portal Reference Architecture.
The Portal Services provide access to the users and administrators of the system
through a client. The Catalog Services store metadata and location information
about geospatial services. The Portrayal Services process and prepare geospatial
information for presentation/visualization. The Data Services process and provide
geospatial data stored in repositories or databases.

The World Wide Web Consortium (W3C) takes a four-model perspective of an SOA
depicted in Figure 2 [13]. The Message Oriented Model is concerned with the agent
that sends and receives messages, message structure, and message delivery
mechanisms. The Services Oriented Model describes the relation between
messages, the agents exchanging them, the metadata describing services, and the
organizations or persons owning or controlling the services. The Policy Model
focuses on the constraints on agents and services in terms of their access to
resources. The Resource Oriented Model is concerned with resources described in
terms of the architecture of the Web and the persons or organizations owning those
                    Figure 2: W3C Service-Oriented Architecture Model [13]

The IBM SOA Reference Architecture shown [14] in Figure 3 depicts a nine-layer
reference architecture for SOAs. The service consumer is concerned with the
Consumers and Business process layers, while the service provider is concerned
with the Service components and Operational layers. Both the consumer and
provider are concerned with the Services layer. The Operational layer contains
existing applications over which the components in the Services components are
built upon. The Services layer contains services, which are one or more functions
that are accessible through interfaces made available across a network. The
Business process layer contains entities called processes, which invoke services in
the Services layer in a particular logical sequence. The Consumers layer contains
entities that provide the presentation or visualization of information that are
accessible by users through clients. The Integration layer subsumes the previously
described layers by providing the transport and routing services that allow
exchanging of data between service consumers and service providers. The QoS layer
provides mechanisms that help ensure different qualities of services such as
security, maintainability, and reliability. The Information architecture layer captures
metadata and data structures that can span industries or be industry-specific.
Finally, the Governance layer provides functionality that allows for management of
the SOA throughout the business lifecycle.
                  Figure 3: IBM Nine-layer SOA Reference Architecture [14]

B. Information Modeling

The development of information architectures is critical to enabling
interoperability. Significant work has been done in developing domain specific
information models as a means for describing information objects [ref]. Within
Planetary Science, work has occurred by the Planetary Data System to develop a
domain model for planetary science. Likewise, for other domains, there has been
work in science, engineering, and business to construct these common information
models. Healthcare, for example, uses standard models such as Health Level Seven
(HL7), Systematized Nomenclature of Medicine (SNOMED), and the International
Classification of Diseases – 9th Revision (ICD9) to normalize vocabulary and other
standards terms. Within business-to-business communications, there are standard
models for the exchange of information.

Within the space domain, those standard models need to be developed. As
mentioned, there has been some work on standards within the scientific
community, but there has been little effort to develop common models for sharing of
information across the end-to-end space data system. One of the major challenges is
the governance of such models within distributed communities. The development
of these models, given diverse organizations, can be difficult because of varying
perspectives and needs. However, such models are critical to improving systems
and interoperability.

Another challenge is the use of common nomenclatures for representing and
managing models. While there has been a variety of different methods to express an
information model [16, 17, 18, 19], there is little convergence on how such models
are best managed. Emerging standards in the area of the semantic web (e.g. the
development of standard ontologies and ways to express them) is helping to
emphasize the importance of standards for information architecture and
mechanisms to capture the semantics when describing a data object. However,
many of these standards are still in their infancy and the modeling is still left to the
graybeards who understand the domain. It is also critical to separate the
implementation from the information architecture such that model can evolve with
the organization. What is needed by an organization such as CCSDS is the ability to
define an over-arching information model that encompasses the CCSDS areas and is
implementation-neutral. This will help to provide guidance for the development of
models within each of the CCSDS working groups such that those models are
derived from a core, upper-level model and expressed as a model (e.g., Unified
Modeling Language (UML) [17, 18]) vs. an implementation language/schema (e.g.,
Extensible Markup Language (XML)).

III. Decomposed Architecture Model

The ISO/IEC 42010:2007 (formerly, ANSI/IEEE 1471-2000)Recommended Practice
for Architecture Description of Software-Intensive Systems defines architecture as
“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]. From a CCSDS information service architecture
perspective, the architecture encompasses three critical views, based on the
reference architecture being developed within the CCSDS Reference Architecture
BoF [11], which include
     Functional View
     Information View
     Services View

Within CCSDS, for the information view, we recommend that any information
system explicitly define its information architecture using a well-specified
information model. This includes definition of the information objects [Open
Archival Information System (OAIS) [5], A Reference Architecture for Space
Information Management (RASIM) [6] ] that are captured and exchanged within and
among interoperable systems and applications. The information objects are based
on common and domain-specific models that govern definition of the semantic and
syntax of their content. Well-designed systems that exchange information across
distributed services need to ensure that their interfaces and the content that is
exchanged across these interfaces is governed by explicit information models.
Mechanisms for describing models and deriving objects from these models are
further explained in section VI.
Second, the functional view provides a set of standard components and
infrastructure services that allow for construction of distributed systems. We use
the term components to mean any modular element of a software system. We use
the term service to mean an application that is constructed from a set of
components that is deployed within a distributed system. Services include both
generic information infrastructure services such as registries, repositories, and
messaging services, and domain specific services. Within distributed systems
services are used to support flexible deployment of software systems with standard
interfaces that support the access and exchange of information as well as
computation. For data and information oriented, systems, standard components
that capture, register, discover and exchange information is critical.

Figure 4 below shows an abstract diagram that separates the conceptual elements
contained in the data architecture/content (top layer), the functional information
services/components (software/application layer), and the
messaging/communications layer that are typically found in an information service
architecture. These separations are critical for allowing flexibility in architecting
distributed systems for multiple domains. It also shows the importance of achieving
interoperability at each layer by ensuring standards are in place. At the data
architecture layer, these are standard models and meta-models. At the
software/application layer it is the introduction of standard software interfaces and
APIs. At the messaging layer, it is the standardization of protocols and messaging.

    Figure 4: Decomposition of information and functional elements of an information system in a
                  distributed environment showing interoperability at each layer

Finally, the services view allows for definition of services, particularly domain-
specific services. These domain-specific services should be built on the atomic
components defined in an information service architecture. Layering domain-
specific services on top of an information service architecture allows for moving
domain services into a distributed, information-driven architecture. As CCSDS
moves to more of a distributed architecture, it is critical that application layer
components be built that leverage explicit distributed computing principles to
support their deployment as distributed services within an agency or multi-agency
model. Figure 5 below, shows the relationships of services, based on the OASIS
Reference Model for SOA v1.0 [2] definition.

                       Figure 5: Service Description conceptual model

IV. Services and Patterns

From a functional view, a service-oriented architecture encapsulates services so that
they expose messaging interfaces that allows for their functions to be accessed and
executed over the network. Figure 6 provides logical/static and runtime views of a
service-oriented architecture that shows a set of components that are used to
enable interoperability between distributed applications through a messaging
     Figure 6: Static View (left) and Runtime View (Right) of an Information Service Architecture

Popular architectural patterns in an information service architecture involve
pub/sub vs request response as well as more granular patterns such as
Client/Server, Model-View Controller (MVC). These patterns have been
implemented in various ways emphasized by separating the service layer from the
application layer. They employ services that are decoupled from applications
allowing for access to computational and information services that can be
provisioned both within and between enterprises. Critical to accessing these
services is defining standards that allow for their use is a common manner.

Within CCSDS, we have a similar architecture and a need to both provision services
and define standard interfaces for their use. The CCSDS Information Service
Architecture is critical to decoupling common information services, models and
middleware from applications to improve reuse and interoperability between
systems. It prescribes:
        Common information services and components
        Common meta models
        Common information model
        Distributed middleware
        CCSDS space domain-specific services
The services aspects define a number of common services supporting various
patterns that are crucial to implementing a distributed information system. While
space-domain specific services are critical to supporting the business of the capture
and exchange of space information objects, common information services are
necessary to enable such exchanges cross enterprises. These services include:
    Registries
    Repositories
    Messaging
    Orchestration

Registries provide for the registration of information objects and services. This
includes registration of models, data or services that enable discovery, information
sharing and computation. Within the context of an information services
architecture, a service registry is critical to registering the existence and access
points for services such that client applications can discover and bind to such
services. Several standards exist that allow for registration of services including the
Universal Description Discovery and Integration (UDDI) and the Electronic Business
using eXtensible Markup Language (ebXML). These standards prescribe
mechanisms that allow for the annotation and registration of services such that they
can be discovered both by humans and remote applications. One of the critical
advantages is allowing for logical-to-physical mappings whereby applications use
logical identifiers to request access to services and are returned a physical entry
point, which is necessary for binding to that service.

In addition to service registries, the general concept of registries are important
because they allow for registration of both models and their associated attributes as
well as actual information objects. Model and metadata registries allow for
registration of the components of a model including data elements, relationships,
schemas, and the like. This is important in enterprise scale applications because
common models are necessary to support exchange of information in a consistent
manner. Such exchanges, whether messages or content, should be derived from
models that support both the messaging and domain in which the application is
running. Within CCSDS, messages should be built on top of standard messaging
models and the content should be specific to CCSDS, built on common CCSDS
information models that support such areas as service management, navigation,
mission operations, etc. Registration of the Extensible Markup Language (XML)
schema and associated elements, are important to ensure applications are sharing,
using and build schemas that are captured and versioned in common registries.
Figure 7: Space domain functions and information services in a distributed environment
At the information object level, information objects should also be registered in
registries that provide common interfaces within distributed environments that
support access and sharing as needed to meet the business cases. Examples within
CCSDS include capture and sharing of spacecraft identifiers and other standard
values. More broadly, within mission operations, capture and sharing of engineering
and science data can also be performed using common registries such that the data
can be shared and accessed both within an enterprise and by federated partners
such as other space agencies.

Registries and repositories are highly related. While registries provide mechanisms
for discovery and access, repositories provide mechanisms for the physical storage
of information objects. While multiple patterns exist for the implementation of
registries and repositories, a critical pattern is the registration of metadata portion
of an information object with the data object being stored in a repository.

Figure 7 shows the form of communication between common services and models
to CCSDS-related functions. Each of the mission-oriented functions can be
instantiated with a common set of information services coupled with information
models for their local deployment. These models dictate the structure, organization
and content of the information objects that flow between space domain functions.
What is missing is how this is distributed. However, as stated early as one of the
core principles of a distributed information service architecture, the decoupling
between the space domain functions and the backend services is critical to
supporting an integrated enterprise that involves distributed operations.

Messaging services within an information services architecture are key to
decoupling the application from the service layer. Messaging services carry
requests between clients and servers that both support the messaging interface. As
mentioned, both request response and publish/subscribe models are applicable to
CCSDS. Request/response patterns are largely built around standard messaging
protocols whereby applications subscribe to events that are notified when those
events occur. In this case, applications and other clients of the services run
asynchronously with a thread of execution that monitors a message queue and acts
on the message when it arrives. This pattern is often referred to as an enterprise
service bus (ESB) because applications and clients plug into and are notified via a
conceptual software bus by standard messages. The Java Messaging Service (JMS) is
a popular messaging specification that is supported by several vendor and open
source efforts for implementing a messaging bus. Enterprise buses are often tightly
coupled and employ orchestration mechanisms which are discussed later. This can
be advantageous to a tightly integrated environment, but less advantageous in
scenarios where multiple enterprises need to be loosely coupled. Figure 8 shows the
concept of an enterprise bus.
                  Figure 8: Information Services Connected to a Software Bus

In contrast to the ESB publish-subscribe model is the the RESTful request-response
model, where RESTful refers to a model that conforms to the style of REST. This
model is organized for loosely coupled environments, which significantly
contributes to the great scalability of systems like the Web. This pattern is generally
synchronous in that a client sends a request, is blocked, and then a result is
returned. However, the RESTful request-response model is increasingly
incorporating client-side non-blocking mechanisms and is becoming more prevalent
in sharing data between enterprises. The science community, for example, is largely
employing RESTful approaches for sharing scientific data across scientific data
systems. This model also has less orchestration in that in many cases of the modern
World-Wide Web (WWW), state is not maintained between subsequent calls. Web
Service (WS) standards including SOAP and REST have been built on top of the
standard Hypertext Transfer Protocol (HTTP ) of the WWW. Each of these employ a
request-response pattern. The SOAP-related standards, known as the WS stack,
provide quite a bit of sophistication in terms of supporting a variety of standards
from security to messaging. The REST-related specification is generally viewed as an
extension of HTTP with simple messaging intertwined in the request and response
as shown in Figure 9. Both are deployed and both have their benefits and uses.
       Figure 9: REST-based distributed architecture with information services on
       the backend

In both the above messaging patterns (RESTful request-response, ESB publish-
subscribe), the message protocols are critical to supporting the enterprise. At the
protocol level, there are standard specifications, but what you run on top of those
specifications in terms of the type of messages and their content, needs to be
specific to the domain. As such, it is important with CCSDS to both define the
architecture as well as identify the messaging patterns, protocol and content that
are needed to support space-domain related functions.

Orchestration allows for a set of functions to be executed in a distributed
architecture following a set of rules that are instantiated as part of the messaging
system. In a publish-subscribe pattern, orchestration allows for events to be
triggered based on a specific workflow such that services are invoked and accessed
in a coordinated manner. This is important for developing domain-specific
workflows that directs the execution of services. Within CCSDS, the use and
deployment of a service architecture benefits from employing orchestration as
engineering and science data move through end-to-end space data system pipeline
executing generation and capture of command, engineering and science data

V. CCSDS Deployments

Figure 10 below shows a layered view of the CCSDS-related services abstracting out
the messaging middleware, from the information infrastructure. This is followed by
the application services and application. CCSDS is involved in the development of
standards at each of these levels. It is important, however, that CCSDS considers
how these standards fit into an organized, distributed information service
architecture as described in this white paper. Table 1shows a potential mapping
between the layers presented in Figure 10 and the CCSDS standards areas. The
critical point is that 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.
               Figure 10: Information Service View of the CCSDS Layered Stack

            Table 1: CCSDS Standards Efforts to Information Service Layer Mapping

CCSDS Standards Effort                         Layer
SANA                                           Application
SANA                                           Application Service
Service Management
Spacecraft Monitor & Control
Registry-Repository Standards                  Information Infrastructure
Data Archive Standards
Asynchronous Messaging Service (AMS)           Messaging Middleware
Transfer Services…?                            Network Protocol Layer
Security                                       Cross-cutting (Application, Service,
                                               Messaging Layers)

                                                                 Has a                  Has a
The separation in the architecture that is
presented is intended to ensure separation
of critical elements to support deployment               Data Object
                                                                                  Metadata Object

and movement towards a CCSDS
information service architecture. This
     Identifying standards related the         Figure 11: Information Object Concept
        messaging middleware so
        applications, infrastructure and services can be decoupled
     Standards related to the definition of application services
     Standard information infrastructure components that form the basis for
        application services
     Common models and meta models that support the exchange of information
        between application services

Section VII provides recommendations on a roadmap for CCSDS to move this

VI. Information Models and Information-Driven Architectures

The information architecture aspects of a service architecture is critical to moving to
data-driven approaches. This is particularly important in a distributed information
system where information objects are exchanged across application environments
through well-described interfaces, as has been discussed. In data-driven
approaches, services are configured by the information_model, continuing to
support the notation of a loosely coupled system. As a service architecture is scaled
across an enterprise, the need for moving towards data-driven approaches
increases. This particularly true for CCSDS which needs to ensure that the content
being exchanged across end-to-end space system is not embedded in the core
software, but rather described at the content layer. As such, the architecture
prescribes exchange of information objects on top of services.

An information model consists of a set of data models. Each data model defines what
is needed to describe the meaning of the data and how it is organized and
structured. At its simplest an information model is a set of classes, class attributes,
and class relationships.

The process of modeling involves applying a specific information modeling theory to
create information models that meet the specified requirements. For example a data
model for a magnetometer time-series data product must prescribe the information
necessary to make the data scientifically useful. This information might include data
structure, provenance, and the location and context within which the data was

Examples of data modeling theory include the Entity-Relationship (E-R) Model, the
Unified Modeling Language (UML), and ontologies based on the Web Ontology
Language (OWL). Ontologies in particular are useful for modeling complex scientific
domains and allow for the capture and organization of semantically rich information

To implement a data-driven service architecture, each data item must be modeled.
Subsequently the model must be used to collect and validate the prescribed
information. In addition, complex scientific research networks such as that
supported by the CCSDS poses special challenges. For example, the information
model must change in pace with the evolution of the scientific research and
technological methods of the domain. The technology used to implement the
information system will change at a different speed, frequently faster, than the
domain. This requires that the information model must remain independent of the
technology, languages, or notations into which it is implemented or expressed.

In addition, the information model must be scalable to handle increases in size,
sophistication, and complexity of the underlying domain. It must also be responsive
by maintaining the upper bound on the semantic richness needed for capturing
domain knowledge. It must also allow the export of its information to diverse
notations and languages for use by both machines and humans for processing and
documentation respectively.

Two common requirements for data systems are the need for science data system
interoperability and science data correlation. Shared data standards are
fundamental to meeting these requirements. The Information Object is a model that
prescribes the metadata needed to describe a data object - an instance of actual data
such as the time series above - so that it is useful both for current and future users.
Information objects are defined to include both the metadata and the data as shown
in Figure 11. The metadata needs to be defined and maintained by a domain model
as shown in Figure 12. Within CCSDS, we define the domain model to include a
schema and attributes that are specific to the domain (e.g., navigation, service
management, etc). However, the current practice is generally that each domain
within CCSDS maintains and publishes their own schema. There is no regard to how
these fit together and they are often maintained as a pseudo information model
within the specification language itself, such as XML schema. What is needed is to
derive those schemas from a CCSDS set of information models that are maintained
in a modeling environment. Derivation of information objects from the domain
model is critical to supporting interoperability. While the services provide the
functional capabilities necessary to discover, access and exchange information, the
content of the information that is exchanged needs to be derived from the model.
Furthermore, how the model is organized can be further defined by a standard
governing meta-model.

               Figure 12: Relationship between information architecture concepts

What Figure 12 is communicating is that 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.

VII. Recommendations

Movement towards a distributed information service architecture is strategic for
CCSDS. It allows for improving interoperability between services and applications
while abstracting away local implementations such that they can be agency or
application specific. It is recommended that CCSDS adopt such a strategy. However,
this impacts how services are defined and ultimately how systems are deployed. It
also impacts how the interfaces between services are defined. This includes the
definition of the functional interface as well associated structure of the information
that will be exchanged through those interfaces. In addition, services which will
enable exchange of information are all necessary to support discovery and access.

Therefore, it is recommended that CCSDS initiate a cross-CCSDS working group that
will focus on:
•       Standardizing common information services and components
•       Adopting common meta models that prescribe CCSDS interface to CCSDS
•       Developing a common information model that is shared across CCSDS
•       Selecting a distributed middleware standard for use within CCSDS

A distributed information service architecture is the next evolution for moving
towards truly multi-organization, multi-agency data systems. Standards should fall
out of the architectural models, and common patterns should be established for the
deployment of these architectures into agency systems.

IX. References

[1] Recommended Practice for Architectural Description of Software-intensive Systems,
ISO/IEC 42010:2007.
[2] Reference Model for Service Oriented Architecture 1.0. OASIS Standard, 12 October
[3] Practical Guide to Federal Service Oriented Architecture (PGFSOA) v1.1, June 2008.
[4] Information technology—Metadata registries (MDR)—Part 1: Framework.
International Standard, ISO/IEC 11179-1:2004. 2nd ed. Geneva: ISO, 2004.
[5] Reference Model for Open Archival Information System, CCSDS 650.0-B-1, January
[6] A Reference Architecture for Space Information Management. Pasadena, CA : Jet
Propulsion Laboratory, National Aeronautics and Space Administration, 2006.
[8] Federal Enterprise Architecture Framework (FEAF), Version 1.1, 1999.
[9] Reference Model on Open Distributed Processing (RM-ODP), ISO 10746, 1998.
[10] The Open Group Architecture Framework, TOGAF 8.1.1, 2006.
[11] CCSDS Reference Architecture White Paper, 2010.
[12] Geospatial Portal Reference Architecture. Open Geospatial Consortium Inc. 2004-
[13] Web Services Architecture. W3C Working Group Note 11 February 2004.
[14] Design an SOA solution using a reference architecture. IBM. 28 Mar 2007.
[15] Consultative Committee on Space Data Systems. Information Architecture
Reference Model. CCSDS 312.0-G-1, Green Book, 2006.
[16] Chen, Peter Pin-shan. The Entity-Relationship Model: Toward a Unified View of
Data. ACM Transactions on Database Systems, 1976.
[17] OMG Unified Modeling Language (OMG UML), Infrastructure. Version 2.2. OMG
Document Number: formal/2009-02-04. February 2009.
[18] OMG Unified Modeling Language (OMG UML), Superstructure. Version 2.2. OMG
Document Number: formal/2009-02-02. February 2009.
[19] ISO 10303-11:2004 Industrial automation systems and integration -- Product data
representation and exchange -- Part 11: Description methods: The EXPRESS language
reference manual.

Shared By: