OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-coord message

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

Subject: RE: [wsrp-coord] Questions about events

-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Wednesday, August 13, 2003 1:45 AM
To: wsrp-coord@lists.oasis-open.org
Subject: Re: [wsrp-coord] Questions about events

"Supporting properties" is an extension/upgrade to our existing property mechanism that allows portlets to send/receive data values between the consumer and other portlets.  I.e. Rather then a portlets data depending on either its current model state or values passed in the request from the client, "supporting properties" allows a portlet to in addition depend on the state of another portlet.  This is commonly used to orient  a set of related portlets within a page.  For example I may have various news syndication portlets on a page that I would like to display current articles based on a new category I can set in another portlet -- i.e. one portlet to choose the focus while the other portlets display article/data constrained to this focus.  

As Yossi has pointed out any general purpose event mechanism we define should be capable of also supporting transmitting portlet state.  There are reasons however to represent/model this function independently:
    a) better fit for the user case(s).  The above scenario not only requires the ability to communicate new values when state changes but also initial values.  For example the portlet that sets the focus likely has a customization property for setting the default topic.  Its more natural to ask for these initial values directly vs. sending an event.  
    b) provides a simpler programming/design model.  Events typically represent actions [verbs].  Its certainly possible to represent data [changes] as actions.  Choosing not to reduces the portlet developers design decisions to merely what data do I want to expose vs. what events/actions will I communicate.  This has an important impact on the page developer/end user/receiving portlet developer when they are wiring based on state as the firing portlet will likely have many events that carry similar state.  Mapping data value X to data value Y is a simpler model for such users then Mapping data value X from event M and data value X from event Q and data value X from event W to data value Y.  Basically, "supporting properties" constrains portlet developers [makes it simpler for them to design their portlets] and results in simpler systems overall.
[Yossi Tamari] I have a few comments regarding this:
First of all, as you said at the end of the message, the properties a portlet exposes for coordination is completely different than the properties it exposes for customization. Therefore the initial state is as much a problem with properties as it is with events.
Also, as you said bellow, normally changes will be generated
 as a result of a user interaction. User interaction is much more naturally described by a verb (event) than by the state change that it causes to a specific portlet. In other words it makes more sense to send an event ItemSelected("umbrella"), than to expose a change to the internal property MyThirdSelectedItemInTheThirdPaneOfTheForm with the value "umbrella". (In other words, in order to make sense, exposing a portlet properties will probably require the portlet to map each of its properties to a nice external name. We don't even know if this portlet has a property for this at all - it may be that when "umbrella" is selected, the only thing that changes is the navigational state (or simply a form is generated with "umbrella" in one of the fields.
 the complex mapping you describe can be needed in the property model as well, since it is very common to require two properties to need to change together (like SelectedItem and Price).

That all being said, though I prefer [and think many portlets will prefer] the state interchange model, its okay if we decide to support both.  I.e. the premise that there are things that are best represented exclusively as actions/verbs. However, if we support both I would expect it to be differentiated.  We would recommend that portlets not use Events to model state interchange/data changes rather events would be used to communicate all other logical portlet actions.
[Yossi Tamari] Of course I disagree with this recommendation. Events should be used to model user interactions. State changes should be used to model logical state changes that have some application logic associated with them. This means state changes are better for more complex, strongly tied, portlet applications, while events are for more loose, UI based coordination. 

As for your questions:
1. Agree with Yossi, namespace:name.
2. Well its the name of the event + associated data.  The data is specified by the event.  It has the same generality as our ModelDescriptions -- i.e. can represent types [its not attribute/value].
3. Actually, anything can send an event.  The most likely culprits are portlets and the consumer itself.  Basically an event is as stated in 2: a namespace:name + data.  As we say later that a broker sits between the sender/receiver we don't ultimately care how many different channels/formats the broker can listen on.  We, obviously will define the WSRP protocol for sending an event from the portlet to the broker.  Namespacing will likely be a problem in this system as it will be difficult to guarantee uniqueness.  We may have to define a convention ala Java, namely company.producer.
4. Actually, any part of the consumer/application can receive events.  Again, most typically its other portlets or the consumer itself.  We, obviously, will define the WSRP protocol for posting an event from a broker to a portlet.
5. No, they are only aware of events.  A event can optionally carry data that publishes a service [port] for the receiver to use for P2P comunication.
[Yossi Tamari] There are other reasons a receiver may want to know who the sender is. I agree that we can leave this to portlets to define on their own, but there may be value to defining this as an optional parameter in the protocol.  
6. We will likely have to define mechanisms for both synchronous and asynchronous sending of events from portlets.  We will likely only support portlets receiving synchronous events.
7. Leaving out for the moment out-of-band/asynch events, the scope is "Before Rendering".  Event processing, like actions will have to complete before any portlet rendering occurs.  As an event change is typically kicked off as a result of an action [though a consumer will have the rights to send an event when no action has occurred] the scope can largely be thought of as "Action".  This becomes even more true as we have to deal with action/event redirect.  We certainly want an action to be able to return an event & signify a redirect -- with the likely behavior being processes the event chain then do the redirect.  Its unclear whether we want event processors to be able to return their own redirects [I hope not].
8. There is an event broker.  For in-band events the consumer [not the producer] knows the identity of the broker.  For out-of-band events the producer will need to know this identity [or at least a proxy for it.  At a minimum brokers will be required to dispatch posted events to portlets that have published that they want to receive that event [by name].  Many brokers will implement/support a mapping system.  I.e. a portlet publishes: events it sends, events it receives [by name(space)], and  mappable events.  Mappable events describe a logical event the portlet would like to receive and requires the broker support defining/dispatching from one event structure to the other.
9. Yes, just like you described.
10. Because there is a broker it is Pub/Sub.  To handle the case where the receiving portlet knows the particular event it wants to receive, then Yossi's namespace wildcarding seems interesting though we will have to balance this with worries that portlets will use this too liberally and cause performance problems.
11. Yes, its part of the "portlet description".  We will have to decide whether to carry it in PortletDescription  i.e. getPortletDecription()/getServiceDescription() or via a separate call.  If the former we likely would want to pass a boolean indicating if we want the information.  If the later the PortletDescription would likely carry a boolean indicating such information exists.
12. One of two ways:  either it publishes explicit events it wants to receive or it publishes logical [mappable] events.  

One question you don't ask about is authorization/security.  Its easy enough for a set of cooperating portlets within a single producer to restrict access to interchanged data by merely not carrying any data in the event.  But how does this work when the porlets aren't in the same producer?  The downside of the broker model is the sender has no control over the who are the receipients of its information.  Will we need to build some support here?
[Yossi Tamari] No. If a sender wants too have security on its payload, it should use encryption on it and make sure only the intended receivers have the key. This is outside of our scope.

And finally, to keep the state interchange model in sync let we reask your questions:
  1. Are published state categorized?
    • Not explicitly.  State is implicitly namespaced by the producer/portlet that publishes it.
  2. Is in the payload of an interchanged state?
    • Its a property list.  GetPortletProperties gets the initial state from the portlet. A portlet posts updated properties by returning a list from an action or a setPortletProperties call.  Likewise a portlet receives updated properties via the setProperties call.  I.e. setProperty is passed some new values that update the protlets internal model.  A side effect of this update may be to change some of the model the portlet publically publishes.  Hence it returns a property list so the other portlets that depend on these [new] values can be notified.  
  3. Who can post state?
    • Portlets.  Though like events, a receipient of state, doesn't know where it came from -- though its likely from another portlet this is not necessarily the case.
  4. Who receives and processes state?
    • As with events, any part of the consumer application can receive/process state.  Typically, its other portlets.  
  5. Are senders and receivers aware of each other?
    • Typically no.  However, just as in the case where events transport data we may have to concern ourselves with allowing the senders to authorize the receipt of state.
  6. Are state interchange synchronous or asynchronous?
    • State interchange can only be synchronous.  If/where asynchronous communication is needed events must be used.
  7. What is the scope of an state interchange delivery?
    • Same answer I gave for events above, namely "pre-render". In this case its more suitable to use "pre-render" vs. action as consumers will commonly get/transfer the initial state the first time the scope [page] is accessed and then rely on actions to communicate changes to this state.
  8. Is there an state interchage broker, or the producers distribute the state?
    • There is a state interchange broker known/managed only by the consumer.
  9. Do we need to support chaining state interchanges (new state as a response of a setPortletProperties)?
    • Yes.  And we will have to require the consumer deals with cycles/loop detection.
  10. What is the distribution model, P2P or Pub/Sub?
    • It is Pub/Sub.  The portlet publishes its "public" model.  Data interchange requires a broker that supports mapping from one model to another.  A portlet doesn't listen for specific data change values of other portlets.
  11. How does an portlet publish what state it can supply/receive? 
    • Similar answer as events, its part of the portlet description.  We will need to decide whether its shipped directly with the portlet description or the portlet description merely indicates this description is available.  
  12. How does an portlet binding/receive state changes?
    • The portlet merely publishes what its public model is [i.e. properties that are settable].  If the consumer supports data wiring the portlet will receive setPortletProperties with appropriate values at the appropriate time.
One thing we will need to consider with respect to the state interchange model is whether we want/need to clearly differentiate between publishes entity persistent state for the purposes of allowing the consumer to implement the customization UI vs. publishes entity state [be it persistent or transient] for the purposes of expressing its public model in use for this state interchange mechanism.  I don't think an entity would want the all customization data to become public from an interchange point of view merely because it defers/prefers to let the consumer control this UI.  We should be able to account for this easily by separating the published descriptions.  For identification/security reasons we may have to also separate the  get/set APIs.   


Alejandro Abdelnur wrote:
I'm not sure I understand what it means support properties then, could  somebody explain it to me?



On Monday, August 11, 2003, at 01:44  AM, Tamari, Yossi wrote:

1. With name and namespace.
2. XML.
3. What you said.
4. What you said, but the consumer is also part of the cycle, and can  do stuff.
5. No. (Maybe we should add a parameter that identifies the sender, if  we have such an identifier, listeners can always ignore this).
6. What you said.
7. What you said.
8. What you said.
9. What you said, but the consumer can decide to stop distributing  events for a request at some point (what's the point, if the user  request has already timed out?). We should probably define a minimum  number of cycles a consumer must respect.
10. What you said. A portlet can also subscribe to an event namespace,  and got all the events in this namespace.
11. The "portlet descriptor" you suggest sounds like Java. In the  PortletDescription.
12. What you said.

I like this quiz, but I think it ignores the fact that there is a  group in our SC that really feel we need to support properties, at  least together with events. I am fine with supporting just events.


-----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: [wsrp-coord] Questions about events

Hi there,

I have the impression we are a little unorganized right now :).

Following is a list of questions I think it will help us to define the
scope and some high-level characteristics of the eventing model we want
to build. Once we agree on the answers to these we can create a second
set of questions based on the answers to the first set and so on.

  1. Are events categorized?
  2. What is in the payload of an event?
  3. Who can send events?
  4. Who receives and processes events?
  5. Are senders and receivers aware of each other?
  6. Are events synchronous or asynchronous?
  7. What is the scope of an event delivery?
  8. Is there an event broker, or the producers distribute the events?
  9. Do we need to support event sequences (new events as a response
     of an event processing)?
10. What is the distribution model, P2P or Pub/Sub?
11. How an event-creator and an event-listener advertise the events
     they create/produce?
12. How does an event-listener do a binding to receive events?

My answers:

  1. Yes, with a name.
  2. String name-value pairs.
  3. Portlets, through the producer.
  4. Portlets, through the producer.
  5. No.
  6. Synchronous, upon delivery the call is blocking until ends
  7. a user request, an event is sent and processed during a single  user
  8. Yes, the consumer acts as a broker.
  9. Yes, they broker keeps distributing/receiving/distributing events
until there are not more events.
10. Pub/Sub, using the event category name.
11. In their portlet descriptor.
12. Mapping in the consumer (a la user categories)

I hope this approach helps.


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