"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

SEEgrid Roadmap - Computational Viewpoint



The computational viewpoint is concerned with the functional decomposition of the system into a set of services that interact at interfaces.

The SEEGrid computational architecture has two main challenges:
  1. Identify the necessary components
  2. Identify suitable interfaces between these components

The SEEGrid architecture will draw on "mainstream IT", with particular reference to those initiatives that address interoperability across enterprise boundaries.

This section will identify key patterns and relevant standards, and pay particular attention to the additional considerations that must be supported by the SEEGrid architecture by the addition of appropriate layers of the architecture.

Service Oriented Architectures

The basic SOA model is shown in Figure 1.

pub_find_bind.gif

Figure 1: Service Oriented Architecture: Publish/Find/Bind Pattern

Of particular note is that in mainstream IT, business functions are essentially unbounded, and thus there is an assumption that a Developer will find it necessary to create customised code to access a service. The SEEGrid architecture (in line with the SDI model) will seek to constrain service interfaces so that certain types of services are *interoperable.*This means that data access services will become standardised and a software framework can be established.

The SEEGrid architecture also adopts a key principle from ISO19119 and the OGC-RM: a service can have multiple interfaces . This means, for example, that a given business function can support multiple information views (e.g. as a feature collection, a coverage or a controlled vocabulary) and multiple " Distributed Computing Platforms " - i.e. technical implementations. Consequently, whilst there is a need to fully implement at least one DCP profile of component interfaces to ensure that services will interoperate semantically, specific functions can be integrated with external systems or specialised workflows. Thus the most likely pattern is to ensure that each component has at least one common mandatory implementation and optional alternatives. If it proves necessary SEEGrid itself can then undergo coherent evolution through versioning of the mandatory profiles.

The key Service Oriented Architectures of note are those promoted by the W3C, UDDI and ebXML communities, and the Open Grid Services Interface. There are a number of harmonisation efforts under way and a new approach recently published (WSRF - Web Services for Resource Frameworks) that seeks to bring the state-ful nature of GRID processing into a position where it is an extension of the W3C Web Services work (SOAP, WSDL)

The actual drivers for the decisions rest in the business issues (Enterprise Viewpoint) and deployment practicalities (Engineeering Viewpoint), but this viewpoint must establish the basic principles, feasibility, starting points and approaches to sustainability of the computational aspects.

The notional architecture section below describes the components, and how they might be partitioned. The interfaces between them will be based on the "stack" of standards shown in Figure 2. Note that standards are largely described by functional behaviour with current best practice implementations highlighted in (parentheses). Note also that care has been taken to separate the protocol functions from the content and metadata encoding standards.

Figure 2

Figure 2: "Layer" view of key protocol and content description standards

Thus, the SEEGrid architecture can be seen as a layering of standards and efforts, with each layer potentially evolving, being replaced or augmented by alternatives, yet the overall effort of creating a series of semantically interoperable capabilities involving a very specific set of challenges.

Notional architecture

Figure 3 shows the key components required to implement the SEEGrid framework. The interfaces between these components are based on the suite of protocols and content encodings as per Figure 2.

components.gif

Figure 3: Notional Component Architecture

An animated version of Figure 3, highlighting specific examples, is available:

Points to note:
  • Each component may have multiple deployed instances
  • Each component may support multiple bindings of interfaces to technologies
  • All interactions are governed by the same set of rules
  • The diagram clearly shows which content and metadata types are managed as registries (using common community data models and semantics) and which can be provided by data access services that merely need to conform to the published data model. (in other words, the registry contents define the semantic scope of SEEGrid)
  • Models and Observational data are regarded as equivalent
  • Feature Collections may provide ontologies in thier own right - for example a set of named phenomena may be used to classify other resources
  • Model management is seen as an exercise in creating and publishing service chains and results. There must be a tight coupling between the service chaining framework and the registry model, consistent with other forms of data classification.
  • There is an implicit relationship between Feature Type Catalog, Features and Coverages, as explained in the Information Viewpoint

Overlapping GRID Infrastructures

GRID infrastructures will tend to deliver a set of functional services, to a community defined by jurisdiction and domain. Thus, the UK NERC DataGrid will deliver data access services to the stakeholders of Natural Environment Research Council (both as clients and providers).

SEEGrid will thus establish interconnectivity at both a technical and governance level with key GRID infrastructures. The first priority for SEEGrid will be to establish a "DataGRID" capability to allow the exploitation of emerging computational GRID capabilities, and the semantic interoperability with specialist modelling facilities and academic networks.

[more details and Louis Moresi's pic in here - have contact him to ask for it.]

Integrating Suites of Interface Standards

The discussion above shows the key components and a functional breakdown of technical standards. SEEGrid will be based, in practice, on "suites" of interface standards that meet the minimum requirements:
  • managed by a transparent and robust process
  • logically consistent with SEEGrid requirements
  • implemented (inc planned or implementable) by available software
  • preferably supported by open source "reference implementations"
  • provide a significant advantage for at least some interoperable services over alternative options

The key suites of interface standards of interest are the Web based SOA components of
  • ISO 19000 series
  • ISO 15000 series (OASIS ebXML)
  • W3C transport oriented protocols and metadata (HTTP, SOAP, WSDL etc)
  • OpenGIS Consortium interfaces (as per ASDI policy)
  • WSRF : Web Services Resource Framework (aka Open Grid Services Architecture)

The key suites of "content" standards are
  • W3C XML
  • W3C OWL
  • OGC GML (aka ISO19136) (especially XMML as a developed application schema)
  • NetCDF - used for existing "packaged" information products

The roles and layers described above are critical to understand how these standards interact and in fact are mutually interdependent. SEEGrid will provide the mechanism to adopt technical standards as they prove their usefulness and ability to "map" onto the semantics of the overarching Service Oriented Architecture. The logic here is that if the semantics can be mapped then it is possible to build a data converter or gateway service between components. The onus is however on the proponents to provide the formal semantic mapping and sample gateway or data conversion services for broader SEEGrid community to be able to evaluate the option, and then adopt if advantageous.

SEEGrid will maintain a Web accessible formal ontology of such standards and tools to map between them, so that it will always be possible to identify how possible standards can be applied, and also the preferred options for interoperability within the SEEGrid community.

Many of these mappings are obvious or being explored as part of the standards tracks themselves. SEEGrid will nevertheless introduce an "information community" perspective into these efforts, and doubtless be required to pioneer some level of implmentation, refinement and community consensus approaches.

The key mappings to be explored within the next phases of SEEGrid are:

Phase 1b:

  • GML application schema / OpenGIS WFS implementations

Phase 2:

  • GML coverages using native NetCDF encoding
  • GML application schema to OWL ontology
  • OWL ontologies to ISO/OGC/ebXML registry concepts (Feature Type Catalog)

Phase 3 (in collaboration with NERC)

Topic attachments
I Attachment Action Size Date Who Comment
NotionalArchitecture.pptppt NotionalArchitecture.ppt manage 41.5 K 10 May 2004 - 10:49 RobAtkinson Animated powerpoint showing notional architecture
arch.pptppt arch.ppt manage 33.5 K 15 Apr 2004 - 10:24 SimonCox Source for figures 1,2,3
Topic revision: r3 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).