Title: RE: [wsrp-coord] Events vs StateChanges
Your
example of a potlet taking in event A and raising event B and a consumer
transforming events may differ when more than one portlet subscribes to event A.
I.e. does a consumer filter all events before they are raised to portlets or
not? That's they type of question we need to address.
regards,
Andre
-----Original Message-----
From: Tamari, Yossi
[mailto:]
Sent: 06 August 2003
11:27
To:
Subject: RE:
[wsrp-coord] Events vs StateChanges
Hi
Andre,
I am
also less comfortable with the exposed state model, but the "justification"
from its proponents is that the portlet chooses which property it wants to
expose for reading or writing, so in effect it is equivalent to the event
model. (each inbound/outbound event can be modeled as a readOnly/writeOnly
property, and vice-versa.)
Event transformation example: Say the race car telecast portlet from my
previous examples exposes an event CarSelected, and passes as parameters all
its information regarding this car (driver info, car model, etc.), in addition
to the car number. On the other hand I have a portlet that displays driver
history, but it does so based on getting the driver name (through an event).
It does not expect all the extra info that the telecast portlet exposes. Event
Mapping enables the consumer (with the help of the page designer) to extract
the driver name from the published event, and send it to the the driver
history details.
Another more rudimentary example: An SAP R/3 sales orders portlet
contains an event CustomerSelected [outbound, CustomerIdType], which is
fired when the displayed sales order changes, so that another SAP R/3 customer details portlet
can synchronize with the displayed sales order. However, a specific customer
uses Siebel to hold its customer details, and has a Siebel portlet that
subscribes to the event DisplayCustomer [inbound, CustomerIdType]. Because the
names of the events are different, without some kind of consumer mapping, the
two portlets cannot coordinate. With a simple event name mapping the problem
is solved.
We
should remember that we cannot prevent event mapping, even if the spec will
says it is disallowed, since any one can create an invisible portlet that
subscribes to event A and sends event B. This portlet could then always send
event B when it receives event A with some parameter manipulation. So event
mapping will happen. Now we should try to make it work
well.
I
think we all agree on having the consumer as event broker for in-band events.
It is not as clear for OOB events, which is another reason to leave it out of
scope.
Yossi.
-----Original Message-----
From: Andre Kramer
[mailto:]
Sent: Wednesday, August 06,
2003 12:48 PM
To:
Subject: RE: [wsrp-coord] Events
vs StateChanges
Yossi,
Thanks for explaining the shared data model.
Still seems to break encapsulation, as the consumer is directly
involved in all interactions.
On
event transformations - I'm not uncomfortable, just less comfortable
(would like to see examples).
Both seem to model the consumer as a broker (mediating events or
performing direct writes) so maybe that's our core
pattern?
regards,
Andre
-----Original Message-----
From: Tamari, Yossi
[mailto:]
Sent: 06 August 2003
10:30
To:
Subject: RE:
[wsrp-coord] Events vs StateChanges
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:]
Sent: Wednesday, August
06, 2003 11:10 AM
To:
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:]
Sent: 06 August 2003 00:58
To:
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
