Progress Report July 11th

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

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

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

Progress Report April 18th

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

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

Progress Report February 21st

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

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.