Data oriented coordination use case

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

          Here is an interesting coordination use case that should challenge
our use of eventing.  I describe from the perspective of a current implementation. 
 I would like to discuss how/why this general use case can be implemented
using events.  I would also like to discuss how this specific implementation
style can be extended to provide its function in a world using WSRP and pre-existing
portlets coded to this model.  [I.e. the first question merely asks us to
articulate equivalent function using our coordination mechanism; the second
question challenges us to adjust our description so it can run/work side
by side with a data/parameter oriented coordination mechanism unbeknowst
to the end user].  
 
 The consumer is a commercial Portal product.  It supports a concept called 
Page Parameters.  Page parameters are values defined [by a page developer] 
at the portal page level and wired to inputs of portlets on a page.  Portlet 
inputs are declared as part of the portlets meta data. Once defined/wired, 
these parameters can either be passed directly from the client on the URL 
to the page or if missing in the URL/request defaulted to a preset [page] 
value.  As the page processes the portlets in the page, the values from the 
page parameters [whether they came on the URL or its the default] are transferred 
to the portlet.  For efficiency reasons these values are transferred as additional 
state vs. an action parameter.  I.e. a portlets public parameters don't cause 
computational side-effects, rather they define part of the portlets render 
state.  In a sense they are public navigational state -- i.e. the consumer
 can see and set values for the portion of the navigational state that is
public.

The above described function is powerful/useful for pages where some/all
of the portlets share a common type of input value.  For example you can
conceive or a variety of stock analysis portlets on a stock analysis page.
 Each of these portlets is independent of each other [many coming from different
producers].  What they have in common is each focuses on presenting its type
of analysis for a single stock.  Each portlet indicates it has a a public
parameter representing the stock symbol to be analysed [no commonly is needed
in the naming of these parameters].  The page is developed with a page parameter
representing the stock symbol and defaulted to the company building the portal
stock symbol.  This page parameter is wired in turn to each of the portlets
public parameter [using a UI invoked from the portal page].  Once this is
completed, links can now be made from other pages, portlets, or even externally
using something like bookmarks  to this analysis page.  Each link represents
a different stock by encoding the stock symbol [page parameter] in the request
parameters.
     -Mike-