Here is the list of features that WSRP 2.0  addresses or adds over WSRPv1 specification. We'll try to contrast and compare with the JSR286 specification in some places and see how these two specifications compliment each other. Here is the list of new stuffs that WSRP v2 brings to the table

• Consumer Managed Coordination
• Event distribution
• Three step protocol
• State distribution
• Navigational Params
• Session Properties
• Extensions
• Leasing (active, suspended, Expunged)
  
• Aggregation Related Enhancements
• Resource Serving
• Support for CC/PP Profiles and JSR188
  

Note :  Much of the details present in this note are derived from the drafts of both WSRP and 286 specification. Its possible that some of the features are dropped or changed etc in the final version of these specifications.

1.0 Consumer Managed Coordination:

    The WSRP 2.0 specification defines different ways by which a consumer can co-ordinate state across the portlets that it consumes namely Eventing, Navigational Params and Session Properties, some detailed description is as follows.

1.1 Eventing:

    JSR 286 describes a mechanism by which portlet could communicate with each other, some sort of inter portlet communication. Eventing in portlets is modeled as loosely coupled and brokered model and there is no guarantee on the event delivery or the order of event delivery.  WSRP compliments this by defining a mechanism by which a consumer could co-ordinated events across the portlet it consumes from different producers.

1.2 Consumer co-ordinated Eventing:

WSRP 2.0 adds eventing or a method by which consumer can co-ordinate events between portlets. By consumer co-ordinated it means that a consumer could consumer portlets from various location , the portlets could be from different producers or event local portlets. The Consumer managed co-ordination provides a option where consumer can distribute events across the portlets that it consumes.

For Eg : Consider a case where the consumer has two portlets one local portlet and one remote portlet,  The  consumer coordinated events mechanism allows the consumer to propagate events published by local portlet to remote portlets and vice versa.

Its also enables the consumer to co-ordinated events across two different producers from which it consumes events.  For Eg : Consider a case where the consumer has two portlets both of them are remote , one portlet is consumed from one producer and another portlet from another producer. Now the consumer can co-ordinated events across producers by mean consumer co-ordinated events.

The both the above cases dealt with how consumer co-ordinated events across portlets that it consumes, The consumer implementation will support the combination of the above i.e. a consumer can consumer portlets from three different locations  i.e.one local portlet , a remote portlet from producer1 and another remote portlet from producer2 and co-ordinates events across all these three portlets

WSRP 2.0 emphasizes on Consumer co-ordinated events.  Its worth while to note that even though that the WSRP v1 specification does not talk about eventing, Its up to the WSRP Producer implementation to propagate events across portlets that it offers, This event coordination would have been transparent to that Consumer and there are references to such co-ordination in the WSRP v2 specification as Producer mediated eventing.

The  following sequence diagram shows a event from a local portlet  being propagate to the remote portlets consumed from two different producers. 

1.3 Three-step Protocol:

WSRP v1 had defined a two step protocol for consumer to perform state change operation over the remote portlet i.e. for any execute action on the portlet the WSRP consumer is expected to call performBlockingInteraction() followed by a getMarkup().

The WSRP v2 specification expands this two step protocol to included eventing called the three step protocol, The sequence of operations for a WSRP Consumer to perform on a Producer are are performBlockingInteraction(), handleEvents() and followed by a getMarkup(). This allows the consumer to mediate or coordinate events across the portlets it consumes.

1.4 Event Wiring and Policy:

The eventing defined by WSRP v2 is optional and a consumer or producer may implement the event features, This loosely coupled brokered style of eventing allows consumer to enforce policies on how to handle with events or help consumers to wire these events.  For Eg : A consumer discovers that  a portlet offers event called zipcode and another portlet offers or consumes a event called postal code, The consumer could resolve these discrepancies and decide to map zipcode to postal code as both mean the same. Such mappings are referred to as wiring of events.

1.5 JSR 286  JAXB Event Binding:

    Any event that a portlet publishes caries a name, description, type  and a event payload.  The event payload should have binding that enables serialization of the event payload in JSR286 case this binding is JAXB binding. This compliments the WSRP case where the event can be serialized to XML and exchanged between the producer and consumer.

1.6 Producer Mediated Eventing:

Producer mediated eventing talks about a case where a consumer obtains or consumer two remote portlets from the same producer, Where any state change that has triggered in one portlet that is served by this producer has resulted  in  state change in the other portlet offered by the same producer.  This type of coordination or eventing is transparent from the consumer perspective and there is no way where a consumer consuming portlets from two different producers could co-ordinate or wire events.

1.7 Dynamic Events:

In JSR286 any event that a portlet intent to publish or fire is declared in the portlet.xml,  Lets refer to these kinds of events as static events, where the portlet upfront declares the events that it intent to publish or subscribe too.  However JSR286 provides a mechanism whereby a portlet could fire a event without having declared in the portlet.xml. In such instance the portlet container of the producer upfront would not know the event that this portlet publishes.  In WSRP terms the WSRP Consumer would not have obtained the event description esp type of this dynamic event from the producer.  Its not clear how the WSRP eventing should work in this case.

2.0 Navigational Params

The other co-ordination mechanism that is introduced in WSRP 2.0 is Navigational Params. The JSR 286 specifications calls it as shared render parameters, shared render parameters or navigational params can be thought as a bookmarkable state of the  portlet.  The shared render params works  like a event the only difference is that the state is encoded in the URL and shared across portlets. Shared render params are lightweight coordination mechanism where the coordination happens over the parameters encoded in the URL ( think of it as GET, while the eventing as POST)

