Julien Viet eXo Platform 18th of September 2008

-  Julien Viet •  eXo Portal Product Manager •  JSR 286 Portlet 2.0 Expert Group member (and a few others) •  JBoss Portal founder and former lead

-  eXo Platform •  Open Source project founded in 2001 •  Standard based: Portlet, Java Content Repository •  Complete product line: portal, ECM, collaboration suite, knowledge suite

•  Worldwide company founded in 2003 •  Consutling and training •  24x7 support

-  Introduction -  Why use a portal ? -  Introduction to Portlet -  What Portlet 2.0 brings on the table -  Conclusion / Q&A

-  What is a portal ? •  Boxes in my web browser ?

-  Unify the access to your applications and information •  Integrate heterogeneous web applications •  Syndicate content •  Across organizational boundaries •  Integration occurs at the presentation layer

-  Usual features •  Single Sign-On •  Personalization •  Dashboards •  Internationalization, Right-To-Left •  Collaboration •  Social networks

Calendar Portlet

Por

tal

Mail Portlet

Java EE

-  Homegrown portals work only for small scale portals -  Do you have control over the applications ?

•  Support past, present and future web frameworks •  Application life cycle

-  Decrease time to market •  Don't reinvent the wheel •  Community management •  Integrate thirdparty application such as enterprise content management,

collaboration tools, …

-  Users will always need more… •  More personalization •  More collaboration •  More applications

-  Portlets are a pluggable user interface component model living in the portal ecosystem •  At minimum it produces a markup fragment

-  Portlets are not widgets or gadgets •  Portlets are managed by a portlet container and a portal •  Widgets or gadgets are not

-  A fragmented market before 2003 •  Historically Java EE has seen a variety of different component models •  Beyond Java EE, other middleware stacks have defined their own component

models

  A service managing portlets   Deployed in an application server   Implements the component model defined by the JSR 286 Portlet specification

(JCP)

  Interacts with a portal in various way   Provide portlet description   Manage portlet state   Portlet runtime invocations   Contract defined by the Web Service for Remote Portlet specification (Oasis)

-  The Portlet 1.0 specification defines the component model for the Java EE stack •  Finalized in October 2003 •  Wide market adoption by all Java EE based portal

-  Defines a component model for the Java EE stack •  Integrated with the Java EE stack but not part of it •  Security propagated to other components such as EJB •  But you cannot expect to have a portlet container in an app server

•  Web frameworks are bridged •  The developer should never use the native portlet API •  JSR 301: Portlet Bridge Specification for JavaServer Faces •  Existing bridges for popular frameworks (Wicket, Tapestry, Struts2)

-  The portlet application defines the packaging unit as a standard Jave EE web application •  /WEB-INF/portlet.xml deployment descriptor •  Portlet classes implement the javax.portlet.Portlet interface

-  Portlets are involved in the global portal request/response cycle -  Portlet are described with rich meta data

•  Description / display name •  Categorization through keywords •  Capabilities, portlets can potentially talk to different devices •  etc…

public interface Portlet {

void render(RenderRequest req, RenderResponse resp); void processAction(ActionRequest req, ActionResponse resp); … }

-  A list of portlet descriptions is available for the portal -  Portlet integration within an aggregated page through two

decoupled phases •  Render phase produces markup from a set of render parameters •  Action phase perform a state update from a set of action parameters

-  Content personalization •  Application based via portlet preferences •  User based via the profile, the locale

-  Access to several state scopes •  Render parameters is a Map<String,String[]> that provides navigation

