Adopting and Extending Portlet Technologies for e-Science Workflow Deployment

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)


• 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

Traditional DNet Web Portal: TasksTraditional DNet Web Portal: Tasks

Traditional DNet Web Portal: UserspaceTraditional DNet Web Portal: Userspace

OverviewOverview







• 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


• 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


• 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_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



SERVICE PORTLET

writeoutput_path

readinput_path

Message Centre

service_pathitem_path

message name mapping


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


• 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)


– External, independent store (EJB, Database)

– Portal-specific hacks (session object..)

Cross-context communication (multiple portlet apps)



SERVICE PORTLET

writeoutput_path

readinput_path

Message Centre

PORTAL

Ses

sio

nID

Ses

sio

nID



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







• Conclusion

Discovery Net PortletsDiscovery Net Portlets

• DNet Portlets developed– Login– Service Index– Service– Userspace Index– Userspace Viewer– Userspace Manager– Userspace Upload– Task Manager– Admin


• Service Portlet: Flexibility– Access any DNet workflow – no portal admin required


• 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







• 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/

thank you…thank you…

• questions?

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


• 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


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

Adopting and Extending Portlet Technologies for e-Science Workflow Deployment

Documents

Transcript of Adopting and Extending Portlet Technologies for e-Science Workflow Deployment