Developing Grid Portals

Using Portlets
Marlon Pierce
Community Grids Lab
Indiana University
 Overview of Material
 General remarks on portals and portlets.
• General remarks to provide context for the remainder of
the session.
 OGCE Portal capabilities.
• Summary of things we do in OGCE.
 JSR 168 Review
 Developing OGCE portlets
• How to develop OGCE compatible portlets.
• With launching points for Dennis and Gregor.
 Useful third party testing tool: HttpUnit.
 A brief JSR 168 tutorial.
 At the risk of a low tutorial rating, I will cover
higher level issues. Slides on nuts and bolts
details are provided for homework.
Towards A Common Grid
Client Hosting
Environment
Grid portal background and
emerging common
frameworks
 What Is a Grid Computing Portal?
 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
 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.
 Customizable interfaces and user roles/views
 What a Grid Portal Is/Is Not
 It is
• A tool for aggregating and managing web content
• A user customizable view of these Web content pieces.
 You see what you want/can see.
 But you must log in.
• Implemented on top of standard services
 Like login, authorization, customization.
 May include collaboration, etc, that depend on login.
• A way to accomplish Grid tasks through browsers:
 Launch, monitor jobs
 Move files
 Run science applications based on these services.
• Compatible with emerging standards and best practices
(such as portlets, JSR 168 and WSRP).
 It is not (just)
• A web page
• A collection of links
• An applet
Which Is the Portal?
Which Is the Computing Portal?
 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.
 The screen shot on the left is of the NASA
JPL QuakeSim project page.
• http://quakesim.jpl.nasa.gov/
 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 codes, access earthquake
databases, etc.
 Let 10,000 Flowers Bloom
 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.
 Continue to be important component of
many large projects
• NEESGrid, DOE SciDAC projects, NASA, NSF,
many international efforts
 Global Grid Forum’s Grid Computing
Environments (GCE) Research Group
• Community forum
 Three-Tiered Architecture
Grid and JDBC,
Web Local, or
Protocols Remote
Connection
Portal User Interface

Portal
Database
Client Database
Service
Stub

Portal HPC
Grid Resource
Client or
Broker Service
Stub Compute Cluster

Portal Information
Grid Information
Client and
Services, SRB
Stub Data Services

Three-tiered architecture is accepted standard for

accessing Grid and other services
 Problem with Portals
 GCE revealed two things
• Everyone was doing the same thing
 Not quite, but significant
 Everyone builds secure logins, remote file manipulation, command
execution, access to info servers.
 Everyone would at least like support for multiple user roles
(administrators, users) and customization
• No one could share components with other groups
 No well defined way of sharing UI components or making services
interoperate.
 No well defined interfaces to portal services.
 A research opportunity!
• Two levels of integration: user interfaces and services
 Our challenges
• Stop reinventing things and provide ways for groups to reuse
components.
• Provide a portal marketplace for competing (advanced)
services.
• Provide APIs for service integration
 A Solution based on
components
 A software component is object defined by
• A precise public interface
• A semantics that includes a set of “standard” behaviors.
 A Software component architecture is:
• A a set of rules for component behavior &
• A framework in which components can be easily installed
and interoperate.
 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
 We have now many, many components.
• So don’t start from scratch.
 Things to Hate About Portals
 If you involved in portal efforts, be aware of the following:
 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.
 Developing really useful user interfaces to your set of
services is a time consuming, non-scaling process.
• Get users involved early in design.
 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.
 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.
• You will be blamed when things don’t go smoothly.
 OGCE: Open Grid
Computing Environments
Marlon Pierce
Indiana University
 NSF NMI Project for Reusable
Portal Components: Who We Are
 University of Chicago
• Gregor von Laszewski
 Indiana University
• Marlon Pierce, Dennis Gannon, Geoffrey Fox,
and Beth Plale
 University of Michigan
• Charles Severance, Joseph Hardin
 NCSA/UIUC
• Jay Alameda, Joe Futrelle
 Texas Advanced Computing Center/San
Diego State University
• Mary Thomas
 What Is OGCE’s Release 1
 The OGCE Portal release is based on
CHEF/Jetspeed 1.4
 Available for download and installation from
http://www.collab-ogce.org.
 It 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.
 Apache Ant-based installation procedure:
• Edit one properties file, run ant, and away you go.
 User Portlets
