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

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.

                      (HP-NewJersey,ex2        To:       "'Sasha Aickin'" <AlexanderA@plumtree.com>, Alan Kropp  
                      )"                        <akropp@epicentric.com>, "Tamari, Yossi"                         
                      <gregory_pavlik@h         <yossi.tamari@sapportals.com>, wsrp@lists.oasis-open.org         
                      p.com>                   cc:                                                               
                                               Subject:  RE: [wsrp][interfaces]: Actions vs. Events              
                      04/24/2002 07:51                                                                           

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.

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

                  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

                  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



                        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

                        - 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) [
                        Sent: Monday, April 15, 2002 10:20 PM
                        To: 'Alan Kropp'; 'Carsten Leue';
                        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
                        manager: <http://lists.oasis-open.org/ob/adm.pl>


                        To subscribe or unsubscribe from this elist use the
                        manager: <http:/

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

Powered by eList eXpress LLC