Developing Grid Portals Using Portlets

Developing Grid Portals

Using Portlets

Marlon Pierce

Overview of Material

n

General remarks on portals and portlets.

• General remarks to provide context for the remainder of the

session.

n

OGCE Portal capabilities.

• Summary of things we do in OGCE.

n

JSR 168 Review

n

Developing OGCE portlets

• How to develop OGCE compatible portlets. • With launching points for Dennis and Gregor.

n

Useful third party testing tool: HttpUnit.

A brief JSR 168 tutorial.

n

At the risk of a low tutorial rating, I will cover higher level

Towards A Common

Grid Client Hosting

Environment

Grid portal background and

emerging common

What Is a Grid Computing Portal?

n

Browser based user interface for accessing grid and

other services

• “Live” dynamic pages available to authenticated, authorized

users.

• Use(d) Java/Perl/Python COGs

• Manage credentials, launch jobs, manage files, etc. • Hide Grid complexities like RSL

• Can run from anywhere

• Unlike user desktop clients, connections go through portal

server, so overcome firewall/NAT issues

n

Combine “Science Grid” with traditional web portal

capabilities

• Get web pages for news feeds • Post and share documents

• Search engine interfaces, calendars, etc. • Enabled by portlets, as we will see.

What a Grid Portal Is/Is Not

n

It is

• A tool for aggregating and managing web content

• A user customizable view of these Web content pieces.

n You see what you want/can see.

n But you must log in.

• Implemented on top of standard services

n Like login, authorization, customization.

n May include collaboration, etc, that depend on login.

• A way to accomplish Grid tasks through browsers:

n Launch, monitor jobs

n Move files

n Run science applications based on these services.

• Compatible with emerging standards and best practices (such as

portlets, JSR 168 and WSRP). n

It is not (just)

• A web page

• A collection of links

Which Is the Computing Portal?

n

In fairness, the screenshots are not large

enough to see, but you have to log in to the one

on the right.

•

Point is that they are superficially similar to browser

users, but have many differences under the hood.

n

The screen shot on the left is of the NASA JPL

QuakeSim project page.

•

htt

p://quakesim.jpl.nasa.gov/

n

The

screen shot on the right is the NASA JPL

QuakeSim portal.

•

http://www.complexity.ucs.indiana.edu:8282

•

Go here to run QuakeSim earthquake simulation

Let 10,000 Flowers Bloom

n

Many portal projects have been launched since

late ’90s.

•

HotPage from SDSC, NCSA efforts, DOD, DOE

Portals, NASA IPG

•

2002 Special Issue of Concurrency and Computation:

Practice and Experience.

n

Continue to be important component of many

large projects

•

NEESGrid, DOE SciDAC projects, NASA, NSF, many

international efforts

n

Global Grid Forum’s Grid Computing

Environments (GCE) Research Group

Port al User Int erf ace Grid Resource Broker Service Grid and Web Protocol s Information and Data Services Database Service Database HPC or Compute Cluster Grid Information Services, SRB Portal Client Stub Portal Client Stub Portal Client Stub JDBC, Local, or Remote Connectio n

Three-Tiered Architecture

Problem with Portals

n GCE revealed two things

• Everyone was doing the same thing

n Not quite, but significant

n Everyone builds secure logins, remote file manipulation, command execution, access to info servers.

n Everyone would at least like support for multiple user roles (administrators, users) and customization

• No one could share components with other groups

n No well defined way of sharing UI components or making services interoperate.

n No well defined interfaces to portal services. n A research opportunity!

• Two levels of integration: user interfaces and services

n Our challenges

• Stop reinventing things and provide ways for groups to reuse

components.

A Solution based on

components

n

A software component is object defined by

• A precise public interface

• A semantics that includes a set of “standard” behaviors.

n

A Software component architecture is:

• A a set of rules for component behavior &

• A framework in which components can be easily installed and

interoperate.

n

The component architecture of choice for the Portal

community is the one based on

portlets

• (Java) components that generate content, make local and

remote connections to services.

• Portlet containers manage portlet lifecycles

n

We have now many, many components.

Things to Hate About Portals

n If you involved in portal efforts, be aware of the following: n Browsers have limited interactivity.

• Desktop GUIs provide much better interactivity but have other

problems.

• Applets are a solution, but they don’t interact with other parts of the

browser very well.

• Solution: Service Oriented portals let you use services through both

