[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-coord] Event processing completion status use case
Hi Andre, I think we should break this into two separate
problems: 1. The events failed to reach the target
(network problems or any other reasons) – I do not think we can even
consider this an error. It is quite clear that there are some consumers who
will not support events, or only support one cycle, or only for one second,
etc. Since the portlet that raises the event cannot really know how far down
the chain it is, and how far down the chain the portlet that actually displays
the results is, it cannot “strongly” assume the event was received. 2. The receiver of the events failed to do
its part (because of some internal error) – It is the responsibility of
the receiver to handle the error in a user friendly way. This may be by
displaying a specific UI, or by sending an event back to the first portlet to
let it know that it should go back to its original status, depending on the
technical relationships between the portlets. In my opinion we should not really
consider 2 at all. It is not a protocol level issue. 1 is more interesting for
us, depending on how much complexity returning such information adds to the
interface. One more issue: you write that we suppose
a synchronous interaction chain, and I think this is misleading: if a portlet
raises an event, it is not “stopped” until the event is handled, as
in a synchronous function call. It is synchronous only in the sense that until
the event handling phase finishes, the markup phase does not begin. Yossi. From: Andre
Kramer [mailto:andre.kramer@eu.citrix.com] On this Wednesday' coordination call, I was asked to
come up with a use case for some sort of event processing completion status
notification. Currently, we suppose a synchronous interaction chain for event
processing, along the following lines: a user action which may trigger one or
more events that need to be forwarded to other interested parties (consumer,
producer/portlets); consuming events may generate further secondary events to
be processed; one or more further event processing rounds occur, until no
further new events are raised; followed by the consumer calling getMarkup on
portlets. When getMarkup is called, the portlets are given no
indication of whether the event processing (in which they may have cooperated)
succeeded normally or was terminated by some participant raising an error or by
a network communication failure. Also, getMarkup may not even be called,
depending on caching. As the following use case attempts to show, this may make
coding portlets more difficult than needs to be the case: A user (MD) configures two or more portlets on a page
as part of a knowledge workflow application (e.g. Doctor making a query on
multiple medical databases). She uses one portlet which is currently in the
maximized window state to construct and submit a query (an XML document using
some domain specific schema), pressing "submit". After submit, the
query portlet would normally minimize itself, allowing other portlets on the
page more space to display the results of the query. The query portlet
therefore always requests a transition to wsrp:minimized before/on generating
its "process query event". Normally other portlets on the page would
update to display the results of the query. However, event processing can fail and one or more of
the database search portlets could fail to get the event. They will therefore
not update their display (may even be displaying results of the previous
query). The user has no indication that some thing went wrong (the consumer
portal could provide some low level event processing error feedback, but how is
a busy Doctor supposed to interpret that?). It would be much better for the query portlet to be
notified of the event processing error so that it does not minimize and is able
to generate a "The query was not processed fully by all your analysis
portlets - would you like to re-submit the query later?" message. Note that: the fact that different window states are
used sort of implies that a separate event processing failure notification is
provided so that the query portlet can undo the change request to
wsrp:minimized. We are not proposing to provide any strong form of
event delivery or failure detection / notification reliability guarantees, just
giving the portlets involved in event processing an extra indication of the
(synchronous) event processing outcome, thereby allowing them to react to
common failure situations (as WSRP portlets are remote). An alternative (reliable) communication mechanism
could be used to submit the query but then why have support for events /
coordination in WSRP in the first place? In the above, only the event
processing initiator need be notified of completion failure but the use case
could be extended to notification of successful completion and to all portlets
that have participated in the event processing (breaking the query portlet into
two parts, for example: a query editor and a query submission portlet). Such
portlets could be allowed to subscribe to the completion notification
"event" when added to a Portal page. regards,
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]