Project Status > Architecture Issues
The Reference Model of Open Distributed Processing (RM-ODP) (ISO/IEC 10746-1:1998) is an international standard for architecting open, distributed processing systems. It provides an overall conceptual framework for building distributed systems in an incremental manner. The RM-ODP standards have been widely adopted: they constitute the conceptual basis for the ISO 19100 series of geomatics standards (normative references in ISO 19119:2005), and they also have been employed in the OMG object management architecture.
ISO/IEC 10746 specifies an architectural framework for structuring the specification of ODP systems in terms of the concepts of viewpoints and viewpoint specifications.
The viewpoints identify the top priorities for architectural specifications and provide a minimal set of requirements plus an object model to ensure system integrity. They address different aspects of the system and enable the ‘separation of concerns’. Five standard viewpoints are defined:
- The enterprise viewpoint: A viewpoint on the system and its environment that focuses on the purpose, scope and policies for the system.
- The information viewpoint: A viewpoint on the system and its environment that focuses on the semantics of the information and information processing performed.
- The computational viewpoint: A viewpoint on the system and its environment that enables distribution through functional decomposition of the system into objects which interact at interfaces.
- The engineering viewpoint: A viewpoint on the system and its environment that focuses on the mechanisms and functions required to support distributed interaction between objects in the system.
- The technology viewpoint: A viewpoint on the system and its environment that focuses on the choice of technology in that system.
The aspect of a distributed ODP system is handled by the concept of distribution transparency. Distribution transparency relates to the masking from applications of the details and the differences in mechanisms used to overcome problems caused by distribution.
An RM-ODP-based approach has been selected for the design of the GMES HMA Architecture as the primary objectives of RM-ODP like:
- support for aspects of distributed processing,
- provision of interoperability across heterogeneous systems, and
- hiding consequences of distribution to systems developers
are largely coherent with the GMES-HMA objectives.
However, as GMES-HMA will have the characteristic of a loosely-coupled network of systems and services instead of a “distributed processing system based on interacting objects”, the RM-ODP concepts are not followed literally. The main difference is that the “computational viewpoint” is referred to as “service viewpoint” in GMES-HMA.
The proposed architecture is a so-called Service Oriented Architecture (SOA) to which data providers and other HMA service providers will be able to attach their services.
The DAIL services are published as Web Services i.e. services which operations are declared using a WSDL and exchanging SOAP messages with the DAIL clients. Moreover for conveying these messages HTTP is the chosen protocol binding.
The EO DAIL has been decomposed in the following sub-components:
Service Container: It is the run-time environment for executing other EO DAIL components. It provides main functionality for service storage, activation and management and their interactions with other EO DAIL elements e.g. other services, Database and Workflow Engine.
Database: it is the database management system used to store the data needed by the EO DAIL. Database is used by HMA Services (e.g. Monitoring & Control Service) and also by the Workflow Engine to maintain the status of running workflows.
Workflow Engine: this is the core component of the EO DAIL architecture. It is in charge of executing the EO DAIL’s services. The same component provides also the functionality to deploy new services and for monitoring & control the status of running work-flows. It represents the HM instance of the Orchestration Service, Service Registration Service, and Monitoring & Control Service.
User Profile Repository: it is the repository in charge of storing HMA user’s profiles of the EO-DAIL. User profile information includes only authentication information.
Collection Discovery Server: it is the catalogue server storing the list of collections available in the HMA infrastructure. It is the HM instance of the Collection Discovery Service.
Service Discovery Server: it is the catalogue server storing the list of “Human Readable Services” provided by the HMA infrastructure. It is the HM instance of Service Discovery Service.
Service Description Registry: it is the component in charge of maintaining specification of the services available in the HMA infrastructure. It is the HM instance of the Service Configuration Discovery Service.
Catalogue Service, Order Service and Programming Service: these are the HM instances of the Catalogue, Order and Programming services. They are implemented through BPEL scripts and then are run by the Work-flow engine.
Virtual FTP service: component implementing the Virtual FTP Service interface ([AD16]).
User Management: package of infrastructure components in charge of providing to the EO DAIL the following functionalities:
IDP, Identity Provider, for EO DAIL users;
PEP, Policy Enforcement Point, for accessing EO DAIL resources;
PDP, Policy Decision Point, for evaluating EO DAIL policies.
Feasibility Server: component in charge of performing light and coarse feasibility analysis without calling the corresponding ground segment. It includes propagation algorithms for predicting satellite sensor earth track and functionalities for taking into account meteorological conditions.
A Distributed deployment (distributer model) is foreseen for the architecture whereby the policy enforcement and policy management are controlled by the GS as depicted in the figure below. The GS provides the tools to create, store and manage their policies. The policy enforcement point/s (PEP) is/are created at the GS. A local LDAP server may be deployed at the GS.
Through a client the user tries to access a PEP protected resource on the DAIL or GS (The policy specifies that the user must be authenticated)
- The user is required to identify themselves to the IdP.
- The IdP verifies the user and creates a SAML ticket containing authentication and attribute assertions e.g. “IdP x” has authenticated “user y” at “time t”
The PEP protecting the resource recognises the SAML authentication assertion from the trusted authority, maps the user to a local user (if one exists) and verifies if the user is authorised to use the resource.