based state (current page id) •  The PortletSession can hold complex objects temporarily (shopping cart) •  The PortletPreferences persist state across sessions (# of visible topics)

-  Action parameters (POST) •  Parameterize the action of the portlet:

{ action='addBlogEntry', title='The post title', body='The post body'}

-  Render parameters (GET) •  Encoded in the browser URL supporting

browser back button and bookmarkability •  Parameterize the markup produced by the

portlet: { mode='showBlogEntry', entryId='56349' }

•  Can only be updated after an action usually by a send redirect (HTTP 302 code) to an URL containing the new render parameters

addcolor='red'

{color='red'}

addcolor='blue'

{color='red','blue'}

{}

Brow

ser back button

Use

r Int

erac

tions

-  Effort •  Started late 2005 •  Led by Stefan Hepper •  Involvement from all major portal vendors •  More information at http://jcp.org/en/jsr/detail?id=286 •  Released by the Executive Committee on 12th of June 2008

-  Main goals •  Efficient portlet coordination mechanism •  Ajax support •  Resource serving •  Ease bridge implementations •  Backward compatibility

-  Build composite application -  Since the portlet 1.0 specification it is possible to share a

portion of the session between all portlets of the same application •  Easy to use •  Too coarse grained

-  The portlet 2.0 specification provides two additional coordination mechanisms •  Public render parameters (abbreviated as PRP) •  Portlet eventing

-  A very powerful feature •  Simple and easy •  Flexible •  Allows efficient fragment caching •  Not intrusive

-  Several portlets can share the same render parameters -  A portlet declares a subset of its render parameters as

public •  In the deployment descriptor of the portlet •  Exposed by the portlet container to the portal •  Sharing scope is a feature of the portal •  Depends on the use case •  Scope can be page, portal, …

-  Use cases •  Several portlets on the same page share the same zipcode, and are able to

display informations related to the geographic location •  Weather •  Map •  Etc…

•  Contextualization of a portlet by the portal •  Pages could have properties bound to portlets public render parameters

-  Cons •  Sometime to simple •  Portlet have to agree on data format

<portlet-app>

<portlet> <portlet-name>GoogleMap</portlet-name> … <supported-public-render-parameter>zipcode </supported-public-render-parameter> … </portlet>

<public-render-parameter> <identifier>zipcode</identifier> <qname xmlns:g='urn:google'>g:zipcode</qname> </public-render-parameter>

</portlet-app>

public void render(RenderRequest req, RenderResponse resp) {

String zipcode = req.getParameter("zipcode");

render(zipcode, resp);

}

public void processAction(ActionRequest req, ActionResponse resp) {

String newZip = req.getParameter("zipcode"); resp.setRenderParameter("zipcode", newZip);

}

-  Really coordination events •  not business events, use JMS instead

-  Declarative •  What I can process/publish

-  Synchronous event routing mediated by the portal •  A portlet can publish one or several event •  One same event can be processed by several portlets

-  A new optional event phase is introduced •  An event can be published during the action phase or an event phase •  An event can have an object payload •  Each event delivery to a single portlet will trigger a call to the new life cycle method

processEvent(EventRequest, EventResponse) of that portlet •  The processEvent is similar to the processAction method •  State update semantic •  Parameterized by an event instead of the Map<String, String[]> action

parameters •  The render phase occur when all events are processed

Portal event mediation

Portlet Container

Aggregated Page

Portlet Container

Portlet Container

Action Phase Event Phase Render Phase

-  The applications defines the event in deployment descriptor •  The name identifies the event •  The class name of the optional event payload can be declared

-  Each portlet declares what it publish/process

<portlet-app>

<event-definition> <name>product-selected</name> <value-type>com.myshopping.Item</value-type> </event-definition>

</portlet-app>

public void processAction(ActionRequest req, ActionResponse resp) {

Item item = getClickedItem(req); resp.setEvent("product_selected", item);

}

<portlet> <supported-publishing-event> <name>product_selected</name> </supported-publishing-event> </portlet>

public void processEvent(EventRequest req, EventResponse resp) {

Event event = req.getEvent(); Item item = (Item)event.getPayload(); ShoppingCart cart = getShoppingCart(req); cart.addItem(item);

}

<portlet> <supported-processing-event> <name>product_selected</name> </supported-processing-event> </portlet>

-  Use cases •  Decouple different applications that need to communicate •  Synchronize complex session object because PRP are too simple •  You are already using an application that can generate events, and you want to

integrate it with that application •  Communication between the portal and the portlet •  Login/Logout •  Activities

-  Antipatterns •  Do not synchronize render parameters with events, use PRP directly •  Do not abuse, a carefully designed application can avoid to use events •  Event cascading cycling forever •  Not a messaging system

Event PRP Semantic Change based State sharing Change detection Yes No State sync Managed by the portlet Managed by the portal Usage Intrusive Not intrusive Portlet 1.0 Require sources code Out of the box Bookmarkable No Yes

-  Resource serving offers the portlet the opportunity to act as a servlet •  The portlet implements the void serveResource(ResourceRequest,

ResourceResponse) method •  Full control over the HTTP response •  Access to the runtime state •  Read/write access to the session •  Read access to preferences or render parameters

-  Various use cases •  Window popup •  Image or PDF serving •  Ajax…

-  Resource serving can be used by the portlet to retrieves data from the portlet •  Markup fragment, XML or JSON data •  Field auto completion for instance

-  But there is a limitation •  Render parameters cannot be modified during resource serving •  Updating render parameters requires a full page refresh

-  Fundamental reason is that updating portlet state may affect the whole page •  Render parameters may be public •  Other portlets may receive events and modify their state •  The portal would not be able to update the page because it is an ajax request

and it does not manage it

Container Browser

-  It is possible to use the portlet session instead of the render parameters for the navigation •  Portlet session is private to the portlet and can be written anytime •  Provides the same experience

Ajax Portlet Session Ajax

Markup

Por

tal

1)  XmlHttpRequest 2)  Session update 3)  DOM update

1

2

3

-  Full request/response header access •  Page headers allow to inject markup in the <head/> section of the page •  Read/write HTTP headers •  Read/write cookies

-  Portlet filters similar to servlet filter •  Custom security •  Markup filtering •  Etc…

-  Caching improvements •  Resource caching •  Cache re-validation

-  Window ID available in the portlet request •  Uniquely identify the portlet window •  Useful for using a cache with the window id as a key

-  More powerful request dispatching to servlets •  Targeted for web framework bridges •  Extended to all phases: action, event, render and resource serving

-  Next possible modes •  The portlet can specify the next possible modes available

-  Portal provides an unified access to your applications -  The Portlet spec makes your applications portable between

portals -  The Portlet 2 specification fills the gap -  More

•  http://jcp.org/en/jsr/detail?id=286 •  http://www.exoplatform.com

Q&A