[wsrp-coord] Event processing completion status use case

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

Title: [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