„Like Peanut Butter and Chocolate“or Ajax meets Portals

Micha Kiener

mimacom ag

8980

Neil Grif f in

Liferay Inc.

2

AGENDA

> Introduct ion

> History

> Definit ions

> Rendering and Form Submission

> Ajax to the Rescue!

> Demo

> Behind the Scenes

> Wrap Up

> Quest ions

3

AGENDA

> Introduct ion

> History

> Definit ions

> Rendering and Form Submission

> Ajax to the Rescue!

> Demo

> Behind the Scenes

> Wrap Up

> Quest ions

4

Introduction

> Micha Kiener

– Head of Research & Innovat ion at mimacom ag

– Init iator of Open Source Project edoras (edorasframework.org)

– ICEfaces commit ter (icefaces.org)

– Liferay committer (liferay.com)

> Neil Griffin

– Senior Software Engineer at Liferay Inc.

– edoras commit ter (edorasframework.org)

– Liferay committer (liferay.com)

– JSR- 314 (JSF 2.0) expert group member

5

AGENDA

> Introduct ion

> History

> Definit ions

> Rendering and Form Submission

> Ajax to the Rescue!

> Demo

> Behind the Scenes

> Wrap Up

> Quest ions

6

History

> In the mid- 90s, web portals like AltaVista, AOL, Excite, and Yahoo! emerged the scene

> Software vendors began to produce prepackaged enterprise portals

> Portals became a hype in the late 90s

> A lot of big portal projects failed

– Poor performance

– Lack of standardizat ion

– Incompatibility of port lets

– Bad user experience

7

History

> Working on standardizat ion

> Technology has evolved

> Combinations of web technologies with portal solut ions can leverage the user experience

> Started to become popular again, but no hype anymore

8

AGENDA

> Introduct ion

> History

> Definit ions

> Rendering and Form Submission

> Ajax to the Rescue!

> Demo

> Behind the Scenes

> Wrap Up

> Quest ions

9

Definitions

> What is a Portal?– A portal is a framework for creat ing websites that aggregate

dif ferent types of content and applicat ions

– Portals are typically referred to as portlet containers

> What is a Portlet?– A portlet is a region of a portal page that contains content and

/ or applicat ion funct ionality

– With respect to Java EE, a portlet is deployed as Web Applicat ion Archive (WAR) and requires a descriptor named portlet.xml

10

Definitions

> Portal Page– Like any website, portal

sites are made up of pages

– Portal pages contain one or more portlets

– Portlets can be combined on a portal page to create a composite application

Portlet A Port let B

Port let C

Portal Page

11

Definitions

> Portlet Standards– JSR- 168 (Port let 1.0), Released on 27.10.2003

– JSR- 286 (Port let 2.0), Released on 12.06.2008

> Portlets can be developed using various technologies– JSF, JSP, Struts, Tapestry, GWT...

– Basically most frameworks can be made compatible to the port let standard, eventually using a specif ic port let bridge for integrat ion

12

AGENDA

> Introduct ion

> History

> Definit ions

> Rendering and Form Submission

> Ajax to the Rescue!

> Demo

> Behind the Scenes

> Wrap Up

> Quest ions

13

Rendering and Form Submission

> A portal page is created by rendering all port lets, combining them into a single, composite applicat ion

Portal Page Links

Portlets

Dock

14

Rendering and Form Submission

> Although portal pages can contain mult iple port lets, only one port let at a t ime can part icipate in form submission

> Form submission in Port let A causes Port let B, Port let C, … to re- render themselves

> Port let form submission can cause a disruptive end-user experience

15

Rendering and Form Submission

JSP JavaScript

Port let

JSFPortlet

Submitt ing the JSF portlet form causes an HTTP POST and forces the other portlet

to re- render itself

Click

16

AGENDA

> Introduct ion

> History

> Definit ions

> Rendering and Form Submission

> Ajax to the Rescue!

> Demo

> Behind the Scenes

> Wrap Up

> Quest ions

17

Ajax to the Rescue!

> Use Ajax within port lets to avoid a full page reload and thus a re- rendering of all port lets on it

– Better performance due to interact with only one port let

– No full page reload

– Smooth user experience, making a portal page feeling fast again

> Use Ajax Push for IPC (Inter- Port let- Communicat ion)

– Re- render other port lets needing to be refreshed due to a change in the model init ialized by an Ajax request

18

AGENDA

> Introduct ion

> History

> Definit ions

> Rendering and Form Submission

> Ajax to the Rescue!

> Demo

> Behind the Scenes

> Wrap Up

> Quest ions

19

Demo of Ajax in Portlets

> The demo uses:

– Liferay as the portal server

– Tomcat as the servlet container

– ICEfaces (JSF) as the Ajax and Ajax Push provider for developing the port lets

– Port letFaces (subproject of the edoras framework) as the “glue” code and ut ility provider for JSF in portals

