SBIR Meeting, Jun 1, 2007

Introduction

• Coordinates: 10am Chicago; 1-510-665-5437 #1122
• Attending: Rob, Paul, Suchandra, Ravi
• Last meeting: NotesMay18

ODE-WS Gram (Paul)

• Paul can you give an overview of ODE and current progress on integration with Gram?
• Putting ODE on same server as Gram, setting up client calls.

Globus work on BPEL-Gram (Ravi)

• Ravi - can you discuss a bit current work or interest in this approach to managing workflows to gram, etc?
• Included here is Stu's mail to Paul, as a refrence:

Thanks for the intro Rob. Hi Paul.

Yes, looks like a framework like that could be leveraged for validation testing. Ravi Madduri (also with Globus/ANL) is working with the CaGrid team to develop (or extend) BPEL workflow engines that can interface with GRAM4 (WS GRAM). So it looks like there may be more to talk about there too.

There are a number of tools that have been developed on top of GRAM4, so application developers should not be limited to condor-g. Condor-g does well and is a good tool, but probably not for every applications. Some higher-level tools that interface to GRAM4 are some I know about:

	GridWay - Metascheduler using Java GramJob API
	GEMLCA - Provides WSRF legacy application specific port type.   Uses Java GramJob API.  UK project.
	AHE - Provides WSRF legacy application specific port type.  Uses WSRF-Lite Perl client bindings.  UK OMII project.
	Condor-G - Multi-threaded, throttling, fault tolerant, client for remote job management.  Uses Java GramJob API
	CoG - Provides common Java client abstraction API for both GRAM2 and GRAM4
	Swift - Grid workflow tools based on VDL using CoG GRAM API (?)
	caBIG workflow - Grid workflow based on BPEL tools using GramJob API (?)
	GridSam - Provides JSDL jobs and translates to JDD / RSL GRAM jobs
	GridSphere / OGCE Portlets - Provides portlets for job submissions to GRAM2 and 4 services
	PyGlobus - Python based grid client and service APIs.  Provide client APIs for GRAM 2 and 4 services
	WSRF-Lite - Perl based grid client and service APIs.  Provide client APIs for GRAM 2 and 4 services

The main GRAM4 doc page: user, developer, admin doc is here: http://www-unix.globus.org/toolkit/docs/4.0/execution/wsgram/

As far as GRAM4 goes, here is a diagram of the the GRAM state machine:

caBig (Ravi)

• caBig is the Cancer bioinformatics grid. 22 institutions, distributed all over, hospitals and cancer research institutes.
• Starting with a SOA intrinsically. All services are GT4.0.3.
• Working groups get spawned to develop technologies.
• Workflow working group evaluated approaches in context of caBig.
• Two types of services- analytic (processing) and data (over databases).
• Saving data types in XML schema, centrally located - standard - for interoperability.
• NCIB goal is for this project to discover a cure for cancer by 2014. In 4th year. Ravi involved for a year.
• Orchestrate services across various sites using BPEL technology - non-computationally.
• Looking for an engines for workflow - wanted an open source product. Active BPEL, JBPM, Agila ...
• Discusses security in Gram - uses delegation - there is a small workflow involved. This will have to be integrated with ODE.
• Demonstrate a gram job submission integrated with bpel.
• 4 invoke statements in a BPEL document.
  • EPR holds delegated creds of user. Jdd (job description, RSL) file, stage-in directive (rft service), exe, RFT again to get results back and transfer, RFT to cleanup.
• Remote application virtual environment (RAVE). Framework that takes an app, wraps as a gt4 service, deploy, invoke automatically. Execute as a gram job, boostrap as a gram container.

Next steps

• Paul to get ODE integration package into shape that Ravi can look at. Paul to port Axis 1 to Axis 2.
• Setup testbed on uct3-edge7.
• Ravi to help with the GSI security pieces.

AOB

• None

-- RobGardner - 31 May 2007