OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [wsrp][interfaces]: Actions vs. Events

Would it be reasonable to take a vendor poll to determine 1) which vendor's products support some form of interportlet communication and 2) for those products that do, what mechanism is employed, ie, loose-coupled events, direct interaction between portlets, etc. That might be helpful to determine the priority of an event model. I think it would be wrong to exclude the event model based on it's complexity if it's in fact a standard feature of most portal frameworks.
As a side point, if an event model winds up in JSR 168, it would again be desireable to have alignment.
My own view is that the "endless loop" problem is a problem that can be easily scoped and the portal becomes alot less capable without some form on interportlet communication. In practice, enterprising vendors are going to add this capability anyway, so it's most likely in our interest to address it up front.
-----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.
-----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.
-----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.


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.


- 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.


-----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
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.


-----Original Message-----
From: Carsten Leue [mailto:cleue@de.ibm.com]
Sent: Monday, April 15, 2002 3:49 AM

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC