VO Desktop can be happily run in a headless server environment, as part of the implementation of a web application. The Astro Runtime library makes it simple to add VO functionality to a web application - for example, single-sign on, vospace access, registry queries, etc.
This page describes how to launch VO Desktop on a server, and how to integrate it with your chosen web-application technology.
To run VO Desktop on a headless server, it should be launched with the -headless commandline option. See Scripting Host for details. As noted on the Scripting Host page, you may wish to disable additional unused services - for example RMI.
How VO Desktop should be integrated with the web application - i.e. how the web layer calls functions of the Astro Runtime - depends on the web application technology. Some scenarios are sketched in the sections below.
If your web application layer is implemented in Python (or some other non-JVM language), then this is the only suitable deployment scenario. Your web application (in the figure, the yellow script) runs in the framework / server of your choice (in the figure CherryPy). VO Desktop runs in a separate process, started conventionally, using the -headless flag. The web application calls functions of the Astro Runtime library using XML-RPC method calls.
To achieve this, the web application will need to read ~/.astrogrid-desktop to discover the XML-RPC URL for the Astro Runtime. This is no different to
usual Python scripting - there are many examples in the Astro Runtime documentation.
This scenario is essentially the same as the one above, only the web application is implemented in a Java technology (for example JSP) and hosted in a java web container (e.g. Tomcat). (a) in the figure above shows this configuration. The web application connects to a VODesktop in an external process and calls Astro Runtime library functions using either XML-RPC or Java RMI.
A more efficient deployment scenario is shown in (b). VODesktop is deployed as a library within the same web container as the web application. The figure shows VODesktop / AR and the web application both running within the Topcat web container. As the AstroRuntime library is in the same process as the web application, function calls can be made directly, removing the overheads incurred for RMI or XML-RPC.
To achieve this, the VODesktop jar should be added to the library directory of the web application's WAR file. To call Astro Runtime functions, the web application should use the org.astrogrid.acr.Finder class to return a reference to the Astro Runtime Library. The procedure for using this class is the same as when connecting using RMI - however, if the VODesktop jar is on the classpath, a local instance will be started, and a reference to this instance returned. The resulting org.astrogrid.acr.builtin.ACR object can then be stored in the servlet context, or somewhere similar where it can be accessed as needed. The ACR object can then be used as usual to return service instances. These will then make direct function calls, rather than RMI calls (although there is no observable difference to the client code.)
Another alternative is shown in (c). VoDesktop contains an internal webserver (implemented using Jetty). This is used for a variety of purposes. It is possible to deploy an additional web application into this webserver. The web application is running in the same process as the Astro Runtime library, and so can make direct function calls, as in the previous scenario. Using VoDesktop as the web container simplifies things because it removes the need to deploy and configure another web server such as Tomcat.
To achieve this, an additional hivemind xml descriptor should be supplied at startup using the -addModule commandline argument. The descriptor should contribute a new web context to the system.webapps configuration point, or contribute new servlets to the system.servlets configuraiton point; while additional supporting libraries should be added to the classpath.
A new servlet or web application will find it's context populated with the items listed in the system.servletContext hivemind configuration point. In particular, an instance of org.astrogrid.acr.builtin.ACR can be found under the key module-registry. This ACR object can be used as usual to return service instances.
You may also wish to adjust the Configuration to control the IP address and port that the VODesktop runs it's internal server on.
If a web application has different users which have varying range of rights (for example, if it requires it's users to log on), then it needs to maintain some model of multiple user sessions. Sometimes the data associated with each session can be held just within the web application - in fact most web application frameworks provides a way of associating requests with user sessions by cookie or url rewriting.
However, in other cases the user-specific data is passed down into the Astro Runtime library. For example, a web application that allows each user to navigate their vospace files would prompt each user to login, and pass the login information to Astro Runtime to perform the VO-login. Once logged in, the web application then calls functions of the Astro Runtime File service to list the content's of that user's home directory. Later, the user may traverse to another folder, which in turn causes calls to Astro Runtime to list that directory.
The example above is problematic for the standard use of AstroRuntime, which has a single-user model. It _could_ be possible to repeatedly log in and out with every different user request. However, this is very inefficient. Instead, Astro Runtime provides support for multiple user sessions, so multiple users, with different logins and contexts can be accommodated simultaneously within a single Astro Runtime.
The org.astrogrid.acr.builtin.SessionManager service can be used to create new user sessions and connect to them. The Session Identifiers created by this service can be stored in the user context within the web application, to 'link' the user sessions of the web layer and Astro Runtime.
NB: at present, sessioning is only supported for the XML-RPC and RMI conneection methods to the AstroRuntime. Direct function calls to the AstroRuntime can't be sessioned (yet). This means that deployment scenarios (b) and (c) above cannot be used if muliple sessions are required. We hope to fix this at some point.