RE: [wsrp-coord] Events vs StateChanges

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

Hi Alejandro,

I was just going with Sports Portal Scenario that Aditi wrote and Rich offered as the main use case for the group.
I believe I can make each of these points in a business scenario as well, I will try to write something if I have the time until Wednesday, but it will certainly not be a full blown use case document.

	Yossi.

-----Original Message-----
From: Alejandro Abdelnur [mailto:Alejandro.Abdelnur@Sun.COM]
Sent: Friday, August 08, 2003 3:54 AM
To: wsrp-coord@lists.oasis-open.org
Subject: Re: [wsrp-coord] Events vs StateChanges


I'm not sure on the validity of the use case or how realistic it is.

* Portlet showing a streaming data: We need a plugin to show this in  
the user-agent, remember the portlet generates markup.

* User clicking on passing car: We need the previous streaming data to  
send coordinates+carInfo. We need previous plugin to pop to markup  
object model the info about the car. We need some scripting to collect  
this info from the object model. We need to push that info back to the  
consumer, using a portlet created URL.

This will make the user-agent to request a new portal page, losing  
current streaming data.

IMO, this is solved by other technologies, not WSRP.

As many of the TC members are from ISVs companies (CRMs, ERPs, CMs,  
etc), could be possible to get a real and simple business use case. I  
don't know, for example something like a shopping cart portlet  
interacting with a inventory portlet and a catalog portlet.

Thanks.

Alejandro

On Wednesday, August 6, 2003, at 02:17  AM, Tamari, Yossi wrote:

> 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 behavior!
>  s !
> 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
>
> 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
>


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