next up previous contents
Next: CCF Whiteboard Up: WP 3 - Making Previous: InfoPortal   Contents

HPCPortal and NGS Portal

A National Grid Service portal is now being developed using the CHEF framework for use in a production environment. The NGS portal will consist of the standard CHEF collaboration tools such as Welcome page; Announcements for posting current, time-critical information; Schedule for posting and viewing deadlines, meetings, events, etc; Resources for posting documents, URLs, etc; Discussion for conversation in written form; and Work Site to allow NGS members to setup their own project worksite either as a private Web page or allowing other members to participate in their workspace forming a VO. In addition, the Grid tools are being provided to allow users to perform activities such as Grid Proxy Delegation for creating the x.509 proxy certificate; Grid Resource Broker for job submission; LDAP Browser for resource discovery and GridFTP for file/ data tranfer between the NGS compute and data nodes. Examples of these Grid tools had been developed as xportlets by the OGCE team [53,54].

HPCPortal has ``Active'' services for authentication, file management, data management, workspace, job submission and applications.

One aim of the ReDReSS project is to access Grid resources to enable live demonstrations of the sort of applications social scientists might want. We are also developing a prototype portal for the National Grid Service (NGS) to provide easy access to resources at CCLRC an the Universities of Leeds, Oxford and Manchester. To enable this we have ported a couple of tools from InfoPortal and HPCPortal [26] and OGCE into the CHEF framework. This was made easier by the fact that the US NMI portal, OGCE [53], is already using CHEF.

URL feeds from the InfoPortal map and resource status display panels were easily added to CHEF and retained all original functionality. Active services previously found in HPCPortal were included by porting the relevant portlets from OGCE. A portlet was also written from scratch as a client interface to web services in InfoPortal. These return a list of available compute resources on the NGS and also provide query interfaces to return an XML description of a resource (static data) or output from the Globus MDS giving the status of a resource (dynamic data). In this way we have shown that a new Grid tool can be easily integrated into the CHEF/ Sakai portal by adding the tool definition into the XML site description table, adding the tool portlet in the CHEF/ Sakai portlet registry and finally deploying the tool portlet on Apache Tomcat.

Building Grid Tools into Sakai

The CVS version of the Sakai portal framework was used in creating and implementing a simple grid Sakai tool to retrieve an X509 certificate proxy from a Myproxy server.

Building of a Sakai tool depends on understanding how Maven works [82] to manage its source, compile and deploy the application. A knowledge of JSF is required or some understanding of how the Model-View-Controller (MVC) pattern works. This will help the developer in designing the user interfaces and the necessary managed beans (Java methods) which interact with the GUI.

The current best practice to create a Sakai tool is to "clone" an existing tool module, see [79]. This way the directory structure and resource files are kept intact and the developer can use the skeleton structure to develop the new tool. The following outlines some of the steps which would be carried out to convert the clone tool to a new Sakai tool.

An overview of the basic directory structure of Sakai module is as follows:

    |__ maven.xml
	|__ project.xml
	|__ target
	|__ src
		|__ reg (contains the XML tool registration description)
		|__ bundle (message propertie file for JSF view and 
		|__ webapp (web deployment files)
			|__ WEB-INF (web.xml, faces-config.xml)
			|__ JSP files (JSF user interface files)
		|__ java
			|__ component (interface class implementation)
			|__ service (interface service class)
			|__ tool (tool logic application)

As it can be seen the process of creating a tool requires a number of steps to be completed in describing the build and deployment configuration. There is also an additional effort in implementing the tool logic. However it might take a long time to produce a tool but in the longer run it will be much easier to manage the tool application as the whole process of creating the tool separates out the developing tool logic, user interfaces and configuration.

Building of a Sakai tool is well documented in a technical report "Building a Sakai Tool" by Chuck Severance and Glenn Golden of Sakai Project [79].

next up previous contents
Next: CCF Whiteboard Up: WP 3 - Making Previous: InfoPortal   Contents
Rob Allan 2005-05-09