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 Message-----
Fro!
m: Carsten Leu
e [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 portal. If we unify actions and
even
t 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鐽lingen , 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" |
| | |
|---------+----------------------------->
