Portal Standards Richard Jacob, Portal Standards Lead

Agenda Portal Standards 2.0 Major New Concepts Coordination Mechanisms Eventing Public Parameters Resource Serving AJAX use cases WebSphere Portal - Standards support

Portal Standards 2.0

Major New Concepts

Coordination Mechanisms

Eventing

Public Parameters

Resource Serving

AJAX use cases

WebSphere Portal - Standards support

Portal Standards 2.0 JSR 286 & WSRP 2.0

Why 2.0? 1.0 design goal Define how independent web apps (portlets) may be aggregated onto a single page Portlet communication via common session For portlets bundled into same web application Applies to WSRP 1.0 & Java Portlet API 1.0 (JSR168) 2.0 design goal Define how portlets may be coordinated and react as a whole Portlet communication cross boundaries Cross web application Cross Producers Applies to WSRP 2.0 & Java Portlet API 2.0 (JSR286) Both standards are closely aligned Concepts match JSR portlets can easily exposed as WSRP remote portlets

1.0 design goal

Define how independent web apps (portlets) may be aggregated onto a single page

Portlet communication via common session

For portlets bundled into same web application

Applies to WSRP 1.0 & Java Portlet API 1.0 (JSR168)

2.0 design goal

Define how portlets may be coordinated and react as a whole

Portlet communication cross boundaries

Cross web application

Cross Producers

Applies to WSRP 2.0 & Java Portlet API 2.0 (JSR286)

Both standards are closely aligned

Concepts match

JSR portlets can easily exposed as WSRP remote portlets

Standard Roadmaps WSRP October 2007: public review December 2007: approve committee specification February 2008: submit final committee draft to OASIS for standardization Final review and approval by OASIS March 2008: WSRP 2.0 approved OASIS standard JSR286 July 2007: 1 st public draft December 2007: final public draft March 2008: Spec approved in JCP

WSRP

October 2007: public review

December 2007: approve committee specification

February 2008: submit final committee draft to OASIS for standardization

Final review and approval by OASIS

March 2008: WSRP 2.0 approved OASIS standard

JSR286

July 2007: 1 st public draft

December 2007: final public draft

March 2008: Spec approved in JCP

Standards 2.0 – Major Features Common New Features: Consumer mediated coordination Eventing  notification based coordination Public Navigational Parameters  shared navigational state Resource serving in protocol / API Support for AJAX patterns CC/PP support … WSRP 2.0 Leasing Portlet factories JSR286 Better support for Web Frameworks like JSF and Struts Alignment with Web Service for Remote Portlets (WSRP) 2.0

Common New Features:

Consumer mediated coordination

Eventing  notification based coordination

Public Navigational Parameters  shared navigational state

Resource serving in protocol / API

Support for AJAX patterns

CC/PP support

…

WSRP 2.0

Leasing

Portlet factories

JSR286

Better support for Web Frameworks like JSF and Struts

Alignment with Web Service for Remote Portlets (WSRP) 2.0

Eventing – An Example Portlets react on events Event name Event payload (Remote) Portlets participate in event distribution Events can be distributed between local & remote portlets Remote systems can react in a distributed and cooperative manner

Portlets react on events

Event name

Event payload

(Remote) Portlets participate in event distribution

Events can be distributed between local & remote portlets

Remote systems can react in a distributed and cooperative manner

Eventing – Loosely Coupled Model Enables Portlets to generate and consume events Semantic meaning through qualified event name Schema described data in the event payload Auto-wiring possible Declarative wiring Portlets describe the events they eventually emit Portlets describe the events they are interested in Flexible wiring, possible at deployment/page placement/integration or runtime Three step protocol performAction  handleEvents  getMarkup Consumer/Portal acts as mediator Events gathered in action and event distribution phases Consumer/Portal can also generate/fire events Stayed in the synchronous model Portlets can only emit events based on user interaction or other events received

Enables Portlets to generate and consume events

Semantic meaning through qualified event name

Schema described data in the event payload

Auto-wiring possible

Declarative wiring

Portlets describe the events they eventually emit

Portlets describe the events they are interested in

Flexible wiring, possible at deployment/page placement/integration or runtime

Three step protocol

performAction  handleEvents  getMarkup

Consumer/Portal acts as mediator

Events gathered in action and event distribution phases

Consumer/Portal can also generate/fire events

Stayed in the synchronous model

Portlets can only emit events based on user interaction or other events received

