Michelle Osmond & Yike Guo All Hands Meeting September 2005 Adopting and Extending Portlet Technologies for e-Science Workflow Deployment The Discovery Net Web Portal

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 3 rd 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

Inter-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 A Customer B Customer C Customer Details Name Address Orders… click SERVICE INDEX PORTLET SESSION: APPLICATION SCOPE service_path write service_path read service_path SERVICE PORTLET

Inter-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 write service_path read service_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 write output_path read input_path Message Centre service_pathitem_path message name mapping

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! Execute ServiceAdd new Service PortletUse Result in new Service 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 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 P1P2P3P4 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 P1P2 click P1P2 Render phase (P2) - read message (P1)

Inter-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 write output_path read input_path Message Centre PORTAL SessionID SESSION: APPLICATION SCOPE SERVICE INDEX PORTLET SERVICE PORTLET write output_path read input_path Message Centre 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)

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) Output maps to message named “Created Table (Messaging Services 2)” First Service: Property is read in from message Second Service: Parameter uses message input 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 3 rd party portlets/integrate into users’ existing portals Open source utilities available for download –Wrappers –Messaging library

thank you… questions?

Discovery Net System Data mining system, integrates heterogeneous tools Encode scientific analysis procedures as DNet workflows Deployment Web Interface 3 rd party access Execution Result storage Work history Visualisations Workflows Authoring Storage Scientific Data Files Databases Instrument data Applications DNet components Custom programs Web/Grid services Discovery Net Client / Server

Discovery 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 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 1Param 2 Output Param 1Param 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 Deployment workflow workflows Data Cluster Web Service Grid Service DNet Java Client Workflow editing, execution, deployment Userspace and task management DNet Web Portal - a page for each DNet service Workflow execution Userspace management Task management Workflow Storage Userspace Storage Execution Engine DNet Portlets - all features of DNet Portal - pages contain a mixture of DNet and 3 rd party portlets - user-customisable content and layout

JSR168 Portlet Technology Portlet Container User’s Web browser Portal Portlet Web Service (WSRP) Portlet Web Service (WSRP) J2EE App Server Jetspeed Oracle Portal Pluto Tomcat, JBoss, Oracle AS Technologies and Architecture Internet HTTP SOAP User’s Web browser

Portlet 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