RE: [wsrp-coord] Event processing completion status use case

[Andre Kramer <andre.kramer@eu.citrix.com>]

Title: [wsrp-coord] Event processing completion status use case

I agree that whether or not event processing completed normally is the issue, rather than if portet(s) processed the event(s) without error. I would say "synchronous" from the point of view of user/consumer as no other processing is allowed to happen until the event processing ends.

 

And we would need to be very clear that we are not providing strong guarantees - only adding an opportunity for portlets to react if something did or appeared not to have terminated normally.

 

My use case did question what we allow events to do (such as changing window state) and what they are used for (workflow control?). Possibly we need to push back on other questions before we conclude on the usefulness of completion status feedback.

 

regards,

Andre

-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: 18 January 2004 09:56
To: wsrp-coord@lists.oasis-open.org
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]
Sent: Friday, January 16, 2004 1:11 PM
To: wsrp-coord@lists.oasis-open.org
Subject: [wsrp-coord] Event processing completion status use case

 

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