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, , 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: . 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.

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

Comparison of Shared Application Deployment versus Set of Services Deployment

There are a variety of advantages and disadvantages for integrating Application as a set of AG services or as an AG shared application. It is likely that the time involved in deploying Application as a shared application would be shorter because the event channel used for a shared application allows a communication mechanism for accomplishing sharing events and communicating locally with each site’s Application. A negative aspect to this implementation is that the AG event channel is not able to act as a file transfer mechanism. Because of this deficiency, a file downloading on-demand function would have to transfer files in a different manner or rely on the AG venue server to provide such functionality. Another downside to this implementation is that all parts involved are not fully contained within the AG 2 model. This comment is in specific reference to having an XML-RPC program sitting on the PC with Application. However, this disadvantage could be eliminated if it were possible to deploy the XML-RPC program as a node service. A positive aspect of using XML-RPC to control Application involves not having to change the Application to fit within the existing AG 2 framework. Application simply is controlled via batch and shell scripts.

The deployment of the various parts of Application as a combination of node services and a venue services would not be desirable for integrating Immersaview into AG 2 in a timely manner because of the additional complexities involved with respect to a similar deployment using the shared application method. There may be the difficulty of having venue services send messages to node services in order to coordinate them in a collaborative session. Additionally, there is the consideration for the task of writing and deploying venue services. The positive aspects of deploying parts of Application as services would be a tighter coupling of Application in the same way that VIC and RAT are seen as tightly coupled to the AG. Another advantage is the reuse of services. It is likely that there will be other programs that must be integrated into AG 2 that utilize these same types of services. This could include something like downloading presentation files automatically and then starting the current session portion’s presentation using the appropriate presentation software. Another reusable service would be some sort of control service for configuring, starting, and stopping the presentation software. In this manner, other sites could more quickly integrate their software into AG 2 without having to design services that apply to their programs from scratch.

General Design of SAL Framework

In order to facilitate the deployment of any application into the AG 2 framework, it would be beneficial to provide some sort of development framework that could provide the basic collaborative functionality described throughout this paper. Specifically, the introduction of the Shared Application Launcher (SAL) is described. SAL will provide a means for taking existing applications and allowing them to be shared in a collaborative manner. The level of collaboration is fairly limited to downloading the appropriate files for the session as well as starting and stopping the application. A future enhancement might be to include keyboard and mouse macro playback for directly interacting with the application’s GUI and somehow synchronizing this action across all sites, but this will be explored at a later time. Since the author is somewhat knowledgeable in deploying AG shared applications (and since it is called the Shared Application Framework), the SAL framework will be described as a program that will deploy existing applications as shared applications. However, deploying this same framework as a set of services should be considered as a future possibility.

SAL can be designed as a set of components. The first component of SAL should be a limited GUI designer. The GUI designer should minimally support entry of text into text fields, displaying of static text, and browsing of files and directories that allow the placement of this selection into a text box. The next component of SAL involves mapping events to batch files and shell scripts. Because there is likely to be some platform-specific differences in this component of SAL, it will be necessary to have the developer specify the action as well as the platform where the application runs and what shell script or batch file is associated with the action. It is important to note that since SAL is concerned specifically with deploying applications as shared applications, the PC containing the application should also have an XML-RPC server running on it. Consequentially, the first part of mapping GUI actions to events would start with the mapping of shared application events to batch files or shell scripts. For instance a “start” event would run a shell script that starts Application. Then, from the GUI standpoint, it would be necessary to map the XML-RPC call to a particular GUI event. Since the types of GUI components would be fairly limited, the pressing of the “Start application” button, for example, would map to the button action to the “start” call in the XML-RPC server. If it is necessary to specify certain filenames to pass to the scripts, accommodations can be made to take the names specified in the GUI, pass them to the XML-RPC server, and then have the server call shell scripts with these names.

In this situation, the file downloading on-demand services could be used in conjunction with SAL, but the framework does not directly address this problem. Additionally, it should be noted that the AG event channel is not suited for the transfer of files. One possible workaround would include allowing the file browsing/selecting mechanism provided in the GUI to directly search for appropriate files in the venue. Then, when it is time to run the application, the shared application could interface with the files on the venue server and download the files to the appropriate location. Another possibility would be to somehow leverage the XML-RPC servers to communicate with one another the location of the appropriate files for the collaborative session and distribute them to the appropriate locations at each site. Therefore, consideration should be given in designing the framework of SAL to consider having selections made to integrate with other node services and venue services, such as those related to file downloading on-demand.