portals and grid desktops.

n Developing really useful user interfaces to your set of services is a time consuming, non-scaling process.

• Get users involved early in design.

n Browsers notoriously have incompatible features.

• Things don’t work the same on IE, Mozilla, Konqueror, etc. • Same browsers on Macs, Windows don’t work the same. • No substitute for lots of testing.

n Grid portals need grids.

• Setting up grids is a fragile process.

• Plenty of dumb mistakes like setting up CA signing policies that even

experts make.

OGCE: Open Grid

Computing Environments

Marlon Pierce

NSF NMI Project for Reusable

Portal Components: Who We Are

n

University of Chicago

•

Gregor von Laszewski

n

Indiana University

•

Marlon Pierce, Dennis Gannon, Geoffrey Fox, and

Beth Plale

n

University of Michigan

•

Charles Severance, Joseph Hardin

n

NCSA/UIUC

•

Jay Alameda, Joe Futrelle

n

Texas Advanced Computing Center/San Diego

State University

What Is OGCE’s Release 1

n

The OGCE Portal release is based on CHEF/Jetspeed

1.4

n

Available for download and installation from

h

ttp://www.collab-ogce.org.

n

I

t comes with many pre-configured capabilities if you

want a grid portal “out of the box”.

• Except for the mysql jar.

• You must still set up Grid services (MyProxy servers, Globus,

etc).

• Globus version compatibility through the Java CoG.

n

Apache Ant-based installation procedure:

Access context services for managing metadata GridContext Portlets

Access to Anabas shared display applets Anabas

View, interact with HPC status, job, etc information. GPIR Portlets

Run simple executables on remote hosts GRAM Job Submission

Live chat services and interfaces Chat

Persistent topic-based discussion for groups Discussion

Interactive individual and group calendars Schedule

WEBDav based document system for group file sharing

Document managers

Post topics to newsgroup, manage group references and citations with access controls Newsgroups and citation portlets

Upload, download, crossload remote files. GridFTP

Basic Globus MDS browsing and navigating MDS/LDAP Browsers

Get MyProxy certs after logging in. Grid Proxy Certificate Manager

Description Portal Capabilities

Set up and run task graphs using the Java CoG CoG Workflow demonstration portlet

The backend for the Grid Context portlet XDirectory Services

Combine GridFTP and GRAM into application wizard forms.

Application Management

Interact with Condor through browser. Condor Portlets

Download and install server side of the OGCE newsgroup system.

Newsgroup Services

Manage complicated grid tasks through an extensible, Apache Ant like task list.

OGRE Job Management Services

Schedule sequences of jobs on several hosts using Community Scheduling Framework.

Job Scheduling and Sequencing

Description

Grid Portlet Examples

n

We’ll next overview several portal

capabilities.

n

Jetspeed/CHEF acts as a clearing house

for portal capabilities

•

User interface components can be added in

well defined ways.

•

First level of integration

n

All Grid access goes through the Java

Example Capability: Portals for

Users

n The user contacts the portal

server and asks it to do “grid” things on behalf of the user.

n To make this possible the

server needs a “Proxy Certificate”

• The user has previously

stored a proxy cert in a

secure MyProxy Server stored with a temporary password.

• User give the portal server

the password and the portal server contacts the proxy server and loads the proxy.

• The portal server will hold the

proxy for the user for a “short amount of time” in the user’s session state.

Portal Server

1. Load my Proxy

Certificate!

User “Beth”

MyProxy Server

Example Capability: Grid Context

Service

n

User’s want to be able to use the portal to keep

track of lots of things

•

Application and experiment records

n File metadata, execution parameters, workflow scripts

•

“Favorite” services

n Useful directory services, indexes, links to important

resources

•

Notes and annotations

Portlet Interfaces to Grid Context

n A Remote Service Directory

Interface

• Holds references and

metadata about application services.

n User selects interface to

application service from the directory browser.

n Examples: (near completion)

• Select a link to a Dagman

document and invoke the Condor service on the script.

• Same for GridAnt/Ogre or

BPEL workflow script.

• Factory services for any grid

Example Capability: Topic Based

Messaging Systems

n

XML metadata system based on

messages.

n

Newsgroups

•

Topic based message posting and

administration

n

Citation/reference browsers

•

Topic based, export/import bibtex

n

Portlets sit atop JMS-based message

system

User Privileges for Group Channels

n

Users request access to specific