Portal Capabilities Description
Grid Proxy Certificate Manager Get MyProxy certs after logging in.
Schedule Interactive individual and group calendars
Discussion Persistent topic-based discussion for groups
Chat Live chat services and interfaces
Document managers WEBDav based document system for group
file sharing
MDS/LDAP Browsers Basic Globus MDS browsing and navigating
GridContext Portlets Access context services for managing
metadata
GRAM Job Submission Run simple executables on remote hosts
GridFTP Upload, download, crossload remote files.
GPIR Portlets View, interact with HPC status, job, etc
information.
Anabas Access to Anabas shared display applets

Newsgroups and citation portlets Post topics to newsgroup, manage group

references and citations with access controls
 More User Portlets and Services
Portal Capabilities Description

CoG Workflow demonstration Set up and run task graphs using the Java
portlet CoG
Job Scheduling and Sequencing Schedule sequences of jobs on several hosts
using Community Scheduling Framework.

Condor Portlets Interact with Condor through browser.

Application Management Combine GridFTP and GRAM into application

wizard forms.

Newsgroup Services Download and install server side of the OGCE

newsgroup system.

OGRE Job Management Services Manage complicated grid tasks through an

extensible, Apache Ant like task list.

XDirectory Services The backend for the Grid Context portlet

 Grid Portlet Examples
 We’ll next overview several portal
capabilities.
 Jetspeed/CHEF acts as a clearing
house for portal capabilities
• User interface components can be
added in well defined ways.
• First level of integration
 All Grid access goes through the Java
COG.
 Example Capability: Portals for
Users User “Beth”
 The user contacts the portal
server and asks it to do “grid”
things on behalf of the user.
 To make this possible the
server needs a “Proxy 1. Load my
Certificate” Proxy
• The user has previously
stored a proxy cert in a Certificate!
secure MyProxy Server stored
with a temporary password. Portal Server
• User give the portal server MyProxy
the password and the portal Portlet
server contacts the proxy 2. Give me
COG
server and loads the proxy.
I am
3. Beth’s
Beth’s proxy
• The portal server will hold the Proxy
proxy for the user for a “short certificate
amount of time” in the user’s
session state.
MyProxy
Server
 Example Capability: Grid Context
Service
 User’s want to be able to use the portal to
keep track of lots of things
• Application and experiment records
 File metadata, execution parameters, workflow
scripts
• “Favorite” services
 Useful directory services, indexes, links to important
resources
• Notes and annotations
 “Scientific Notebooks”
 Portlet Interfaces to Grid Context
 A Remote Service Directory
Interface
• Holds references and
metadata about application
services.
 User selects interface to
application service from the
directory browser.
 Examples: (near completion)
Portal
• Select a link to a Dagman Server
document and invoke the
Condor service on the script.
• Same for GridAnt/Ogre or
BPEL workflow script. Remote
Grid
Remote
• Factory services for any grid Service
Application
Service
apps that have interactive Directory
user interfaces. Service
 Example Capability: Topic Based
Messaging Systems
 XML metadata system based on
messages.
 Newsgroups
• Topic based message posting and
administration
 Citation/reference browsers
• Topic based, export/import bibtex
 Portlets sit atop JMS-based message
system
• NaradaBrokering, used in JMS mode.
User Privileges for Group Channels
 Users request access to specific
topics/channels.
• Granted by administrator for that topic
 Can request
• Read/write by browser
• Read/write by email (newsgroups)
• Receive/don’t receive attachments.
 Topic admin can edit these requests.
 Super admins can manage administrators
to topics
 GPIR Data
 Load - aggregated CPU
 Downtime data for a  Expanding to include:
machine • queuing system
• Jobs: aggregated queue
• application profiles
 MOTD
• performance data
 Nodes: job usage for
• Application profiles
each machine node
• Doc links
 NWS: based on VO
and Click model  Model allows generic
 Grid Monitoring inclusion of any XML
• Based on TACC GMS data from any
System
• Custom providers
recognized source
• Plans to include MDS3.0 • Need schema
and INCA data uderway • Need query
Grid Portal Information Repository
(GPIR 1.1)
 GPIR Components
 Web Services Ingestor
• Web Services Ingestor and clients
• XML Schemas - can be changed
 Data Repository
• Local Cache
• Archival --> PostgreSQL
 Web Service Query
• retrieve data – XML Queries
• Retrieving current snapshot and archived data
 Clients
