is it also fair to state that the actions recieved by the producing service
potentially can create events for consumption by interested parties ?
-----Original Message-----
From: Thomas Schaeck [mailto:]
Sent: Thursday, April 25, 2002 10:03 AM
To: Sasha Aickin
Cc: Rich Thompson;
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I think the key point is that
actions are sent by a portal to the WSRP service to trigger an "action" in
that service as a result of a user acting on the markup previously produced
by that service
while
events are notifications sent by WSRP services to other WSRP services or
the portal.
Best regards,
Thomas
Sasha Aickin <> on 04/24/2002 06:15:40 AM
Please respond to Sasha Aickin <>
To: Rich Thompson/Watson/IBM@IBMUS,
cc:
Subject: RE: [wsrp][interfaces]: Actions vs. Events
Rich,
Your definitions specify that Events come *from* a Producer, whereas
Actions go *to* a Producer. Does that mean that the portal sends an
Action to Producer A in order to process the Event which came from
Producer B?
Sasha.
-----Original Message-----
From: Rich Thompson [mailto:]
Sent: Monday, April 22, 2002 9:33 AM
To:
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I'm not sure limiting event types to those published in meta-data would
suffice. Consider the case of a Producer that provides a redirection to
other services that it has been instructed to instantiate (or maybe just
"contain"). The events such a Producer would publish are dependent on
the
indirect providers and therefore can not be published statically. An
example of such a Producer could be a portal publishing a set of
portlets
as a WSRP service for other portals to consume.
While I consider events to a important to both the WSIA and WSRP
standards,
I would suggest not pushing them into the first versions of the
standards
as the WSDL layer of the web services stack has these poorly defined now
and there are efforts to clean up that portion of the WSDL spec.
Also, unless I missed it, I don't think I saw
the terms action and event
being crisply defined. My suggestion:
Action - A request to a Producer to execute some functionality.
Event - A notice from a Producer that some logical transition has
occurred.
Jeff Broberg
<jbroberg@silvers To: "Tamari, Yossi"
<>,
tream.com>
cc:
04/22/2002 11:40 Subject: RE:
[wsrp][interfaces]: Actions vs. Events
AM
Please respond to
jbroberg
my mistake, i meant it in the context of
actions not events.
-----Original Message-----
From: Tamari, Yossi [mailto:]
Sent: Monday, April 22, 2002 11:27 AM
To: ''
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I do not know if I agree on this, since events are not generated by the
user, but by other providers (in the context of the user).
Anyway, if a provider does not wish to process a certain event in a
certain
context, it can ignore the event in runtime.
I think that the overhead of implementing dynamic events may be bigger
than
the overhead of having ignored events.
Yossi.
-----Original Message-----
From: Jeff Broberg [mailto:jbroberg@silverstream.
com]
Sent: Monday, April 22, 2002 6:22 PM
To: Tamari, Yossi;
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I can imagine a scenario where the events that a provider allows for a
particular user is context based, so that one individual may be able to
perform some type of action while another can't. So we could define the
availalbe events in the metadata, but we may have to also allow this
info
to
be dynamically generated and discovered.
jeff
-----Original Message-----
From: Tamari, Yossi [mailto:]
Sent: Monday, April 22, 2002 11:01 AM
To:
Subject: RE: [wsrp][interfaces]: Actions vs. Events
My take on the registration issue is that the provider should include
the
list of events/properties that it wants to subscribe to in its metadata.
It seems to me like this list does not need to be dynamic since in order
to
process more events, more code needs to be written in the provider.
The place were loops may actually happen is when provider A raises event
X,
which causes provider B to raise event Y, which causes provider A to
raise
event X again (for example). There are different algorithms that can
prevent
this, and maybe we should leave this to the implementing portal. We
could
define that the same event can not be fired by the same provider more
then
once per request, and that the consumer is not required to continue
processing events if the chain is deeper than some constant number. I
would
like to hear other suggestions to solving this problem.
Yossi.
-----Original Mes
sage-----
From: Carsten Leue [mailto:]
Sent: Monday, April 22, 2002 5:43 PM
To: Tamari, Yossi
Cc:
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I think that this would be a good solution for events to decouple the
portlets and solve the problems that the portlets might not "see" each
other through the firewalls. Furthermore it take the complexity of
managing
listeners away from the services to the portal. I still see a semantic
difference between actions and events but maybe we can unify that. Some
open issues are from my point of view:
- visibility: per definition the portal has access to the service (e.g.
though a firewall). The same is not necessary true for the service that
may
be shielded from directly accessing the por
tal. If we unify actions and
event we need
- a way for the services to register/unregister themselves as
listeners passively without initiating a communication to the portal
(e.g.
in the return values for the markup call)
- is it also possible to trigger events passively?
- chaining: a portlet that has been integrated in a portal might be
republished and reintegrated by another portal
- register/unregister requests for listeneres need to be delegated
to
both portals
- how can loops be avoided in such cases?
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
| | "Tamari, Yossi" |
| | <yossi.tamari@sapp|
| | ortals.com> |
| |
|
| | 04/22/2002 03:31 |
| | PM |
| | Please respond to |
| | "Tamari, Yossi" |
| | |
|---------+----------------------------->
