Adopting and Extending Portlet Technologies for e-Science Workflow Deployment

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

2. 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

3. 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 • Discovery Networkflows 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’).

4. 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 • Advancedweb-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

5. Traditional DNet Web Portal: Services • Service page dynamically generates form for selected service

6. Traditional DNet Web Portal: Tasks

7. Traditional DNet Web Portal: Userspace

8. 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

9. 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

10. JSR168 Portlet Technology • 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 • 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

11. 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.

12. 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/

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

14. SERVICE INDEX PORTLET SERVICE PORTLET write service_path read service_path service_path SESSION: APPLICATION SCOPE 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 • 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. • 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

15. Result Result Result Result 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! event 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

16. click P1 P2 Action phase (P1) - send message Render phase P1 P2 P3 P4 (P1) (P2) - read message P1 P2 Inter-portlet Communication 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. • 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

17. SERVICE INDEX PORTLET SERVICE PORTLET SERVICE INDEX PORTLET SERVICE PORTLET write output_path read input_path write output_path read input_path Message Centre Message Centre SESSION: APPLICATION SCOPE SESSION: APPLICATION SCOPE PORTLET APP PORTLET APP PORTAL SessionID SessionID Message Store message name mapping item_path service_path Inter-portlet Communication Cross-context communication (multiple portlet apps) • External, independent store (EJB, Database) • Portal-specific hacks (session object..) • 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) Library allows implementations to be plugged in

18. 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

19. Discovery Net Portlets • DNet Portlets developed • Login • Service Index • Service • Userspace Index • Userspace Viewer • Userspace Manager • Userspace Upload • Task Manager • Admin

20. Discovery Net Portlets • Service Portlet: Flexibility • Access any DNet workflow – no portal admin required

21. First Service: Property is read in from message Output maps to message named “Created Table (Messaging Services 2)” Temporary result table is passed between services Parameter uses message input Second Service: Discovery Net Portlets • Communication between Service portlets (and others)

22. 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

23. 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

24. 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/

25. thank you… • questions? http://www.doc.ic.ac.uk/~mo197/portlets/

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

28. 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

29. Output Param 1 Param 2 Output 1 Output 2 Output 3 Param 1 Param 2 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 • Multiple deployed workflows (‘Services’) may be designed to be used in sequence

30. Cluster Cluster Cluster • DNet Web Portal • a page for each DNet service workflow workflow workflow workflows DNet Java Client Summary: Discovery Net’s Web Deployment Workflow execution Userspace management Task management DNet Server Workflow editing, execution, deployment Userspace and task management • DNet Portlets • all features of DNet Portal • pages contain a mixture of DNet and 3rd party portlets • user-customisable content and layout Workflow Storage Userspace Storage Execution Engine Grid Service Web Service Data

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

32. Web application sessions are kept separate: Servlet specification /shop /forum /jetspeed /support /forum_portlets Servlet Container (e.g. Tomcat) /shop_portlets Servlet Container 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 http://server.com/forum/index.jsp http://server.com/shop/index.jsp http://server.com/support/index.jsp http://server.com/jetspeed/portal • 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