topics/channels.

•

Granted by administrator for that topic

n

Can request

•

Read/write by browser

•

Read/write by email (newsgroups)

Receive/don’t receive attachments.

n

Topic admin can edit these requests.

GPIR Data

n

Load - aggregated CPU

Downtime data for a

machine

• Jobs: aggregated queue

n

MOTD

n

Nodes: job usage for

each machine node

n

NWS: based on VO

and Click model

n

Grid Monitoring

• Based on TACC GMS

System

• Custom providers

• Plans to include MDS3.0

and INCA data uderway

n

Expanding to include:

• application profiles • performance data • Application profiles • Doc links

n

Model allows generic

inclusion of any XML

data from any

recognized source

GPIR Components

n

Web Services Ingestor

• Web Services Ingestor and clients • XML Schemas - can be changed

n

Data Repository

• Local Cache

• Archival --> PostgreSQL

n

Web Service Query

• retrieve data – XML Queries

• Retrieving current snapshot and archived data

n

Clients

• GridPort services

• Portal/Web Interface (Portlets, servlets, JSP)

• Command line

What’s Next for the OGCE?

n

JSR 168 Compatible Grid portlet release at

Supercomputing.

• Basic capabilities: MyProxy, GridFTP, GRAM, GPIR, based on

CoG 4.

• Working in uPortal, GridSphere, Jetspeed2, ….

n

Join (all of) us at SC2004 for a portals BOF.

n

Solutions JSR 168 limitations that work in multiple JSR

168 containers.

n

Grid-compatible WSRP portlets.

• Compatible with Sakai/CHEF 1.2 capabilities.

n

Backward compatibility bridges to previous portlets.

A JSR 168 Overview

What is JSR 168?

n

Defines a standard for vendor container-independent

portlet components.

n

Many implementations:

• Gridsphere, uPortal, WebSphere, Jetspeed2, ….

n

From the portlet development point of view, it is really

very simple:

• You write a java class that extends GenericPortlet.

• You override/implement several methods inherited from

GenericPortlet.

• You use some supporting classes/interfaces

n Many are analogous to their servlet equivalents

n Some (portletsession) actually seem to be trivial wrappers

Some Terminology

A webapp containing a group of related

portlets, content, supporting jars, etc.

Portlet

Application

Displays the portal content provided by

the container. The portal is responsible

for the actual layout.

Portal

Manages the lifecycle of the portlets

(inits, invokes,destroys).

Portlet

Container

Java code that manages a piece of web

content and which may invoke remote

services.

Portlet

Some Generic Portlet Methods

Place for handling any <form> actions before turning over to the display mode method (like doView). You should override this for web forms.

processAction

Other portlet display modes doHelp, doEdit

Controls what happens immediately before the portlet is displayed in view mode.

Normally you override this. doView

Called when the portlet is created. Override if you need to set initial params.

Init

Supporting Classes/Interfaces

The request and response objects available to the processAction() method. Similar to the servlet

request and response objects. ActionRequest,Actio

nResponse

Use this to include/forward to a JSP or servlet in the same portlet app.

PortletRequestDispat cher

Use this to create URLs that reference the portal. PortletURL

See if you are in minimized, maximized, normal state.

WindowState

The request and response objects available to the doView() method. Similar to the normal servlet request

RenderRequest, RenderResponse

Stores attribute information for a single portlet application across multiple requests.

PortletSession

Similar to servlet context; get context info and the RequestDispatcher from here.

PortletContext

The Infamous Big Picture

n As a portlet developer, the previous set of classes are

all you normally touch.

n The portlet container (such as Pluto or Gridsphere) is

responsible for running your portlets.

• Init, invoke methods, destroy.

n Portlets have a very limited way of interacting with the

container.

• It is a black box.

Deploying Portlet Applications

n

The portlet container (i.e. uPortal) runs as a

distinct web application.

•

That is, it has its own directory in tomcat.

•

Moreover, it runs as a separate context, with its

own classloader, session management, etc.

n

Portlet applications are deployed as distinct

war files/web applications.

•

You go through the container webapp to get to the

portlet webapp.

•

Portlets in the same application share jars,

classes, and runtime stuff like request and session

variables.

•

Portlets in different portlet apps do not share

A Critique of JSR 168

n There is no way to share data/objects between portlet applications.

• So all grid portlets would have to be in the same portlet app.

