[wsrp-interfaces] Use case for GetResource operation for 2.0 Markup portType

[Andre Kramer <andre.kramer@eu.citrix.com>]

Title: [wsrp-interfaces] Use case for GetResource operation for 2.0 Markup portType

For WSRP 1.0 by default bindings, portlet markup is obtained via the getMarkup SOAP/WSDL operation. Portlet resources however, are served using normal HTTP protocol . No other bindings for resources (SOAP or other) are possible. This fails to address the following use cases:

A firewall admin agrees to a portlet / producer being set up in her DMZ as the developer states that WSRP uses SOAP. So the admin sets up a XML/SOAP firewall (application level security interceptor) to filter and forward the SOAP traffic. This use case is supported by the WS-Addressing (or WS-Routing) Web Service specifications (and more minimally by SOAP actor and message headers). However, the developer forgot that his portlet includes gifs and some dynamic generated HTML content that for WSRP legacy reasons must be served over HTTP! The firewall admin reacts badly when notified of this fact and refuses to open such a general "port 80 or (worse) port 443" firewall hole. The developer hears that WSRP 2.0 will address this use case so waits for the next version of our spec: deadlock.

A WSRP developer wishes to write a client to consumer WSRP. His Web Service tools quickly allow the markup factor to be imported but he notes that he will also have to make use of raw HTTP when portlets produce URLs for (HTTP/HTTPS) portlet resources. He swallows hard and codes but fails to get the WSRP demo portlets to work. He did not know that HTTP cookies have to be shared between the SOAP and plain HTTP stack. Worse, his Web Service guru may explain that the company recommended Web Service stack does not expose cookies in its API (and uses its own HTTP client).

Rather than revive the previous proposal for getResource it may be best to start with the 1.0 getMarkup operation signature and:

- clone this as defined for 1.0
- rename it to getContent
- add a "contentURL" parameter (type ID 5.1.4)

and add a new wsrp-urlType "wsrp-content" similar to wsrp-resource & wsrp-render, where wsrp-url is mapped to the above "contentURL" parameter (and wsrp-requiresrewrite is used as is). WSRP-content would be allowed to also use all of the wsrp-render tokens.

add a contentTemplate which combines renderTemplate and resourceTemplate.

This would give us a generic means to ask a portlet to provide "content" that can be imbedded in portlet markup, just like (HTTP) resources can be in 1.0. A new "content" markup factor operation may be cleaner than overloading wsrp "resources" with other protocol bindings (SOAP or other Web Service transports). Having a superset of the "getMarkup" signature would allow a simple implementation re-use.

This proposal may be slightly more general than what we would need to simply allow SOAP transport of resources but would be just building on what we already have and this would allow a Portlet to be broken up into multiple markup "pieces" that can be referenced from portlet markup fragments. Consumers would need to create links in HTML very much like they do today for render URLs but would have to be able to call a SOAP operation (nearly identical to getMarkup) when the link is requested.

regards,
Andre