Introduction to Grid Portals

(A Tutorial)

Rob Allan
E-Science Centre
CCLRC, Daresbury Laboratory

Rob Allan
Portal Tutorial
 Learning Outcomes
We will study Grid portals, which are Web-based facilities that provide
a personalised, single point of access to Grid resources that support
the end user in one or more tasks. From this chapter, you will learn:
• What is a Grid portal and what kind of roles will it plays in the Grid?
• First-generation Grid portals.
• Second generation Grid portals.
• The features and limitations of first generation Grid portals.
• The features and benefits of second generation Grid portals.

Material in this course is re-produced with permission of John Wiley and

Sons Ltd. and is contained in more depth in a forthcoming book
“Introduction to Grid Computing” by Mark Baker et al.

This material also forms part of the ReDRESS project

http://redress.lancs.ac.uk on training and awareness. The project has
an associated Sakai portal which will be demonstrated Presenter
Rob AllanName

if time permits. Facility

Portal Name
Tutorial
 Outline

1. Introduction
2. First Generation Grid Portals
3. Second Generation Grid Portals
4. Summary
5. Further Reading and Testing

Acknowledgements
• Mark Baker and Hong Ong (Portsmouth)
• Matthew Dovey and Mike Fraser (Oxford)
• Stephan Marceau (IBM)
• Jason Novotny and Mike Russell (GridLab)
• Dharmesh Chohan and Xiao Dong Wang (Daresbury)
• Rob Crouchley and Adrian Fish (Lancaster)

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 What is a Portal?

A Web based application that provides:

• Personalization
– Different set of Portlets creating content for different users
• Single sign on
• Content aggregation
– Aggregation is the action of integrating content from different
sources
• Hosts the presentation layer

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Customisable Portal Interfaces

HPCPortal

DataPortal

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 InfoPortal, MDS Browser
and Active Map
Operational
monitoring:
resource-centric
and site-centric
views of Grid
resource and
network status

http://www.grids.ac.uk/InfoPortal
Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Why Portals?

We can consider two main types of Grid users, system developers and
end users. System developers are those who build Grid systems using
middleware packages such as Globus, UNICORE, or Condor. The end
users are the scientists and engineers who use the Grid to solve their
domain-specific problems perhaps via a portal.

A Grid portal is a Web-based gateway that provides seamless access to a

variety of backend resources.

In general, a Grid portal provides end users with a customized view of

software and hardware resources specific to their particular problem
domain. It also provides a single point of access to Grid-based
resources that they have been authorized to use. This will allow
scientists or engineers to focus on their problem area by making the
Grid a transparent extension of their desktop computing environment.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Institutions need Autonomy and
Security

Host – client relationship

Example solution suggested
by Web server - browser

Communication must be initiated

by client because of firewall
around client’s institution. Can use
a proxy or gateway.
Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 The Grid “Client Problem”
Many clients want to access a few
Grid-enabled resources

Grid Core

Middleware Consumer
Workplace: clients: PC,
desktop e.g. Globus TV, video,
clients AG

Grid Core Portable clients:

phones, laptop, Presenter Name
Rob Allan
pda, data entry… Facility
PortalName
Tutorial
 Existing Grid Portals

• HPCPortal. R.J. Allan, A.J. Richards and R.P. Tyer. Proc. AHM
2003. http://www.grids.ac.uk/HPCPortal/
• The XCAT science portal. S. Krishnan, R. Bramley, D. Gannon, M.
Govindaraju, R. Indurkar, A. Slominski, B. Temko, J. Alameda, R.
Alkire, T. Drews and E. Webb: In Proc. of SC 2001.
• A Computational Web Portal for the Distributed Marine Environment
Forecast System. T. Haupt, P. Bangalore, G. Henley: HPCN Europe
2001: 104-113.
• The Hotpage Portal, https://hotpage.npaci.edu/
• JiPANG, a Jini-based computing portal system.T. Suzumura, S.
Matsuoka, H. Nakada: In Proc. of SC 2001.
• The DSG PORTAL, http://dsg.port.ac.uk/dsgPortal/
• The Gateway system: uniform web based access to remote resources.
T. Haupt, E. Akarsu, G. Fox, C-H. Youn: Concurrency - Practice and
Experience 12(8): 629-642 (2000).
Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 More…

• Grappa, http://iuatlas.physics.indiana.edu/grappa/
• The Astrophysics Simulation Collaboratory Portal: A Science Portal
Enabling Community Software Development. G. Allen, G. Daues, I.
Foster, G. Laszewski, J. Novotny, M. Russell, E. Seidel, J. Shalf. Proc.
of the 10th IEEE Intl. Symp. on High Perf. Dist. Comp 2001.
• The GENIUS Portal https://genius.ct.infn.it/ This is being used in the
EGEE project for its training and dissemination

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 1st Generation Portals

The first generation of Grid portals mainly used a three-tier

architecture:

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Properties
• A three-tiered architecture, consisting of an interface tier of a Web
browser, a middle tier of Web servers, and a third tier of backend
services and resources, such as databases, high performance
computers, disk storage, and specialized devices.
• A user makes a secure connection from their browser to a Web
server.
• The Web server then obtains a proxy credential from a proxy
credential server and uses that to authenticate the user.
• When the user completes defining the parameters of the task they
want to execute, the portal Web server launches an application
manager, which is a process that controls and monitors the actual
execution of Grid task(s).
• The Web server delegates the user’s proxy credential to the
application manager, so that it may act on the user’s behalf.
In some systems, the application manager publishes an event/message
stream to a persistent event channel-archive, which describes the
state of an application’s execution and can be monitoredPresenter
by
Robthe user
Name
Allan
through their browser. Facility
Portal Name
Tutorial
 Grid Services Provided
