|
Proposal for Access Grid Portal
Melvin Chee Kian, Koh 1. Overview There have been a lot of interest on the open-source Grid Engine Portal (GEP) and there have been some complains on the current version of the GEP by end-users. The complains are:
This report will attempt to propose some possible solution as well as a architecture for the next generation of GEP.
In order to address point 1 of the complains, the new GEP has to be developed using open standards. There are several new standards that have been approved that will aid the development of GEP. 2.1 Portlet Specification JSR168 JSR168 specification [1] was finalized in end of October and its purpose is to enable interoperability between portlets and portals. Thus a portlet that is implemented with the JSR168 APIs will be able to be deploy seamlessly in any portal server that is JSR168 compliant. 2.2 Web Services for Remote Portlets Integration of content and application into portals has been a task requiring significant custom programming effort. Typically, portal vendors or organizations running portals had to write special adapters to enable communication with applications and content providers using a variety of different interfaces and protocols. The OASIS Web Services for Remote Portlets (WSRP) [2] standard simplifies integration of remote applications and content into portals to the degree where portal administrators can select from a rich choice of remote content and applications and integrate it in their portal with just a few mouse clicks and no programming effort. As a result, WSRP becomes the means for content and application providers to provide their services to organizations running portals in a very easily consumable form. 2.3 Distributed Resource Manager Application API Distributed Resource Manager Application API (DRMAA) [3] is a standard for a set of APIs that can be use to interface to the dynamic resource manager (DRM) like the Sun Grid Engine (SGE). The advantage for applications is that they will be able to run in any DRM that is compliant to the DRMAA specification.
3. Functional Modules It is important to categorize the functions of the GEP into modules. The modules will be a set of APIs that provides the backend functionalities of the GEP, and they will be use by the presentation layer to perform tasks like job submission, monitoring, and authentications.
The reason for the two-tier architecture is to allow easier customization of the GEP graphical interface. Users who wish to change the look and feel of the GEP can just modify the presentation layer, or even build their own from scratch. Note:
This section will describe the various modules needed to provide the backend functionalities. 3.1 Job Submission and Management This module will be responsible for providing the job submission service. Depending on the complexity of the DRMAA Java binding, this module may just be a wrapper to make it easier to do job management. The functions to be provided are job submission, suspension and deletion. 3.2 Monitoring Not only for monitoring of the status of submitted jobs, this module will also provide monitoring of system resources. The module should be design in such a way that monitoring for new type of resources could be added easily as a plug-in. 3.3 Accounting and Analysis As DRMs store their accounting information differently, this module will be tightly coupled to the DRM that it is specifically written for (in our case, it will be SGE). Using this module, detailed as well as summarized statistics can be retrieve from the accounting database. It will also be able to generate graphs and provide analysis functions like finding the most submitted type of jobs and users who used the most resources. 3.4 Application Registration Registering new applications for the current GEP is quite tedious. This is because the system administrators need to write their own scripts to for job submission. Simple applications do not require more than couple of minutes, but for more sophisticated applications (eg. MPI or PVM applications) more work will be required. Borrowing the concept from the Grid Engine Scripting Tool (GEST) [4], this module will provide an infrastructure that allows registration by using pre-made packages. These packages will contain the needed scripts and submission forms for their respective applications, and the user only has to provide information such as the application directories, working directories etc. and the applications will be ready to run. 3.5 User Authorization As most of the authorization mechanism for different portal server will likely be different, the code to check for the users' permission will be contain in this module. Therefore, different authorization module can be plugged in for different portal servers. 3.6 Output Visualization This module will provide an architecture that allows users to program their own customized graphical output viewer as an Java applet and plug it into the GEP. The module will need to provide some mechanism for the output viewer applet to retrieve the output.
4. Portlets The presentation layer will be written as portlets and they will be compatible to portal servers that are JSR168 compliant. Using the functionalities provided by the backend modules described in the previous section, the portlets' interface should be simple, intuitive and easy to use. The following is the list of portlets that are should be in a Grid Engine Portal. Grid Portlets:
Administration Portlets:
Non-Grid related Portlets:
5. Web-based Graphical Display Currently, the GEP uses VNC to display graphical jobs. However, the performance of VNC even in the local area network is quite unacceptable. Therefore we need to take at other alternatives to provide the display. 5.1 WeirdX Like VNC, WeirdX [5] is a free X Window Server written in pure Java. Unlike VNC, WeirdX handles X protocols directly, so it does not need any proxy server. It also support rootless windows, another advantage over VNC. However, as indicated on its website, WeirdX is not suitable for heavy X applications. 5.2 WiredX WiredX [6] is the non-free version of WeirdX and has more advanced features that the free version does not have. 5.3 Tarantella Tarantella [7] offers thin-client solution for enterprises, providing secure remote access to X window applications with a web browser. It shows good performance for applications like Gimp over the Internet on a broad band connection. However, it is quite sophisticated and may not be easily integrated with some of the portal servers. 5.4 Broadway Broadway [8] standardizes two methods for invoking an X application by clicking on a URL: via a small platform-specific helper application called xrx, or via a browser plug-in (which could also be a Java or ActiveX applet). The first method launches the X application in a separate window entirely controlled by the X server. The other method uses plug-in which results in the X application’s output being displayed within the browser window, with the use of a new protocol, the application group extension (XC-APPGROUP). This protocol allows an application designated as "application group leader" (in this case the browser) to intercept display requests to the desktop window manager (i.e. the PC X server) and reparent the intended X window into the group leader’s window. The limitation to using Broadway is that there must already be an existing X server on the local machine. There will be no problem if the machine is on Linux or Unix operating systems. However, for Windows operating system, 3rd party software like StarNet's Xwin32 or Hummingbird's Exceed which are not free.
References
For more resources, goto our Portal Links page. |
