[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-coord] Events vs StateChanges
Hi, On 7/22/2002, Tim Granshaw from SAP, a WSRP member at the time, sent a "Cooperating WSRP Services" business scenario document to the WSRP alias. It described a use case for coordinating portlets that may be more realistic than the one we have been using. The document seems to have been lost somehow, since it is not currently in the Business Scenarios folder in Kavi, but I suggest we look at it and see if we feel we should use it as the basis for our discussions (we will probably need to extend it however). Since the Email archive seems to be still down, I can not find and link to the original email, but I will attach the original document. Yossi. -----Original Message----- From: Alejandro Abdelnur [mailto:Alejandro.Abdelnur@Sun.COM] Sent: Friday, August 08, 2003 3:54 AM To: wsrp-coord@lists.oasis-open.org Subject: Re: [wsrp-coord] Events vs StateChanges I'm not sure on the validity of the use case or how realistic it is. * Portlet showing a streaming data: We need a plugin to show this in the user-agent, remember the portlet generates markup. * User clicking on passing car: We need the previous streaming data to send coordinates+carInfo. We need previous plugin to pop to markup object model the info about the car. We need some scripting to collect this info from the object model. We need to push that info back to the consumer, using a portlet created URL. This will make the user-agent to request a new portal page, losing current streaming data. IMO, this is solved by other technologies, not WSRP. As many of the TC members are from ISVs companies (CRMs, ERPs, CMs, etc), could be possible to get a real and simple business use case. I don't know, for example something like a shopping cart portlet interacting with a inventory portlet and a catalog portlet. Thanks. Alejandro On Wednesday, August 6, 2003, at 02:17 AM, Tamari, Yossi wrote:Hi, I do not think we should go too far with a. I do not object to defining a set of events that are within WSRP, as long as the protocol does not depend on them, and does not define what the consumer should do if they happen. I am glad we agree that d and e are private cases of b and c. I think our problem is that we are arguing on points of view rather than facts, and therefore none of us is "correct". Just as it can be claimed that since many events contain parameters (data), it makes sense to represent them as state changes, it also can be claimed that since many such events pass data that the source/destination may not perceive as representing its state, it does not make sense to represent them as state changes. For example, there may be a stateless portlet (say that it just shows a live feed of a car race, but the viewer has no control over it, as in practically every telecast), and it wants to be able to let other portlets know when the user selects an item in it (the user clicks on a car, expecting to see the driver details, from a separate DB. The telecast portlet knows to recognize car numbers in a passive way, and raise an event). If we have Events, it can just send an event (CarSelected[integer]). If we have State Changes, it will have to expose a virtual property (SelectedCar [integer, readOnly]), and now a portlet developer needs to think about what are my (virtual) properties, are they read/write/both/none etc. Also, if we expose CarSelected as a property, if the user clicks on this car again, since the telecast portlet does not keep track of which car was previously selected, it will raise the "property changed" flag even though this did not happen. Of course its behavior! s ! will be the same with the events model, but than at least there is no pretense of this being a state change. It is simply a broadcast of the fact that a user interaction happened, that other portlets may be interested in. I do not agree that it is more difficult for the developer (you used the word user, but that is misleading), to try to match an event, with a logical name, and a logical set of parameters, than to try to match properties between two portlets, when at different (logical) events a different subset of these properties may be changed, and there is a implicit semantic meaning to the subset of the properties that was changed at a time. Let me explain this by extending the previous example: Lets assume the telecast portlet exposes the SelectedCar read only property, and it wants to play nice, so it also keeps the state of this property in the session so that it does not broadcast a change notification when the same car is clicked again. Now the currently selected car gets disqualified. The telecast portlet wants to do two things: tell other portlets that a car was disqualified, and deselect it (since in its logic a disqualified car stops existing). It must now change two properties: selectedCar should change to NULL, and DisqualifiedCars [Array of Integer, readOnly] should change to reflect the addition of a new disqualified car. The DisqualifiedCars array should be also maintained in the session... It can be suggested that DisqualifiedCars can be replaced with LastDisqualified [Integer, readOnly], but this will not work when two cars are disqualified at once, or LastDisqualifiedCars [Array of Integer, readOnly], which may work but really does not make sense as a property. Now bear in mind that all these complexities must also exist in the "listener" portlet: It must expose exactly the same array variables (since it is really too much to expect from the consumer mapping to be able to maintain a mapping from a DisqualifiedCars property to a LastDisqualifiedCars property. All this would be much simpler if the telecast portlet just exposed two events: CarSelected and CarDisqualified [Integer]. In this example it would raise three events: CarSelected(NULL), and two CarDisqualified(X). Before someone else says this, I know CarDisqualified does not work well as an in band event, but this is just an example (imagine that these portlets are actually being used by the referees, and they can disqualify cars by portlet interaction). I do think we should care (high priority) about consumers who do events/state-changes but not mapping. However, I agree that if we design our solution correctly they will fit in seamlessly. We should not need to add extra functionality for them. Yossi. -----Original Message----- From: Michael Freedman [mailto:Michael.Freedman@oracle.com] Sent: Wednesday, August 06, 2003 2:58 AM To: wsrp-coord@lists.oasis-open.org Subject: [wsrp-coord] Events vs StateChanges Last week we discussed the value of defining an in-band event model vs. a state changed model. Here are some further thoughts: I see the following types of events that could be dealt with: a) WSRP events -- these are well known events that WSRP defines -- currently these "events" are implicit in our protocol being explicitly represented as lifecycle calls [and their parameters/returns]: i.e. perform action, render. Examples of such events we might consider adding are Begin/EndTransaction. I.e. placing a series of calls between portlets within a consistent transaction. [Important once we start propagating state changes/data across portlets?] b) Mappable events -- these are events typically defined by the producer [though also can be done by the consumer] that the receiving portlet is not aware of. Consumers provide a facility to declare mappings from one portlets event namespace to anothers. Yossi indicated he will provide some examples of this. c) Known events -- these are events typically defined by the producer [though also can be done by the consumer] that the receiving portlet is aware of. No mapping is necessary, consumer merely route the events to interested parties. Commonly used within a producer to build cooperation within a known set or portlets or by producers building building-block portlets that it hopes other producers will include in a cooperating set. d) Mappable state changes -- probably the most common form of mappable event where the consumer acts as a mediator for data exchange between two portlets. I.e. an action results in state changes, a portion of which a portlet wishes to publish [e.g. bug report number]. The consumer understands that the portlet "publishes" this data and supports mapping it to similarly published state in another portlet. e) Known state changes -- like known events, the consumer doesn't provide any mapping -- the sending/receiving portlets understand/agree on the data being exchanged via prior knowledge/agreement. I agree with Yossi that Mappable events are a generalization of mappable state changes. However, I am not yet convinced that our in-band mechansim needs this generalization. For me there is a developer and user cost/complexity to introducing MappableEvents here. As I don't yet have an example of a pure event -- one that indicates no state change/has no associated state -- A mappable event leaves the developer in the quandry of whether to define a new event for every state change or whether to expose the state changes via a common event [e.g. UpdateModel]. The later has the benefit of having a single form allowing the consumer to present a simplified user interaction -- map from this portlets published data to the other ones. When individually named events are involved the user must first choose the event they want to map and then map the data between the events. For me, this is an unnecessary complication to the user interaction. Until I see/understand the use cases for in-band mappable events that aren't satisfied by mappable state changes my preference is to limit our in-band mechanism just to mappable state changes. As for (c) and (e) -- known events/state changes -- should we care and if so what is its priority? Mappable events/state changes is a superset of the known case -- should we care and if so is it a priority to support Consumers who merely want to deal with distpaching/managing known events/state changes but not mappable ones? -Mike- You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/ leave_workgroup.php You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/ leave_workgroup.phpYou may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/leave_workgroup.php
You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]