• Authentication: When users access the Grid via a portal, the portal
can authenticate users with their usernames and passwords. Once
authenticated, a user can request the portal to access Grid resources
on the user’s behalf.
• Job Management: A portal provides users with the ability to manage
their job tasks (serial or parallel), i.e., launching their applications via
the Web browser in a reliable and secure way, monitoring the status
of tasks and pausing or cancelling tasks if necessary.
• Data Transfer: A portal allows users to upload input data sets
required by tasks that are to be executed on remote resources.
Similarly the portal allows results sets and other data to be
downloaded via a Web browser to a local desktop.
• Information Services: A portal uses discovery mechanisms to find
the resources that are needed and available for a particular task.
Information that can be collected about resources includes static and
dynamic information such as OS or CPU type, current CPU load, free
memory or file space, and network status. In addition, other details
such as job status and queue information can also be retrieved.
Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Implementation
The first generation Grid portals mainly use GT2 to provide Grid
services. One main reason for this is that Globus provides a complete
package and a standard way for building Grid enabled services.
• A dynamic graphical user interface (GUI) based on HTML pages, with
JSP (Java Server Pages), or JavaScript. Common Gateway Interface
(CGI) and Perl are also used by some portals. CGI is an alternative to
JSP for dynamically generating Web contents.
• The secure connection from a browser to backend server is via
Transport Layer Security (TLS) and Secure HTTP (S-HTTP).
• Typically, a Java Servlet or Java Bean on the Web server services
requests from a user and accesses backend resources.
• MyProxy and GT2 GSI are used for user authentication. MyProxy
provides credential delegation in a secure manner.
• GT2 GRAM is used for job submission.
• GT2 MDS is used for gathering information on various resources.
• GT2 GSIFTP or GT2 GridFTP for data transfer.
• The Java CoG provides the access to the corresponding
Globus services for Java programs. Presenter Name
Rob Allan
Facility
Portal Name
Tutorial
 MyProxy

MyProxy is an online credential management system for the Grid. It is

used to delegate a user’s proxy credential to Grid portals which can
be authenticated to access Grid resources on the user’s behalf.
Storing your Grid credentials in a MyProxy repository allows you to
retrieve a proxy credential whenever
and wherever you need one. You can
also allow trusted servers to renew
your proxy credentials using MyProxy,
so, for example, long-running tasks do
not fail due to an expired proxy
credential. The figure shows the
steps to securely access the Grid
via a Grid portal with MyProxy.

myproxy.grid-support.ac.uk

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Using MyProxy
1. Execute myproxy-init command on the computer where your Grid
credential is located to delegate a proxy credential on a MyProxy
server. The delegated proxy credential normally has a lifetime of one
week. The communication between the computer and the MyProxy
server is securely managed by TLS. You need to supply a user name
and pass phrase for the identity of your Grid credential. Then you
need to supply another different MyProxy pass phrase to secure the
delegated proxy credential on the MyProxy server.
2. Log into the Grid portal with the same username and MyProxy pass
phrase used for delegating the proxy credential.
3. The portal uses myproxy-get-delegation command to retrieve a
delegated proxy credential from the MyProxy server using your
username and MyProxy pass phrase.
4. The portal accesses Grid resources with the proxy credential on your
behalf.
5. The operation of logging out of the portal will delete your delegated
proxy credential on the portal. If you forget to log off,
Presenter Name
then the proxy credential will expire at the lifetime specified.
Rob Allan
Facility Name
Portal Tutorial
 Java CoG Kit
The Java Commodity Grid (CoG) Kit provides access to GT2 services
through Java APIs. The goal of the Java CoG Kit is to provide Grid
developers with the advantage to utilize much of the Globus
functionality, as well as, access to the numerous additional libraries
and frameworks developed by the Java community. Currently GT3
integrates part of Java CoG, e.g., many of the command-line tools in
GT3 are implemented with the Java CoG.
The Java CoG has been focused on client-side issues. Grid services that
can be accessed by the toolkit include:
• An information service compatible with the GT2 MDS implemented
with Java Native Directory Interface JNDI;
• A security infrastructure compatible with the GT2 GSI implemented
with the iaik security library;
• A data transfer mechanism compatible with a subset of the GT2
GridFTP and/or GSIFTP;
• Resource management and job submission with the GT2 GRAM
Gatekeeper;
• Advanced reservation compatible with GT2 GARA;
Presenter Name
• A MyProxy server managing user credentials. Rob Allan
Facility Name
Portal Tutorial
 GridPort and HPCPortal
GridPort 2.0 (GP2) is a Perl based Grid portal toolkit. The purpose of
GP2 was to facilitate the easy development of application specific
portals. GP2 is a collection of services, scripts and tools that allow
developers to connect Web-based interfaces to backend Grid
services. The scripts and tools provide consistent interfaces between
the underlying infrastructure, which are based on Grid technologies
such as GT2, and standard Web technologies such as CGI.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 GridPort Layers
• Client Layer: represents the consumers of Grid portals, typically Web
browsers, PDAs, or even applications capable of pulling data from a Web
server. Clients interact with a GP2 portal via HTML form elements and use
secure HTTP to submit requests.
• Portal Layer: consists of portal-specific codes. Application portals run on
standard Web servers and handle client requests and provide responses to
those requests. One instance of GP2 can support multiple concurrent
application portals, but they must exist on the same Web server where they
share the same instance of the GP2 libraries. This allows the application
portals to share portal-related user and account data and thereby makes
possible a single-login environment. GP2 portals can also share libraries, file
space, and other services.
• Portal Services Layer: GP2 and other portal toolkits or libraries reside at
the portal services layer. GP2 performs common services for application
portals including the management of session state, portal accounts, and Grid
information services with GT2 MDS.
• Grid Services Layer: consists of those software components and services
that are needed to handle user requests to access the Grid. GP2 employs
simple, reusable middleware technologies, e.g., GT2 GRAM for job submission
to remote resources; GT2 GSI and MyProxy for security and authentication;
GT2 GridFTP and the San Diego Supercomputer Center (SDSC) Storage
Resource Broker (SRB) for distributed file collection and management [56];
and Grid Information Services based primarily on proprietary GP2
information provider scripts and the GT2 MDS. Presenter Name
Rob Allan
Facility
Portal Name
Tutorial
Distributed Component Architecture

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Adding Value to the Infrastructure

Integrated e-Science Some Environment

Environment

User layer (application, GUI, script, Portal, etc.)

We are here Web service, CGI, etc.

Front end services (session management etc.)

Web service or close coupling

Back end services (Globus wrappers etc.)

Globus protocols
Infrastructure (Globus etc.)

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 GridPort, HPCPortal and GROWL
GP2 can be used in two ways. The first approach requires that GT2 be
installed, because GP2 scripts wrap the GT2 command line tools in the
form of Perl scripts executed from CGI-Bin. GT2 GRAM, GSIFTP,
MyProxy are used to access backend Grid services. The second
approach does not require GT2, but relies on the CGI scripts that
have been configured to use a primary GP2 Portal as a proxy for
accessing GP2 services, such as user authentication, job submission,
and file transfer. The second approach allows a user to quickly deploy
a Web server configured with a set of GP2 CGI scripts to perform
generic portal operations.
HPCPortal uses the C API in the Globus toolkit for MDS, GridFTP and
GRAM. There is a front-end CGI script which passes data from the
user’s form interface to the back end Globus code which in turn
submits the remote job. The front and back end services can be
connected using a web service call so do not need to be located on the
same server (previous figure).
GROWL uses the same back end services but provides a C programming
API to the user in the form of a function liibrary. Presenter Name
Rob Allan
Facility
Portal Name
Tutorial
 GPDK and the Java™ World

GPDK is another Grid portal toolkit that uses Java Server Pages (JSP)
for portal presentation and Java Beans to access back end Grid
resources via GT2. Beans in GPDK are mostly derived from the Java
CoG kit.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Java Services in GPDK
Grid service beans in GPDK can be classified as follows. These beans can
be used for the implementation of Grid portals.
• Security: The security bean, MyproxyBean, is responsible for
obtaining delegated credentials from a MyProxy server. The
MyproxyBean has a method for setting the username, password, and
designated lifetime of a delegated credential on the Web server. In
addition, it allows delegated credentials to be uploaded securely to
the Web server.
• User Profiles: User profiles are controlled by three beans:
UserLoginBean, UserAdminBean and the UserProfileBean.
– The UserLoginBean provides an optional service to authenticate
users to a portal. Currently, it only sets a username/password and
checks a password file on the Web server to validate user access.
– The UserAdminBean provides methods for serializing a
UserProfileBean and validating a user's profile.
– The UserProfileBean maintains user information including
preferences, credential information, submitted job history, and
computational resources used. The UserProfileBean is generally
instantiated with session scope to persist for the duration
Presenter of the
Name
Rob Allan
user's transactions on the portal. Facility
PortalName
Tutorial
 More…
• Job Submission: The JobBean contains all the necessary functions used in
submitting a job including memory requirements, name of executble code,
arguments, number of processors, maximum wall clock or CPU time, and the
submission queue. A JobBean is passed to a JobSubmissionBean that is
responsible for actually launching the job. Two varieties of the
JobSubmissionBean currently exist. The GramSubmissionBean submits a job
to a GT2 GRAM gatekeeper that can either run the job interactively or
submit it to a scheduling system if one exists. The JobInfoBean can be used
to retrieve a job related timestamped information including the job ID,
status, and outputs. The JobHistoryBean uses multiple JobInfo beans to
provide a history of information about jobs that have been submitted. The
history information can be stored in the user's profile.
• File Transfer: The FileTransferBean provides methods for transferring
files. Both GSIFTPTranferBean and the GSISCPTransferBean can be used
to securely copy files from source to destination hosts using a user's
delegated credential. The GSISCPTransferBean requires that GSI enabled
SSH [57] be deployed on machines to which file transfer via the GSI
enhanced “scp”. The GSIFTPTransferBean implements a GSI enhanced FTP
for third-party file transfers.
• Information Services: The MDSQueryBean provides methods for querying a
Lightweight Directory Access Protocol (LDAP) server by setting and
retrieving object classes and attributes such as OS type, memory, and CPU
load for various resources. LDAP is a standard for accessing information
directories on the Internet. Currently, the MDSQueryBean makes Presenter use
Rob Allan of the
Name
Mozilla Directory SDK [27] for interacting with a LDAP server. Facility
PortalName
Tutorial
Comparison of 1st Generation Portals

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 What are the Restrictions?
First generation Grid portals have been focused on providing basic task-
oriented services, such as user authentication, job submission, monitoring,
data transfer. However, they are typically tightly coupled with Grid
middleware tools such as Globus. The main limitations of first generation
portals can be summarized as follows.
• Lack of Customization: Portal developers instead of portal users normally
build portals because the knowledge and expertise required to use the portal
toolkits, as described in this chapter, is beyond the capability of most Grid
end users. When end users access the Grid via a portal, it is almost
impossible for them to customize the portal to meet their specific needs,
e.g., to add or remove some portal services.
• Restricted Grid Services: First generation Grid portals are tightly coupled
with specific Grid middleware technologies such as Globus, which results in
restricted portal services. It is hard to integrate Grid services provided by
different Grid middleware technologies via a portal of this generation.
• Static Grid Services : A Grid environment is dynamic in nature with more
and more Grid services are being developed. However, first generation
portals can only provide static Grid services in that they lack a facility to
easily expose newly created Grid services to users. Presenter Name
Rob Allan
Facility
Portal Name
Tutorial
 2nd Generation Portals

Second-generation Grid portals are being developed to overcome the

limitations of first generation portals, portlets have been introduced
and promoted for use in building second-generation Grid portals.
Currently, portlets are receiving increasing attention from both the
Grid community and industry.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Portlets

From a user's perspective, a portlet is a window in a portal that provides

a specific service, for example, a calendar or news feed. From an
application development perspective, a portlet is a software
component written in Java, managed by a portlet container, which
handles user requests and generates dynamic contents. Portlets, as
pluggable user interface components, can pass information to a
presentation layer of a portal system. The content generated by a
portlet is also called a fragment. A fragment is a chunk of markup
language (e.g., HTML, XHTML) adhering to certain rules and can be
aggregated with other fragments to form a complete document. The
content of a portlet is normally aggregated with the content of other
portlets to form the portal page. A portlet container manages the
lifecycle of portlets in a portal.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 What is a Portlet (in a nutshell)?
• A Java technology based Web component, managed by a Portlet
container, that processes requests and generates dynamic content;
• Used by Portals as pluggable user interface components that provide a
presentation layer;
• The content generated by a Portlet is also called a fragment
– A piece of markup (e.g., HTML, XHTML, WML) adhering to certain
rules and can be aggregated with other fragments to form a
complete document
• The content of a Portlet is normally aggregated with the content of
other portlets to form the Portal page;
• The lifecycle of a Portlet is managed by the Portlet container;
• Integration component between applications and Portals that enables
delivery of an application through a Portal;
• Eliminates vendor specific Portlet API;
• Applications can be delivered through any Portal almost immediately.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Client-Portlet Interaction
• Web clients interact with Portlets via a request/ response paradigm
implemented by the Portal;
• Normally, users interact with content produced by Portlets
– example by following links or submitting forms
– resulting in Portlet actions being received by the Portal, which
are forwarded by it to the Portlets targeted by the user's
interactions
• The content generated by a Portlet may vary from one user to
another depending on the user configuration for the Portlet;
• Portlet contains an implementation of Model-View-Control (MVC)
pattern.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Portlet MVC Pattern

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Portlets vs. Servlets

Portlets are a specialized and more advanced form of Java Servlets. 

They run in a portlet container inside of a Servlet container, which is
a layer that runs on top of an application server. Like Java Servlets,
portlets process HTTP requests and produce HTML output, e.g. with
JSP. But their HTML output is only a small part of a Web page. The
portal server fills in the rest of the page with headers, footers,
menus, and other portlets.
Compared with Java servlets, portlets are administered in a dynamic
and flexible way. The following updates can be applied without having
to stop and restart the portal server.
• A portlet application, consisting of several portlets, can be installed
and removed using the portal’s administrative user interface;
• An administrator with the appropriate access rights can change the
settings of a portlet;
• Portlets can be created and deleted dynamically.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Portlets differ from Servlets
• Portlets can not:
– send redirects
– send errors to browsers directly
– forward requests
– write arbitrary markup to the output stream to assure that they
don’t distract the Portal Web application which uses them

• Portlets rely on Portal specific infrastructure functions:

– access to user profile information

• Portlets are administrated more dynamically than Servlets

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Advantages

Portlets also have many standard features that are not available to Java
servlets. One key feature is the built-in support to automatically use
different JSP interfaces with different user devices. This allows
users to write portlets that work on many devices, such as desktop
computers with modern Web browsers, or palmtop computers with
limited Web browsers, or alternatively Personal Digital Assistants
(PDAs), or Web-enabled wireless phones. Users do not need to
provide portability via the lowest common denominator. By reusing the
same underlying business logic, the portal server will choose the most
appropriate rendering for each client. Users can even have multiple
portlet controllers, which allows different page/ action sequences to
be used for each device type.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 JSR-168 Portlet Specification
• Developed as part of the Java Community Process
• Released August 2003
• Specification: http://www.jcp.org/en/jsr/detail?id=168
• Enables interoperability among Portlets and Portals
• Defines a set of APIs for Portlets
• Addresses standardization for
– Preferences
– User information
– Portlet requests and responses
– Deployment packaging
– Security

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 What is the Portlet Specification?

Defines:

• Portlet Container and Porlet Life cycle management

• Definition of window states and Portlet modes
• Portlet preferences management
• User information
• Packaging and deployment
• Security
• JSP tags to aid Portlet development

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Portlet Life Cycle
The basic lifecycle of a portlet includes the following three parts:
• Initialisation, using the init class to initialise a portlet and put it into
service.
• Request Handling, processing different kinds of actions and
rendering content for different clients.
• Termination, using the destroy class to remove a portlet from a
portal page.
The portlet receives requests based on the user interaction with the
portlet or portal page. The request processing is divided into two
phases:
• Action processing: If a user clicks on a link in a portlet, an action is
triggered. The action processing must be finished before any
rendering of the portlets on the page is started. In the action phase,
the portlet can change the state of the portal.
• Rendering content: In the rendering phase, the portlet produces its
markup content to be sent back to the client. Rendering should not
change any state of the portlet. It refreshes a page without
modifying the portlet state. Rendering multiple portletsPresenter
on a page Name
can
be performed in parallel. Rob Allan
Facility Name
Portal Tutorial
 Portlet Events

The typical sequence of events to access a Web page via portlets is given
below.

1. A client (e.g., a Web browser) after being authenticated makes an

HTTP request to a portal.
2. The portal receives the request.
3. The portal determines if the request contains an action targeted to
any of the portlets associated with the portal page.
4. If there is an action targeted to a portlet, the portal requests the
portlet container to invoke the portlet to process the action.
5. A portal invokes portlets, through the portlet container, to obtain
content fragments that can be included in the resulting portal page.
6. The portal aggregates the output of the portlets in the portal page
and sends the portal page back to the client.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Life Cycle Methods
init()
– Called when the Portlet is instantiated by the container
– Intended to contain logic that prepares the Portlet to serve
requests
destroy()
– Called when the container destroys the Portlet
– to contain logic that cleans up when Portlet is no longer needed or
the server shuts down
processAction()
– Called after the user submits changes to a Portlet
– to process input from a user action
render()
– Called whenever the Portlet is redrawn by the desktop

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Specialized Render Methods
(GenericPortlet)
Developers can extend GenericPortlet and implement as many of these
specialized render methods as are necessary for their Portlet

doView
• to contain logic that displays the View page for the Portlet
doEdit
• to contain logic that displays the Edit page for the Portlet
doHelp
• to contain logic that displays the Help page for the Portlet

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Other Portlet Modes

