Server Runtime (SR)

Introduction

This page will store ideas for how we might provide server-side access to AstroGrid functionality. The original approach was to derive a server-side version of the AstroRuntime: one which would permit multiple users to invoke AG services under their own identities. Such an approach might, however, be expensive to implement and so could not be delivered within C05.

Here we might add alternative approaches with feedback from developers on whether they are feasible and how they might be implemented.

Use Cases

Other VO Components

An obvious use case is that other people/projects will want to develop their own components. We do face NIH problems with other VO projects: they might be reluctant to use AG if it is seen to diminish the importance of their own efforts in their funders' eyes. But it might also be seen that, with access to the SR largely hidden, this is less of a problem. An added benefit is that components can be developed and demonstrated more quickly so the person/project can show off more quickly.

UK Projects

PPARC funds a number of new projects and all of those ought to want to develop services which make use of the VO: we will want them to make use of AG as their VO infrastructure. It may even happen that pipelines will be built using the AG infrastructure such that the components of the pipelines can be made available as VO services.

Website Access

Existing data centres have their own websites. If we can provide SR in a way that it can be called from PHP or other common website building languages, it is more likely these centres will provide data access via DSA. We can then expect them to add access to services which their site users are most likely to want, create small scripts to do common tasks covering their science area etc.

New AstroGrid Functions

Perhaps even AG developers can quickly build new component services using the SR.

Alternative Approaches

Server Runtime

Description

Modify the AR such that it is able to recognise multiple users - perhaps as a website recognises separate sessions.

Discussion

Tony 20070115: how long would it take to do this?

Tony 20070115: how does the AR invoke, say, a 'put' to MySpace? I assume it has to pass a valid user/community to the MySpace component so that the file goes to the correct place. If AR holds 'session' information as it currently holds single user info, could it allow calls to its services such that using the session id will make it call MySpace 'put' using the associated user info?

Use AR on server

Description

Leave AR as it is. To use it on a server, any app wanting to use it would have to invoke their own instance of it for each user of that app.

Discussion

Tony 20070115: if, say, a website gets people to log in using their username/community/password then it can spawn a separate instance of the AR for each logged-in user. How efficient might this be? Is it feasible?

Tony 20070115: how might the website know which services can be called without login details?

Guy 20070128: Eventually, the registry will show which services require authentication. For the CEA, the assumption is that all services accept authentication credentials, most authenticate these at present (and log the result) but only a few reject the request if authentication fails. We're heading to a system where clients attempt to authenticate all requests to CEA services. Note also that when we move to VOSpace, which itself requires authentication, then all requests to CEA services will need to be backed up by delegation of credentials.

Tony 20070115: what does the headless AR do when a service is called without login details when they are needed?

Guy 20070128: At the moment, the call would fail and the AR would report the failure.

SR facade to AR

Description

Create a small app which acts as a front end to the AR. It has the same interface with the following changes:

• when started, a default AR session is spawned
• login method spawns separate AR session and calls its login method, returns some sessionId
• offers all existing methods with additional sessionId parameter which causes the sending of that call to the appropriate spawned AR
• calls to methods which leave out the login parameter sent to default AR

Discussion

Tony 20070115: is this likely to be more work than creating the SR?

Make CEA wrapper AR-aware

Description

Imagine a user has written a script using AR which they then deploy on a server wrapped in CEA. If the script includes a call to 'put' a file to MySpace, could the wrapper intercept that call and insert login details.

Discussion

Tony 20070115: might work for creating service but not really useful for website (or is it?).

Guy 20070128: If the script uses MySpace or VOSpace than presumably it's using an AR. Therefore, the AR in the script needs to get delegated credentials from the desktop client. This is conceptually the same process as the application server getting the credentials so that it, the server, can use VOSpace. In each case, the proper method is through the IVOA-standard delegation-service on the site. This problem is already solved in the Globus Toolkit and we can probably use their code.

Guy 20070128: AFAIK, the current AR is designed to be a singleton: one per desktop. This suggests that a headless ACR run by a script in an application server will behave as if it were a singleton; two jobs using ACR in the same service may clash. I suspect that using the AR from a script in an application server needs the same developments as making the ASR to be called by the server directly.

Applet accesses desktop

Description

This is an idea from JohnTaylor and demonstrated at http://plastic.sourceforge.net/tupperware/PlasticApplet/ShowApplet.html (note: strictly alpha code). As I understand it, the server-side web pages use an applet to communicate with the user's desktop AstroRuntime in order to eg save a file to MySpace.

Discussion

Tony 20070126: would work but asking users to allow an applet access to their desktop is, IMO, asking for trouble.

John 20070126 (by email): 'One partial solution is that we go and get ourselves a proper certificate to sign stuff with... If we use the same one to sign the workbench and the applet, then the user would only have to accept the certificate once, and that's it done for life for both apps.'
'There are a couple of points in favour of the applet approach though: 1) You maintain SSO; 2) Integration with PLASTIC (no way of doing /that/ server side)'
'I think an equally important problem is that the applet is too big and takes too long to load up.'

Tony 20070127: Points about SSO and PLASTIC access are good ones (any downside to signing our code? anything stopping us?).
Applet access might be worth developing but we still need ASR for making it easier for other developers to create server-side tools and for websites which can be used by astronomers who are not sitting at their own machines or are at sites which block applets from running on their browsers.

Message Queue

Description

An idea that John's prompted. Could you run the AR behind a message queue application which, whenever it received a message from an application with an AR command 'owned' by a different user, first instructed the AR to re-login as that user. The app could have a fixed pool of ARs to minimise the logging in. And if server-side web page was configured to look like it worked asynchronously with the VO then the time delay with logging in might not seem so bad.

Discussion

Tony 20070126: need techies to say if this would work

Guy 20070128: See remarks below about delegation.

Notes

Delegation Service

-- GuyRixon - 28 Jan 2007

The core of the problem is how to get credentials for different users into the AR, or into the CEA-server core without using the AR. The equivalent problem of delegation is already solved in the Globus toolkit. IVOA GWS-WG is aware of the problem and is working on it: we plan to document and standardize what is done for delegation in GT4, making the least changes needed to fit it for our purposes. Would it not make sense to wait for details of this mechanism before designing a separate solution?

My understanding of the Globus delegation service is as follows. There is one such service -- a SOAP service -- per site. Clients interact with the delegation service when they need to delegate credentials to other services on that site. The delegation service maintains a local, site-wide cache of delegated credentials that can be copied into other, local services. In respect of holding credentials, it is a multi-user ASR. Therefore, I suggest that we make our ASR stateless but able to read credentials from the delegation service at need: it gets a fresh copy for each secured message. (Naturally, we have to make sure that the credential copying is an efficient process; possibly, we have to do it differently to Globus.)

We might also consider using the credential cache in the delegation service from the ACR. This covers the case where the ACR is invoked from a script run by an application server. The ACR would then have two places to find credentials: its internal cache, filled by a succeful call to MyProxy, and the external cache. On the desktop, it would find them in the internal cache; on the server, the internal cache would be empty, but it would them find in the external cache.

Now consider that the ACR's credential cache is actually the security-facade library. If a service -- e.g. a CEA application-server -- were to use delegation and security without the AR, then it would do so using the security facade, as is currently done. Therefore, it seems sensible to abstract the delegation mechanism into the facade and therefore make it available to the ACR too.