Conclusion

The process of integrating different applications into AG 2 have a small set of functionality in common that includes starting and stopping the application as well as downloading files used in this collaborative setting. By providing an implementation of the SAL framework as a design tool for developers, the integration of existing applications into the AG 2 framework can be completed more easily. Although this is not a complete solution, it will provide a minimal set of functionality for all shared applications designed with this tool that may be sufficient for many applications that need to be shared. The SAL design tool will allow non-developers to perform the task of integrating their applications into AG 2 more easily as shared applications, thus increasing the overall value of the AG.

-----------------------

NETWORK

Actual connections

Logical connections

Quanta

XML-RPC

Quanta

Quanta

XML-RPC

EventChannel

FIGURE 1: Immersaview Launcher is a SharedApplication that shares events between remote “Launcher” clients such as start/stop Immersaview. To communicate among AG sites, each site will join the Immersaview Launcher program in order to receive events from its peers via the AG event channel. For a site to locally communicate with its Immersaview PC, a program running an XML-RPC server that processes events from “Launcher”. The “server” will then run shell scripts that will start and properly configure Immersaview as well as stop the program. Immersaview peers are able to collaborate with one another by connecting to a single Immersaview server that uses Quanta.

EventChannel

SharedApplication

SharedApplication

Immersaview Launcher

Access Grid

Venue Client

Access Grid

PC

Immersaview

XML-RPC Interface to Immersaview

Immersaview / Geowall PC

SITE 2

Immersaview

XML-RPC Interface to Immersaview

Immersaview / Geowall PC

Immersaview Launcher

Access Grid

Venue Client

Access Grid

PC

PC

Immersaview Server

SITE 1

NETWORK

Actual connections

Logical connections

Collaboration

Middleware

XML-RPC

Collaboration

Middleware

Collaboration

Middleware

XML-RPC

AG EventChannel

FIGURE 2: X-Launcher is a SharedApplication that shares events between remote “Launcher” clients such as start/stop Application. To communicate among AG sites, each site will join the X-Launcher program in order to receive events from its peers via the AG event channel. For a site to locally communicate with its Application PC, a program running an XML-RPC server processes events from “Launcher”. The “server” will then run shell scripts that will start and properly configure Application as well as stop the program. Application peers are able to collaborate with one another independent of the AG by connecting to a single Application Collaboration Server.

AG EventChannel

AG SharedApplication

AG SharedApplication

X-Launcher

Access Grid

Venue Client

Access Grid

PC

Application

XML-RPC Interface to Application

Application PC

SITE 2

Application

XML-RPC Interface to Application

Application PC

X-Launcher

Access Grid

Venue Client

Access Grid

PC

PC

Application Collaboration Server

SITE 1

FIGURE 3: Application and its related parts are deployed as a set of AG services. X-Launcher: Local operates acts as the GUI for configuration of Application via the ApplicationController node service. Running Application would involve starting or stopping the service with its existing configuration. X-Launcher: Collaborative runs as a venue service and would be responsible for properly configuring a session (with information such as which site is the master, which files should be shared, etc.) and starting all remote X-Launcher Local services from this venue service. Using the FileChooser venue service, the files for the session can be chosen and be downloaded on-demand from the venue to each site via its FileDownloader node service. If Application already runs collaboratively, starting its Application Collaboration Service is as simple as starting its related node service.

X-Launcher

Collaborative

Collaboration Server

Middleware

Application

Access Grid

Venue Client

SITE 2

5

4

SOAP

6

Access Grid

Node Services

FileDownloader

Application

Controller

FileChooser Application

Configuration function for ApplicationController service

6

XML-RPC

4

5

Access Grid

Node Mgmt

Application PC

SOAP

Application

Access Grid

Venue Client

SOAP

X-Launcher:

Collaborative

MCS-ANL

FileChooser

Venue Services

PC

ANL Virtual Venues

NETWORK

Actual connections

Logical connections

1

2

33

33

2

11

Collaboration Server

Middleware

Access Grid

Node Mgmt

Configuration function for ApplicationController service

XML-RPC

Application

CollaborationService

Access Grid

Node Services

PC

Application Collaboration Server

Application

Controller

FileDownloader

Access Grid

Node Services

Application PC

X-Launcher:

Local

Access Grid

PC

SITE 1

[pic]

X-Launcher:

Local

Access Grid

PC

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download