In WSRP v1 Navigational state is consider as opaque i.e.. the consumer has no idea about the information that is encoded in the navigational state. The WSRP v2 specification provides a capability where a producer can declare a set of parameter in the navigational state as public hence making them shared render parameters or navigational parameters.

2.1 Bookmarkable Event:

For Eg : Consider a case where a portlet declares zipcode as a shared render parameter or navigational parameter ( in the portlet.xml for local portlets of as the part of service description in case of WSRP portlet). The portal or the consumer know the list of portlets that share this parameter . So if any of the portlet that changes this render parameter then the portal or the consumer delivered this encoded shared render parameter in the portals URL to all the portlet that has declared this parameter as shared render parameter.

Since shared render parameter are encoded in the URL, The enduser can bookmark this URL which has the shared render parameter encoded in it. So the next time when the user clicks on his bookmark , the portal or the consumer would have identified this parameter as a shared render parameter and distributed it as render parameter to all the portlets that consume it , hence making shared render parameter as a bookmarkable event.

3.0 Session Properties :

Another type of co-ordination mechanism, Its modeled around the Portlet Session. In this type of co-ordination the WSRP Producer upfront declares the session properties to the WSRP Consumer , The consumer is free to use the session properties for co-ordination of state across the portlets that it consumes.

The Consumer can supply a new value of Session Properties in the requests that it places to the WSRP Producer, and any response form the Producer can change remove or add new session properties that are already declared.

4.0 Leasing:

Leasing is a concept by which a resource is made available for certain period and then either renewed or released. WSRP v2 has added specific lifecycle to the WSRP enduring (non transient) resources that are involved in the interaction,  Any WSRP resource in v2 has the following states Active, Suspended and Expunged. Portlets ( cloned ) or Consumer registration are the two specific resources that follow the above states.

For eg : Lets consider a case where a consumer registers with the producer, the registration could potentially be under a lease i.e. the producer would offer a set of portlets to this consumer for a specified amount of time. The registration representation by the registration handle with the consumer would go through  the  above states  ice when registration was created it remains active for some time, upon expiration its in the suspended state where the consumer could optionally renew the lease and the final state where the registration is expunged or removed.

The same life cycle or leasing is followed for the portlets that are offered by the producer esp the ones which are cloned by the consumer, these portlets which are represented by a portlet handle follow the same lifecycle and move through above states.

5.0 CC/PP (Composite Capabilities/Preference Profiles):

CC/PP defines syntax for describing a device's capabilities and user preferences. CC/PP is used in portal context esp when a portal tries to deliver content to multiple devices (handheld devices, computers and mobile phones). The CC/PP provides information to content providers (portal/producer in our case) about the device such as screen size the mime types support etc., based on which content can be generates. There is also a JSR that is related to CC/PP described in JSR 188.

WSRP v2 add data structures to the WSRP datatypes to the ClientData structure which now describes the  CC/PP profile. This would enable a WSRP producer to generate content for multiple devices.

6.0 Import/Export Portlets:

The Portlet Management interface now supports additional operations that would allow a consumer to export  a portlet and then import it later from a another registration handle.  This addresses case where a consumer may need the current state of the portlet to be exported and later request the producer for import. In such events the producer returns a opaque handle of the exported portlets to the consumer, which it can use for later import operation.

7.0 Resource Serving:

The JSR 286 specifications adds additional operation called serveResource() which provides the ability to portlets to generate resources. Now a portlet could generate two types of URL's  a direct link to the resource (which means the  portlet has no control over the resource it serves) or a resource URL that points back to the portlet.

What serveResource() provides is control to the content developers where they can generate resources to a markup from a context, The best example of serveResource() is that a markup generated by a portlet may refer to a  .js (javascript file). In the older versions there is no option but to generate the whole javascript file along with markup if there are some state associated with it which the portlet understands or refer the javascript as a static resource. serveResource() give complete control to the developer where they can have complete control over the generates resource.

The JSR286 advocates the usage of serveResource() for read only AJAX requests i.e.  when a AJAX based portlet requires to obtain a resource from the portlet, It uses the standard XML HTTP Request (XHR) to make a request to the generated resource URL which is delegated to the portal container by the portal server hence providing complete control for content developers to generate resources.

The equivalent serveResource() mapping in WSRP is this resource serving concept. Earlier the WSRP Consumer is expected to implement a equivalent of a HTTP Proxy where it reads requests from the userAgent and tunnels the request to the webserver that host the WSRP Producer  and sends the response back esp on resources having to be static. Note: In this case the producer does not generate the resource rather the webserver that hosts the producer serves the resource and there in no way the producer could have control over the served resource.

This resource sharing concept adds methods within the WSRP protocol where the WSRP Consumer can request the WSRP Producer to serve a resource rather than acting as a HTTP proxy and the important stuff to note here is that resource serving happens within the WSRP protocol and does not go outside of it as in the previous cases.

8.0 Extensions:

The Extensions were provided for vendor to add vendor specific implementation over the WSRP protocol. The WSRP v2 specification tries to define a set of well known extensions , so that even though the extensions are vendor specific implementation there would be some interoperability with these well know/defined extensions.