A Web Portal for the National Grid
Service
Xiaobo Yang, Dharmesh Chohan, Xiao Dong Wang
and Rob Allan
CCLRC e-Science Centre, CCLRC Daresbury
Laboratory
Warrington WA4 4AD, UK
Rob Allan
Daresbury Laboratory
The Grid “Client Problem”
Many clients want to access a few Gridenabled resources
Grid Core
Workplace:
desktop
clients
Grid Core
Middleware
e.g. Globus
Portable clients:
phones, laptop,
pda, data entry…
Consumer
clients: PC,
TV, video,
AG
Options
• Provide heavyweight functionality (Globus?), but only on Gridenabled hosts;
• Implied need for client-server software architecture, e.g.:
– Web-based portal with familiar browser
– Client programming library, API in C, C++ Java, Perl,
Python, R etc.
– Ability to link to existing applications/ GUIs
– Command-based shell interface
Our chosen solution
– Drag and Drop interface (a la Mac)
• Need a published set of services on Grid hosts – OGSA model,
registry, semantics;
• Need easy development and deployment framework for
applications and client tools, e.g. using Web services encourage community contribution via an open process.
Why a Portal
Right functionality:
• Encapsulates Grid functionality
• Separation of “front-end” session management and presentation
layers
• Model code layer at “back-end” using Globus C/ Java API or other
middleware, e.g. SRB
Right technology:
• Good support for portal developments – standards and tooling in Java
• Web services (Java, Perl, C, Python, PHP, etc.)
Knowledge:
• Previous experience, we have been using Web portals to develop and
test Grid functionality since 2000
• HPCPortal, InfoPortal, DataPortal
• Based on work in the Global Grid Forum – Grid Computing
Environments research group (GCE-RG)
Building on the Infrastructure
NGS Portal
Integrated e-Science
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.)
NGSPortal v1.0
• NGSPortal 1.0 was based on OGCE v1.0: the Open Grid Computing
Environment portal
– Adopted in USA by NMI: the National Middleware Initiative
– http://www.collab-ogce.org/nmi/portal
• Used the CHEF framework (Comprehensive Collaborative Framework)
from U. Michigan
• Some additional ideas taken from HPCPortal and InfoPortal
• NGSPortal tools available November 2004:
– MyProxy management
– GRAM job submission
– FileTransfer based on GridFTP
– MDS resource discovery
• Feedback at NeSC training event, December 2004
NGSPortal v1.0 file-transfer tool
Why change?
• Was always planned to migrate to Sakai along with OGCE v2.0
– http://www.sakaiproject.org
– had letters of support from Brad Wheeler and Chuck Severance
– JISC Sakai VRE Demonstrator funded
• But, OGCE is no longer using Sakai. Decided to deploy JSR-168 Java
standard portlets to replace the CHEF teamlets
• GridSphere and uPortal frameworks now supported
• Many European projects have tried GridSphere
• We also therefore decided to use JSR-168 in NGSPortal v2.0 for
complete portability and sharing with other projects such as
Integrative Biology and e-HTPX
• GridSphere, uPortal, LifeRay, eXo Platform and StringBeans
evaluated
– workshop with Jason Novotny, NeSC, March 2005
– See separate paper
• StringBeans chosen because of its good level of support and
flexibility of customisation
Single Sign-On
Most feedback has been about SSO
•
•
•
–
PKI infrastructure adopted as standard for middleware on UK Grid
with a policy statement issued by CA to enable international
collaborations – took a lot of effort!
v1.0 was therefore intended to work with Globus using a MyProxy
certificate repository for pervasive access
Same as HPCPortal and an established Grid security procedure
1. Log into portal with username/ passwd
2. Retrieve proxy credential from MyProxy using possibly a
different username/ passwd
MyProxy is maintained by the Grid Operations and Support Centre
for all Grid users myproxy.grid-support.ac.uk
But
• Widespread lack of awareness of Grid security issues
• Users not willing to make the effort to manage their own certificate
• Need more training?
2-step login method
Simplified by using MyProxy as
primary authentication via a CHEF
service
NGSPortal v2.0
• Using JSR-168
• Chose StringBeans r2.4
– http://www.nabh.com/projects/sbportal
• Portlets will also work in other environments, e.g. GridSphere
– As demonstrated at NeSC workshop, March 2005
• Single Web application for all portals enables shared session
information, e.g. proxy credential
• Using JAAS architecture for MyProxy Login Module (SSO)
– Map to local portal accounts
– Still has a portal login for those who don’t want to use Grid
services
NGSPortal v2.0 “Welcome!”
Authentication in NGSPortal v2.0
Inter-portlet Communication using JMS
• Need more integration of portal services
– an “integration API”
• But, having all portlets in one Web application is not satisfactory
– Configuration and management problems
– Hard to distribute via a portlet repository
• Inter-portlet communication is provided in commercial portal
frameworks, e.g. WebSphere
– Extensions to JSR-168
• JMS is used for the BatchJobMonitor portlet.
– A finishing job sends a JMS message to a server
– BatchJobMonitor can consume this message to get the job status
– Can also provide notification
BatchJobMonitor portlet
Other Features of J2EE Architecture
• Current development is being doing using J2EE architectural
features hosted in JBOSS
• JAAS and JMS are already part of J2EE and being used as
described
• EJB: Enterprise Java Beans enables further factoring of a multi-tier
server-centric application such as a portal.
– EJBs can be automatically exposed as Web services
• This will enable NGSPortal services to be accessible from other
client environments
– e.g. GROWL and Sakai – see separate papers
• WSRP is being investigated to enable projects to use NGS portlets
directly in their own portal frameworks
– But GridSphere does not have a WSRP consumer
• ongoing discussion with Jason Novotny
– Sakai?
• similar discussion with Chuck Severance
Re-factoring using J2EE Architecture
Business Logic
Enterprise
JavaBeans
JSR 168
Portlets
Proxy
Manager
Job
Submission
File Transfer
GridFTP/SRB
LDAP
Browser
Portal
JSR 168
Compliant
Sakai
Framework
Web
Service
Interfaces
UDDI
Registry
EJB Internal Comm
Accessing Web Services
Accessing EJBs
Web Service Registry
Future Work
• The current architecture is being re-factored as above
• Other portlets are being developed by popular demand, e.g. an SRB
portlet
• Further integration of the portlets is taking place, e.g. using SRB
together with GridFTP or closely coupled with the JobManager
portlet
• Application-specific portlets such as DL_POLY
• Cloning of portlets for other projects such as Integrative Biology
• Portlet registry - jUDDI
Talk to us!
• Workflow – WOSE project
• Chargeable services – GridMarkets project
• WSRP for aggregation of remote services and provision of NGS
portlets to projects’ own portals
• WSRP export of portlets for Sakai VRE Demonstrator project
* See other papers at this conference *
Thanks!