[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][interfaces]: Actions vs. Events
what happens if a producer returns a null markup, wouldnt that be considered invisible ? -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wednesday, April 24, 2002 8:46 AM To: wsrp@lists.oasis-open.org Subject: RE: [wsrp][interfaces]: Actions vs. Events The way we looked to factor the portTypes in WSXL would allow a portal to consume those types of services by allowing services to implement a subset of the WSRP portTypes. A service only implementing the event oriented portTypes would not participate in the output generation processing, but would be included in any processing in an event brokering service of the portal. "PAVLIK,GREGORY (HP-NewJersey,ex2 To: Rich Thompson/Watson/IBM@IBMUS, )" wsrp@lists.oasis-open.org <gregory_pavlik@h cc: p.com> Subject: RE: [wsrp][interfaces]: Actions vs. Events 04/24/2002 08:13 AM Would this imply that portals consuming these kind of services would have to be aware of more than just WSRP? -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wednesday, April 24, 2002 8:09 AM To: wsrp@lists.oasis-open.org 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. "PAVLIK,GREGORY (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 AM 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 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. Cheers, Sasha. -----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. dave 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. Yossi. - 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. 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 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 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: <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:/ ---------------------------------------------------------------- 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