RE: [wsrp-coord] Events vs StateChanges

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

Hi Alejandro,

 

I also prefer the events model. I was just trying to show that in the end they are nearly equal. As a side effect it also turns out to show that the events model is simpler AND stronger. (and I wasn't even trying...)

 

    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 don't like the idea of readOnly\writeOnly\both properties. It would be defining calls by reference.

I prefer a more simpler model. A la event/sender/listener.

Alejandro

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

Hi Andre,

What Mike is proposing is not that one portlet can change the state of another, or send an event to another, but that it can declare its own state has changed, and that enables consumers to change the state of another portlet when the state of the first portlet is changed.

(In other words, each portlet exposes a set of properties, that can be readOnly\writeOnly\both, and the consumer reads state changes from one portlet and writes them to another).

Of course, this requires mapping, since there is absolutely no way for two portlets to communicate without the consumer knowing which of their properties need to be mapped. This is another huge advantage of the events model, since if two portlets agree on the signature of an event, no mapping is needed.

I do not see why you are uncomfortable with event mapping. What is wrong in a situation where a consumer decides that that portlet A exposes an event that is logically the same as an event that portlet B subscribes to, and decides to do some match-making? This would need tailoring at the page level by the page designer at the consumer, and certainly not every portal would support this, and the spec does not need to specify how it should be done. The model should simply allow events to have enough metadata to enable this.

    Yossi.

-----Original Message-----

From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]

Sent: Wednesday, August 06, 2003 11:10 AM

To: wsrp-coord@lists.oasis-open.org

Subject: RE: [wsrp-coord] Events vs StateChanges

I've got some background in CCS & CSP so am used to pure signals and very

comfortable with extending such a (message based) model to carry data

(events (c) in Mike's email). Another common extension is to add a broker

or event mediation layer (brokered events - i.e. the consumer routes events).

I'm less comfortable with arbitrary consumer transformations of events

and would like to see a proposal. Maybe supporting event sub-typing

to allow a portlet to register for generic sets of events would cover

most use cases?

I'm very uncomfortable with any direct state based approach (Portlet A

can update a shared variable on Portlet B) as this seems to break

encapsulation even more than consumer event transformation. Allowing

portlet A to force a state transition on another portlet has similar

encapsulation problems.

Mike - for (d,e) are you proposing that portletA can do

portletB.write("variableName", "value")

or

portletB.goto("stateName", "withData")

or ...?

regards,

Andre

-----Original Message-----

From: Michael Freedman [mailto:Michael.Freedman@oracle.com]

Sent: 06 August 2003 00:58

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