Optional custom modes:

• These are modes that a Portal may support
• While in an optional mode, a Portlet might not be called
• The optional modes include:
– About
• display an "about" message
– Config
• let administrators configure the Portlet
– Edit_defaults
• let an administrator preset the Edit mode's values
– Preview
• show the Portlet's preview
• Print mode to render a view that can easily be printed

Portal vendor-specific modes:

• These modes are not defined in the specification and are
therefore vendor specific Presenter Name
Rob Allan
Facility
Portal Name
Tutorial
 Portlet Window States
• Normal
– Indicates that a Portlet may share the page with other Portlets
– This is the default window state
• Maximized
– Indicates that a Portlet may be the only Portlet on the Portal page
or that the Portlet has more space compared to other Portlets in
the Portal page, and can therefore produce richer content than in
a normal window state
• Minimized
– Indicates that the Portlet should only render minimal output or no
output at all

Notes:
• In addition to these window states, JSR-168 allows the Portal to define
vendor-specific window states
• A Portlet can be called in any of these three window states, but is free
Presenter to
Name
Rob Allan
produce the same markup for all three states Facility Name
Portal Tutorial
 Example

The figure shows a Web page with two portlets. A portlet on a portal has
its own window, a portlet title, portlet content (body) which can be
rendered with portlet.getContent() method, and some actions to
close, maximize or minimize the portlet.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Persistent Store
The Portlet can store persistent data for a specific user by using the
PortletPreferences object:

• Preferences can be read and written in the action phase, and read in
the render phase
• The preferred mode to write preferences is the Edit mode, which
provides the user with a customization screen
• The preferences can be either strings or string array values
associated with a key of type string
• Preferences can be preset with default values in the deployment
descriptor
• Preferences and the Portlet's definition in the deployment
descriptor together define a Portlet, sometimes called a Portlet
entity

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Portlet Session Scope
As Portlet applications are Web applications, they use the same session
as Servlets

• To allow Portlets to store temporary data private to a Portlet, the

default session scope is the Portlet scope
– the Portlet can store information needed across user requests
and specific to a Portlet entity
– Attributes stored with this scope are prefixed in the session by
the Portlet container to avoid two Portlets (or two entities of the
same Portlet definition) overwriting each other's settings
• There’s also a Web application session scope
– Every component of the Web application can access the
information
– The information can be used to share transient state among
different components of the same Web application (e.g., between
Portlets, or between a Portlet and a Servlet)

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 The Portlet Container

A portlet container provides a runtime environment in which portlets are

instantiated, executed, and finally destroyed. Portlets rely on the
overall portal infrastructure to access user profile information,
participate in window and action events, and communicate with other
portlets, access remote content, lookup credentials, and store
persistent data. A portlet container manages and provides persistent
storage mechanisms for portlets.

A portlet container is not a stand-alone container like a Java Servlet

container; instead, it is implemented as a layer on top of the Java
Servlet container and reuses the functionality provided by the
Servlet container.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 More…
The Container
• Provides a runtime environment for Portlets implemented according
to the Portlet API
– Example Pluto
• In this environment Portlets can be instantiated, used and finally
destroyed
• Not a stand-alone container like the Servlet container
• Is implemented as a thin layer on top of the Servlet container
• Reuses the functionality provided by the Servlet container

Container Contract
• Much like Java Servlet extensions run inside a Servlet container
• Define a Portlet container that manages Portlets
• Contract is defined for the container to call methods during a
Portlet’s life cycle
• The Portlet developer can implement these methods to provide the
desired functionality
Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Architecture Picture

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Portlet Container Separation

• The Portlet container remains completely separated from every

other Portal component
• You can embed the standalone Portlet container in any Portal by
complying with the Portlet container's requirements, such as
implementing all Service Provider Interfaces (SPIs)

Portlet Container Invoker API

• Also called entrance point
• Acts as the Portlet container's main calling interface
• The API combines a Portlet container's lifecycle (init, destroy) with
request-based calling methods
– initPage(), performTitle(), portletService()
• The method signature resembles the Portlet API's main Portlet
interface, except that a Portlet identifier must be passed

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Portal Implements SPIs
The Portal must implement SPIs defined for the Portlet container.

Therefore,
• Runtime Interface (RI) introduces container services:
– pluggable components that can be registered at the container to
either extend or provide basic functionality
• The RI includes the following built-in container services:
– Information provider
• Gives the Portlet container information about the Portal and
its framework (URL generation with navigational state, Portlet
context, Portlet mode, and window-state handling)
– Factory manager
• how to get an implementation through a factory
– Log service
– Config service
• how to get configuration values
– Property manager (optional)

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Portlet Container Architecture

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Portlet Deployment

The Portlet container leverages the Servlet container's functionality.

• The Portlet container injects servlet artifacts into each Portlet-

application war file
• The Portlet component, Deployment, takes the original war file,
then injects a new or modified web.xml and a servlet to wrap each
Portlet and uses it as a calling point
• The Portlet deployment passes the modified war file to the
application server deployment
• which deploys it into the application server's system
• During the Portlet's invocation, the Portlet container calls the
injected Servlet as an entrance point into the deployed Portlet war
file

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Portlet Deployment

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Pluto

• Reference Implementation of the Java Portlet Specification

• Portlets are designed to run in the context of a Portal. They are
written to the Portlet API which are similar to the Servlet API

Pluto (incubated at Apache)

• Pluto normally serves to show how the Portlet API works and offers
developers a working example platform from which they can test
their Portlets
• However, it's cumbersome to execute and test the Portlet container
without a driver, in this case, the Portal
• Pluto's simple Portal component is built only on the Portlet
container's and the JSR-168's requirements

References
• Pluto http://jakarta.apache.org/pluto
• Pluto Eclipse plugin http://plutoeclipse.sourceforge.net/
Presenter Name
Rob Allan
Facility
Portal Name
Tutorial
 WSRP
Web Services for Remote Portals (WSRP) defines a standard for
interactive, user-facing Web services that plug and play with
portals.

