Re: [wsrp-coord] Events vs StateChanges

[Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>]

Comments and questions embedded.

Alejandro

On Tuesday, August 5, 2003, at 04:57  PM, Michael Freedman wrote:

> Last week we discussed the value of defining an in-band event model  
> vs. a state changed model.  Here are some further thoughts:
>      I see the following types of events that could be dealt with:
>       a) WSRP events -- these are well known events that WSRP defines  
> -- currently these "events" are implicit in our protocol being  
> explicitly represented as lifecycle calls [and their  
> parameters/returns]:  i.e. perform action,  render.  Examples of such  
> events we might consider adding are Begin/EndTransaction.  I.e.  
> placing a series of calls between portlets within a consistent  
> transaction. [Important once we start propagating state changes/data  
> across portlets?]

I think we should keep WSRP completely outside of transactions. All  
interactions that require transactions has to be handled in a  
transactional environment (i.e. EJB container). If not soon well have  
to deal with transaction monitors, two phase commit, etc; way out of  
the scope of WSRP chapter. Not to mention there is not standard  
infrastructure to enable web-services to do such a thing yet.

I would suggest we make clear that any eventing we define through WSRP  
is to aid the user experience when interacting with a collection of  
portlets through a consumer. But any eventing requiring reliability  
should be done in the business logic layer.

>       b) Mappable events -- these are events typically defined by the  
> producer [though also can be done by the consumer] that the receiving  
> portlet is not aware of.  Consumers provide a facility to declare  
> mappings from one portlets event namespace to anothers.  Yossi  
> indicated he will provide some examples of this.
>       c) Known events -- these are events typically defined by the  
> producer [though also can be done by the consumer] that the receiving  
> portlet is aware of.  No mapping is necessary, consumer merely route  
> the events to interested parties.  Commonly used within a producer to  
> build cooperation within a known set or portlets or by producers  
> building building-block portlets that it hopes other producers will  
> include in a cooperating set.

Not clear what known events we would have, this seems similar to the  
discussion on having predefined roles.

>       d) Mappable state changes -- probably the most common form of  
> mappable event where the consumer acts as a mediator for data exchange  
> between two portlets.  I.e. an action results in state changes, a  
> portion of which a portlet wishes to publish [e.g. bug report number].  
> The consumer understands that the portlet "publishes" this data and  
> supports mapping it to similarly published state in another portlet.
>      e) Known state changes -- like known events, the consumer doesn't  
> provide any mapping -- the sending/receiving portlets understand/agree  
> on the data being exchanged via prior knowledge/agreement.

It is not clear to me why we have to consider 'events' and 'state  
changes' as two different things. IMO a state change triggers an event.

> I agree with Yossi that Mappable events are a generalization of  
> mappable state changes.  However, I am not yet convinced that our  
> in-band mechansim needs this generalization.  For me there is a  
> developer and user cost/complexity to introducing MappableEvents here.  
>  As I don't yet have an example of a pure event -- one that indicates  
> no state change/has no associated state -- A mappable event leaves the  
> developer in the quandry of whether to define a new event for every  
> state change or whether to expose the state changes via a common event  
> [e.g. UpdateModel].  The later has the benefit of having a single form  
> allowing the consumer to present a simplified user interaction -- map  
> from this portlets published data to the other ones.  When  
> individually named events are involved the user must first choose the  
> event they want to map and then map the data between the events.  For  
> me, this is an unnecessary complication to the user interaction. Until  
> I see/understand the use cases for in-band mappable events that aren't  
> satisfied by mappable state changes my preference is to limit our  
> in-band mechanism just to mappable state changes.
> As for (c) and (e) -- known events/state changes -- should we care and  
> if so what is its priority?  Mappable events/state changes is a  
> superset of the known case -- should we care and if so is it a  
> priority to support Consumers who merely want to deal with  
> distpaching/managing known events/state changes but not mappable ones?  
>     -Mike-
>
>
> You may leave a Technical Committee at any time by visiting  
> http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/ 
> leave_workgroup.php
>