The Discovery Net

indexadjustmentInternet και Εφαρμογές Web

13 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

90 εμφανίσεις

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

http://www.doc.ic.ac.uk/~mo197/portlets/portlet_wrappers/

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_path

item_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 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 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 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

PORTLET APP

Message Store


service_path

item_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

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

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 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 Deployment

workflow

workflow

workflow

workflows

Data

Cluster

Cluster

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

Portlet

Portlet

Portlet

Web Service (WSRP)

Portlet

Web Service (WSRP)

J2EE App Server

Jetspeed

Oracle Portal

Pluto

Tomcat, JBoss, Oracle AS

Technologies and Architecture

Internet

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

http://server.com/forum/index.jsp

http://server.com/shop/index.jsp

http://server.com/jetspeed/portal

http://server.com/support/index.jsp