• WSRP is designed to allow developers to write programs in several

languages, including Java, C# and .Net maybe C, Python and Perl in
future
• JSR-168 Portlets run on the same server as the Web Portal,
whereas WSRP Portlets would run on a different server than the
Web Portal
• Fragile Portlet could damage an entire Portal server and because
they claim to get better scalability with WSRP
• Java aficionados believe the opposite and claim that JSR 168 allows
for greater scalability

References
• WSRP Specification
http://www.oasis-open.org/committees/wsrp
• Open Source implementation of WSRP is called OASIS Presenter Name
Rob Allan
http://www.oasis-open.org/ Facility
PortalName
Tutorial
 Potted History

JCP - Java Portlet API

Apache JetSpeed Portal
JSR 168

OASIS TC
WebServices Web Service for Remote Portals
OASIS TC
WSIA Family
WSRP as the initial spec.

OASIS TC
Web Service User Interface
Web Service for Interactive Applications
uPortal
WebService channel

999 2000 2001 2002 2003

Very rough timeline…
Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Overview
• WSRP defines:
– A WSDL interface description for invocation of WSRP services
– How to Publish, Find, Bind WSRP services and metadata
– Markup Fragment Rules for markup emitted by WSRP services
– Applicable Security Mechanisms, Billing information ?, ...

• Companies involved in WSRP:

– Bea, Bowstreet, Divine, Epicentric, Factiva, France Telecom, Fujitsu,
HP, IBM, Interwoven, Lexis-Nexis, Lotus, Moravia IT, Netegrity,
Oracle, Peoplesoft, Plumtree, Silverstream, Stellent, SUN, Sybase,
Tibco, WebCollage, SAP Portals, SeeBeyond

• Committee Draft – went to OASIS vote July 2003

– BEA, IBM, Oracle, Plumtree, SAP, Vignette

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Integrated Portals

GSI
Data Systems

DataPortal

Web Services

GridFTP
Web Services

HPCPortal

Web Services
Visualisation
HPC Systems

Working with GGF Grid

Globus Computing Environments
Research Group
Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 WSRP and Portlet API(s)
Platform
Independent
Web Services for Remote Portals (WSRP)
Web Service
Interface

Platform
specific, Java C# WSRP Impl. on
Portlet API „Portlet API“ ... plain J2EE or .NET
local
Portlet APIs (JSR 168) (.NET) platform

Portlet APIs may be defined for different programming languages;

WSRP can bridge between the different platforms, leveraging platform
independence of Web services

Goal:
Portlets written to Portlet API can be published as WSRP services
WSRP services can be integrated through Portlet Proxies written Presenter
to Portlet API
Name
Rob Allan
Facility
Portal Name
Tutorial
 WSRP Services Plug&Play with Portals

Registry
Find Publish
Portals
Portals
Clients WSRP
Clients Portals
WSRP
Portals
Portals
Services
WSRP
Portals
Web
Web Portals
Services
Web
Web
Web Services
Web
Web
Web Clients
Clients
Clients Portals Bind
Web
WebClients
Clients Portals
Portals
Portals
Clients
Clients
Clients Portals
Clients
Clients

e.g.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 WSRP and related Standards

Voice ...
(X)HTML WML cHTML
XML

WSRP WSRP/WSIA
Common Base WSIA

UDDI WSDL SOAP

(Publish,Find&Bind) (Description) (Invocation)

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Local and Remote Portlets

Publish via WSRP

Other portals and Access remote portlet

JetSpeed API

JSR 168 etc.

uPortal API
VRE clients via WSRP

WebService
Server
WebService SOAP
Client

UDDI
Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Simple WSRP Service – View only

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Interactive WSRP Service with transient
conversational State
• API
– getMarkup
– performInteraction/performBlockingInteraction
– releaseSessions
– initCookies

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Interactive WSRP Service with persistent
Entity
• API
– clonePortlets
– getMarkup
– performInteraction/performBlockingInteraction
– initCookies
– releaseSessions
– destroyPortlets

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Persistent Entity and Session State

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Other API

• Portlet Entity Properties

– getPortletPropertyDescription
– getPortletProperties
– setPortletProperties
• cf OGSI ServiceData

• Non anonymous consumers (e.g. authentication)

– register
– deregister
– modifyRegistration

• Metadata (e.g. requires ssl, uses cookies etc)

– getPortletEntityDescription
– getServiceDescription

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Overview of WSRP

User WSRP Consumer WSRP Producer

Adds (Portal) (Service)
Create Portlet Instance
Portlet
I

Allocate new Instance

Views
Portlet Get Portlet Markup
I I S A
Generate Markup,
S (opt: create Session)
A
Clicks
Action Perform Portlet Action
I S A I S A
Action Handling
(opt: create Session)
Removes
Portlet Destroy Portlet Instance
II I
Presenter Name
Rob instance
Allan
Destroy
Facility
PortalName
Tutorial
 Full WSRP API Overview

• ServiceDescription
– getServiceDescription

• Markup
• Portlet Management
– getMarkup
– getPortletDescription
– performBlockingInteraction
– clonePortlet
– releaseSessions
– destroyPortlets
– initCookies
– getPortletPropertyDescription
– getPortletProperties
• Registration – setPortletProperties
– register
– deregister
– modifyRegistration

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 JSR-168 and WSRP
• JSR-168 aligns closely with the WSRP

• Both standards, which emerged at the same time, released open

source implementations capable of all necessary functions described
in the respective specifications

• Both standards strive to work well together

– The Portlet container can run WSRP Portlets as a consumer as well
as a producer
– A Portal must be able to run multiple Portlet containers in one
Portal
– A Portlet container can be instantiated multiple times and, more
importantly, it can be instrumented in different ways
– Each Portlet container, therefore, can use different
implementations for SPIs

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 WSRP and JSR-168

Although they are being governed by different standards bodies and