– Liferay social networking plugin (WOL, World of Liferay)

20

Demo of Ajax in Portlets

21

Liferay

> Liferay Portal is an open source portlet container built with Java technology

> Liferay supports JSR- 168 and was one of the f irst to support JSR-286

> Ships with 70+ out- of- the- box port lets

> Built - in Content Management System (CMS)

> Built - in social networking port lets:

– Friends, Message Forums, Shared Calendar, Wiki, Blogs

> Liferay portlets can be built with a variety of technologies, including

– Java– JSP– JSF

– Struts– Tapestry– Javascript

– PHP– Python– Ruby

22

ICEfaces

> ICEfaces is an open source Ajax extension to JSF– Robust suite of Ajax- enabled JSF UI components

– Ajax and Ajax Push on page level

> Standards based– extends and enhances Java Server Faces (JSF)

– not a JSF implementat ion (Sun RI, MyFaces)

> Server- centric– emphasize Java, minimize JavaScript

> Transparent– features available with minimum conf igurat ion and coding

– developers leverage ex ist ing JEE expert ise and tools

23

ICEfaces

> Portlets built with ICEfaces never perform an HTTP post, instead, form submission is done via Ajax

> Because of this feature, port lets built with ICEfaces don’t disturb other portlets on the same portal page

> The end result is a rich UI that does not disrupt the end- user experience

24

AGENDA

> Introduct ion

> History

> Definit ions

> Rendering and Form Submission

> Ajax to the Rescue!

> Demo

> Behind the Scenes

> Wrap Up

> Quest ions

25

JSF Portlets

> JSR- 127 (JSF 1.1) specif icat ion was designed with JSR-168 (Port let 1.0) in mind

> Because of this, JSF web applications can typically run as port lets with lit t le to no modif icat ion

> JSF 2.0 was f inalized in June, 2009

– Requires Port let 2.0 container

– Requires JSR 329 Port let 2.0 Bridge Implementat ionFollow- on to JSR 301RI donated to Apache by OracleSVN branch ex ists with preliminary JSF 2.0 support

26

Portlet 2.0 and Ajax

> Portlet 2.0 provides the ability to issue XmlHttpRequest calls that go through the port let container

> Benefit :

– Provides complete access to port let state

> Drawbacks:

– Developer must manually update the DOM

– No support for Ajax Push

– Does not support Ajax- based Inter- Port let Communicat ion

27

Portlet 2.0 and Ajax

Portlet A

Port let Container WAR

Servlet Container / App Server

Port let AWAR

Portlet BWAR

Portlet CWAR

Servlet

XmlHttpRequest Async Response

28

Inter- Portlet Communication

> Inter- Port let Communicat ion (IPC) is a technique for sharing data between port lets and building composite applications

> User interact ions in Port let A can affect the rendered markup in Port let B, Port let C, …

> IPC can be achieved by client- side and server- side techniques

29

Inter- Portlet Communication

Portlet APort let B

Port let CButton / Link

Click

UpdatedMarkup

UpdatedMarkup

30

Client- Side IPC

> Client- side IPC can be achieved with JavaScript

> Liferay provides an event system based on the jQuery JavaScript API

> Can be fort if ied with Ajax calls in order to acquire data that is not- yet in the browser’s DOM

31

Client- Side IPC

> Benefits:

– Simple publisher / subscript event mechanism

– Rich user experience as Port let A triggers DOM update in Port let B, Port let C, …

– Network activity only takes place if Ajax is used to acquire data

– No full page submit

32

Client- Side IPC

> Drawbacks:

– Only one user (and one web browser) part icipates in IPC

– Have to write JavaScript for Ajax interact ions

– Have to write JavaScript to update DOM in affected port lets

– Potential risk of business logic being exposed on the client

– Port let development is part ly in JavaScript, part ly in Java, which can be diff icult to maintain sometimes

33

Server- Side IPC - Public Render Parameters

> Portlet 2.0 defines the ability for port lets to set public/ shared parameter names in the URL controlled by the portal

Portlet A Port let B

Button / Link

art icleId= 1234

Click

http://server/portalpage?articleId=1234

Updated Art icle

Content

34

Server- Side IPC - Public Render Parameters

> Benefits:

– Easy to implement

> Drawbacks:

– Requires full page submit

– Only practical for passing small amounts of data, such as the “id” of a record in the database

35

Server- Side IPC - Events

> Portlet 2.0 provides the publish / subscribe method for port lets to communicate via events

> Benefits:– Portal acts as broker and distributes events and payload (data)

to port lets

> Drawbacks:– Can be challenging to implement

– Not yet supported by JSF port let bridges

– Requires full page submit

– Payload must be serialized by the portal when events are passed to listeners in other classloaders

36

Server- Side IPC - JSF Session Scope

