[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I think the key point is that actions are sent by a portal to the WSRP service to trigger an "action" in that service as a result of a user acting on the markup previously produced by that service while events are notifications sent by WSRP services to other WSRP services or the portal. Best regards, Thomas Sasha Aickin <AlexanderA@plumtree.com> on 04/24/2002 06:15:40 AM Please respond to Sasha Aickin <AlexanderA@plumtree.com> To: Rich Thompson/Watson/IBM@IBMUS, wsrp@lists.oasis-open.org cc: Subject: RE: [wsrp][interfaces]: Actions vs. Events Rich, Your definitions specify that Events come *from* a Producer, whereas Actions go *to* a Producer. Does that mean that the portal sends an Action to Producer A in order to process the Event which came from Producer B? Sasha. -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Monday, April 22, 2002 9:33 AM To: wsrp@lists.oasis-open.org Subject: RE: [wsrp][interfaces]: Actions vs. Events 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> ---------------------------------------------------------------- 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