Gradual migration from myspace to vospace

The following plan outlines a gradual migration from myspace to vospace, implemented as a series of steps.

The main objective is to have a working system at each point in the process, so if one step takes longer than expected the wheels don't fall off and the system continues to work.

Use workspace URIs

The first step would be to modify the client AR and GUI to use the abstract workspace://path/file form of URIs for all the users data.

This involves updating and testing the GUI and xmlrpc interface to accept workspace://path/file URIs. It also means updating all of the Python libraries and examples to use workspace://path/file URIs as well.

The goal of this step is to insulate the users from any further changes to the identifier syntax.

Note that without this, we would need still to update all of the Python libraries and examples when we eventually move from myspace to vospace. Changing over to the workspace://path/file form in the AR and GUI now means that the change happens early and our scientists can start work on updating and testing the Python libraries and examples early in the testing phase.

Use concrete ivo URIs

The second stage is to modify the AR client to send fully resolved concrete URIs to the CEA and DSA services. This means that the AR client needs to resolve the users community and 'myspace home' within the client before it send a myspace URI to any of the services (the client already gets this information when the user logs in).

The goal of this step is to reduce the number of steps that a CEA or DSA has to go through to access data in myspace, increasing the reliability and reducing the access time.

Specifically, the CEA and DSA services should not need to check the users community and 'myspace home' before they attempt to access data in myspace.

Implement vospace 1.1 service and client

It is unlikely that the vospace service and client will be ready by end of January, which means we should not rely on having these components ready in time to be fully tested for the March release.

However, work on IVOA specification for version 1.1 service is in progress, and we plan to have the specification ready for the IVOA May interop meeting. We should continue to work on pre-release versions of the specification as this will help to shape the specification.

The goal of this step is to complete the version 1.1 IVOA specification, and have a working implementation that is compatible with other IVOA services.

Update AG components to use vospace

The next stage is to add the vospace client library to the AR, CEA and DSA services, enabling them handle vos://service/path/file vospace identifiers. If the AR has already been modified to use workspace:P//path/file identifiers, then we can use all of the existing Python scripts to test the new configuration.

The goal of this step is to update the components to enable them to handle IVOA standard vospace identifiers and services. At this point we would have a choice as to whether we made the transition from using the myspace to vospace interface.

If the myspace system is performing well, then we may decide leave the production system using the myspace interface, and defer the transition to vospace until we have added the security components to it.

On the other hand, if the myspace system is causing problems then may decide we need to transfer to the vospace system as soon as possible.

If the AR has already been modified to use workspace:P//path/file identifiers, then a transition at this stage should not have a huge impact on most users.

Update vospace to add security components

The next stage is to add handling for the certificate based authentication, and the internal structures required to implement authorization to the vospace service. Most of the work required for certificate based authentication has already been done, but the internal structures for authorization will require new code in the vospace server.

The goal of this stage is to implement the full IVOA specification for a secure vospace 1.1 service.

Update AG components to use certificate delegation

A lot of the development work required to impement this step has already been done. However, we will need to do a lot of reliability and integration testing before we can deploy these changes on the live production system.

Completion of this stage means that all of the AG services are capable of negotiating proxy certificates from the community services and using the certificates to access secure vospace services.

The goal of this stage is to end up with a fully secure system, using IVOA standard vospace services.

Note that even if we don't plan to use them immediately, the vospace 1.1 client and service components can be included in our standard software releases as soon as they are ready.

As the new versions are released, our deployed services become capable of using the vospace services and security certificates, even if we don't start to use them immediately. Our users would continue to use the existing services, while enabling us to test the vospace and security capabilities deployed on the live system.

Once we are confident that the deployed vospace and security capabilities are reliable we can switch over to using the new capabilities.

-- DaveMorris - 08 Jan 2008