Title: RE: [wsrp-coord] Events vs StateChanges
See
bellow.
-----Original Message-----
From: Andre Kramer
[mailto:]
Sent: Wednesday, August 06, 2003
3:31 PM
To:
Subject: RE:
[wsrp-coord] Events vs StateChanges
maybe an example would help:
porlet A and portlet B register for event X
portlet C registers for event Y
portlet D registers for event X and Y
consumer maps event X to Y (Is this mapping for specific
portlets or for all?)
[Yossi
Tamari] Good question. But my answer is that is up to the Portal
(consumer) to decide. It does not need to be part of the
spec.
portlet E raises event X
Do A & B still see X?
[Yossi
Tamari] Yes.
Does D see X twice (once as Y)?
[Yossi Tamari] Up to the consumer. A good
consumer will allow the page designer to define this per event per portlet,
but since mapping is not specified in the spec and not required for it to
function, we don't need to specify
this.
Some of the above would be hard to model as a portlet (e.g Portlet B
raising Y on X)
[Yossi Tamari] What do
you mean? The way this would be implemented is by adding to the page
another invisible portlet (I) that would subscribe to X and raise
Y.
regards,
Andre
-----Original Message-----
From: Tamari, Yossi
[mailto:]
Sent: 06 August 2003
13:16
To:
Subject: RE:
[wsrp-coord] Events vs StateChanges
I
am not sure I am following you.
I
think it is OK the say that a consumer (that does events) that receives an
event NS:X MUST forward it to all portlets (in the same context) that
subscribe to event NS:X.
Event mapping only comes into play when the inbound
and outbound events are different.
The number of subscribed portlets is
really not important here. As I said, event mapping should not be a
part of WSRP, it is just that WSRP should allow/help portals to do event
mapping if they want to, with any mechanism they choose.
When a portlet fires an event, he has no knowledge
which portlets will receive it. When a portlet receives an event, it does
not know where it came from (at least in the strict sense, there may be a
parameter indicating the source of the event). The model should be
decoupled.
Yossi.
-----Original Message-----
From: Andre Kramer
[mailto:]
Sent: Wednesday, August 06,
2003 2:02 PM
To:
Subject: 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
