Re: [wsrp-coord] Questions about events

[Michael Freedman <Michael.Freedman@oracle.com>]

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

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.

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

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.   

      -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: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 
> > 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 
>   
>