OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrp-wsia] Minutes for 06 March 2003 Meeting

We may have a quite ugly way for JSR168 containers to do 90% of this today.
[This adds a third option to Mike's a) extend the existing proxy resource
design and b) augment/remove our proxy design with a new WSRP call, sorry.]

A JSR 168 container that needs to provide remote consumers access to web app
resources could just use a non-blocking action URL for such resources.

When writing the non-blocking action URL, the producer / JSR 168 container
encodes a special flag (JSR168-RESOURCE-URL) with a url value
(JSR168-RESOURCE-URL="http://...resource.xyz") on the URL (in
{wsrp-interactionState}). This has no impact on our protocol.

The producer side container logic that dispatches performInteraction
requests detects JSR168-RESOURCE-URL requests and serves up the referenced
resource directly (from the JSR168-RESOURCE-URL in returned MarkupContext).
Requests without this flag in the interaction state get forwarded to the
portlet as usual (JSR 168 has no non-blocking actions but other containers
could use this switch).

The question is how would the consumer handle results of such non-blocking
action URLs? It normally posts the action and calls getMarkup on all
portlets on the page. To change this behaviour, what we would need is a new
flag in the InteractionResponse that says "proxy the markup context back to
the user agent" (optional boolean proxyMarkupContext default is false). The
producer must also return a MarkupContext (with markup, mimeType etc) in the
InteractionResponse when the "proxyMarkupContext" flag it returns is true.
The consumer must then return the markup in MarkupContext as the document in
the http reply it generates [i.e. returns the resource instead of a portal
page or a redirect to the user agent.] Also, the current navigational state
must be retained as is, if proxyMarkupContext=true (not discarded because
the url had no {wsrp-navigationalState}).

This change (the proxyMarkupContext boolean) and associated semantics of not
generating a page but a http reply from the MarkupContext (now not an
optional optimization if proxyMarkupContext=true, plus the more complex nav
state rules) may still be more change than we can do for 1.0, but it seems
less problematic than a) and more re-use than b).

The new flag (with its associated semantics) could even be carried as an
extension for JSR 168 in 1.0. Also, it may help with portlets in iframes. 

Just like for resource URLs, security is an issue as the content seems to
come from the consumer.

This proposal may not fly (I hope for (b)) but I wanted to mention it before
today's conf call.


-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: 13 March 2003 00:04
To: wsrp-wsia@lists.oasis-open.org
Cc: Michael.Freedman@oracle.com
Subject: Re: [wsrp-wsia] Minutes for 06 March 2003 Meeting

JSR 168 requires that resources running in the same portlet application 
have access to the portlet application's session and user identity and 
"role" information.

For sessions, it is anticipated that the JSession cookie will commonly 
be used by JSR 168 applications to maintain the session.   It is 
reasonable to assume that resources, which commonly will have additional 
references back to the application will want to assume such cookie 
support is maintained.

For user information, at the last JSR 168 F2F we discussed how this user 
identity and "role" information can be provided by the portal vs. the 
underlying J2EE security system implying that there be an ability to 
send such information [basically the UserContext] to the portlet 
applications resources.


Subbu Allamaraju wrote:

> Michael Freedman wrote:
>> Rich,
>>   Are you suggesting we defer the discussion of updating the portlet 
>> API to support access/retrieval of resources or are you also 
>> suggesting we defer the discussion of modifying the existing proxy 
>> resource mechanism to allow user context/cookies to be passed when 
>> the resource is invoked?  I hope its not the later as JSR 168 needs 
>> such function -- and asking that the information be carried on the 
>> URL itself suffers not only from the privacy/exposure issue but also 
>> from the long URL issue.
> Could you clarify why this is a JSR168 requirement?
> Subbu
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]