Note: this document now deprecated in favour of three others, starting with ArchVision^?

AstroGrid Architecture

This doc will contain notes of my own about the AstroGrid Architecture, hopefully helping Keith pull together a formal architecture document.

I have already finished some notes on registry structure. This one will start at the other end - a domain model and work downwards.

Periodically, I will attach a zipped up version of the Together model I'm using to generate the pics: model.zip

Vision

A few words about my vision of what the VO is and how it will work. I've often likened the VO to the web. No-one owns it, it doesn't really exist as a separate entity, but it works. It works because there are standards such as http and HTML which everyone more or less adheres to. The VO ought to be the same: we will have standards about how components interoperate, what must happen for an entity to be recognised as a player in the VO etc. But beyond that, everyone must be free to come up with their own implementations. In this way, the VO can expand and evolve, hopefully as quickly and as effectively as the web.

To enable this vision, though, requires an understanding of what the VO is, what it is or will be or can be made up of and where we need standards stating how it all fits together: ie, an architecture. Hopefully, this document and the official AstroGrid one which derives from this will be the first steps in the creation of that architecture.

Domain model

AG started with a domain model (see rbAgDomain.gif) but this picture ended up focussing on the domain of astronomy rather than that of the virtual observatory (VO). The VO is largely an information system which just happens to deal with astronomical information. It will be the tools that work on top of the VO infrastructure which enable astronomy to be done, not the infrastructure itself.

We've been working with the original component diagram, as represented in the Phase A Report for some time now.

I'd like to simplify that diagram a little into one which represents the core domain entities of any VO (as envisaged by AstroGrid).

Entities

As is obvious, this diagram is based on the component one, drawing multiple entities into one. A brief description of each entity:

• Registry : maintains a list of resources known to the VO
• Community : manages aspects of VO to do with people, organisations, projects etc
• Portal : the user interface to the VO, whether server/web-based or client-based
• Security : to do with authenticating and authorising users and permissioning access to resources
• Workflow : doing work on the VO, either immediately or by constructing and running jobs
• Messaging : passing messages between components
• Data Access : how access to data is enabled
• perSpace : a virtual directory of user owned information space
• Tools : any service which can be activated (or plugged into a workflow)

Links

It is in the links between the entities where VO interoperability will be enabled. Document and message exchange formats and protocols must be standardised if the components created by the different VO projects can work together and, for any user, replace one another.

Core entities

There are many ways to picture the domain space of a VO system. The one above is very simplistic and is component focussed, ie based on the likely major components of such a system. There may be over-simplification in this model: the Workflow component includes workflow construction and job control which are quite distinct; Tools covers a wide variety of different types of software component; Security encompasses both user authentication and the access policies for resources. At least this approach is a start and will enable people to picture both the way AstroGrid is structured and one possible generic architecture for the VO.

Registry

The registry is the source of metadata for any resource in the VO. Three terms in that statement deserve further explanation:

Resource:

A resource is anything that might be used or referenced by any user, agent or component of a VO system. Resources include, as expected, services such as those which provide access to datasets or images, those which will analyse or reduce data, those which provide visualisation of data etc. Other resources will include people, organisations, projects, groups of people etc. AstroGrid will also want to register items such as files and tables which are managed under the MySpace^? virtual storage system (referred to in this document by the generic name of MySpace^?).

Metadata:

Metadata are items of information used to describe a resource. So all resources will include some identity information, a service will be described by curation information (who created and publishes the service, a URL for more information etc.) and means of invocation, a specific data access service will include coverage information and information about data itself.

Source:

That a registry can provide all this metadata does not mean that every registry must store every piece of metadata about every resource. A registry may choose to only store certain classes of resource or to only store the metadata for a select number of resources (the difference being that the list of resources in a class will grow as such resources are added to any registry in the VO while the select list will only grow as teh curator of that registry adds to it).

Resource Identity

