Shared Application Launcher for Access Grid (AG) 2

Shared Application Launcher (SAL) for Access Grid (AG) 2

Allan Spale, EVL@UIC --- August 2003

Introduction

With respect to terminology used in this paper, Application will appear as the term for defining the application that is to be shared. Additionally, Master will appear in reference to a site controlling the collaborative session sharing the Application.

Shared applications are a new feature of AG 2 that allows for applications to become sharable within this framework. There are varying degrees of sharing an application. In this document, a design will be shared that allows for having a Shared Application Launcher (SAL) that have the following capabilities:

·  Have a Master who would control when an Application starts and stops. The site acting as Master could change over the duration of the session.

·  Distribute start and stop Application messages to all participants in a venue including one’s local node.

·  Permit the application to exist on a PC other than the PC used to run the AG venue client.

o  Transfer files downloaded from the AG venue client to the PC where Application resides.

Case Study: Immersaview Launcher

EVL is working on a project that specifically integrates Immersaview into the AG as a shared application. Immersaview, http://www.evl.uic.edu/cavern/agave/immersaview/, is a collaborative 3-D model viewer whereby all participants simultaneous share the same view of a model. An Immersaview collaboration server performs the coordination of viewpoints to a shared view for each individual site running Immersaview locally. This collaboration server utilizes the Quanta API that maintains a database of relevant state information during the session. Quanta also has many other capabilities besides running a database. Additional information on this software can be found at: http://www.evl.uic.edu/cavern/quanta/. Since the collaborative capabilities of Immersaview are already provided, it is simply necessary to use the framework for designing shared applications to coordinate all sites to start and stop Immersaview at the same time.

In order to accomplish this task, Immersaview Launcher will be deployed as an AG shared application. This will allow events to be shared by all sites participating in the shared application session. Immersaview Launcher will have the following capabilities:

·  Standalone

o  Start/Stop local site Immersaview

o  Send configuration file from Immersaview Launcher to Immersaview PC

o  Send model file(s) from Immersaview Launcher to Immersaview PC

·  Shared

o  Includes all standalone capabilities

o  Announce a site’s intention to be the “master” for a part of the session. The “master” site will have the following capabilities:

§  Start/Stop session Immersaview

§  Choose which model file(s) to share for a session

Immersaview Launcher will communicate between the other sites’ Immersaview Launcher programs via the AG event channel provided by the AG shared application session whose information is stored in the venue. The shared events will include either starting or stopping Immersaview for all participating sites. Once the event is captured, Immersaview Launcher will need to communicate with the PC running Immersaview. In order to eliminate the need for the Immersaview PC to have AG 2 components installed, this PC will run an XML-RPC server program to execute commands issued by Immersaview Launcher, which will run an XML-RPC client. The XML-RPC server will only have to execute a few simple commands that include transferring files, starting Immersaview, and stopping Immersaview. The actions of starting and stopping Immersaview will be accomplished through batch or shell scripts depending on the operating system of the Immersaview PC. Since Immersaview Launcher can run in standalone mode, local events also will be transmitted via XML-RPC.

Immersaview Launcher will have the user specify the appropriate information needed for running a standalone or shared session. For the convenience of the user, the information entered in the last session will be saved to a file and be loaded when the next session begins. The information that Immersaview Launcher requires includes the following:

·  Site name (independent of whatever name is used in the AG)

·  Name and port of the Immersaview PC

·  Directories on the Immersaview PC where model files are stored and where the Immersaview executable resides

·  Local directories where configuration files and model files are stored, as well as the directory containing the supporting files of a particular model file

·  The name of the model file

It is important to note that Immersaview Launcher is not a complete solution for accomplishing the task of complete automation of all the steps necessary to run Immersaview collaboratively, although enhancements can be made so that it would be more automatic. For instance, it is still necessary to download the appropriate files from an AG venue and place them into the appropriate directory on the PC running Immersaview Launcher, which is assumed to be the same PC running the AG venue client. Additionally, it is also necessary to manually create the configuration file used by Immersaview that also includes the information for connecting to the Immersaview collaboration server. Future versions may include these and other enhancements.

For a diagram of how the Immersaview PC, Immersaview Launcher, and AG venue client interconnect, please see Figure 1 on the next page.

Developing the SAL Framework

With the SAL framework, it should be possible to adapt an existing application into an application that can be collaboratively shared. As illustrated with Immersaview, this can be accomplished through the AG shared application API. Another possibility, which will be explained later, would be to deploy various aspects of the collaboration as AG node and venue services. In either case, the deployment of a program called X-Launcher will be the interface for controlling the Application.

Shared Application

To write X-Launcher, it is necessary to provide an interface for controlling the Application on the other PC. This can be done in any manner but must use the AG 2 shared application API. To share an application, it is necessary to write an XML-RPC server program that will start, stop, transfer files, and perform any other important functionality necessary for the operation of the application. Since this server program does not directly manipulate the Application, it can indirectly control the application through batch or shell scripts. Another possibility that could be considered is creating keyboard and/or mouse macros that would allow the Application to be directly manipulated through its user interface. In this manner, the code for the Application does not need to be modified, and the X-Launcher program would still have the ability to control the Application during its execution. One example of this would be a shared presentation viewer. X-Launcher, running an XML-RPC client, could have a function such as “next slide” or “previous slide” that would communicate with the XML-RPC server on the application PC which would run the keyboard macro for allowing the presentation viewer to go to the next slide or the previous slide.