JSR 286 – Eventing Declarative Definitions of Portlet Events In the Portlet Deployment Descriptor (portlet.xml) Portlet API extended to additional processEvent() method Portlets implement this to receive events brokered to them Portlet API extended to allow portlets to fire events As a result of processAction() or processEvent() Event names Are defined as QNames in the DD May have additional aliases for automatic event mapping Event Types Defined in the portlet deployment descriptor via the Java class name Can be complex, but must be Java and JAXB serializable

Declarative Definitions of Portlet Events

In the Portlet Deployment Descriptor (portlet.xml)

Portlet API extended to additional processEvent() method

Portlets implement this to receive events brokered to them

Portlet API extended to allow portlets to fire events

As a result of processAction() or processEvent()

Event names

Are defined as QNames in the DD

May have additional aliases for automatic event mapping

Event Types

Defined in the portlet deployment descriptor via the Java class name

Can be complex, but must be Java and JAXB serializable

JSR286 – Event Flow

WSRP 2.0 – Declarative Event Wiring ServiceDesc Portlet 3 Events … ServiceDesc Portlet 1 Events … Portlet 2 Events … getServiceDescription Event Wiring wire* wire* *Events can be mapped: - automatically by event Qname and payload type - manually with wiring tool (incl. payload transformation) 1 1 2 2 Producer A Portlet 1 Event out : selected Payload: itemNo Portlet 2 Event in : addToCart selected Payload: itemNo Producer B Portlet 3 Event in : addToCart selected Payload: itemNo Consumer Portlet 1 Event out : selected Payload: itemNo Portlet 2 Event in : addToCart selected Payload: itemNo Portlet 3 Event in : addToCart selected Payload: itemNo

WSRP 2.0 – Eventing Interaction Flow Event Phase as a new element in the protocol flow Consumer distributes events to portlets which match event wire Events can be fired to portlets in parallel WSRP optimizations Events can be transferred as a bulk operation handleEvents() can return portlet markup Any type of state change interaction Producer Click! performBlockingInteraction markup fragment 1 2 handleEvents 3 4 getMarkup 5 6 Portlet Portlet Portlet Consumer this is a link this is a link

Event Phase as a new element in the protocol flow

Consumer distributes events to portlets which match event wire

Events can be fired to portlets in parallel

WSRP optimizations

Events can be transferred as a bulk operation

handleEvents() can return portlet markup

Public Parameters – An Example Portlets automatically render in context Portlets automatically pick up current context when added to the page. e.g. city when the weather Portlet is added. Context is propagated to all pages. No wiring needed Remote Portlets participate in Context Easily consume Partner Services (WSRP 2.0) E.g. weather service Portlets share context Without locally deploying any partner Portlets

Portlets automatically render in context

Portlets automatically pick up current context when added to the page.

e.g. city when the weather Portlet is added.

Context is propagated to all pages.

No wiring needed

Remote Portlets participate in Context

Easily consume Partner Services (WSRP 2.0)

E.g. weather service

Portlets share context

Without locally deploying any partner Portlets

Public Parameters Extension to the portlet navigational state, managed by Consumer Can be thought of as Consumer managed and shared portion of navigational state Enables portlets to react in a coordinated manner Declarative “subscription” Portlets describe in metadata the navigation parameters they want to receive Portlets allowed to “write” navigation parameters on URL invocation on action/event response Any Consumer/Portal constituent can also write the navigation parameters

Extension to the portlet navigational state, managed by Consumer

Can be thought of as Consumer managed and shared portion of navigational state

Enables portlets to react in a coordinated manner

Declarative “subscription”

Portlets describe in metadata the navigation parameters they want to receive

Portlets allowed to “write” navigation parameters

on URL invocation

on action/event response

Any Consumer/Portal constituent can also write the navigation parameters

JSR 286 – Public Parameters Re-use existing render parameter APIs Allows to even enable JSR 168 portlets to use public render params by just giving changing the deployment descriptor to JSR 286 Public Parameter Declaration Defined in the portlet.xml which render parameters are public Has an simple ID string that the portlet can use in the code Provides a QName and optional alias names for wiring the parameter Public Parameter Retrieval Just use the standard PortletRequest interface to obtain those parameters

Re-use existing render parameter APIs

Allows to even enable JSR 168 portlets to use public render params

by just giving changing the deployment descriptor to JSR 286

Public Parameter Declaration