• GridPort services
• Portal/Web Interface (Portlets, servlets, JSP)
• Command line
• Any that speak web services
 What’s Next for the OGCE?
 JSR 168 Compatible Grid portlet release at
Supercomputing.
• Basic capabilities: MyProxy, GridFTP, GRAM, GPIR, based
on CoG 4.
• Working in uPortal, GridSphere, Jetspeed2, ….
 Join (all of) us at SC2004 for a portals BOF.
 Solutions JSR 168 limitations that work in
multiple JSR 168 containers.
 Grid-compatible WSRP portlets.
• Compatible with Sakai/CHEF 1.2 capabilities.
 Backward compatibility bridges to previous
portlets.
 Fancy new capabilities available in separate
downloads.
A JSR 168 Overview
A review of the latest portlet
developments.
 What is JSR 168?
 Defines a standard for vendor container-
independent portlet components.
 Many implementations:
• Gridsphere, uPortal, WebSphere, Jetspeed2, ….
 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
 Many are analogous to their servlet equivalents
 Some (portletsession) actually seem to be trivial
wrappers around servlet equivalents in Pluto.
 Some Terminology
Term Definition
Portlet Java code that manages a piece of
web content and which may
invoke remote services.
Portlet Manages the lifecycle of the
Container portlets (inits, invokes,destroys).

Portal Displays the portal content

provided by the container. The
portal is responsible for the actual
layout.
Portlet A webapp containing a group of
Application related portlets, content,
supporting jars, etc.
 Some Generic Portlet Methods
Method Description
Init Called when the portlet is created.
Override if you need to set initial
params.
doView Controls what happens immediately
before the portlet is displayed in view
mode. Normally you override this.

doHelp, doEdit Other portlet display modes

processAction Place for handling any <form> actions

before turning over to the display mode
method (like doView). You should
override this for web forms.
Supporting Classes/Interfaces
Class Description
PortletContext Similar to servlet context; get context info
and the RequestDispatcher from here.
PortletSession Stores attribute information for a single
portlet application across multiple requests.
RenderRequest, The request and response objects available
RenderResponse to the doView() method. Similar to the
normal servlet request
ActionRequest,Acti The request and response objects available
onResponse to the processAction() method. Similar to
the servlet request and response objects.
PortletURL Use this to create URLs that reference the
portal.
PortletRequestDisp Use this to include/forward to a JSP or
atcher servlet in the same portlet app.
WindowState See if you are in minimized, maximized,
normal state.
 The Infamous Big Picture
 As a portlet developer, the previous set of classes are all
you normally touch.
 The portlet container (such as Pluto or Gridsphere) is
responsible for running your portlets.
• Init, invoke methods, destroy.
 Portlets have a very limited way of interacting with the
container.
• It is a black box.
• The API is basically one-way.
Deploying Portlet Applications
 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.
 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 anything.
 A Critique of JSR 168
 There is no way to share data/objects between portlet
applications.
• So all grid portlets would have to be in the same portlet app.
 There is no way to extend the portlet API to add such
services.
 There is a lack of general purpose portlets.
• Right now, you make specific extensions to GenericPortlet for each
portlet you develop.
 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.
 No defined way to integrate with portal-specific services (i.e.
logins).
 No inter-portlet communication.
 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 (Web Service security).
Writing Basic OGCE
Portlet Templates
Developing Portlets for OGCE
Release 1
 Writing a Velocity Portlet
 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.
 The output file is written back to the
user’s home directory, so he or she can
gridftp it later.
 Before we can do this, we first need a bit
of background on programming portlets.
 Velocity Portlet Example
 Before handling the Grid execution,
we will first construct a dummy form.
 We will use Velocity templates.
• Jetspeed has better support and
documentation for Velocity.
• Most of the portlets in the release use
this.
 We will examine a JSP example later.
 Create the Template
 Open a new file in <h3> Enter the command
nmi/WEB- you want to execute</h3>
INF/templates/vm/portlets <form method="post">
/html. <table>
 Give it a name, <tr>
myTestApp.vm
 Write the Velocity template <td> Command
Name:</td>
 Write an xreg file (see next <td> <input
slide). type="text"
 Restart Tomcat. name="runCommnad"
 Customize your display to value="">
show the new portal. </td>
 So far, so good. </tr>
</table>
</form>
 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</clas
sname>
<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>
</registry>
 Specifying The Template
 The parts in red <parameter