n There is no way to extend the portlet API to add such services. n There is a lack of general purpose portlets.

• Right now, you make specific extensions to GenericPortlet for each portlet

you develop.

n JSR 168’s MVC approach is incompatible with Turbine, Struts, ….

• The issue is managing <form action=“”> and href URLs.

• No fundamental problem, but this is a gap that must be filled. • JSF Portlets are the exception.

n No defined way to integrate with portal-specific services (i.e. logins). n No inter-portlet communication.

n Despite these problems, JSR168 (and WSRP) are the best available

standards.

• They are compatible.

• WSRP overcomes many of the JSR 168 limitations.

• But more work needs to be done to make WSRP ready for Grid portals

Writing Basic OGCE

Portlet Templates

Writing a Velocity Portlet

n

Imagine the following simplistic scenario:

•

I have a web form that helps a user submit a job to a

supercomputer.

•

I only need one input form to generate the input file,

pick a host computer, etc.

n

The output file is written back to the user’s home

directory, so he or she can gridftp it later.

Velocity Portlet Example

n

Before handling the Grid execution, we will

first construct a dummy form.

n

We will use Velocity templates.

Jetspeed has better support and

documentation for Velocity.

Create the Template

n Open a new file in

nmi/WEB-INF/templates/vm/portlets /html.

n Give it a name,

myTestApp.vm

n Write the Velocity template n Write an xreg file (see next

slide).

n Restart Tomcat.

n Customize your display to

show the new portal.

n So far, so good.

<h3> Enter the command

Sample JSP Portlet Template

<?xml version="1.0" encoding="UTF-8"?> <registry>

<portlet-entry name="myScienceApp" hidden="false" type="ref" parent="CustomizerVelocity" application="false">

<meta-info>

<title>Sample Proxy Form</title>

<description>Sample Proxy Form</description> </meta-info>

<classname>org.apache.jetspeed.portal.portlets.VelocityPortlet</classname>

<parameter name="template" value="myScienceApp" hidden="true" cachedOnName="true" cachedOnValue="true"/>

<parameter name="action" value="portlets.myScienceAppAction" hidden="true" cachedOnName="true" cachedOnValue="true"/> <media-type ref="html"/>

<url cachedOnURL="true"/> </portlet-entry>

Specifying The Template

n

The parts in red

(template and

action) point to

things that you

must write.

n

The line below is

used to name the

VM template in the

XREG.

•

Points to

myScienceApp.vm

<parameter

name="template"

value="myScienceApp

"

hidden="true"

cachedOnName="true

”

Actions in Templates

n

Note our velocity template is just HTML (at this point)

with a form action.

• The action implementation is specified in the XREG file.

• MyScienceAppAction.java is the code that does the work when

you click the button.

n

Jetspeed action managers are responsible for calling

your actions.

• You just need to write the java code, put it in the right place, and

connect it to a Velocity template in the XREG file.

Writing An Action

n

A portlet action is just a java class.

n

It should extend VelocityPortletAction

n

You should implement the buildNormalContext()

method.

•

This method is called by default when you invoke an

HTML form action.

•

This can do anything you want (i.e. make calls to Grid

services through the Java COG).

Getting Started

n

Let’s give our simple

portlet an action.

n

To do this, we first

modify the

• Don’t forget to

shutdown tomcat first.

n

We then write the

action and compile it

into

nmi/WEB-INF/classes.

• See next slide

• Set classpath correctly! n

Restart the server.

<parameter name="action" value="portlets.myScience ApAction"

hidden="true"

cachedOnName="true "

A Minimal Action:

myScienceAppAction.java

package org.apache.jetspeed.modules.actions.portlets; //Import Turbine packages.

import org.apache.turbine.util.RunData; //Import Velocity packages

import org.apache.velocity.context.Context; //Import Jetspeed packages.

import org.apache.jetspeed.modules.actions.portlets.VelocityPortletAction; import org.apache.jetspeed.portal.Portlet;

