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

The clickstream example was mentioned several times, but I am not sure how
one would employ invisible services to do clickstream analysis.

I could imagine that a portal implementation allows local portlets to
callback on the portal server to provide clickstream information (amongst
those might be portlet proxies connected to a WSRP service) and that the
portal server would have an associated tool that can consume and analyze
the clickstream info.

How would the invisible service function ?

Best regards,


"PAVLIK,GREGORY (HP-NewJersey,ex2)" <gregory_pavlik@hp.com> on 04/24/2002
01:51:54 PM

Please respond to "PAVLIK,GREGORY (HP-NewJersey,ex2)"

To:    "'Sasha Aickin'" <AlexanderA@plumtree.com>, Alan Kropp
       <akropp@epicentric.com>, "Tamari, Yossi"
       <yossi.tamari@sapportals.com>, wsrp@lists.oasis-open.org
Subject:    RE: [wsrp][interfaces]: Actions vs. Events

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

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.

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


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

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

Powered by eList eXpress LLC