[wsrp-interfaces] Re: [wsrp-wsia]: Updated alternative API

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

Alejandro,
Thanks for the questions/comments.

Q1: What is an entity reference?  An entity reference is an identifier that
distinguishes between different consumer instances of the same type.  A portal
wants to have many distinct instances of a portlet in its structure.  One
instance may be the toolbox template.  Another may be the portlet on a page.
And finally there may be multiple instances of these portlets on a page.  You
may ask yourself how does this differ from a persistence reference?  Though its
common that there is a one to one mapping between a persistence correspondence
between an entity reference and a persistence reference this is not always so.
It should be possible to have two consumer portlet instances refer to the same
persistence record.  I.e. if you adjust the (persistent) settings in one the
other is impacted.  However, while running, each "entity" may maintain distinct
transient (runtime) state to reflect what is going on in that particular
portlet on the page at a given time.

Q2:  Good question.  The answer I believe depends on your taste.  My taste is
that parameters that are explicit to the operation are reflected explicitly in
the API.   Contextual parameters appear in the context object. I feel this
makes the API more "readable" in that a developer can look at the call and see
what is the focus of the operation.  The taste question is what to do when
these overlap?  I chose to keep my goal of readability -- others might argue
for merely reusing the context.  One things to note: I primarily include the
context so the method will have access to the session and user identify.

Q3: Can we see the complete API?  I will try and have this for the F2F, if not
earlier.

Q4:  What is the use case for consumer sending session data to the producer?  I
don't have an answer for this.  This is here because its in the API draft Rich
and Carsten put together.  I believe/suspect it has to do with WSIA having
broader requirements then we do one of which is allowing an intermediary
between a consumer and a producer.

Q5: Where is WindowState in FragmentRequestData?  I obviously left out details
here.  The API draft Rich and Carsten put together includes the WindowState in
the Mode object.  I intend(ed) to leverage this.

Q6: What are FragmentResponseProperties?  They contain the equivalent of the
response defined headers returned by an HTTP request.  I.e. we can't assume we
are running solely in an HTTP environment so need a direct mechanism for
returning the meta data about the response.

Q7: How are you proposing session creation for different scopes?  I am not sure
which scopes you refer to.  The idea is the consumer is logically maintaining
two types of session conversations -- one on a per producer level and one on a
per entity level.  Though the per entity level could always be modeled in a
namespace within the per producer level some folks were objecting.  Hence the
suggestion to have the consumer represent these two different level
explicitly.  Now, the key here is that these two ids merely represent
conversational levels.  They aren't the physical producer/entity session
itself.  The producer/entity creates/maintains an internal physical notion of
session(s).  We "burden" the producer with having to maintain a distinct map
between these conversational levels and these internal physical realizations.
I.e. I need to lookup using the sessionRef or the entitySessionRef the actual
reference to my internal session.  Personally, I don't see how this adds a
greater burden then in the draft proposal from Rich and Carsten as an ID lookup
has to occur in that situation as well.

Suspecting that this may not be totally clear let me use an example:
User X is logged into the portal.  User X starts interacting with the portal
which results in the portal talking to the portal service.  On each request
sent by the Portal to the service, a sessionRef representing the conversation
between User X/Portal and the service is sent.  If the API involves
"entities"/"instances" (such as getFragment) an entitySessionRef is also sent.
The portlet service/portlet is free to create an internal representation of
session whenever it chooses.  If it wants to wait until it actually needs
session state -- so be it.  Its sessionRef to session map is null.  When the
portlet/service decides a session is needed it merely creates such an internal
representation and maintains a key mapping using the appropriate Ref passed by
the consumer so it can find it again.  I.e. Refs define conversational scopes
that producers use to maintain mappings to internal mechanisms.

I hope this helps,
     -Mike-