public class myScienceAppAction extends VelocityPortletAction { public void buildNormalContext(VelocityPortlet portlet,

Context acontext, RunData rundata) {

//Real action code goes here.

System.out.println("buildNormalContext called"); }

Some Miscellaneous Notes

n

This action is automatically called whenever the

JSP template’s form action is invoked.

n

In the portal release, the

chef-1.0.7/modules/nmi-lib directory contains all the

jars needed to compile this code.

•

You can use our ant build scripts as templates for

writing your own.

n

The portlet actions’s system.out.println() is

written to catalina.out.

RunData, Requests, and

Sessions

n

The method buildNormalContext includes an

object called

RunData

in its arg list.

n

RunData is your access point to all HTTP

request, response, and session data.

•

HttpSession session=rundata.getSession();

•

HttpServletRequest req=rundata.getRequest();

n

From here, you can do standard java.net.*

development.

Connecting Multiple Templates

n

In reality, a single web form is not enough to set

up a complicated input file, select a host and

execute a job.

•

These may be spread over multiple linked forms.

n

Form actions in templates must be handled a bit

differently.

n

<form action=“SomeOtherPage”>

•

This can’t point to a template, since it is not directly

accessible (in WEB-INF).

Redirecting to Another Page

n

Setting up and

running applications

from a portal typically

requires many

successive HTML

forms.

n

So we need to see

how to do this with

Jetspeed.

n

Let’s call this

myScienceApp2.vm

and place it in the

same place as

myScienceApp.vm.

myScienceAp

p

myScienceAp

p2

myScienceAppAction

First, Modify myScienceApp.vm

n

Use the

eventSubmit_{acti

on} construction.

n

This action will be

tied to a specific

method in

myScienceAppActio

n.java.

<h3> Enter the command you want to execute</h3>

<form method="post"> <table> <tr> <td>Command Name:</td> <td><input type="text" name="runCommnad" value=""></td> </tr> </table> <input type="submit" name="eventSubmit_doGet_c ommand" value="Click to

Next, Modify Your Action Code

n Add the following method to

myScienceAppAction.java.

n Your method name should

follow the pattern given in the form.

n This particular action runs

setTemplate(), which loads the indicated Velocity

template.

n When you click a form,

Jetspeed will look for all methods matching

eventSubmit’s pattern.

n If it finds them, it executes

them.

n If not, buildNormalContext()

is the default.

public void

doGet_command( Run

Data runData, Context

aContext ) {

Write the Destination Template

n The following is an

example of

myScienceApp2.vm.

n Note the eventSubmit. n Both of our templates use

the same action.

n We can add a method

doGet_host to

myScienceAppAction.java to handle host events.

n You can build

• Once=anomaly • Twice=infinitely

reproducible pattern

<form method="post">

BigIron: <input type=radio name=host

value="BigIron"> <br>

IronBird: <input type=radio name=host

value="IronBird"> <input type="submit"

name="eventSubmit_doGe

t_host" value="Click to

Grid Portlets

n There is nothing fundamentally special about Grid portlets

• Just implement your portlet action with Java COG calls.

n We handle all access to the Grid through the Java COG kit.

• Hides differences between Globus toolkit versions.

• Currently a higher level programming API for the COG is under

development as part of NMI.

• GVL is one of our PIs, so we all have vested interest in this.

n Basic procedure:

• Proxy credentials acquired through MyProxy client portlet. • Modify your action java class (myScienceAppAction.java)

• Use convenience methods to get local GSSCredential from memory. • Use GSSCredential in COG calls to Grid resources.

Example Code: Fetching

Credentials

n

The OGCE provides

a convenience

class

ProxyManager

for

storing/fetching

proxy creds.

•

Assumes you have

logged in to the

proxy portlet.

HttpSession session

=

runData.getSessio

n();

GSSCrendential cred

=

Using the CoG Portlet Interfaces

n

From here, you can develop portlet actions

using the Java CoG kit.

n

Gregor will discuss new interfaces in the

Portal Testing with

HTTPUnit

Types of Unit Testing

n

JUnit is a great way for testing code

functionality.

n

But how do you test portals and portlets?

•

Portal interfaces need to be tested by simulated

users.

n

Button clicks, link clicks, form interactions, etc.

n

For the NMI OGCE project, we have adopted

HttpUnit for this.

Unique Challenges for Testing

Grid Portals

n

Fluid GUI

n

Much setup required for Grid Portal

•

Portal account

•

Grid Software, accounts

•

Reliance on external services

n

Broken HTML

n

Infinite set of user operations

HTTPUnit Features

n

Extension of Junit

•

Integrates easily with Ant <junit> task

n

Fairly high level API

n

Browser emulation (cookies, JavaScript,

etc.)

n

Includes a sloppy/quirky HTML parser

Setting Up Your Test

n

The code on the

right shows the

boilerplate to

put at the start

of your test.

n

We will fill in

the rest of the

test in the

following slides.

package xportlets.tests; import

com.meterware.httpunit.*; import junit.framework.*; public class XPortletTestCase

extends TestCase { ....

public void setUp() throws Exception {

super.setUp(); }

Testing a Login Form

n The code shows how to

actually write a simple form test.

n Create a

WebConversation object.

n Use WebResponse to

work programmatically with the HTML.

n Use WebForm to invoke

HTML <forms>

n Assertions are used to

test the content of the returned page.

public WebConversation xPortletAuth() throws Exception {

WebConversation wc = new WebConversation(); WebResponse resp =

wc.getResponse(url); WebForm form =

resp.getForms()[0]; form.setParameter("username", username); form.setParameter("password", password); form.submit();

WebResponse resp2 = wc.getCurrentPage();

String page = resp2.getText();

assertTrue("Failed to log in", page.indexOf("Welcome to your workspace") != -1);

Simulating Button Clicks

n

Create SubmitButton

objects to simulate

button clicks.

• “myButton” is the name

of the submit button in the HTML <form>

n

Calling click() causes

the form action to

take place.

n

Get the new page

from the

WebConversation

object.

public void testSimplePing() throws Exception {

WebConversation wc = xPortletAuthProxy(); WebResponse resp =

wc.getCurrentPage(); WebForm form =

resp.getForms()[3];

form.setParameter("service", "rainier.extreme.indiana.edu");

SubmitButton addServiceBtn =

form.getSubmitButton(“myButton" );

assertNotNull(“myButton", addServiceBtn); addServiceBtn.click();

WebResponse resp2 =

wc.getCurrentPage(); WebForm form2 =

Running HttpUnit with Ant

n

After you have developed a suite of tests,

you can automate your portal tests using

Ant’s optional JUnit task.

n

Even better, you can combine this with the

<junitreport> task that will generate nice

HTML report forms.

n

First, you will need to put these jars in ant’s

lib directory.

•

httpunit.jar

An Example Unit Test Target

n Let’s say all of your tests

fit the pattern Test*.class.

n Then run a <batchtest>

to run all of them at once.

• Will run all tests

• Won’t exit on failed test.

n Use errorProperty and

failureProperty to catch these states.

n Specify an XML formatter

for pretty output (next).

Generating HTML dashboards

n

The <junitreport>

target can be used to

convert the report

outputs from

<junit>.

n

Use <report> to

generate HTML.

n

Finally the <fail>

message checks if

any tests failed.

• See previous target.

Example Report Dashboard

List of

Test Classes

Some Drawbacks to HTTPUnit

n

Tests are tied to page structures.

•

If you change your page (say, reordering links

or forms), you will break your tests.

n

Tests also depend on

n

Test assertions typically depend on the

content of the page.

•

If content changes, tests may break.

•

Checking content is not completely sufficient

Capability: Community

Scheduling Framework Portlets

CSF Use Case

n Researcher submits job through User Portal n User Portal uses GridPort to

• authenticate user

• optionally make advanced reservation to visualization system

• submit job to CSF

n CSF selects compute cluster with best fit and forwards job n Gridport sends results to visualization system

User

Workstation User PortalGridPort

CSF

Visualization System

Bandera

Blanco

Capability: Job Sequencer Portlets

User uses Portal to generate XML description of sequence. " xsi:schemaLocation="http://grids.tacc.utexas.edu/schemas/sequencer/jobSequence C:\DOCUME~1\Maytal\Desktop\Maytal\Work\GP-IR\GP-IRX~1\motd.xsd"> <<Status>New</Status> <Step> <Status>Unscheduled</Status> <Type>CSFJob</Type> <Parameter name="jobFactoryServiceHandle">http://129.116.218.36:15080/ogsa/services/metasche duler/JobFactoryService</Parameter> <Parameter name="queue">normal</Parameter> <Parameter name="executable">pam</Parameter> <Parameter name="arguments">-g 1 mpichp4_wrapper /home/monitor/mpi_jobs/mpimd_5</Parameter> <Parameter name="directory">/home/monitor/mpi_jobs</Parameter> <Parameter name="count">4</Parameter> <Parameter name="stdIn">/dev/null</Parameter> <Parameter name="stdOut">/home/monitor/mpi_jobs/tomislavSequencerJobOut</Parameter> <Parameter name="stdErr">/home/monitor/mpi_jobs/tomislavSequencerJobErr</Parameter> </Step> <Step><Status></Status> <Type>GridFTP</Type> <Parameter name="fromHost">[Previous]</Parameter> <Parameter name="toHost">blanco.tacc.utexas.edu:2811</Parameter> <Parameter name="fromFileFullName">/home/monitor/mpi_jobs/tomislavSequencerJobOut</Paramet er> <Parameter name="toFileFullName">/home/monitor/mpi_jobs/tomislavSequencerJobOutCopied</">/h ome/monitor/mpi_jobs/tomislavSequencerJobErr</Parameter><Parameter name="toFileFullName">/home/monitor/mpi_jobs/tomislavSequencerJobErrCopied</Par ameter> </Step> </JobSequence> Currently, sequence steps can consist of File Transfers and Job

Submissions to the CSF meta scheduler

GPIR

The XML is then decomposed and persisted to GPIR where the status information of each step in the sequence

and of the sequence as a whole can be

stored

Sequencer

GridPort returns a Sequence ID to the Portal immediately and

then begins executing the Sequence to completion or to error. Status information can be obtained at any time

O.G.R.E.—A Job Management

Engine

•

O.G.R.E. =

O

pen

G

rid Computing Environments

R

untime

E

ngine

•

What Ant lacked, but we needed:

•Broader conditional execution,

•Ant: based on write-once String properties.

•A general “loop” structure for Task execution.

•Data-communication between Tasks (and with their containers).

•Specialized tasks

•File reading and writing

•Local and remote file management (gridftp)

•Web service related tasks

XDirectory: A Grid Context Service

n XDirectory is itself a Grid Service that is access by the portal.

• An index over a relational database

• Each node is either a “directory node” or a leaf.

• Leaf nodes are xml elements which contain metadata as well as html

Java CO

G

Example Capability: File

Management

n

Grid FTP portlet–

Allow User to manage

remote file spaces

• Uses stored proxy for

authentication

• Upload and download

files

• Third party file transfer

n Request that GridFTP

server A send a file to GridFTP server B

n Does not involve traffic

through portal server

JSR 168 Tutorial

In Action: Get started.

public class JunkPortlet extends

GenericPortlet {

public void init(){

//Do any initialization.

}

//Rest of the methods on following slides

go here.

Override doView()

protected void doView( RenderRequest req, RenderResponse res) throws PortletException, IOException {

//Include the desired JSP or HTML page.

//We could also use out to write directly to the response. WindowState state=req.getWindowState();

if(!state.equals(WindowState.MINIMIZED)) { res.setContentType("text/html");

PortletRequestDispatcher rd=

getPortletContext().getRequestDispatcher(“MyJSP.jsp”); rd.include(req,res);

The JSP Page

<

portlet:defineObjects

/>

<%

PortletSession

portletSession=renderRequest.getPortletSession();

portletSession.setAttribute("localattname","localattval");

PortletURL url=renderResponse.createActionURL();

String theActionString=url.toString();

%>

HTML Content is here.

A form is below.

<form method=post action="<%=

theActionString

%>">

<input type=…>

Some Notes

n Include the <%portlet:definedObjects/%> tag, which will instantiate renderRequest, renderResponse, and portletConfig objects.

• You can then just use them, as with request, response, and other JSP

implicit objects.

n The renderRequest gives you access to the PortletSession, if you want to store session variables.

• One of the trouble points.

n The renderResponse gives you access to the PortletURL object. n Use the PortletURL to generate a URL for the <form action>

• So that it points to portlet container and gets handled by the

processAction() method, rather than going of into space.

• Handle href URLs similarly.

Lastly, Override processAction()

n When you invoke the form on the

previous JSP, the portlet

container will pass the action handling to the processAction method.

n The ActionRequest can be used to

get any of the <input>

parameters in a way similar to the usual HttpServletRequest.

n When the processAction method

returns, the container then invokes the appropriate do method (usually doView).

n If you need to pass <form>

parameters on to doView, add them to the ActionResponse.

• This will give them to the

RenderRequest.

• The example shows how to add

ALL parameters.

public void processAction (ActionRequest request, ActionResponse actionResponse) throws PortletException, java.io.IOException { //Process request parameters …

//Add any other request params

// to the renderRequest actionResponse.setRender Parameters(request.getPar ameterMap());