I'm not sure what this would mean to
a portlet. Consider the following variations:
Four 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 scenarios happen:
1. On C1's page there is no match to
a consuming portlet and the event is thrown away
2. On C2's page there is a matching
portlet, but it chooses to throw the event away anyway
3. On C3's page there is a matching
portlet to whom the event is distributed, but it fails to process it
4. 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.
All four Consumers then request P1's
markup.
Questions:
1. What are the use cases for P1 generating
different markup for the four different Consumers?
2. What are the use cases for P1 caring
that the Consumer received, let alone distributed, the event?
3. 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 information?
I suspect we are driving toward some
core questions of whether the portlet or the Consumer is in charge relative
to event distribution.
Rich
Andre Kramer <>
12/14/2004 03:57 AM
To
"'Richard Jacob'"
<>, Andre Kramer <>
cc
Subject
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.
Regards,
Andre
-----Original Message-----
From: Richard Jacob [mailto:]
Sent: 13 December 2004 18:38
To: Andre Kramer
Cc:
Subject: RE: [wsrp] handleEvent or handleEvents?
One other 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.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:
Andre Kramer
<andre.kramer@eu.
citrix.com>
To
12/13/2004 03:17
cc
PM
Subject
RE: [wsrp]
handleEvent or
handleEvents?
Recognizing 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.
Regards,
Andre
From: Rich Thompson [mailto:]
Sent: 13 December 2004 14:10
To:
Subject: Re: [wsrp] handleEvent or handleEvents?
The F2F 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:
1. Portlets are loosely coupled components integrated onto
the page by the
Consumer.
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)
I think 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?
Rich
Andre Kramer
<>
To
12/10/2004 07:06 AM
-open
.org
cc
Subject
[wsrp] handleEvent or
handleEvents?
My 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?
Regards,
Andre
