RE: [wsrp-coord] Events vs StateChanges

["Tamari, Yossi" <yossi.tamari@sap.com>]

Hi,

I do not think we should go too far with a. I do not object to defining a set of events that are within WSRP, as long as the protocol does not depend on them, and does not define what the consumer should do if they happen.

I am glad we agree that d and e are private cases of b and c. I think our problem is that we are arguing on points of view rather than facts, and therefore none of us is "correct". Just as it can be claimed that since many events contain parameters (data), it makes sense to represent them as state changes, it also can be claimed that since many such events pass data that the source/destination may not perceive as representing its state, it does not make sense to represent them as state changes.
For example, there may be a stateless portlet (say that it just shows a live feed of a car race, but the viewer has no control over it, as in practically every telecast), and it wants to be able to let other portlets know when the user selects an item in it (the user clicks on a car, expecting to see the driver details, from a separate DB. The telecast portlet knows to recognize car numbers in a passive way, and raise an event). If we have Events, it can just send an event (CarSelected[integer]). If we have State Changes, it will have to expose a virtual property (SelectedCar [integer, readOnly]), and now a portlet developer needs to think about what are my (virtual) properties, are they read/write/both/none etc. Also, if we expose CarSelected as a property, if the user clicks on this car again, since the telecast portlet does not keep track of which car was previously selected, it will raise the "property changed" flag even though this did not happen. Of course its behaviors !
will be the same with the events model, but than at least there is no pretense of this being a state change. It is simply a broadcast of the fact that a user interaction happened, that other portlets may be interested in. 

I do not agree that it is more difficult for the developer (you used the word user, but that is misleading), to try to match an event, with a logical name, and a logical set of parameters, than to try to match properties between two portlets, when at different (logical) events a different subset of these properties may be changed, and there is a implicit semantic meaning to the subset of the properties that was changed at a time. Let me explain this by extending the previous example:
Lets assume the telecast portlet exposes the SelectedCar read only property, and it wants to play nice, so it also keeps the state of this property in the session so that it does not broadcast a change notification when the same car is clicked again.
Now the currently selected car gets disqualified. The telecast portlet wants to do two things: tell other portlets that a car was disqualified, and deselect it (since in its logic a disqualified car stops existing). It must now change two properties: selectedCar should change to NULL, and DisqualifiedCars [Array of Integer, readOnly] should change to reflect the addition of a new disqualified car. The DisqualifiedCars array should be also maintained in the session...
It can be suggested that DisqualifiedCars can be replaced with LastDisqualified [Integer, readOnly], but this will not work when two cars are disqualified at once, or LastDisqualifiedCars [Array of Integer, readOnly], which may work but really does not make sense as a property.
Now bear in mind that all these complexities must also exist in the "listener" portlet: It must expose exactly the same array variables (since it is really too much to expect from the consumer mapping to be able to maintain a mapping from a DisqualifiedCars property to a LastDisqualifiedCars property. 
All this would be much simpler if the telecast portlet just exposed two events: CarSelected and CarDisqualified [Integer]. In this example it would raise three events: CarSelected(NULL), and two CarDisqualified(X).

Before someone else says this, I know CarDisqualified does not work well as an in band event, but this is just an example (imagine that these portlets are actually being used by the referees, and they can disqualify cars by portlet interaction).


I do think we should care (high priority) about consumers who do events/state-changes but not mapping. However, I agree that if we design our solution correctly they will fit in seamlessly. We should not need to add extra functionality for them.

	Yossi.

-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Wednesday, August 06, 2003 2:58 AM
To: wsrp-coord@lists.oasis-open.org
Subject: [wsrp-coord] Events vs StateChanges


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?]
       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.
       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.

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