review processes, WSRP and JSR-168 are complementary
specifications. While JSR 168 defines a standard Portlet API that is
specific to Java-based portals, WSRP defines a universal API that
allows portals of any type to consume portlets of any type. They can
be used together in the following two ways:
• Portlets written with the Java Portlet API may be wrapped as WSRP
services and published in UDDI directories.
• WSRP services can be exposed as portlets with the Java Portlet API
to aggregate them in portals.

Whereas JSR-168 defines a set of Java APIs that allows portlets to run
on any compliant portals, WSRP allows Web services to be exposed as
portlets in a plug-and-play fashion.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Distributed Portlets

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Portal Grid

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 WSRP4J

WSRP4J can act as a bridge between JSR-168 and WSRP. It can both
export a portlet as a Web service and consume such a service
converting it into a pluggabe portlet.

Use WSRP4J to wrap Java object and export as a Web service.

WSRP can equally be consumed by other tools, such as Swing, so portlets

are not restricted to use in portals.

More information to be provided…

Reference
• http://ws.apache.org/wsrp4j/

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Portal Frameworks supporting Portlets

• JetSpeed v2.0 - http://portals.apache.org/jetspeed-2

• Jportlet - http://jportlet.sourceforge.net/
• uPortal v2.0, v3.0 - http://www.uportal.org
• LifeRay - http://www.liferay.com
• IBM WebSphere v5.0 –
http://www-4.ibm.com/software/webservers/portal/
• Oracle Portal - http://portalcenter.oracle.com
• Sun ONE Portal – http://www.sun.com
• BEA Weblogic – http://www.bea.com
• GridSphere - http://www.gridsphere.org
• More ???

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 GridSphere

GridSphere is an open source research project from the EU GridLab

project. It provides a portlet implementation framework based upon
the IBM Portlet API and an infrastructure for supporting the
development of re-usable portlet services. GridSphere allows
developers to create and package third-party portlet-based Web
applications that can be executed and administered within the
GridSphere portlet container.
GridSphere includes a set of core portlets and services that provide the
basic infrastructure needed for developing and administering Web
portals. A key feature of GridSphere is that it builds upon the Web
Application Repository (WAR) deployment model to support third-
party portlets. In this way, developers can distribute and share their
work with other projects that use GridSphere to support their portal
development.
The current GridSphere release provides a portal, a portlet container,
and a core set of portlets including user and group management, as
well as layout customization and subscription. Presenter Name
Rob Allan
Facility
Portal Name
Tutorial
 GridSphere Features
• The Portlet API implementation in GridSphere is almost fully compatible
with IBM WebSphere Portal version 4.2 or higher.
• Support for the easy development and integration of "third-party” portlets
that can be plugged into the GridSphere portlet container.
• A high-level model for building complex portlets using visual beans and the
GridSphere User Interface (UI) tag library.
• A flexible XML-based portal presentation description that can be modified
to create customized portal layouts.
• A built-in support for Role Based Access Control (RBAC) in which users can
be guests, users, administrators, and super users.
• A portlet service model that allows for creation of "user services", where
service methods can be limited according to user rights.
• Persistence of data provided using Hibernate for RDBMS database support.
• Integrated Junit and Cactus unit tests for complete server side testing of
portlet services including the generation of test reports.
• GridSphere core portlets offer base functionality including login, logout,
user and access control management.
• Localization support in the Portlet API implementation and GridSphere core
portlets that support English, French, German, Czech, Polish, Hungarian and
Italian. Presenter Name
Rob Allan
Facility
Portal Name
Tutorial
 Example Code

A “Hello World” portlet with GridSphere. All portlets need to extend

the AbstractPortlet class.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Portlet Descriptor

Here is the “Hello World” portlet descriptor in GridSphere.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Developing Grid Portals with Portlets

Portlet technology is gaining attention from the Grid community for

building second-generation Grid portals to overcome problems
encountered in first generation Grid portal development frameworks
and toolkits.
A portlet in a Grid portal is not just a normal portlet that can be plugged
into a portal; it is also associated with a backend Grid service.
We define a portlet associated with a Grid service to be called a Grid
Portlet.
The figure shows how to access a Grid service from a Grid portal via a
Grid Portlet.

Reference:
See proceedings of NeSC Workshop “Portals and Portlets 2003”
http://www.nesc.ac.uk/technical_papers/UKeS-2003-01/

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Extending the Model

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Continued…

The model is that a Grid Portlet interacts with a Grid service provided
by Grid middleware such as Globus to access backend resources.
Since Grid services provided by difference service providers using
different Grid middleware technologies can be exposed as standard
portlets, portals built from portlets are loosely coupled with Grid
middleware technologies.
Portal frameworks such as Jetspeed, WebSphere Portal, ad GridSphere
have been widely used for building Web portals with portlets.
They are being integrated with Grid services for constructing Grid
portals with Grid Portlets.
Currently no framework exists that can provide an integrated
development environment (IDE) in which a Grid portal can be visually
built with Grid Portlets that are associated with backend Grid
services.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 NMI Portal and OGCE

With funding from the US National Science Foundation Middleware

Initiative (NMI), the Open Grid Computing Environments (OGCE)
project was established in autumn 2003 to foster collaborations and
sharable components with portal developers worldwide. Tasks include
the establishment of a Grid Portal Collaboratory, a repository of
portlets and portal service components, an online forum for
developers of Grid Portals, and the building of reusable portal
components that can be integrated in a common portal container
system.
The development of OGCE is based on the following projects:
• Java CoG Kit sponsored by SciDAC and NSF Alliance.
• The CHEF Project of the University of Michigan.
• The Grid Portals Information Repository (GPIR) and GridPort of the
Texas Advanced Computing Center.
• The Alliance Portal Expedition project, including NCSA, Indiana
University's Extreme Labs, and the Community Grids Lab at Indiana
University. Presenter Name
Rob Allan
Facility
Portal Name
Tutorial
 CHEF and Sakai

CHEF - Comprehensive Collaboration Framework

• Developed as a content management system for managed learning at
University of Michigan
• Now widely used for Grid portals: NMI OGCE, Alliance, LEAD, CMCS,
etc.
• Being used for the UK National Grid Service initially.
• More information to follow…

