Mehmet Nacar CGL Reports

Progress Report July 11th

2007-07-12T13:31:00.000-04:00

Grid tags should support client side implementations for browser clients. This will show that GTLAB architecture is portable among various technologies. GTLAB components would work generally within any technology or tool.

Progress Report June 13th

2007-06-14T12:07:00.000-04:00

JSF and Web 2.0

JSF based applications require server side processing of the requests. Thus, JSF applications should be contained by an application container such as Tomcat or JBoss. In classical web applications, the browser page is utilized by web forms. Each form submission refreshes the whole screen. There are three aspects of Server side applications currently. i) All requests must be processed and responded on server side. ii) Requests contain a web form that refreshes the whole browser page. iii) Request response model is a model of synchronous communication so client has to hang on to gets response from the server.

Web browsers are thin clients. AJAX engine creates WSRF clients to access Grid services directly from the browser. This architecture requires to use JavaScript libraries extensively on the browser. Nowadays, most of the browsers support AJAX clients. The advantage of this architecture is to getting quick responses to the clients by using asynchronous communication among Grid services. XMLHtttpRequest provides this functionality.

Progress Report May 16th

2007-05-16T23:55:00.000-04:00

GTLAB performance tests showed that the overhead of processing Grid tags are acceptable within JSF web applications.

Progress Report April 18th

2007-04-18T14:14:00.000-04:00

Workflow portlet

Workflow portlet application that utilizes extended GTLAB features to submit Scufl workflows. This portlet loads a Scufl workflow file, collects input values from end users, submits the workflow on Taverna, and monitors the results inside the GTLAB session framework.

Figure 1 illustrates the handling of Taverna tags within GTLAB. In this case, Taverna tags are embedded into JSF portlet page integrated with a Web form. End users only see the Web form with a few text fields and submit button. They never see the Grid tags and JSF tags that build the portlet page. This is common for all web applications. When the end user submits a web form through the portlet page, JSF intercepts this request and calls the associated action methods of Grid beans. Next, Grid beans load the appropriate Scufl document and input parameters to Taverna bean. Finally, the bean method starts execution of the workflow on Taverna enactor.

GTLAB assigns job handlers to each submitted workflow within the user session so that keeping track of the progression. In case of Taverna, the handlers synchronize with Taverna monitoring services to follow the workflow states.

Progress Report March 21st

2007-03-21T14:17:00.000-04:00

Writing a technical report about extensions to GTLAB. These additional tags covers Condor DAGman and Taverna scufl capabilities.

Progress Report February 21st

2007-02-21T17:43:00.000-05:00

I'm building Grid tags for Taverna to execute Taverna workflows through portlets. Taverna portlet should support workflow features. Generally a workflow portlet should contain these three major parts: 1) Workflow building- defining components and their relations. 2) Execute the workflow- in case of scufl they user Freefluo enactor engine. 3) monitor execution flow and apply capabilities like resume, checkpoint, cancel, remove etc. Building a workflow generation is possible by using Taverna workbench. As a result, we're focusing on enactment of the available workflows and monitor them.

Progress Report January 24th

2007-01-24T12:35:00.000-05:00

Condor DAGMan

Condor 6.8.3 package is installed on a local Linux box for testing jobs on Condor-G scheduler. Birdbath is part of Condor package and it Web services interface. This Condor machine is configuring to work with web services clients.

DAGMan is Condor workflow mechanism. Its features are very similar to Java Cog Taskgraph, mostly intended to provide multi-staged and batch job submissions. Condor jobs work with input files which are configuration of the job parameters. Similar to Java Cog ‘multitask’, GTLAB tags is extended with Condor DAGman tags.

condorDagman
condorSubmit

TACC Condor portlets are an example implementation of Condor Java clients. However, there is no DAGMan API exist with it. We’re using BirdBath that provides Grid services for Condor. So Web services client stub enables us to generate Java client proxies to use as Condor beans.

MyProxy Guidelines for Community Grids Lab

2006-12-13T11:05:00.000-05:00

1- Requirements

1.1- MyProxy service is running on gf1.ucs.indiana.edu at port 7512

1.2- Globus users has to have globus credentials which are public and private keys.

1.3- CGL Certificate Authority should be trusted by third parties.

1.4- grid-mapfile should contain user's DN and associated user name on the same machine.

eg. "/C=US/O=Indiana University/OU=Community Grids Lab/CN=Mehmet Nacar" manacar

2- Setup

2.1- Get a globus credential from CGL CA. You'll get two files

userxxx-key.pem

userxxx-cert.pem

2.2- Change your credential passwd. (Before running grid-change-pass-phrase command, you have to set environment variables as 3.1)

$ grid-change-pass-phrase

Enter pass phrase for /home/manacar/.globus/userkey.pem:
writing RSA key
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

2.3- If your account has already setup, replace the key and the cert with old ones. Otherwise, you need to follow these steps below.

$ cd
$ pwd	make sure you're at user home.

$ mkdir .globus

.globus directory should contain at least those files below.

.globus	/cog.properties
	/userkey.pem
	/usercert.pem
	/certificates/

