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



I would disagree that an action is a notification that the service's state
has changed. The invoker has no means of knowing that any state change has
occurred ... an example where it hasn't would be a button pressed that just
results in an action being invoked. At the point of the action being
invoked, there has been not a state change for the service (though there
likely will be as a result of the action's execution). That is why I
proposed an action definition that centers around it being a request for
the service to do something ... there may be state changes involved both
before and after the action is invoked, but they aren't central to defining
what an action is.



                                                                                                                 
                      Jeff Broberg                                                                               
                      <jbroberg@silvers        To:       Michael Freedman <Michael.Freedman@oracle.com>, Rich    
                      tream.com>                Thompson/Watson/IBM@IBMUS, WSRP <wsrp@lists.oasis-open.org>      
                                               cc:       Denise Dean <ddean@silverstream.com>                    
                      04/24/2002 09:37         Subject:  RE: [wsrp][interfaces]: Actions vs. Events              
                      PM                                                                                         
                      Please respond to                                                                          
                      jbroberg                                                                                   
                                                                                                                 
                                                                                                                 



i have updated the glossary for these modified terms and will be sending
the latest version out to the group either wed or thu of this week.

jeff
      -----Original Message-----
      From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
      Sent: Wednesday, April 24, 2002 6:03 PM
      To: Rich Thompson; WSRP
      Subject: Re: [wsrp][interfaces]: Actions vs. Events

      Rich,
         I like your idea that given we have many descriptions on the table
      we should see if we can solidify the discussion by first defining
      terms.  Once we have a good definition of terms we can then more
      effectively discuss requirements. I think your definitions are a good
      start but might be improved if made more concise.  What do you think
      of the following definitions:


      Action: a notification that your state has changed.
            There is only one recipient of an action.  This recipient is
            identified in the action request.  For example, a portlet
            encodes an action in the URI of its form's "Submit" button.
            This URI (the action request) explicitly targets the receiver
            (this portlet instance).



      Event: a notification that some state in the system (that you are
      interested in) has changed.
            There may be 0 to many recipients of an event.  The recipient
            of an event is not identified in the event request.  Rather,
            event recipients are managed (by an event manager).  An event
            request is sent to/via the event manager which then dispatches
            the event notification to interested parties.  I.e. the major
            differences between an action an event is that event recipients
            are anonymous and a single event may be dispatched to many
            portlets.


      I believe the above clearly defines the differences between actions
      and events from the point of view of the invoker.  However it doesn't
      address whether the recipient needs to see actions differently from
      events -- as "your state has changed" is just a subtype of "state has
      changed".   I believe we answer this by articulating the
      requirements/constraints on action handlers vs.
      requirements/constraints on event handlers.   As this message is
      about terminology I will leave this discussion to another message.
           -Mike-


      Rich Thompson wrote:
            I'm not sure limiting event types to those published in
            meta-data would
            suffice. Consider the case of a Producer that provides a
            redirection to
            other services that it has been instructed to instantiate (or
            maybe just
            "contain"). The events such a Producer would publish are
            dependent on the
            indirect providers and therefore can not be published
            statically. An
            example of such a Producer could be a portal publishing a set
            of portlets
            as a WSRP service for other portals to consume.


            While I consider events to a important to both the WSIA and
            WSRP standards,
            I would suggest not pushing them into the first versions of the
            standards
            as the WSDL layer of the web services stack has these poorly
            defined now
            and there are efforts to clean up that portion of the WSDL
            spec.


            Also, unless I missed it, I don't think I saw the terms action
            and event
            being crisply defined. My suggestion:
                  Action - A request to a Producer to execute some
            functionality.
                  Event - A notice from a Producer that some logical
            transition has
            occurred.



                                  Jeff Broberg
                                  <jbroberg@silvers        To:
            "Tamari, Yossi" <yossi.tamari@sapportals.com>,
                                  tream.com>
            wsrp@lists.oasis-open.org
                                                           cc:
                                  04/22/2002 11:40         Subject:  RE:
            [wsrp][interfaces]: Actions vs. Events
                                  AM
                                  Please respond to
                                  jbroberg




            my mistake, i meant it in the context of actions not events.


            -----Original Message-----
            From: Tamari, Yossi [mailto:yossi.tamari@sapportals.com]
            Sent: Monday, April 22, 2002 11:27 AM
            To: 'wsrp@lists.oasis-open.org'
            Subject: RE: [wsrp][interfaces]: Actions vs. Events


            I do not know if I agree on this, since events are not
            generated by the
            user, but by other providers (in the context of the user).
            Anyway, if a provider does not wish to process a certain event
            in a certain
            context, it can ignore the event in runtime.
            I think that the overhead of implementing dynamic events may be
            bigger than
            the overhead of having ignored events.


                         Yossi.


            -----Original Message-----
            From: Jeff Broberg [mailto:jbroberg@silverstream.com]
            Sent: Monday, April 22, 2002 6:22 PM
            To: Tamari, Yossi; wsrp@lists.oasis-open.org
            Subject: RE: [wsrp][interfaces]: Actions vs. Events


            I can imagine a scenario where the events that a provider
            allows for a
            particular user is context based, so that one individual may be
            able to
            perform some type of action while another can't.  So we could
            define the
            availalbe events in the metadata, but we may have to also allow
            this info
            to
            be dynamically generated and discovered.


            jeff


            -----Original Message-----
            From: Tamari, Yossi [mailto:yossi.tamari@sapportals.com]
            Sent: Monday, April 22, 2002 11:01 AM
            To: wsrp@lists.oasis-open.org
            Subject: RE: [wsrp][interfaces]: Actions vs. Events


            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-----
            From: Carsten Leue [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
            event 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 Message-----
            From: Alan Kropp [mailto:akropp@epicentric.com]
            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: wsrp@lists.oasis-open.org
            Subject: [wsrp][interfaces]: Actions vs. Events


            Hi - as promised in the interface call here is a definition of
            what I would
            define as "actions" and "events". We might use this as a
            starting point for
            the further discussion.


            Both actions and events are notifications for a WSRP service.


            1. Action:
            Actions are notifications that are triggered by the user.
            During the
            creation of markup the service encodes special URLs in the
            markup and
            associates data to them.
            The aggregator may need to rewrite the URLs to make them appear
            as links
            and redirect them to the aggregator. The end user can click on
            the links to
            trigger such an action. The aggregator then intercepts this and
            issues a
            call to the action handler defined in the WSRP interface
            together with the
            data the service encoded in the markup. As a reaction to this
            action the
            service may modify its state an regenerate its markup.
            The following points are important in this scenario:
            - the set of possible actions is defined by the server by
            embedding them in
            the markup
            - the end user triggers the actions
            - there is only one consumer of an action: the service that
            embedded the
            action into the markup


            2. Event:
            Events are launched programatically by components (the
            aggregator or one of
            the services). Events are not directly represented in the
            markup but issued
            by the components depending on their state (could be a timer, a
            system
            event or as a reaction to an action). Events can either be
            broadcast to all
            services or to a set of registered services.
            The following points are important in this scenario:
            - the set of receivers of events (listeners) is dynamic
            - if a service fires an event it needs to connect to the
            listeners. This
            might not always be possible due to firewall restrictions
            - i becomes possible to halt the system by (accidentally)
            introducing
            cycles in the event propagation


            Following this definition event handling is much more complex
            and error
            prone than action handling and the two serve different
            purposes: user
            interaction and notification.


            3. Relationship to WSRP
            From my point of view we should clearly distinguish between
            action handling
            and event handling in WSRP. Event handling easily becomes very
            complex and
            is not always required to support portal/portlet interaction.
            Maybe we
            should separate event handling out into an optional interface.
            My
            proposition would be to reuse the WSIA event handling
            interfaces for this
            but leave it up to the service to support this feature.
            Action handling however is abosultely essential for user
            interaction. For
            this reason it makes sense for me to include this functionality
            into the
            base WSRP interface.


            I added a PDF document to further clarify the distinction
            graphically.


            (See attached file: Action vs Event.zip)


            Best regards
            Carsten Leue


            -------
            Dr. Carsten Leue
            Dept.8288, IBM Laboratory B÷blingen , Germany
            Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401


            ----------------------------------------------------------------


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










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


Powered by eList eXpress LLC