> Trying JSF session scope for IPC might be the most natural thing for a JSF developer to try, but it doesn’t work!

> Why not? Because the Port let API defines session scope in two ways:

– Port letSession.PORTLET_SCOPE: Data cannot be accessed by other port lets

– Port letSession.APPLICATION_SOPE: Data can be accessed by other port lets

> And…

37

Server- Side IPC - JSF Session Scope

> JSF port let bridges (including the ICEfaces bridge) default JSF session scope to be Port letSession.PORTLET_SCOPE

> Consequently, JSF session scope doesn’t work for IPC

> Can be used though, if Spring is the managed bean container

– Using global session, instead of session scope for beans being shared between port lets in the same WAR

38

Server- Side IPC - JSF Application Scope

> Storing shared data in JSF application scope is another choice for IPC

> Benefit :

– Not restricted to a single user – perfect for a Chat port let

> Drawback:

– Can’t use the stateful features of the session to rely on memory gett ing freed up when the session is invalidated

– Can’t share memory between different port let WARs

39

Server- Side IPC - Sharing Data Between WARs

> Liferay Portal normally lives in the ROOT context of the servlet container

> Liferay provides the PortalClassInvoker utility that can provide access to stat ic data that lives in the ROOT context

> For more information see blog entry on sharing data between port lets in dif ferent .WARs– http:/ / www.liferay.com/ web/ ngriff in/ blog/ - / blogs/ sharing- data-

between- port lets?_33_redirect= / web/ ngriff in/ blog

40

Server- Side IPC - ICEfaces Ajax Push

> ICEsoft pioneered Ajax Push, and made it part of the design of ICEfaces from the very beginning

– Sometimes referred to as “Comet” or “Reverse Ajax”

– ICEfaces webapps/ port lets can use Ajax Push to trigger server- init iated rendering

– In a portal environment, an Ajax Push re- renders the port lets on the same portal page and pushes the DOM- updates to the browser without full page reload

41

Server- Side IPC - ICEfaces Ajax Push

Portlet APort let B

Port let C

IncrementalDOM

Updates

User Event

IncrementalDOM

Updates

42

Server- Side IPC - ICEfaces Ajax Push

> ICEfaces Ajax Push is a compelling technique for IPC

> Benefits:– Easy to implement

– Rich UI experience for the end user

– Behaves like client- side IPC, but has none of the drawbacks!

– Other port lets on the page are undisturbed

– Not just inter- port let , but inter- port let , inter- user communicat ion!

43

Server- Side IPC - ICEfaces Ajax Push

> Demo of Ajax Push IPC

44

ICEfaces – Ajax Explained

45

ICEfaces - Ajax Push Explained

Poll> send a request to the server at

some interval.> response is “empty” if there is no

update.

Http Streaming> send a request and wait for

response.> send “endless” response in chunks.

Long Poll > send a request to the server and

wait for response.> indist inguishable from “slow”

server.

Client Server

response

response

request

request

server eventserver event

response

request

request

server event

response

response

request

server event

server event

46

Ajax Push - Servlet Thread Catastrophe

> Every client (browser window or tab) uses a blocked request

> Strangled by a thread for every blocking request (long polling)

> ICEfaces uses the asynchronous request processing API to release the thread from the long polling request

> Asynchronous request processing API is part of the Servlet 3.0 spec

> Currently ICEfaces detects the Container it is running with– Using Grizzly in Glassf ish, NIO in Tomcat, Cont inuat ion in Jetty

etc

47

AGENDA

> Introduct ion

> History

> Definit ions

> Rendering and Form Submission

> Ajax to the Rescue!

> Demo

> Behind the Scenes

> Wrap Up

> Quest ions

48

Wrap Up

> Adding Ajax to portal solut ions is a great benefit for the user experience

> Makes portals feeling rich, responsive and light- weight

> Ajax Push is a compelling technique for IPC

> Current technologies like Liferay and ICEfaces are great combinations to combine Ajax and Port lets

49

AGENDA

> Introduct ion

> History

> Definit ions

> Rendering and Form Submission

> Ajax to the Rescue!

> Demo

> Behind the Scenes

> Wrap Up

> Quest ions

50

Any Questions?

> We will be available at the mimacom booth after the talk!

> Links:– http:/ / jcp.org/ en/ jsr/ detail?id= 168 (Port let 1.0)

– http:/ / jcp.org/ en/ jsr/ detail?id= 286 (Port let 2.0)

– http:/ / jcp.org/ en/ jsr/ detail?id= 314 (JSF 2.0)

– http:/ / www.liferay.com

– http:/ / www.icefaces.org

– http:/ / www.edorasframework.org

Micha Kiener www.mimacom.ch

mimacom agmicha.kiener@mimacom.ch

Neil Griffin www.liferay.com

Liferay Inc. ngriff in@liferay.com