Defined in the portlet.xml which render parameters are public

Has an simple ID string that the portlet can use in the code

Provides a QName and optional alias names for wiring the parameter

Public Parameter Retrieval

Just use the standard PortletRequest interface to obtain those parameters

WSRP 2.0 – Public Parameter Declaration ServiceDesc Portlet 3 Params … ServiceDesc Portlet 1 Params … Portlet 2 Params … getServiceDescription Portlets declare the Public navigational Parameters they are interested in Consumers distribute these accordingly 1 1 2 2 Producer A Portlet 1 Param: z1 Qname: zipCode Portlet 2 Param: SC1 Qname: sports Param: myzip Qname: zipCode Producer B Portlet 3 Param: zCode Qname: zipCode Consumer

Portlets declare the Public navigational Parameters they are interested in

Consumers distribute these accordingly

WSRP 2.0 – Public Parameter Distribution Consumer Page Context: zipcode=73760 User profile sportsCat: baseball z1=73760 zCode=73760 SC1=baseball myzip=73760 Producer A Portlet 1 Param: zipCode Portlet 2 Param: sports zipCode Producer B Portlet 3 Param: zipCode Portlet 1 Portlet 3 Portlet 2

Eventing vs. Public Parameters Different HTTP semantics Public parameters: GET semantic render parameters can be changed via render links and define view state Events: POST semantics part of the action phase, allowed to change persistent state Advantages of using public parameters Less processing overhead, no action phase required Parallel rendering of portlets possible Bookmarkablity Support of browser back/forward button Caching in the browser Limitations when using public render parameters Payload limited to string data No active notification that something has changed Public render parameters are typically encoded in the URL Browser URL length limitations might become an issue when used excessively

Different HTTP semantics

Public parameters: GET semantic

render parameters can be changed via render links and define view state

Events: POST semantics

part of the action phase, allowed to change persistent state

Advantages of using public parameters

Less processing overhead, no action phase required

Parallel rendering of portlets possible

Bookmarkablity

Support of browser back/forward button

Caching in the browser

Limitations when using public render parameters

Payload limited to string data

No active notification that something has changed

Public render parameters are typically encoded in the URL

Browser URL length limitations might become an issue when used excessively

Resource Serving Producer/portlet acts as proxy to resources Requests for resources (e.g. PDF documents) addressed within portlet API & WSRP protocol WSRP 1.0 / JSR168 required out-of-band connection (e.g. HTTP to servlet) Advantages Consumers do not need full access to resources referenced by portlets Resources do not have to be directly addressable by URLs Producers / portlets can implement any back-end protocol to serve resources (e.g. from CMS) Context information is passed directly over the API / protocol, i.e. Same session User context, Authentication, etc.  resources become portal context aware AJAX use cases are now better supported via the portlet

Producer/portlet acts as proxy to resources

Requests for resources (e.g. PDF documents) addressed within portlet API & WSRP protocol

WSRP 1.0 / JSR168 required out-of-band connection (e.g. HTTP to servlet)

Advantages

Consumers do not need full access to resources referenced by portlets

Resources do not have to be directly addressable by URLs

Producers / portlets can implement any back-end protocol to serve resources (e.g. from CMS)

Context information is passed directly over the API / protocol, i.e.

Same session

User context, Authentication, etc.

 resources become portal context aware

AJAX use cases are now better supported via the portlet

JSR 286 – Resource Serving New lifecycle method “serveResource” Addresses the portlet directly Portlet responsible to dispatch or write resource to output stream In portal context Navigational state, current portlet mode, window state, session, preferences..) New ResourceURLs trigger “serveResource” invocation Resource addressing via resourceID Set as optional ResourceURL parameter Allows complete protocol abstraction Resources can be served from virtually anywhere and brought to the browser AJAX fragments can be served as resources

New lifecycle method “serveResource”

Addresses the portlet directly

Portlet responsible to dispatch or write resource to output stream

In portal context

Navigational state, current portlet mode, window state, session, preferences..)

New ResourceURLs trigger “serveResource” invocation

Resource addressing via resourceID

Set as optional ResourceURL parameter

Allows complete protocol abstraction

Resources can be served from virtually anywhere and brought to the browser

AJAX fragments can be served as resources