Reference
• http://collab.sakaiproject.org/portal

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Alliance Portal Services

The Alliance Portal is an ongoing project that focuses on building second-

generation Grid portals. It is based on Jetspeed and targeted at the
construction of Grid portals using Grid Portlets. Currently the
Alliance Portal can provide the following Grid Portlets that are
leveraged from existing Grid services.

• A Proxy Manager: portlet utility that allows users to load GSI proxy
credentials into their account via MyProxy.
• An LDAP Browser: portlet interface to access the contents of the
LDAP servers.
• A GridFTP Client: portlet provides the basic client functions of Grid
FTP with a user-friendly interface.

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 More…

• Gram Job Launcher: portlet allows a user to submit jobs to a Grid

environment using the Globus GRAM protocol. For this the user must
have a valid GSI Proxy Certificate which can be loaded through the
Proxy Manager portlet.
• Grid Utilities: include the "Grid Ping" utility and the "Grid Job
Submission" utility. The GridPing portlet can ping a resource in a Grid
environment and determine if a user has the access to it or not. The
Grid Job Submission portlet is similar to the Gram Job Launcher
portlet except that this portlet will not return till the job has
completed. The output and the error of the job is displayed by the
portlet.
• OGSA Browser: portlet alows users to query a Grid service for its
Service Data Elements (SDE). Users can query a SDE by using the
name of the SDE as the query string. Users can also obtain a list of
SDEs by using "serviceDataName" as the query string. Once users get
a list of all the SDEs, they can click on each SDE to query it.
Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Proxy Login

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Proxy List

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
LDAP Browser

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Job Launcher

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
GridFTP

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
Web Content in MyWorkspace

Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 State of the Art – Sakai
Sakai is an evolution of CHEF
• Java architecture re-factored to make use of new technology, such as Java
ServerFaces
• Partnership of 5 large US teaching institutions
• Log into http://collab.sakaiproject.org/portal using (id=guest, passwd=guest)
to see some of the available tools
• Principally aimed at educational portal development, course management,
workgroup management etc. - adopted by U. Michigan, Indiana U., MIT,
Stanford etc.
• But easily customised for e-Science projects, e.g. OGCE, NEESGrid
• Collaborative tools for research support
• Workflow engine
• Open Knowledge Initiative OSID (Open Services Interface Definitions)
• Tool portability profile to enable automonous development
• Around 27 FTEs with funding from institutions and the Andrew Mellon
Foundataion.
• Built on Java portlet standard JSR-168 plus CHEF v2/ uPortalPresenter
v3 framework
Name
Rob Allan
Facility
Portal Name
Tutorial
 Sakai Timelines
Portal Technology
Jetspeed 2.0
uPortal 3.0 Java
Websphere É Swing

JSR-168 Technology

Sakai
Legacy Sakai GUI Sakai GUI

Channels, JSR-168 Sakai Sakai

Teamlets Portlets Teamlet Teamlet

CHEF OKI Other

Services Services Services

NMI Grid Portal

NEESGrid

CHEF 1 CHEF 2

Science of Collaboratories

Worktools (Notes Based) WTNG

Coursetools (Notes Based) CTNG

SPARC

1991 - 1997 1998 1999 2000 2001 2002 2003 2004

Presenter 2005
Name
Rob Allan
Facility
PortalName
Tutorial
 Summary
Second generation Grid portals will be produced from pluggable Grid Portlets.
Running inside of a portlet container, portlets can be added into, or removed
from a portal, thus providing users with the ability to customize Grid
services at a portal level. Grid Portlets are independent components that are
based on existing Grid services. A Grid portal built from Grid Portlets can
provide users with the ability to integrate services provided by different
Grid-enabling technologies. Second generation Grid portals with portlets
have the following benefits compared with first generation Grid portals.
• Portal Customization: a user instead of a Grid system developer can
construct their personalized portals out of the available portlets to meet
their specific needs. Portlets can be easily added or removed from a portal.
• Extensible Grid Services: Portals built from portlets are loosely coupled
with Grid middleware technologies since Grid services can be exposed as
standard portlets. A portal constructed from portlets provides users with
the ability to integrate services from different Grid service providers.
• Dynamic Grid Services: New services and components are being developed
for the Grid. A Grid portal should be able to provide users with the ability to
access dynamic Grid services in a Grid environment. To this end, a mechanism
can be provided to expose Grid services as individual portlets that can be
Presenter Name
published and accessed via a portal. Rob Allan
Facility Name
Portal Tutorial
 Key Points (1)

• A Grid portal provides a Web page based user interface as a single

access point to the Grid.
• MyProxy has been widely used for the management of user
credentials.
• JSP and Java servlets are used for dynamically generating portal
pages.
• Grid portals can be broadly classified into first and second-
generation portals.
• Grid portals mainly use JSP and Java Beans to communicate with the
Java CoG to interact with backend Globus-based services, specifically
GT2.
• Existing Grid portal tools such as GPDK, GridPortal, the Ninf Portal,
GridSpeed can provide some kinds of assistance in building first
generation Grid portals.
• JetSpeed, uPortal etc. support portlets.
Presenter Name
Rob Allan
Facility
PortalName
Tutorial
 Key Points (2)

1st Generation
• First generation portals are tightly coupled with Grid middleware
technologies and can only provide static and restricted Grid services.
• First generation Grid portals lack the ability to be customised in that
portals can only be built by Grid system developers instead of users.
It is difficult for end users to modify an existing portal of this
generation to meet their specific needs.
• Portlet technology is gaining attention from the Grid community and
being used to build second-generation Grid portals.
2nd Generation
• Second generation Grid portals are focused on portlets that support
user customisability in that Grid users can build their personalized
portals. Portals of this generation can provide extensible and dynamic
Grid services.
• The Portlet API from JSR-168 is the portlet standard for writing
portable portlets.
Presenter Name
Rob Allan
Facility
PortalName
Tutorial