(template and name="template"
action) point to value="myScienceApp
"
things that you
must write. hidden="true"
cachedOnName="true
 The line below is ”
used to name the cachedOnValue="true"
VM template in the />
XREG.
• Points to
myScienceApp.vm
 Actions in Templates
 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.
 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.
• Jetspeed will take care of the invocation.
 Writing An Action
 A portlet action is just a java class.
 It should extend VelocityPortletAction
 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).
• You can also implement other action methods.
 Getting Started
 Let’s give our simple <parameter name="action"
portlet an action. value="portlets.myScience
 To do this, we first ApAction"
modify the hidden="true"
• Don’t forget to cachedOnName="true
shutdown tomcat first. "
cachedOnValue="true"
 We then write the />
action and compile it
into nmi/WEB-
INF/classes.
• See next slide
• Set classpath correctly!
 Restart the server.
 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
 This action is automatically called
whenever the JSP template’s form action
is invoked.
 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.
 The portlet actions’s system.out.println()
is written to catalina.out.
 If you prefer, you can use Jetspeed’s
logger, which writes to nmi/WEB-INF/log.
 RunData, Requests, and
Sessions
 The method buildNormalContext includes
an object called RunData in its arg list.
 RunData is your access point to all HTTP
request, response, and session data.
• HttpSession session=rundata.getSession();
• HttpServletRequest req=rundata.getRequest();
 From here, you can do standard java.net.*
development.
• I am not planning to cover this, but we can
discuss.
 Connecting Multiple Templates
 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.
 Form actions in templates must be
handled a bit differently.
 <form action=“SomeOtherPage”>
• This can’t point to a template, since it is not
directly accessible (in WEB-INF).
• Jetspeed actions handle this.
 Redirecting to Another Page
 Setting up and
running applications
from a portal typically
requires many
successive HTML myScienceApp myScienceApp2
forms.
 So we need to see
how to do this with Request Response
Jetspeed.
 Let’s call this
myScienceApp2.vm myScienceAppAction
and place it in the
same place as
myScienceApp.vm.
First, Modify myScienceApp.vm
 Use the <h3> Enter the command you
want to execute</h3>
eventSubmit_{acti <form method="post">
on} construction. <table>
<tr>
 This action will be <td>Command Name:</td>
tied to a specific
method in <td><input type="text"
name="runCommnad"
myScienceAppActio value=""></td>
n.java. </tr>
</table>
<input type="submit"
name="eventSubmit_doGet_c
ommand" value="Click to
Select Host">
</form>
 Next, Modify Your Action Code
 Add the following method to public void
myScienceAppAction.java.
Your method name should
doGet_command(

follow the pattern given in the RunData runData,
form. Context aContext ) {
 This particular action runs setTemplate(runData,
setTemplate(), which loads
the indicated Velocity "myVelocityApp2");
template. }
 When you click a form,
Jetspeed will look for all
methods matching
eventSubmit’s pattern.
 If it finds them, it executes
them.
 If not, buildNormalContext()
is the default.
 Write the Destination Template
 The following is an <form method="post">
example of BigIron: <input type=radio
myScienceApp2.vm. name=host
 Note the eventSubmit. value="BigIron">
 Both of our templates use <br>
the same action. IronBird: <input type=radio
 We can add a method name=host
doGet_host to value="IronBird">
myScienceAppAction.java <input type="submit"
to handle host events. name="eventSubmit_doGe
 You can build t_host" value="Click to
• Once=anomaly Run">
• Twice=infinitely </form>
reproducible pattern
 Grid Portlets
 There is nothing fundamentally special about Grid portlets
• Just implement your portlet action with Java COG calls.
 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.
 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.
• Develop Velocity user interfaces to collect necessary info from
users.
 Example Code: Fetching
Credentials
 The OGCE provides HttpSession session
a convenience =
class runData.getSessio
ProxyManager for n();
storing/fetching GSSCrendential cred
proxy creds. =
• Assumes you have ProxyManager.getD
logged in to the efaultProxy(session
proxy portlet.
);
 Using the CoG Portlet Interfaces
 From here, you can develop portlet
actions using the Java CoG kit.
 Gregor will discuss new interfaces in
the next session.
Portal Testing with
HTTPUnit
Marcus Christie and Marlon
Pierce
 Types of Unit Testing
 JUnit is a great way for testing code
functionality.
 But how do you test portals and portlets?