WSRP 2.0 – Resource Serving GetResouce() supports Idempotent operations to resources (can mimic HTTP GET) Non-idempotent operations (can mimic HTTP POST, PUT, DELETE) State changes allowed Resources addressed by resourceID HTTP WSRP Whatever you might think of GetResource() resouceID Contexts Resource URL Pick up resource Consumer Producer Browser Portlet 1

GetResouce() supports

Idempotent operations to resources (can mimic HTTP GET)

Non-idempotent operations (can mimic HTTP POST, PUT, DELETE)

State changes allowed

Resources addressed by resourceID

JSR286 – Portlets Using Ajax Portlet owned AJAX calls Full access to the portlet state Via XmlHttpRequest and ResourceURLs Allowed to change portlet preferences and portlet-scoped session attributes Functionality restricted: No state changes for navigational state (portlet mode, window state, render parameters) No support for events Coordinated between portal and portlet Not covered by JSR 286, but vendor specific solutions exist Needs to include a client side library that the portlet can leverage E.g. for allowing the portal to update the URLs on the page if the portlet sets new render parameters OpenAjax is working on a standardized solution for the future Defining a generic client side gadget programming model

Portlet owned AJAX calls

Full access to the portlet state

Via XmlHttpRequest and ResourceURLs

Allowed to change portlet preferences and portlet-scoped session attributes

Functionality restricted:

No state changes for navigational state (portlet mode, window state, render parameters)

No support for events

Coordinated between portal and portlet

Not covered by JSR 286, but vendor specific solutions exist

Needs to include a client side library that the portlet can leverage

E.g. for allowing the portal to update the URLs on the page if the portlet sets new render parameters

OpenAjax is working on a standardized solution for the future

Defining a generic client side gadget programming model

JSR286 Resource Serving & AJAX Use Case AJAX-enabled portlet reloads affected content using a resource request JavaScript call points to the Portal Application Portal Application dispatches resource serving call to portlet Portal WAR Portal Server Servlet Browser Click XML /HTML XHR(ResourceURL) Portlet WAR WAR Portlet WAR WAR Portlet WAR WAR Portlet WAR JS Data

AJAX-enabled portlet reloads affected content using a resource request

JavaScript call points to the Portal Application

Portal Application dispatches resource serving call to portlet

… any many more features JSR286 Writing Cookies and headers Portlet filters Extended request dispatcher capabilities Enhanced Caching Validation based caching Shared cache entries Tag library extensions Portlet managed modes JAVA5 exploitation: annotations, generices, etc. WSRP 2.0 Leasing Import/Export Custom portlet modes Shared cache scope Extensions framework CSS extensions

JSR286

Writing Cookies and headers

Portlet filters

Extended request dispatcher capabilities

Enhanced Caching

Validation based caching

Shared cache entries

Tag library extensions

Portlet managed modes

JAVA5 exploitation: annotations, generices, etc.

WSRP 2.0

Leasing

Import/Export

Custom portlet modes

Shared cache scope

Extensions framework

CSS extensions

WebSphere Portal – Standards Support

JSR 286 & WSRP 2.0 – Overview Full JSR 286 & WSRP 2.0 support All mandatory spec items implemented Focus on coordination mechanisms Portlet Container Passes JSR 286 & JSR 168 TCK Supports IBM API, JSR 168 & JSR286 portlets Integrated with Property Broker Portlet Filter support WSRP Consumer & Producer WebSphere Portal can act as WSRP Producer & Consumer Passes JSR 168 & JSR286 TCK runs over WSRP Proven interoperability in interop tests with other vendors

Full JSR 286 & WSRP 2.0 support

All mandatory spec items implemented

Focus on coordination mechanisms

Portlet Container

Passes JSR 286 & JSR 168 TCK

Supports IBM API, JSR 168 & JSR286 portlets

Integrated with Property Broker

Portlet Filter support

WSRP Consumer & Producer

WebSphere Portal can act as WSRP Producer & Consumer

Passes JSR 168 & JSR286 TCK runs over WSRP

Proven interoperability in interop tests with other vendors

Standards Support – Coordination Eventing Events can be exchanged between JSR168, JSR286 and remote portlets Property Broker integration, C2A support JSR 168 target actions, JSR286 & WSRP 2.0 events available in C2A selections Exchange events cross Producer, cross vendor boundaries Support wiring for WSRP 2.0, JSR286 & JSR168 portlets  enables rich set of federated applications consisting of JSR168, JSR286 and WSRP 2.0 remote portlets Public Navigational Parameters Full JSR 286 & WSRP 2.0 support Allow local JSR 286 and remote WSRP 2.0 portlets to share common navigational state Manage page buckets of navigational context  page sensitive portlet rendering

