View
218
Download
1
Category
Tags:
Preview:
Citation preview
Michelle Osmond & Yike Guo
All Hands Meeting
September 2005
Adopting and Extending Portlet Technologiesfor e-Science Workflow Deployment
Adopting and Extending Portlet Technologiesfor e-Science Workflow Deployment
The Discovery Net Web Portal
OverviewOverview
• 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 workflowsWeb 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 ClientDNet Web Portal (Java Servlets)- a page for each DNet service (deployed workflow)
Web Deployment of DNet workflowsWeb 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: ServicesTraditional DNet Web Portal: Services
– Service page dynamically generates form for selected service
OverviewOverview
• 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 TechnologyJSR168 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 TechnologyJSR168 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 ProblemHTTP/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 WrappersHTTP/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 CommunicationInter-portlet Communication
• Very common requirement. Typically:
• 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
Customer List
Customer ACustomer BCustomer C
Customer Details
NameAddressOrders…
click
SERVICE INDEX PORTLET
SESSION: APPLICATION SCOPE
service_path
writeservice_path
readservice_path
SERVICE PORTLET
Inter-portlet CommunicationInter-portlet Communication
• Simple use of the session for sending 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.
SERVICE INDEX PORTLET
SESSION: APPLICATION SCOPE
service_path
writeservice_path
readservice_path
SERVICE PORTLET
• 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
SESSION: APPLICATION SCOPE
SERVICE INDEX PORTLET
SERVICE PORTLET
writeoutput_path
readinput_path
Message Centre
service_pathitem_path
message name mapping
Inter-portlet CommunicationInter-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!
Execute Service Add new Service Portlet Use Result in new Service
Result Result Result
Result
event
• 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 CommunicationInter-portlet Communication
• Send messages in Action phase for consistency
– Highly recommended
• Reaction code has to be in the Render phase
– View caching must be turned off
• No reliable message chaining– Requires portal-level support
P1 P2 P3 P4
Restrictions of the messaging library
• Need: portlet instance ID– Not provided in JSR168. – E.g. Generate one and store it in the
local portlet session.
Action phase (P1) - send message
P1 P2
click
P1 P2
Render phase
(P2) - read
message
(P1)
Inter-portlet CommunicationInter-portlet Communication
– External, independent store (EJB, Database)
– Portal-specific hacks (session object..)
Cross-context communication (multiple portlet apps)
SESSION: APPLICATION SCOPE
SERVICE INDEX PORTLET
SERVICE PORTLET
writeoutput_path
readinput_path
Message Centre
PORTAL
Ses
sio
nID
Ses
sio
nID
SESSION: APPLICATION SCOPE
SERVICE INDEX PORTLET
SERVICE PORTLET
writeoutput_path
readinput_path
Message Centre
PORTLET APP
PORTLET APP
Message Store
service_pathitem_path
message name mapping
Library allows implementations to be plugged in
• Need: a single MessageStore accessible by all portlet apps
• Need: portal user session ID (common across all portlet apps)
– Not provided in JSR168– Tricky to do cleanly within JSR168
(JavaScript, cookies…?)
– Portal-specific hacks may be the best way (e.g. use portal SessionID)
OverviewOverview
• 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 PortletsDiscovery Net Portlets
• DNet Portlets developed– Login– Service Index– Service– Userspace Index– Userspace Viewer– Userspace Manager– Userspace Upload– Task Manager– Admin
Discovery Net PortletsDiscovery Net Portlets
• Service Portlet: Flexibility– Access any DNet workflow – no portal admin required
Discovery Net PortletsDiscovery Net Portlets
• Communication between Service portlets (and others)
Output maps to message named“Created Table (Messaging Services 2)”
First Service:
Property is read in frommessage
Second Service:
Parameter usesmessage input
Temporary result tableis passed betweenservices
OverviewOverview
• 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 CompatibilityPortal 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
ConclusionConclusion
• 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/
Discovery Net SystemDiscovery Net System
• Data mining system, integrates heterogeneous tools
• Encode scientific analysis procedures as DNet workflows
DeploymentWeb Interface
3rd party access
ExecutionResult storageWork historyVisualisations
WorkflowsAuthoringStorage
Scientific DataFiles
DatabasesInstrument data
ApplicationsDNet componentsCustom programsWeb/Grid services
Discovery Net Client / Server
Discovery Net Java ClientDiscovery Net Java Client
Available Analysis
Components
User’s Workspace
(file area)
Configuration of an analysis
node
Result visualisation
Workflow construction
area
• DNet Client: the expert user’s interface for authoring workflows
Web Deployment of DNet workflowsWeb Deployment of DNet workflows
• Can be considered as ‘wrapping’ a workflow so it acts like a single node
• 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
Param 1 Param 2
Output 1
Output 2
Output 3
• Multiple deployed workflows (‘Services’) may be designed to be used in sequence
DNet Server
Summary: Discovery Net’s Web DeploymentSummary: Discovery Net’s Web Deployment
workflowworkflow
workflowworkflows
DataCluster
ClusterCluster
Web Service
Grid Service
DNet Java Client
Workflow editing,
execution, deploymentUserspace and task
management
DNet Web Portal- a page for each DNet service
Workflow executionUserspace management
Task management
Workflow StorageUserspace StorageExecution Engine
DNet Portlets- all features of DNet Portal- pages contain a mixture of DNet and 3rd party portlets- user-customisable content and layout
JSR168 Portlet TechnologyJSR168 Portlet Technology
Portlet Container
User’s Web browser
Portal
Portlet Portlet
Portlet
Portlet Web Service (WSRP)
Portlet
Web Service (WSRP)
J2EE App Server
JetspeedOracle Portal
Pluto
Tomcat, JBoss, Oracle AS
Technologies and Architecture
Internet
Internet
HTTP
SOAP
User’s Web browser
Portlet ApplicationsPortlet Applications
• Servlets: multiple “web applications”
• Portlets: – Portal is one web application
– 1 or more portlet web applications• Each portlet application can
contain many portlets/shop
Servlet Container (e.g. Tomcat)
/forum
/support /jetspeed
Servlet Container
/forum_portlets
/shop_portlets
• Separation between sections is clear to the user:
– separate pages in web browser, visible in URL
• Separation is not visible to the user:
– a single portal page can contain portlets from different portlet applications
Web application sessions are
kept separate: Servlet
specification
http://server.com/forum/index.jsphttp://server.com/shop/index.jsp
http://server.com/jetspeed/portalhttp://server.com/support/index.jsp
Recommended