"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 - Engineering Viewpoint


The Enterprise, Information, and Computational viewpoints describe a system in terms of its purposes, its content, and its functions. The Engineering viewpoint relates these to specific components linked by a communications network. This viewpoint is concerned primarily with the interaction between distinct computational objects : its chief concerns are communication, computing systems, software processes and the clustering of computational functions at physical nodes of a communications network. The engineering viewpoint also provides terms for assessing the “transparency” of a system of networked components – that is, how well each piece works without detailed knowledge of the computational infrastructure.

SEEGrid is a SOA that allows for a great deal of flexibility in how services and data are deployed. The actually deployment of processing services, data and applications will evolve as efficiencies and organisational responsibilities become clearer. SEEGrid will focus on ensuring the standards to be used allow the components to be deployed anywhere in the network. Thus, a portrayal service (visualisation) may occur within a modelling package, in a separate network service, in an application service or in a user's browser environment. SEEGrid needs to ensure that the semantics of the data and the process are well enough defined so that all these options are possible, and let component owners, software builders and network optimisation issues resolve the "best" way of solving a particular problem.

Deployment View

Shared (Authoritative) Components

The following components need to be managed as well-known, authoritative services:


Registries use "catalog" interfaces to support search and retrieval, but are characterised by the "governance framework" that allows a client to pose a meaningful query and interpret the data retrieved. Registries may be centralised or "federated" through harvesting, delegation of queries to "partitions", searched in parallel or linked through referral mechanisms. The exact mechanism is not important, however the commonality of sematics and syntax (interoperability) between registries is critical. SEEGrid will seek to adopt (as a documented community consensus policy) externally provided registry infrastructure as it becomes available, but will establish its own registries and governance models where required.


The semantic framework to support interoperability must be shared, and this means that common vocabularies must be established as web accessible components. Further to this, the relationships between vocabularies as a means of classifying content (data) and as descriptors of structural information elements must be managed (strong vs weak typing), and finally, relationships between registered objects of different types must be managed in an authoritative way. The upshot is a general requirement to manage ontologies, initially at least through registration of normative description (e.g. in OWL syntax) in a register. In many cases, the ontology will actually be the contents of one or more registers.

Ownership and management of common ontologies has always been at the heart of any successful interoperability framework. SEEGrid faces the challenge of identifying an appropriate registry owner to host ontologies, in particular the Feature Type Catalog that are in turn managed or extensible by the SEEGrid community.

Quality of Service

Quality of service is a significant engineering issue in an SOA. Much of the framework for handling intermittently available services and varying network traffic considerations is provided through basic Grid technology. SEEGrid will thus initially focus on developing an understanding of the potential data flows in the domain and characterising these according to data volume, sensitivity, etc. From this it will be possible to work out guidelines for different classes of services which can be characterised by run-time behaviour. What processing components get deployed where will be heavily influenced by the specific problem, and a general approach will need to be identified to aid in maximising reusability of services.

Redundancy, Brokering and Caching

These issues are all critical to a robust, scalable architecture. SEEGrid adopts the pragmatic approach that the first priority is to create semantically robust services that can be replicated, discovered and reused. Ongoing tracking and further analysis of requirements, and probably evolution of the core computing frameworks in this regard, is necesary.

Deploying new standards

The critical success factor of SEEGrid will be the ability to support ongoing adoption and adaption of standards within sub-communities without unnecessarily constraining them, or allowing them to diverge to the point of non-interoperability.

The basic practice proposed is that a baseline of standards is published, and stakeholders invited to register their adoption of each standard. Each sub-community that wishes to adapt or change these must:
  • publish a rationale for a new set of standards, and invite comment for a set period
  • provide a migration strategy that addresses the needs of all stakeholders
  • register all the necessary components of the standard in appropriate formats
  • update the SEEGrid community standards ontology with relationships between new and existing standards
  • provide gateway services to for legacy implementations where necessary (i.e. deploy a "wrapper" service, register stylesheets or vocabulary cross-walks etc)

By following this model, the entire community is alway privy to what has changed and why, and has access to all the resources required to migrate. It also makes it easy for sub-groups to extend to meet business needs, but harder to create a completely incompatible island of technology.

Deployment of wrapper services around legacy technologies (where such services cant support multiple interfaces as a matter of course) means that there will be a mild performance cost for not upgrading, but still a basic capability left for users.

It is also worth maintaining a register of client applications that rely on services so that it becomes possible to contact all interested parties if an upgrade is planned. Thus, if a user doesnt want to register their interest they take their chances with stability.
Back to RoadmapDocument.
Topic revision: r2 - 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).