Eventing

Events can be exchanged between JSR168, JSR286 and remote portlets

Property Broker integration, C2A support

JSR 168 target actions, JSR286 & WSRP 2.0 events available in C2A selections

Exchange events cross Producer, cross vendor boundaries

Support wiring for WSRP 2.0, JSR286 & JSR168 portlets

 enables rich set of federated applications consisting of JSR168, JSR286 and WSRP 2.0 remote portlets

Public Navigational Parameters

Full JSR 286 & WSRP 2.0 support

Allow local JSR 286 and remote WSRP 2.0 portlets to share common navigational state

Manage page buckets of navigational context

 page sensitive portlet rendering

WSRP 2.0 Support in WebSphere Portal WebSphere Portal Integrate V1 Producers Integrate V2 Producers Automatic protocol version negotiation for Producers supporting both protocol versions WebSphere Portal expose itself As V1 Producer IBM API portlets JSR 168 portlets As V2 Producer IBM API portlets JSR 168 portlets JSR 286 portlets WSRP 1.0 WSRP 2.0 Portal Consumer WSRP 1.0 WP 5+ Consumer WSRP 2.0 Misc. Consumer WSRP 1.0 WSRP 2.0 Portal Producer WSRP 1.0 WP 5+ Producer WSRP 2.0 Misc. Producer

WebSphere Portal

Integrate V1 Producers

Integrate V2 Producers

Automatic protocol version negotiation for Producers supporting both protocol versions

WebSphere Portal expose itself

As V1 Producer

IBM API portlets

JSR 168 portlets

As V2 Producer

IBM API portlets

JSR 168 portlets

JSR 286 portlets

Federated Portals – Service Federation (WSRP) Vertical (Services) Portals Enterprise Portal WebServices for Remote Portlets (WSRP) Other Portals BEA, SAP, Sharepoint, Oracle, ... WebSphere Portal 5.0, 5.1, 6.0 WebSphere Application Server 6.1 WebSphere Portal 6.1, NEW: JSR286 & WSRP 2.0 Composite Applications build from remote components. publish Deploy services in vertical sites Consume these services in Enterprise Portal (WSRP) Build coordinated composite applications consisting of standard based local and remote and services WSRR can be used as repository of WSRP providers. WebSphere Portal WebSphere Application Server WebSphere Portal WebSphere Portal

WSRP 2.0 Support – Resource Serving In-band (WSRP) JSR286 Portlets can encode resourceIDs in resource URLs Portlets can serve content from virtually any source Out-of-band (HTTP) Maintain and enhance support for Resource Proxy URL protection Easy SSL repertoire management integrated with WebSphere Application Server State management Advanced Cookie Management Enable portlets and resoures to set cookies & receive cookies Coordinate cookie distribution  better integration with portlet applications and existing web applications Share session between remote portlets & remote servlets Support AJAX use cases: servlet serves AJAX request, wants access to shared state

In-band (WSRP)

JSR286 Portlets can encode resourceIDs in resource URLs

Portlets can serve content from virtually any source

Out-of-band (HTTP)

Maintain and enhance support for Resource Proxy

URL protection

Easy SSL repertoire management integrated with WebSphere Application Server

State management

Advanced Cookie Management

Enable portlets and resoures to set cookies & receive cookies

Coordinate cookie distribution

 better integration with portlet applications and existing web applications

Share session between remote portlets & remote servlets

Support AJAX use cases: servlet serves AJAX request, wants access to shared state

WSRP 2.0 Support – WS-Security Consumer administrator can assign WS-Security profile to remote Producer Via portal admin UI WebSphere Portal comes with pre-defined set to choose from Will also contain profiles the OASIS WSRP TC agreed on for identity assertion Customers can create own profiles using WAS tooling Producer A Producer B Producer Configuration Profile Selector Effective WSS Profile Consumer Profiles Profile (1) identity assertion: LTPA Profile (2) identity assertion: signed UNT Secured Messages Profile 2 Secured Messages Profile 1

Consumer administrator can assign WS-Security profile to remote Producer

Via portal admin UI

WebSphere Portal comes with pre-defined set to choose from

Will also contain profiles the OASIS WSRP TC agreed on for identity assertion

Customers can create own profiles using WAS tooling

Thank You! Questions? [email_address]