Transcript Discovery Net Portlets - National e

Adopting and Extending Portlet Technologies
for e-Science Workflow Deployment
The Discovery Net
Web Portal
Michelle Osmond & Yike Guo
All Hands Meeting
September 2005
Overview
•
•
•
Discovery Net’s web deployment system
Traditional Discovery Net Portal
JSR168 Portlet Technology
– Advantages and Disadvantages
– Some problems and solutions
• HTTPServlet/Portlet wrappers
• Inter-portlet communication library
• Discovery Net Portlets
• Portal Compatibility
• Conclusion
Web Deployment of DNet workflows
•
•
•
Discovery Net workflows are built by expert users with
the DNet Java Client.
Workflows are deployed by choosing parameters and
output ports to expose in the web interface.
Non-experts can use the simpler web interface to
modify and execute the deployed workflow (‘service’).
A workflow in the DNet Java Client
DNet Web Portal (Java Servlets)
- a page for each DNet service (deployed workflow)
Web Deployment of DNet workflows
• Functionality of this basic model is sufficient.
• User requests for enhancements were mainly for
customisation of the Service’s web interface, and features
previously only available on the client:
– ‘Skinning’: Company/Group logo
– Applets (or other custom HTML) for special parameters
(e.g. Molecule Sketch, calendar)
– Custom layout of the service form
– Advanced web-visualisation of results, e.g. Applet
versions of the Java client’s visualisers.
– Shareable Service ‘Bookmarks’
(commonly-used parameter values)
– Cached intermediate results for
multi-stage workflows (service state)
– Task management
– Userspace Management
Traditional DNet Web Portal: Services
– Service page dynamically generates form for selected service
Traditional DNet Web Portal: Tasks
Traditional DNet Web Portal: Userspace
Overview
•
•
•
Discovery Net’s web deployment system
Traditional Discovery Net Portal
JSR168 Portlet Technology
– Advantages and Disadvantages
– Some problems and solutions
• HTTPServlet/Portlet wrappers
• Inter-portlet communication library
• Discovery Net Portlets
• Portal Compatibility
• Conclusion
JSR168 Portlet Technology
•
Discovery Net Web Portal dedicates a whole browser
window to each service, or userspace view.
– What if we want to use two or more services together? Switch
back and forth between pages.
•
Portal technology allows multiple
independent components to
appear on one page.
– Each component is a portlet
– Portal manages each user’s
chosen layout and individual
portlet settings/preferences
– Portlets written to the JSR 168
specification can be plugged
into any compliant Portal
JSR168 Portlet Technology
• Why?
– Customisation of Portal
layout
• Design pages and their
contents
– Personalisation
• User settings
• Design private or group
pages
– Better suited for using
multiple related services
– JSR168 Standard
• Choice of portals
– Can include 3rd party
portlets
– Integrate DNet functionality
into an existing Portal
• Why not?
– May be a lot of work
• Particularly if Struts is
involved
• Control code needs to be
cleanly separated
• Known
restrictions/pitfalls to
work around
– Communication between
portlets not in JSR168
– Portlets cannot access
their environment (e.g.
link to pages, add/remove
portlets)
– Migration between portals
may not be smooth
HTTP/Portlet Interface Problem
•
•
A problem you may encounter if you are maintaining both servlet
and portlet versions of an application:
– Common functions that use the HTTP
request/response/session objects cannot be directly used by
both servlets and portlets.
Why?
– Portlets and servlets use different classes to access the HTTP
request, session etc, which have slightly different functionality.
The portlet versions do not extend the javax.servlet.http
classes.
– There are 2 scopes in the PortletSession: a global
‘APPLICATION’ scope visible to all portlets in the same
webapp, and a local ‘PORTLET’ scope.
HttpServletRequest
.getSession()
PortletRequest
.getPortletSession()
(->ActionRequest, RenderRequest)
HttpSession
.getAttribute(name)
.setAttribute(name,value)
PortletSession
.getAttribute(name,scope)
.setAttribute(name,value,scope)
HTTP/Portlet Wrappers
• Duplicate functions with different profiles?
– Works, but bad
public void setPath(String path, HttpServletRequest request){
request.getSession().setAttribute(“path”, path);
}
public void setPath(String path, PortletRequest request){
request.getPortletSession().setAttribute(“path”, path, PORTLET_SCOPE);
}
• Better solution: use a wrapper in portlets when calling a function
written for use by servlets
setPath( path,
new HttpServletRequestWrapper(portletRequest, PORTLET_SCOPE) );
– Only works with common functionality (e.g. session access)
– Be aware of portlet session scopes: need to specify which one
(APPLICATION or PORTLET) should be visible to the wrapper
http://www.doc.ic.ac.uk/~mo197/portlets/portlet_wrappers/
Inter-portlet Communication
•
Very common requirement. Typically:
Customer List
Customer A
Customer B
Customer C
•
Customer Details
click
Name
Address
Orders…
Not defined in JSR168!
– Each portal has its own
implementation
• Not JSR168-compliant, locks you
to that portal
– Spec-compliant recommendation:
use the APPLICATION_SCOPE
Portlet Session.
• Only for communication between
portlets in the same webapp
SERVICE INDEX
PORTLET
SERVICE
PORTLET
write
service_path
read
service_path
service_path
SESSION: APPLICATION SCOPE
Inter-portlet Communication
SERVICE INDEX
PORTLET
SERVICE
PORTLET
write
service_path
read
service_path
• Simple use of the session for sending
service_path
SESSION: APPLICATION SCOPE
messages breaks down in complex portals.
– Programmers need to be aware of message
names used by all other portlets
– Restricts use of portlets on pages: can only
use hardcoded communication channels.
Users can’t affect how the messages flow.
• Solution: add a level of
abstraction: map local message
names to global names
– Programmers only need to deal
with local names for each portlet
– Users can dynamically configure
mappings for each portlet
instance at runtime
SERVICE INDEX
PORTLET
SERVICE
PORTLET
write
output_path
read
input_path
Message Centre
message name mapping
item_path
service_path
SESSION: APPLICATION SCOPE
Inter-portlet Communication
What messaging model is appropriate in this environment?
• Publish-Subscribe / Event-Listener model doesn’t work for our
dynamic scenarios:
– Can’t know about portlets that the user may add after the message
has been sent!
Result
Result
Result
event
Result
Execute Service
Add new Service Portlet
Use Result in new Service
• Message Board / Shared State idea is more appropriate
– Messages stay in their named “message box” until overwritten
• Shared MessageCentre holds all the message boxes for that session, and
provides access using message mappings
– Each portlet registers mappings with the MessageCentre when it loads
• Each portlet saves its mappings in its JSR168 portlet preferences
Inter-portlet Communication
Restrictions of the messaging library
•
– Not provided in JSR168.
– E.g. Generate one and store it in the
local portlet session.
click
P1
P2
•
Action phase (P1)
- send message
•
(P1)
P2
Send messages in Action phase for
consistency
– Highly recommended
Reaction code has to be in the
Render phase
– View caching must be turned off
Render phase
P1
Need: portlet instance ID
(P2)
- read
message
P1
•
P2
P3
P4
No reliable message chaining
– Requires portal-level support
Inter-portlet Communication
Cross-context communication (multiple portlet apps)
SERVICE INDEX
SERVICE
PORTLET
PORTLET
SERVICE INDEX
SERVICE
write
read
PORTLET
PORTLET
output_path
input_path
write
read
output_path
input_path
•
– External, independent store (EJB,
Database)
– Portal-specific hacks (session object..)
Message Centre
Message Centre
SESSION: APPLICATION SCOPE
SessionID
PORTLETAPPLICATION
APP
SESSION:
SCOPE
•
Need: portal user session ID (common
across all portlet apps)
PORTLET APP
PORTAL
– Not provided in JSR168
– Tricky to do cleanly within JSR168
(JavaScript, cookies…?)
Message Store
message name mapping
item_path
Need: a single MessageStore accessible
by all portlet apps
– Portal-specific hacks may be the
best way (e.g. use portal SessionID)
service_path
Library allows implementations to be plugged in
Overview
•
•
•
Discovery Net’s web deployment system
Traditional Discovery Net Portal
JSR168 Portlet Technology
– Advantages and Disadvantages
– Some problems and solutions
• HTTPServlet/Portlet wrappers
• Inter-portlet communication library
• Discovery Net Portlets
• Portal Compatibility
• Conclusion
Discovery Net Portlets
•
DNet Portlets
developed
–
–
–
–
–
–
–
–
–
Login
Service Index
Service
Userspace Index
Userspace Viewer
Userspace Manager
Userspace Upload
Task Manager
Admin
Discovery Net Portlets
•
Service Portlet: Flexibility
– Access any DNet workflow – no portal admin required
Discovery Net Portlets
•
Communication between Service portlets (and others)
Second Service:
Property is read in from
message
First Service:
Parameter uses
message input
Output maps to message named
“Created Table
(Messaging Services 2)”
Temporary result table
is passed between
services
Overview
•
•
•
Discovery Net’s web deployment system
Traditional Discovery Net Portal
JSR168 Portlet Technology
– Advantages and Disadvantages
– Some problems and solutions
• HTTPServlet/Portlet wrappers
• Inter-portlet communication library
• Discovery Net Portlets
• Portal Compatibility
• Conclusion
Portal Compatibility
“JSR168 compliant” doesn’t necessarily mean your portlets
will work on a different portal first try. Some gotchas:
• Instance treatment
– Add multiple ‘copies’ of the same portlet to a page: are they
treated independently? (sessions, preferences)
– Unclear in spec – different interpretations
• Session sharing (or not) between servlets and portlets in
the same webapp
– Tomcat 5.5: “cross-context” and “emptySessionPath”
• JAAS (Authentication) login modules
– Probably needs to be set up in the app server (e.g. Tomcat),
but might be overridden by the portal
• Apache Struts
– Portal might replace with its own version.
• May interfere with struts apps – even normal servlets - in
your portlet webapp
Conclusion
•
•
•
•
•
•
Effort, but worth it
Discovery Net Portlets – added further flexibility
to already popular web interface
Personalisation, custom page creation – “web
toolkits”
Service messaging – new.
Combine with 3rd party portlets/integrate into
users’ existing portals
Open source utilities available for download
– Wrappers
– Messaging library
http://www.doc.ic.ac.uk/~mo197/portlets/
thank you…
•
questions?
http://www.doc.ic.ac.uk/~mo197/portlets/
Discovery Net System
•
•
Data mining system, integrates heterogeneous tools
Encode scientific analysis procedures as DNet workflows
Scientific Data
Execution
Files
Databases
Instrument data
Result storage
Work history
Visualisations
Workflows
Authoring
Storage
Applications
DNet components
Custom programs
Web/Grid services
Deployment
Discovery Net
Client / Server
Web Interface
3rd party access
Discovery Net Java Client
• DNet Client: the expert user’s interface for authoring workflows
User’s
Workspace
(file area)
Result
visualisation
Available
Analysis
Components
Workflow
construction
area
Configuration
of an analysis
node
Web Deployment of DNet workflows
• Can be considered as
‘wrapping’ a workflow so
it acts like a single node
Output
• Or, outputs may be
published at different
stages of the same
workflow
– a multi-step, possibly
branching, service
– user can try different
options at each stage
before proceeding
Param 1
Param 2
Output 1
Output 2
Output 3
Param 1
Param 2
• Multiple deployed workflows (‘Services’) may be
designed to be used in sequence
Summary: Discovery Net’s Web Deployment
Workflow execution
Userspace management
Task management
DNet Web Portal
- a page for each DNet service
workflow
workflow
workflow
DNet Java Client
Workflow
editing,
execution,
deployment
Userspace
and task
management
Data
workflows
Workflow Storage
Userspace Storage
Execution Engine
DNet Server
Cluster
Cluster
Cluster
Grid
Service
DNet Portlets
- all features of DNet Portal
- pages contain a mixture of
DNet and 3rd party portlets
- user-customisable content
and layout
Web
Service
JSR168 Portlet Technology
Technologies and Architecture
User’s Web browser
User’s Web browser
Internet
HTTP
Web Service (WSRP)
Jetspeed
Oracle Portal
Portal
SOAP
Portlet Container
Portlet
Pluto
Internet
Portlet
J2EE App Server
Portlet
Portlet
Tomcat, JBoss, Oracle AS
Web Service (WSRP)
Portlet
Portlet Applications
• Servlets: multiple “web
• Portlets:
applications”
/shop
/forum
/support
Servlet Container
(e.g. Tomcat)
– Portal is one web application
– 1 or more portlet web applications
Web application
sessions are
kept separate:
Servlet
specification
http://server.com/forum/index.jsp
http://server.com/shop/index.jsp
http://server.com/support/index.jsp
•
Separation between sections
is clear to the user:
– separate pages in web
browser, visible in URL
• Each portlet application can
contain many portlets
/jetspeed
/forum_portlets
/shop_portlets
Servlet Container
http://server.com/jetspeed/portal
•
Separation is not visible to the user:
– a single portal page can contain
portlets from different portlet
applications