Re: [wsrp-interop] where to transport cookies returned by portlets (JSR286)

[Rich Thompson <richt2@us.ibm.com>]

I see there being two distinct cookie
issues here:

1. Cookies which flow between the Producer
and Consumer:
     WSRP v1 attempted
to say that Consumers should follow the std cookie rules and return any
cookies set on future invocations within the Markup interface. The std
rules allow for these not being set and restrict when they can be returned.
The WSRP addition was noting that these cookies are unlikely to make it
out to the client (i.e. their usefulness is in returning state to the Producer
when it already expects that state to appear in cookies)

2. Attributes (e.g. cookies) which are
available at the client:
     WSRP v2 is attempting
to add having such state flow out to the client (e.g. could be accessed
by client-side code). The clientAttributes fields were added to carry such
values. Since there is no definition of how these attributes are accessed
on the client, I suspect most people will expect them to appear as cookies
(and they won't understand the potential issues involved in them appearing
that way).

I think the first is most useful for
state the Producer stack wants to set and reaccess later. If the Portlet
is setting state, it likely wants to both access it on the client and receive
it back later. While there are many ways the Portlet could accomplish this,
I think any cookie-oriented means should leverage clientAttributes from
the second case above.


Additional protocol issue: Setting just
clientAttributes in the MarkupContext returned from pbia:
 - I think Stefan had originally
raised this. It may seem odd, but I am fine with the optimization not actually
carrying any markup. I think if we agree on that, it should be that the
returned clientAttributes immediately update the set being supplied to
the Portlet as well as eventually flowing back to the client.

Rich

From:	Richard Jacob <richard.jacob@de.ibm.com>
To:	wsrp-interop@lists.oasis-open.org
Date:	12/11/2007 12:58 PM
Subject:	Re: [wsrp-interop] where to transport cookies returned by portlets (JSR286)

---

I see the following advantages/drawbacks:

choice 1.
Seems to be cumbersome and more complicated.
Introduces need to interpret mimeResponse in updateResponse different -
may
contain no markup, just cookie headers.
Seperates portlet interaction (including headers/cookies) to the WSRP
protocol level, does not mix transport level and WSRP protocol level.
Enables transport-agnostic means to transfer portlet cookies, i.e. WSRP
over something other than HTTP can still act as a bridge.
Consumers need to manage cookies on two levels: transport and WSRP, may
be
difficult e.g. when distributing cookies to other resources.

choice 2.
Seems easy to handle as long as applications are able to set cookies in
their WS stack.
Ties the portlet cookies explicitly to the HTTP binding - cookies however
are a HTTP state management means.
There seems no break to JSR286 spec which says that cookies SHOULD be
transferred between action and render phase to portlets - a MUST would
not
be fulfillable by non-HTTP transport bindings.

Proposed resolution:
Tie portlet cookies to the transport level as a plain HTTP state mechanism.
Clarify that cookies can be set at any time by the producer and consumers
should return them to any operation within the markup portType.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept. 2289, WebSphere Portal Server Development 1
WSRP Team Lead
WSRP Architecture & Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Richard Jacob/Germany/IBM@IBMDE          
                     
                     
                     
                     
                |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |wsrp-interop@lists.oasis-open.org          
                     
                     
                     
                     
              |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |12/11/2007 06:35 PM              
                     
                     
                     
                     
                     
  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |[wsrp-interop] where to transport cookies returned by portlets
(JSR286)                  
                     
                     
            |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|






With the (re-) introduction of setCookie() to the actionResponse in JSR286
the question arose where portlet cookies should be transferred between
the
producer and consumer.

We basically have identified two distinct non-interoperable choices:
1. use MimeResponse.clientAttributes to return cookies and
clientData.clientAttributes to send cookies back to producer
This treats cookies as any other headers and puts their management to the
application level. Here the application needs to deal with the creation
of
set-cookie & cookie headers and stuff them into the WSRP structures.
2. use HTTP cookies on the transport level to return and receive cookies
Producer & Consumer rely on the WS-stack transport level HTTP binding
to
send cookies back and forth

The following questions arose during the discussion
1. are producers allowed to return cookies as a result of any markup
portType operation or just on initCookie()?
The spec seems ambigeous here:
Section 5.5. says: "In general, the Producer completely manages its
own
environment, including items such as the initialization of cookies when
using the HTTP transport."
Section 5.7 says: "If a Producer indicates that it uses cookies, the
Consumer MUST ensure that any cookies the Producer sets are available on
all invocations within the Markup interface. Another implication of the
Producer indicating it uses cookies is that the Consumer should be aware
of
the issues involved in protocol transitions [...]"
This seems to refer to initCookie meta-data in the service description
and
only to that.
If  cookies are allowed to be set at any time, portlet cookies could
be
returned as transport level cookies with pbia().

2. can MimeResponse.clientAttributes be used to return cookies in a pbia()?
Typically the MarkupContext (MimeResponse) structure in UpdateResponse
returned by pbia() is ment to hold markup returned as an optimization to
avoid the seperate render phase.
Since JSR286 portlets can return cookies in pbia() it seems awkward to
return a MarkupContext with just clientAttributes in it.

3. can applications on top of the WS stack set cookies "manually"
at
runtime
Some web service stacks may hide transport level details from the
application layer. WSRP producer implementations may not be able to set
transport level cookies.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept. 2289, WebSphere Portal Server Development 1
WSRP Team Lead
WSRP Architecture & Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php