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

"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?
  2. Is in the payload of an interchanged state?
  3. Who can post state?
  4. Who receives and processes state?
  5. Are senders and receivers aware of each other?
  6. Are state interchange synchronous or asynchronous?
  7. What is the scope of an state interchange delivery?
  8. Is there an state interchage broker, or the producers distribute the state?
  9. Do we need to support chaining state interchanges (new state as a response of a setPortletProperties)?
  10. What is the distribution model, P2P or Pub/Sub?
  11. How does an portlet publish what state it can supply/receive? 
  12. How does an portlet binding/receive state changes?
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]