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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


Subject: Re: [wsrp] redirectURL allowed in handleEvents response?



Thanks Mike and Subbu for these summaries. I hope we can avoid a rehash of the discussion that led to these summaries, but do encourage people ask clarifying questions, particularly those who were not a part of the discussion within the Interfaces SC.

Rich



Michael Freedman <michael.freedman@oracle.com>

08/17/05 07:59 PM

To
wsrp@lists.oasis-open.org
cc
Subject
Re: [wsrp] redirectURL allowed in handleEvents response?





Subbu's primary argument seems to boil down to recognizing the similarities between interactions as represented by PerformBlockingInteraction and event processing [HandleEvents].  He has observed that the only distinguishing feature between the responses of the PBI and HE is that HE doesn't allow you to return a redirect.  He doesn't see reasons for this discrepency and though providing no specific use cases worries that by not correcting it we will later regret this decision as when real world needs are thwarted.

I however do see reasons in 2.0 to distinguish between these two calls and further believe that even when we leave the specification as it is, that all potential redirect usages are already expressible in the specification.   Here is my point of view:

Reasons for not adding redirect to HandleEvents/reasons PBI is different then HE:

1.        Incorrectness (1):
My primary reason for leaving redirects out of HandleEvents is that unlike PBI, its semantics rely on consumer policy/choice which leads to incorrectness.  Because PBI is a synchronous operation we have very tight redirect semantics from the perspective of the producer.  A redirect replaces the normal interaction response and directs the consumer to flow to an external resource [not WSRP managed] on behalf of all consumer entities scoped to this request.  In the simple case [Portal] this means the producer tells the consumer to redirect [the client] to an URL/site that is not relative to the consumer.  

The key in the situation above is that returning a redirect is mutually exclusive from returning an [Interaction] UpdateResponse.  Because of the mutual exclusion the producer has a right to expect the redirect will occur as otherwise it is running in an indeterminate state, as its unable to reflect updated state in its response. This leads us to clear and simple requirements for the consumer: honor the redirect or consider it an error condition.

HandleEvents however isn't a synchronous operation.  This means that unless the producer is running in a controlled environment in which both the consumer and producer are designed to operate there are many possible situations for which we must provide well defined semantics if the producer is going to ensure it doesn't get into an indeterminate state without it being considered an error condition.  Unfortunately Subbu's/the current proposal doesn't address this choosing instead to leave the barn door open saying redirect support from a HandleEvent is entirely a consumer policy decision including such policies as not supporting the redirect in any/all situations when returned from HandleEvent.  This leaves the door wide open for the consumer to operate the producer normally when its in an indeterminate state.  This is incorrect from a specification point of view.  I.e. correct -- both sides reflect that a possibility of leaving the portlet in an indeterminate state is an error condition; incorrect -- the consumer is allowed/encouraged to operate the portlet normally when it is in an indeterminate state.

2.        Not Interoperable:  
For purposes of this point, I define interoperablity to mean that from the end users perspective the portlet behaves in a similar manner when run in different consumers.  Clearly this is not the case given we want to leave the handling of redirects from a HandleEvents call as a consumer policy decision*.  

One might ask however why this is distinguished from the generic interoperable question that allows consumers the option to support events in the first place?  The difference is that redirects always define an operation that impacts the users view of that portlet while events [generally] do not.  Yes, other portlets in context are impacted if portlet raising the event runs in a consumer that chooses not to distribute it but this portlet is not [Note: this argument when extended further says that a event chain greater then 1 cycle is also often not interoperable].

3.        Supports bad UI
Remember, that unless the portlet is running in a controlled environment in which the consumer and other interested portlets agree on supporting a specific form of coordination via events, the portlet has no notion of how the event it raises will be used and even who might receive it.  In such a loosley coupled environment won't many end users be surprised when performing an action in a portlet results in them being redirected to some foreign location when instructed so by another portlet on the page that has happened to handle an event raised by this portlet from its action?  This in part has led us to see the need for allowing consumer policy to direct the handling of such redirects -- so that they can controll/enforce their notion of what good UI is based on how loosely or tightly coupled the coordination is [as only they know].

4.        Our future interest in expanding/redefining redirect semantics is hampered by adding it to HandleEvents.
Redirect is currently a very limited function.  It is mutally exclusive from a regular response hence prevents consumers applying policies without having to put the portlet into an indeterminate state.  It only allows you to express a redirect to a non-consumer managed resource.  This greater limits an ability to transfer state between the redirecter and redirectee.  Each of these are strong/valid reasons for us to redefine/extend redirect support [in the future].  It will be much easier to do this [and give us the most flexibility] if only the current limited/tight semantics of PBI are expressed in 2.0.

5.        Cooperating portlets/consumers can model redirect behavior in HandleEvents without us adding it to the response.
Many of the above arguments have focused on a loosely coupled system where a portlet has no expectations on either the consumer environment it is running and/or the outcome that occurs when it raises an event.  There are however many more tightly coupled coordination situations where a set of portlets are designed to work together in a specific way and a consumer is instructed on how it is expected to behave/configure the portlets so the desired result is delivered.  In such an environment its reasonable to suggest that a redirect is one valid outcome of event processing.  However because of this tight coupling I contend its very reasonable to express the redirect via an event itself vs. directly in the protocol as this not only effectively works for the above situation but also easily allows the raising portlet to handle the case the coordination is not properly set up/supported and the redirect doesn't happen.  I.e. it can return information that leaves it in a determinate state if the redirect doesn't occur.  

  -Mike-

Subbu Allamaraju wrote:

Thanks Rich, for reminding. Here is my summary.

The key point is to keep symmetry in the specification between interactions and event processing. As the designers of a specification (and not an implementation) we ought to allow such a symmetry so that the spec says closer to HTTP.

I can agree with Mike and Richard (per his mail today) that typical portal consumers may find it difficult to honor redirects in event processing. But in WSRP, portals make up just one class of consumers, and the spec need not favor one kind over another.

Regards,

Subbu

Rich Thompson wrote:


This issue has failed to develop a consensus within the Interfaces SC.

In preparation for holding a vote during the August 25th TC call, this is an email thread for Subbu and Mike to summarize the opposing points of view. Rather than rehash the full discussion, I would ask that questions be restricted to any points about those summaries which need clarification.

Subbu, would you post a summary in favor of adding this capability first so that we have a chance of capturing this in a single email thread? --------------------------------------------------------------------- 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

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


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