A resource will be identified by a ResourceID, consisting of an AuthorityID (which looks like a domain URI) and a RegistryKey (which looks like a path). In xml form this looks like:

   <ResourceID>
      <AuthorityID>...</AuthorityID>
      <RegistryKey>...</RegistryKey>
   </AuthorityID>

and in string form:

   ivo://AuthorityID/RegistryKey

An authority is owned by some person or organisation. They will register it with a Registry and from then on, only that registry will be permitted to register a resource on the VO with that authority (to ensure that this happens, every registry will be required to 'know' which authorities have been registered at all other registries). It will be up to the registry implementation to ensure that only the authority owner (ie the person who registered it) can add resources to the authority.

Structure

At the moment (26 Jun 2003), the structure of the registry is under debate within the IVOA (see TonyOnRegistryStructure) but AstroGrid will implement three separate registries:

• Services
• Community
• MySpace

but all three will conform to the IVOA standard (with AstroGrid-specific extensions).

Community

The Community entity encompasses everything to do with people, groups, organisations and projects. The main goal of creating a community is to allow access to resources to be controlled by groups, projects or organisations and for those groups to decide which people will belong to the group.

In general, a community will consist of:

a registry: this will conform to the IVOA standards for all resource registries

software

which, in addition to normal registry functions, will allow the management of groups, organisations and projects: creation and deletion, adding and removing members. assigning privileges etc.

space

access for community members to personal MySpace

Registry

The community registry

Structure

MySpace

Portal

Security

There are two key aspects to Security:

authentication

user is who he/she says they are

authorisation

user is allowed to perform the selected action

Authentication

Authorisation

The process of authorising a user to perform an action is in three steps:

• finding the policy document that covers that action
• determining the identity of those entities authorised to perform the action
• checking if the user belongs to one of those authorised entities (usually a group)

The above process might be made quicker if the agent through which the user operates (or which is operating on the user's behalf) 'remembers' or 'is told' which authorised entity the user belongs to so that it does not have to check all of them looking for the user as a member. There must be algorithms in existence which deal with this sort of circumstance.

We imagine that policy documents will be managed by a policy server in much the same way that registry entries are managed by a registry server. So some areas of functionality may be similar. The key difference is that one will search a registry for entries whose metadata match some criteria but one will go directly to a policy server looking for the access policies for a specific item.

Workflow

Messaging

Data Access

perSpace

Tools

Interoperability: Links between entities

Taking the above domain diagram, I've added directed labels to the links to indicates some of the entity interactions that might be of interest and worth explaining:

Portal --lookup>> Community

Portal/Community --authentication>> Security

Portal --lookup>> Messaging

Portal --create>> Workflow

Workflow --create>> Messaging

Workflow --lookup>> Registry

Workflow --authorisation>> Registry

Workflow/Tools --invoke>> DataAccess/perSpace/Tools

DataAccess/perSpace/Tools --authorisation>> perSpace

DataAccess/Tools --create>> perSpace

Tools --UIdefinition>> Portal

Interoperability: within entities

In the domain model presented here, I have not dissected any of the (very) high level entities. Where it is likely that a sub-entity from one VO implementation will need to address a sub-entity from another implementation, we will require interoperability standards. The only one I can envisage at the moment is Workflow --invoke>> JobControl.

WorkflowEngine --invoke>> JobControl

Standards and Actions

So, which of the above standards do we need now. For those VO projects which are prototyping aspects of the VO then it will be the standards particularly applicable to the area they are prototyping - UCDs, registry, image access etc - but for AstroGrid, it is those standards which govern how the underlying infrastructure hangs together:

• how does a tool represent its desired UI to a portal?
• how is the data access policy of a data centre represented?
• how is a workflow described so that it can be managed by a job control mechanism?
• how does a user find out his allocation of space on a given server?
• etc. etc. etc.

The first action needed will be for the IVOA to agree on what the underlying infrastructure of a VO looks like, then to define the areas of that infrastructure which require standardisation.

-- TonyLinde - 09 Jun 200--