Very hard to answer in general but think
of a "cut and paste" interaction between two portlets:
Use Case: After "highlighting"
in first portlet (highlight event generated with highlighted data distributed) and
user attempted paste into second -
Second portlet sends "cut&paste"
C1 has no "highlightable" portlet.
Cut&paste fails to cause anything. Cut&paste fails to cause anything.
C2 has a portlet that can "highlight"
but it is not (now) in the highlighted state. User's expectations not
C3 has a highlighted portlet but it fails
to process the cut part of the cut&paste. The second portlet may wish to
inform the user that her cut&paste failed.
C4 has a highlighted portlet but it fails
to process the cut part of the cut&paste. A spurious copy for the user to
Just taking the viewpoint that user
feedback is generally good makes C3 seem more intelligent that 1,2 or 4 or than
any C that drops events without failure notifications.
From: Rich Thompson
Sent: 14 December 2004 17:55
Subject: RE: [wsrp] handleEvent or
I'm not sure what this would mean to a portlet.
Consider the following variations:
different Consumers (C1, C2, C3 & C4) all place a portlet (P1) that
generates an event on a page. When the event is generated, the following
On C1's page there is no match to a consuming portlet and the event is thrown
On C2's page there is a matching portlet, but it chooses to throw the event
On C3's page there is a matching portlet to whom the event is distributed, but
it fails to process it
On C4's page there is a matching portlet to whom the event is distributed and
it does not inform the Consumer of any failures when processing the event.
four Consumers then request P1's markup.
What are the use cases for P1 generating different markup for the four
What are the use cases for P1 caring that the Consumer received, let alone
distributed, the event?
While P1 could indicate it is interested in event distribution/processing
failures, since each Consumer gets to decide each time whether or not to
provide such information to it, what use would a portlet make of the
suspect we are driving toward some core questions of whether the portlet or the
Consumer is in charge relative to event distribution.
12/14/2004 03:57 AM
<firstname.lastname@example.org>, Andre Kramer
RE: [wsrp] handleEvent or handleEvents?
I agree that we can't
postulate reliable event or failure notification. However, best effort delivery
of network and event handling failure indications to interested portlets is
still useful as it allows them to offer alternative user interactions.
From: Richard Jacob [mailto:email@example.com]
Sent: 13 December 2004 18:38
To: Andre Kramer
Subject: RE: [wsrp] handleEvent or handleEvents?
important point to me is that we really should understand the
nature of events.
Portlets shouldn't rely on event delivery and thus also shouldn't rely on
correct event processing.
We also do not deliver failure events back to the portlet issuing the
original event (this was the first design we had).
Therefore we might want to ask ourselves what event failures are really for
and who will be doing what with this information.
Key point for me is that we shouldn't try to implement a (relyable)
messaging system based on events, i.e. we shouldn't add any
atomicy,rollback, etc. rules to eventing.
freundlichen Gruessen / best regards,
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
RE: [wsrp] handleEvent
that event processing occurs in rounds would also help the
presentation. Each round involves a consumer delivering a batch of events
to the producer and optionally receiving back a further batch of events
(and failure events) to process.
Rich Thompson [mailto:firstname.lastname@example.org]
Sent: 13 December 2004 14:10
Subject: Re: [wsrp] handleEvent or handleEvents?
decision was to drop to handleEvent for now due to the issues
involved in handling faults in the batched case. We should work on these
and seek to restore the nature to a batch operation for the reasons you
list. Basically the solution should respect the current overall design:
Portlets are loosely coupled components integrated onto the page by the
2. Events are notifications that something has occurred which other
components may use to impact their own state.
3. There are times when a Consumer will care what failures have occurred
(e.g. for retry purposes)
if we agree to these guidelines, then relatively simple solutions
to the failure issues in the batch operation can be designed. Any comments
on these as guidelines before we try and design/debate a solution?
12/10/2004 07:06 AM
[wsrp] handleEvent or
comment is on the current 2.0 draft, so I am sending it to the TC list,
even though it is specific to coordination. As initially written,
handleEvent is constrained to only deliver a single (IN) event and requires
the consumer to not deliver a second event while the first is being
processed (but multiple events can be returned by a portlet). This seems an
unworkable solution to me because of (1) network latency and (2) event
processing logically occurs in rounds. Should we start with handleEvents
rather than try to discuss a handleEvent?