• Portal interfaces need to be tested by simulated
users.
 Button clicks, link clicks, form interactions, etc.
 For the NMI OGCE project, we have adopted
HttpUnit for this.
• http://httpunit.sourceforge.net/
 Unique Challenges for Testing
Grid Portals
 Fluid GUI
 Much setup required for Grid Portal
• Portal account
• Grid Software, accounts
• Reliance on external services
 Broken HTML
 Infinite set of user operations
• Use Cases + Simple Error Handling
 HTTPUnit Features
 Extension of Junit
• Integrates easily with Ant <junit> task
 Fairly high level API
 Browser emulation (cookies, JavaScript,
etc.)
 Includes a sloppy/quirky HTML parser
(NekoHTML)
 Setting Up Your Test
 The code on the package xportlets.tests;
import
right shows the com.meterware.httpunit.*;
boilerplate to import junit.framework.*;
public class XPortletTestCase
put at the start extends TestCase {
of your test. ....
public void setUp() throws
 We will fill in Exception {
the rest of the super.setUp();
test in the }
//Rest of the test
following slides. }
 Testing a Login Form
 The code shows how to public WebConversation xPortletAuth()
throws Exception {
actually write a simple
WebConversation wc = new
form test. WebConversation();
 Create a WebResponse resp =
WebConversation object. wc.getResponse(url);
WebForm form = resp.getForms()[0];
 Use WebResponse to
form.setParameter("username",
work programmatically username);
with the HTML. form.setParameter("password",
password);
 Use WebForm to invoke
form.submit();
HTML <forms> WebResponse resp2 =
 Assertions are used to wc.getCurrentPage();
test the content of the String page = resp2.getText();
returned page. assertTrue("Failed to log in",
page.indexOf("Welcome to
your workspace") != -1);
return wc;
}
 Simulating Button Clicks
public void testSimplePing() throws
 Create SubmitButton Exception {
objects to simulate WebConversation wc =
xPortletAuthProxy();
button clicks. WebResponse resp =
wc.getCurrentPage();
• “myButton” is the name WebForm form =
of the submit button in resp.getForms()[3];
the HTML <form> form.setParameter("service",
"rainier.extreme.indiana.edu");
 Calling click() causes SubmitButton addServiceBtn =
form.getSubmitButton(“myButton"
the form action to );
assertNotNull(“myButton",
take place. addServiceBtn);
 Get the new page addServiceBtn.click();
WebResponse resp2 =
from the wc.getCurrentPage();
WebConversation WebForm form2 =
resp2.getForms()[3];
object. }
 Running HttpUnit with Ant
 After you have developed a suite of tests,
you can automate your portal tests using
Ant’s optional JUnit task.
 Even better, you can combine this with the
<junitreport> task that will generate nice
HTML report forms.
 First, you will need to put these jars in ant’s
lib directory.
• httpunit.jar
• junit.jar
 An Example Unit Test Target
 Let’s say all of your tests <junit printsummary="true”
fit the pattern errorProperty="test.failed
Test*.class. "
 Then run a <batchtest> failureProperty="test.fail
to run all of them at ed">
once. <formatter type="xml"/>
• Will run all tests <batchtest
• Won’t exit on failed test.
todir="${report.dir}">
 Use errorProperty and
<fileset dir="classes"
failureProperty to catch
these states. includes="**/Test*.class"
/>
 Specify an XML formatter
for pretty output (next). </batchtest>
</junit>
Generating HTML dashboards
 The <junitreport> <junitreport
todir="${report.dir}">
target can be used to
<fileset
convert the report dir="${report.dir}">
outputs from <include
<junit>. name="TEST*.xml"/>
</fileset>
 Use <report> to
<report format="frames"
generate HTML. todir="${html.report.dir}
 Finally the <fail> "/>
message checks if </junitreport>
<fail message=“Tests
any tests failed. failed." if="test.failed"/>
• See previous target.
 Example Report Dashboard

List of
Test Classes

Test Results for One

Of the Test Cases
Some Drawbacks to HTTPUnit
 Tests are tied to page structures.
• If you change your page (say, reordering links
or forms), you will break your tests.
 Tests also depend on
 Test assertions typically depend on the
content of the page.
• If content changes, tests may break.
• Checking content is not completely sufficient
for testing Grid portals.
Additional Capabilities
 Capability: Community
Scheduling Framework Portlets
User User Portal Visualization
Workstation GridPort System

Bandera

CSF Blanco

Buda

CSF Use Case

 Researcher submits job through User Portal
 User Portal uses GridPort to
• authenticate user
• optionally make advanced reservation to visualization system
• submit job to CSF
 CSF selects compute cluster with best fit and forwards job
 Gridport sends results to visualization system
Capability: Job Sequencer Portlets
" xsi:schemaLocation="http://grids.tacc .utexas .edu/sc hemas/sequencer/jobSequence
C:\DOCUME~1\Maytal\Des ktop\Maytal\Wor k\GP-IR \GP-IR X~1\motd.xsd">

<
<Status>New</Status>
<Step>
<Status>Unscheduled</Status>
<Type>CSFJob</Type>
<Parameter
name="jobFactorySer vi ceHandle">http://129.116.218.36:15080/ogsa/ser vic es/metascheduler/
JobFactoryService</Par ameter >

Sequencer
<Parameter name="queue">normal</Parameter>
<Parameter name="executable"> pam</Parameter>
<Parameter name="arguments">-g 1 mpichp4_wrapper
/home/monitor/mpi_jobs/mpi md_5</Parameter>
<Parameter name="directory">/home/monitor/mpi_jobs</Par ameter >

GPIR
<Parameter name="count">4</Parameter>
<Parameter name="stdIn">/dev/null</Parameter>
<Parameter
name="stdOut">/home/monitor/mpi_jobs/tomi slavSequencerJobOut</Par ameter >
<Parameter
name="stdErr">/home/monitor/mpi_jobs/tomi slavSequencerJobErr </Parameter>
</Step>
<Step>
<Status></Status>
<Type>GridFTP</Type>
<Parameter name="fromHost">[Previous]</Par ameter >
<Parameter name="toHost">blanco.tacc.utexas.edu:2811</Parameter>
<Parameter
name="fromFileFullName">/home/monitor/mpi_jobs /tomisl avSequencerJ obOut< /Parameter
>
<Parameter
name="toFileFullName" >/home/monitor/mpi_jobs/tomislavSequencerJobOutCopied</"> /ho
me/monitor/mpi_j obs/tomislavSequencerJobErr</Parameter>
<Parameter
name="toFileFullName" >/home/monitor/mpi_jobs/tomislavSequencerJobErrCopi ed</Param
eter>
</Step>
</JobSequence>

Portal

The XML is then GridPort returns a

decomposed and Sequence ID to the
Currently, sequence persisted to GPIR Portal immediately and
User uses Portal to
steps can consist of where the status then begins executing
generate XML
File Transfers and Job information of each the Sequence to
description of
Submissions to the step in the sequence completion or to error.
sequence.
CSF meta scheduler and of the sequence Status information can
as a whole can be be obtained at any time
stored with the Sequence ID
 O.G.R.E.—A Job Management Engine
• O.G.R.E. = Open Grid Computing Environments
Runtime Engine
• 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
• Event- and process-monitoring-tasks
 XDirectory: A Grid Context Service
 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 annotations.
 Example Capability: File
Management User “Beth”
 Grid FTP portlet–
Allow User to manage
remote file spaces
• Uses stored proxy for
authentication
• Upload and download Portal Server
files GridFTP

• Third party file transfer

portlet
Java
COG
 Request that GridFTP
server A send a file to
GridFTP server B GridFTP
Server A
 Does not involve traffic GridFTP
through portal server Server B
JSR 168 Tutorial
Details on Writing portlets
 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=…>
</form>
 Some Notes
 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.
 The renderRequest gives you access to the PortletSession,
if you want to store session variables.
• One of the trouble points.
 The renderResponse gives you access to the PortletURL
object.
 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.
• This is one of the sticking points.
Lastly, Override processAction()
 When you invoke the form on the public void processAction
previous JSP, the portlet (ActionRequest request,
container will pass the action
handling to the processAction ActionResponse
method. actionResponse) throws
 The ActionRequest can be used to PortletException,
get any of the <input> java.io.IOException {
parameters in a way similar to
the usual HttpServletRequest. //Process request
 When the processAction method parameters
returns, the container then …
invokes the appropriate do
method (usually doView). //Add any other request
 If you need to pass <form> params
parameters on to doView, add // to the renderRequest
them to the ActionResponse.
• This will give them to the actionResponse.setRenderP
RenderRequest. arameters(request.getPara
• The example shows how to add meterMap());
ALL parameters.
}