wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] redirectURL allowed in handleEvents response?
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Thu, 18 Aug 2005 09:43:30 -0400
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]