Title: 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
