Resource serving usecases

There are 2 major usecases that a getResource implementation of WSRP v2 needs to support. More details below.

Usecase 1 : Inband Resource Serving

A JSR 286 portlet can implement the getResource method which allows it to serve content which are specific to the portlet context and state. Every resource that portlet wishes to serve gets translated to a resource URL by the portal, Invoking this resource URL results in the invocation of the portlets getResource() implementation.

In the case of WSRP, The WSRP Consumer is expected to invoke the getResource() method call on the WSRP Producer so that the request is propagated back to the portlet by the producer.

This is a in-band resource fetching mechanism where the WSRP producer indicates to the consumer that getResource is a viable method of fetching this resource. And the WSRP Consumer invokes the Markup Ports getResource operation on activation of a resource URL.

Usecase 2: Out-of-band Resource Serving

The out of band usecase is where the portlet (JSR 168 ot 286) portlet does not implement the getResource() operation instead generates URL's to resources that are fetched by the client directly from the webcontainer that the portlet is executing on.

This results in a resource serving mechanism where the resource is served without the context of the portlet/portal by the webcontainer. The portlet developer has no control over the resource generation. The WSRP V1 implementation/protocol relies on such mechanism by which it implements a proxy and forwards all such request from the browser to the WSRP producer and response back from producer to browser.

For WSRP v2, this is still a viable option to fetch resources if a portlet does not intent to serve resources.

Note: Resource Caching would be addressed as a Part of Caching usecases

-- Main.t_rajesh - 25 Feb 2008