[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:richard.jacob@de.ibm.com Andre Kramer <andre.kramer@eu. citrix.com> To wsrp@lists.oasis-open.org 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:richt2@us.ibm.com] Sent: 13 December 2004 14:10 To: wsrp@lists.oasis-open.org 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 <andre.kramer@eu.citrix.com> To 12/10/2004 07:06 AM wsrp@lists.oasis-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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]