[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I agree, invisible services are very valuable, and am in favor of keeping
them in the conversation.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, April 24, 2002 8:09 AM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp][interfaces]: Actions vs. Events
There is clearly value to having participants on a page that don't generate
markup ... it is a different question as to whether they are WSRP services
or not. This is one of the reasons the portTypes proposed in the WSXL
position paper were factored into functional areas. Such a factoring allows
for support of such participants without requiring them to implement
unnecessary operations or requiring the Consumer (ie portal) to treat them
as if they produced output.
"PAVLIK,GREGORY
(HP-NewJersey,ex2 To: "'Sasha Aickin'"
<AlexanderA@plumtree.com>, Alan Kropp
)" <akropp@epicentric.com>,
"Tamari, Yossi"
<gregory_pavlik@h
<yossi.tamari@sapportals.com>, [email protected]
p.com> cc:
Subject: RE:
[wsrp][interfaces]: Actions vs. Events
04/24/2002 07:51
AM
Participants on the page that don't return markup are legitimate and
potentially important, but don't make much sense without an event model in
many case (but not all) cases. Simple example: clickstream analysis via a
special service defined in WSRP.
-----Original Message-----
From: Sasha Aickin [mailto:AlexanderA@plumtree.com]
Sent: Wednesday, April 24, 2002 12:12 AM
To: Alan Kropp; Tamari, Yossi; wsrp@lists.oasis-open.org
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I agree, Alan, that page scope is the first and most useful context for
events.
I am troubled, however, by the notion of "invisible" portlets to act simply
as event listeners. I think that we should not support the notion of
"invisible" portlets, as it significantly undermines our mission of
creating web services for end-user presentation.
I also agree with several folks on this thread that event handling does not
need to be in the first rev of this spec. The endless loop of events
problem troubles me, as well as the overhead of having multiple phases in
portal-portlet interaction within the scope of one user interaction.
Cheers,
Sasha.
-----Original Message-----
From: Alan Kropp [mailto:akropp@epicentric.com]
Sent: Monday, April 22, 2002 12:11 PM
To: 'Tamari, Yossi'; wsrp@lists.oasis-open.org
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I like the idea of page scope as the simplest, and perhaps default
case. However, it's not difficult to imagine a scenario where a
portlet instance has interest in events fired from instances on
different pages. In this case, group scope may work, or maybe
portal-scope (all pages) in the broadest case. But if I read Dave's
original point correctly, the concern may be event overlap if there
are multiple instances of an event-producing portlet. Unless that's
desired behavior, we may need a mechanism which mitigates it.
-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sapportals.com]
Sent: Monday, April 22, 2002 10:00 AM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I think both using the page scope or letting the deployer
define an event scope are good options. Another option is to
use the portlet's group (we discussed this notion at the first
F2F) as the event scope.
One reason using the page scope may be good enough is that you
could create "invisible" portlets in the page from the same
subscriber, whose function would be to persist the fact that
the event was fired.
Yossi.
-----Original Message-----
From: Dave Clegg [mailto:davec@sybase.com]
Sent: Monday, April 22, 2002 7:33 PM
To: Tamari, Yossi
Cc: wsrp@lists.oasis-open.org
Subject: Re: [wsrp][interfaces]: Actions vs. Events
Static event subscription thru metadata is appealing in
its simplicity, but presumeably a portlet that want so
subscribe to events from another portlet isn't
subscribing to all events from that other portlet class
but only to events from some instance of that other
portlet.
If I've got a NewsFeed portlet that listens to
StockSymbol events from a StockTicker portlet, I want
that NewsFeed portlet to fire only when some instance of
the StockTicker fires, not whenever any StockTicker on
the Portal fires.
We could attempt to define some "rules" for converting
event metadata to inter-instance subscriptions (Only
portlets on the same "Page" can subscribe to each other's
events), but I fear that will drag us into a wider set of
issues.
Perhaps we can define a logical "Event Scope" construct.
Portlet instances within that scope may register for each
other's events. Portlet Metadata describes both the
Events produced and Events consumed be each portlet, and
it is the job of the portal definition tools to define
the boundaries of an Event Scope and perform the
registrations among portlets within it.
dave
Tamari, Yossi wrote:
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.
-
m: Carsten Leu
e [mailto:cleue@de.ibm.com]
Sent: Monday, April 22, 2002 5:43 PM
To: Tamari, Yossi
Cc: wsrp@lists.oasis-open.org
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�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" |
| | |
|---------+----------------------------->
----------------------------------------------
-----------------------------
----------------------------------------------------
--------------|
|
|
| To: wsrp@lists.oasis-open.org
|
| cc:
|
| Subject: RE: [wsrp][interfaces]: Actions
vs. Events
|
|
|
|
|
----------------------------------------------
-----------------------------
----------------------------------------------------
--------------|
This is what I had in mind as well. If different
producer want to
communicate directly, they can do this regardless
of WSRP.
What is needed is some variation of a
publish/subscribe (with data)
mechanism managed by the consumer.
Yossi.
-----Original Message-----
From: PAVLIK,GREGORY (HP-NewJersey,ex2) [
mailto:gregory_pavlik@hp.com]
Sent: Monday, April 15, 2002 10:20 PM
To: 'Alan Kropp'; 'Carsten Leue';
wsrp@lists.oasis-open.org
Subject: RE: [wsrp][interfaces]: Actions vs. Events
that would be preferrable.
-----Original Messag!
e-----
From: Alan Kropp [mailto:akropp@epicentric.com]<
br>Sent: Monday, April 15, 2002 3:16 PM
To: 'Carsten Leue'; wsrp@lists.oasis-open.org
Subject: RE: [wsrp][interfaces]: Actions vs. Events
Hi Carsten,
On the subject of event handling, could we simplify
the scenario a bit by
allowing the portal to act as the intermediary in
event propagation? I'm
thinking of a publish/subscribe model (somewhat
like JMS), in portlets
which
support events "publish" those events to the
portal, and portlets which
consume events inform the portal by subscribing for
those event types. The
portal acts as the intermediary, and neither event
producers or consumers
need know specifically about each other.
Alan
-----Original Message-----
From: Carsten Leue [mailto:cleue@de.ibm.com]
Sent: Monday, April 15, 2002 3:49 AM
To: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------
------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------
------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http:/
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC