RE: [wsrp-coord] Questions about events

-----Original Message-----
From: Michael Freedman 
  [mailto:]
Sent: Wednesday, August 13, 
  2003 1:45 AM
To: 
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.
Finally, 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:

  
    
Are published state categorized? 
    
      
Not explicitly.  State is implicitly 
      namespaced by the producer/portlet that publishes it.

    
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.   

    
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.

    
Who receives and processes state? 
    
      
As with events, any part of the consumer 
      application can receive/process state.  Typically, its other 
      portlets.  

    
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.

    
Are state interchange synchronous or asynchronous? 
    
      
State interchange can only be synchronous. 
       If/where asynchronous communication is needed events must be 
      used.

    
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. 

    
Is there an state interchage broker, or the producers distribute the 
    state? 
    
      
There is a state interchange broker known/managed 
      only by the consumer.

    
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.

    
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.

    
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.  

    
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.   

      -Mike-

Alejandro 
  Abdelnur wrote:

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

Thanks. 

Alejandro 
    

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. 
      

    Yossi. 

-----Original Message----- 
      
From: Alejandro Abdelnur [mailto:] 
      
Sent: Friday, August 08, 2003 3:54 AM 
To:  
      
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 
      
processing. 
  7. a user request, an event is sent and 
      processed during a single  user 
request. 
  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. 

Alejandro 

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