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

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 <>

To:


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:        |

|------------>

  >--------------------------------------------------------------------------------------------------------------------------------------------------|

  |          
                     
                     
                     
                     
              |

  >--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>

| 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