Another consideration when writing X-Launcher is file downloading. Currently, each site must download files manually in order to use them in the shared sessions. To improve this situation, being able to somehow download the files from the venue on-demand would allow the process of setting up Application to be performed in a more automatic manner. It may be possible since each file in a venue is accessible via some URL, but the author has made no attempt to include this functionality into Immersaview Launcher at this time. However, it should be noted that the AG event channel is not capable of being used for file transfer. The session for each shared application is maintained in the venue with only small amounts of data used to announce events.

One other consideration would be if Application already has some middleware for running a collaborative session independent of the AG. In this example, there is no need to integrate the application’s collaborative server into the AG or X-Launcher framework unless, for example, it is desirable to test connectivity of the application PC with the application collaboration server or edit some configuration file that provides the connectivity information for the application collaboration server.

The design for deploying a shared application can be found on the next page in Figure 2.

Set of Services

Application could also be integrated as a set of AG services. This was inspired by the tight coupling of how the AG video and audio programs, VIC and RAT, are able to start themselves upon immediate entry of a site in the venue. In the same manner, once a Master decides to launch a collaborative application session, all of the appropriate files should download to all of the “client” sites and start up each site’s Application instance locally. Since there are different service types in AG 2, it is necessary to define what role each component serves in this collaborative setting as well as what type of service this component should be. First, it is necessary to define what types of services will be used in this collaborative application session. A node service is a local service that can run on any PC that contains the necessary AG components in order to operate correctly. A venue service is a service that operates within the context of an AG venue. The author is uncertain as to how a venue service would be deployed at this time in addition to what role a venue service serves. In this context, a venue service will be thought of as a service running on a PC related to the AG venue server that is available for all sites in a particular venue.

Before explaining how X-Launcher works, it is necessary to think about how Application would be controlled. As in the design for controlling Application via an XML-RPC server program, the same design will occur here. However, the difference is that the XML-RPC server program would be deployed as an AG node service. This would allow for the server to be started, stopped, and configured rather easily from the AG venue client without the concern of doing these same tasks manually. The name for this node service will be ApplicationController.

X-Launcher would be written in two ways— as a local application and as a collaborative application. As a local application, X-Launcher would be deployed as the “configuration” function to the ApplicationController node service. In this manner, all control of Application remains local. This would involve something as simple as indicating what configuration files as well as Application files to use in order to run a local session. Then, to start the application, one could simply enter the node’s AG service manager and start ApplicationController. Since this service was already configured to run the appropriate files, ApplicationController will launch Application. Later, selecting the stop function of the ApplicationController node service can stop Application. The collaborative X-Launcher would be created as an AG venue service. Because of the author’s uncertainty in deploying venue services, an assumption must be made. To access a venue service, it is assumed that the interface for the venue service will be deployed in HTML and will appear in a web page. If the functionality provided by HTML is insufficient, the GUI could be deployed as an applet embedded in a web page. The backend for the web page, or the applet itself, would take care of processing events internally and distributing events to all sites in the venue in the same manner that the information (the IP and port number) for binding VIC and RAT to a venue is stored at the venue level but then sends some sort of “message” to the node services bound to instances of VIC and RAT to “start” them in the correct manner through their respective node services.

One other aspect to consider is whether Application already provides its own collaboration server. If it does, then the Application Collaboration Server (ACS) could either be deployed as a venue service or as a node service. In making this choice, it may be important to consider how a site would connect to a venue service related to the ACS. If it is burdensome to connect to the ACS encapsulated within the venue service, it might be more appropriate to deploy the ACS as a node service and announce the location of the node service to participating sites. The remaining advantage of running the ACS as a node service is that its configuration, starting, and stopping would likely be simpler to perform. In the case of choosing how to deploy the collaboration server for Immersaview, it might be best to deploy it as a node service. This is because the configuration file for Immersaview requires that the server name and port be known in advance. Because of the author’s inexperience with venue services, it is not certain whether gathering this same information could be done as effectively through a venue service as with a node service. In either case, it is important to choose the service deployment that finds a balance between end-user functionality as well as simplicity of use.

The final aspect for consideration is on-demand file downloading. It is very likely that the end-user would prefer to have the Master select what Application file will be used for a particular part of the collaborative session and, after launching the Application, have the selected file (and any other supporting files) download to each site. It is possible that this feature may be integrated directly in the AG Venue Server at some point in the future as some sort of implicit venue service. Currently, to the best of the author’s knowledge, the files stored in a venue may only be accessible if the URL for the file is known. Consequentially, it might be necessary to take a two-part approach to deploying this functionality. The Master needs to choose files appropriate for the Application. This functionality may be implemented through a FileChooser venue service. In this manner, a set of files for a particular application’s collaborative session can be chosen at one time. Then, a message can be sent to all participants participating in the collaborative session of the specified application. From a local site’s standpoint, it is crucial to have the files downloaded to the correct location, which may or may not be the AG venue client. In order to do this effectively, there needs to be a local equivalent of the FileChooser venue service which will be called FileDownloader. Deployed as a node service, FileDownloader could be configured to place files on the appropriate PC as well as in the appropriate directory. Because there may be more than one PC that would store files downloaded on-demand, it will probably be necessary to have a FileDownloader running on each PC where this functionality would be needed. For example, application A can place files in PC 1, while application B can place files in PC 2. In this scenario, FileChooser would send a message to all sites in the venue that would be interpreted by the FileDownloader node services running on the PCs at each site. If the appropriate site-specific FileDownloader successfully interpreted the message, the files will be transferred using the mechanism provided by the FileDownloader and store the files in the appropriate location on the appropriate PC for a given Application.