2.4- Rename userxxx-key.pem and userxxx-cert.pem, and also change access rights as appropriate.

$ mv userxxx-key.pem userkey.pem

$ mv userxxx-cert.pem usercert.pem

$ chmod 400 userkey.pem

$ chmod 644 usercert.pem

2.5- Make sure you've copied CGL CA files into ./globus/certificates/

84ff0685.0

84ff0685.signing_policy

2.6- Edit cog.properties

cacert=/home/manacar/.globus/certificates/

ip=156.56.104.81

3- Get Proxy

3.1- After you setup your account, you can get a proxy. Before you do that, you need to set some environment variables.

$ export GLOBUS_LOCATION=/home/globus/nmi-8.0-rh9

$ source $GLOBUS_LOCATION/etc/globus-user-env.sh

$ export MYPROXY_SERVER=gf1.ucs.indiana.edu

3.2- Execute myproxy-init command below and enter credential passwd. Then you need to assign an arbitrary passwd for your proxy.

$ myproxy-init

Your identity: /C=US/O=Indiana University/OU=Community Grids Lab/CN=Mehmet Nacar
Enter GRID pass phrase for this identity:
Creating proxy .................................................. Done
Proxy Verify OK
Your proxy is valid until: Tue Feb 7 15:15:24 2006
Enter MyProxy pass phrase:
Verifying - Enter MyProxy pass phrase:
A proxy valid for 168 hours (7.0 days) for user manacar now exists on gf1.

4- References

4.1- http://grid.ncsa.uiuc.edu/myproxy/userguide.html

Progress Report Nov 29th

2006-11-29T21:46:00.000-05:00

Grid tag libraries was implemented, Java package implementation is almost completed. ComponetBuilderBean and Component parser classes are improved to generate JSF components out of XML tags. We're currently testing available features and fixing bugs. We'll also provide example JSF pages that uses Grid tag libraries.

Grid tag libraries can be implemented using web services as factory providing Grid services. This framework can be compared with WSRF or GT4 counterparts. Web services for Grid job submissions internally use Java Cog to access GT services.

Progress Report Nov 1st

2006-11-01T14:39:00.000-05:00

Grid tags and beans

Grid tags and beans has implemented as explained in the new approach. Prerequisites are for the implementation.
- Compile with Java 5
- Latest version of Java Cog which is 4_1_4.
- Of course maven 2 is the building tool
- I prefer to work on eclipse IDE environment. It's not mandatory for anyone.
- SVN tool for version control.
The implementation would be in multi steps. We're going to consider to use Taverna, DAGman workflows besides CoG taskgraph.

Regarding the implementation there are some reengineering from the older version. For example, tag and UI classes would be re-written with new attributes. Grid Bean classes support additional methods and besides older ones.

The major work is on ComponentBuilderBean class that is responsible for building UI component trees out of Grid tags from JSF pages. We need to find a generic way to implement it. Second part is managing job submissions and monitoring the results. We can borrow ideas from the previous implementation, but it is not totally reengineering of the code. Most of the work is on 'ogce.gsf.factory' and 'ogce.gsf.multitask' packages. It’s going to be finished next week. Currently I've finished 'ogce.gsf.components', 'ogce.gsf.gridtags' and 'ogce.gsf.gridbeans' packages.

GCE 2006 workshop

We’ve submitted Grid tags and beans paper to GCE 2006 workshop held with Supercomputing 2006. We’ve got excellent reviews and we’re going to present it Nov. 12-13. I’ve prepared ppt slides for that workshop.

Taverna

Taverna provides workflow engine that is Taverna Enactor. Taverna basically implements the Scufl workflow language. Tag libraries should have a converter in between scufl and JSF tags. Or else Tag libraries are able to import scufl snippets in JSF. There also should be connection with Taverna enactor. Currently ‘submit’ tag calls action methods of the Grid beans. In case Taverna, ‘submit’ tag should tie to action method of Taverna Enactor using Taverna beans.

DAGMan

DAGMan is Condor workflow mechanism. Its features are very similar to Java Cog Taskgraph, mostly intended to provide multi-staged and batch job submissions. Condor jobs work with input files which are configuration of the job parameters. Similar to Java Cog ‘multitask’, JSF Grid tags should be extended with Condor DAGman tags.

TACC Condor portlets are an example implementation of Condor Java clients. However, there is no DAGMan API exist with it. We’re considering using BirdBath that provides Grid services for Condor. So Web services client stub enables us to generate Java client proxies to use as Condor beans.

GridSphere

I've looked at GridSphere servlet and login modules to alter the authentication module. In my case, it was requiring substantial changes on GS codebase. However, one can access to GridSphere ‘logged-in page’ by giving request parameters on the URL. Adding username and password parameters to the URL would be fine. That redirects to GridSphere from any other web application.
http://serverurl:8080/gridsphere/gridsphere&gs_action=gs_login&cid=login&username=root&password=******
If you apply this URL on the browser window, it'll show you the "logged in" GridSphere page. This may be as secure as TLS (https). Passing the username and password parameter on the URL (even with hidden URLs) is not a secure way.

For more information about GridSphere user login, you can also look at GridSphereServlet.java and login.jsp in GS source code.