[wsrp-wsia] Re: [wsrp-interfaces] Re: [wsia][wsrp][wsrp-wsia jointinterfaces]: Analternative

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

Jeff,
  A couple of changes/additions to represent my point of view
-- i.e. a move away from terminology that represents producer things as
objects and towards representing terminology as references [from the perspective
of the consumer]:

client = an end user

consumer = an intemediary responsible for the aggregation and control of heterogeneous producer services, responsible for the interaction between the client and the producer services placed on the clients application interface.

producer = a container of producer services.   the WSIA/WSRP compliant service.  As consumers are anticipated to be aggregators, a producer represents 1 or more entity types.

producer service = the WSIA/WSRP compliant service ( aka. portlet )

entity type = a specific identifyable consumable function of a producer.  Producers publish  its entity types to consumers.  Consumers reference entity types to address its producer requests.

entity = a consumers particular usage of an entity type.  Consumers are anticipated to be aggregators, including aggregating multiple distinct instances or producer's entity type.  The entity represents each of these uses.  From a producer perspective, the entity identifies a particular consumer usage.  Producers will typically use this ID as a key to per usage state. 

reference:  A reference is an ID passed from the consumer to the producer to identify something known to consumer but maintained by the producer.

persistence reference:  A reference to persistent state managed by the producer.  Typically, a consumer will maintain a persistence reference for entities.

conversation reference:  A conversation reference is an ID that represents a particular (type of) conversation between the consumer and the producer.  There are 4 converstation IDs:  consumer to producer (application), thread of a consumer to a producer (session), consumer to an entity (entity), and thread of a consumer to an entity (entity session).

application reference:  A conversation between a consumer and a producer.  This conversation spans all consumer runtime use and all producer entities of this consumer.  For convenience [in making this unique], this ID is derived from the consumerID created by the producer during regristration.

session reference:  A subconversation within an application conversation between a consumer and a producer.  As such it is a shared scope between all entities within a given producer that a consumer chooses to group together.  This can be all the entities of the producer, a subset of entities, and even at the extreme one session per entity.  Typically, a consumer/producer sessions scope will be tied to a session maintained between the client and the consumer.

entity reference:  A conversation between a consumer and a particular instance of an entity [type].

entity session reference:  A conversation within a session with a particular instance of an entity [type]
 
 

template = a producer service, with initial settings specified

entity = an instance of a producer service ( potentially based on a template )

transient entity = an instance of a producer service

persistent entity = an instance of a producer service + persistent data

session scope = is a shared scope between all entities within a [given] producer that a consumer chooses to group together.  This can be all the entities of the producer, a subset of entities, and even at the extreme one session per entity.  [Typically, a consumer/producer sessions scope will be tied to a session maintained between the client and the consumer.]

Jeff Broberg wrote:

 

Mike -

I agree.  The current model, while clearly understood by many, I believe is being interpreted in slightly different ways, enough so, to be causing all the confusion and concern you mentiono.  I still believe a very high level diagram of the relationships between the client - consumer - producer would be extremely beneficial.  I am not sure how to draw that, as each conference call, the diagram I draw is different from the one before.  So for me, to get this all straight, I quess it comes down to definitions.  And from those definitions we can determine relationships, etc.  So, I took the liberty of using some of the statements that you made in your email, to see if they are agreed upon or not.  This will also be helping for the definitions in the glossary.  So here goes:

client = an end user

consumer = an intemediary responsible for the aggregation and control of heterogeneous producer services, responsible for the interaction between the client and the producer services placed on the clients application interface.

producer = a container of producer services

producer service = the WSIA/WSRP compliant service ( aka. portlet )

template = a producer service, with initial settings specified

entity = an instance of a producer service ( potentially based on a template )

transient entity = an instance of a producer service

persistent entity = an instance of a producer service + persistent data

session scope = is a shared scope between all entities within a producer that a consumer chooses to group together.  This can be all the entities of the producer, a subset of entities, and even at the extreme one session per entity. While, I know some of the definitions are terse, I am trying to see if the relationships are correct.  Because half the battle during these discussions is trying to understand what everyone is saying, especially when we are all working off of various interpretations of what the terms actually mean.  So, please, let me know, where my interpretation is wrong, and hopefully from these definitions, the relationships will be evident, and our efforts can proceed.jeff

-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Thursday, June 13, 2002 9:59 PM
To: wsia; WSRP; wsrp-interfaces@lists.oasis-open.org;
wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-interfaces] Re: [wsia][wsrp][wsrp-wsia joint interfaces]:
An alternative
 

I understood from the draft that a persistent entity referred to "remote portlet logic" + persistent data.   But does persistent entity also refer to
a particular consumer reference of such a thing?  My read of the spec was it did not -- that a transient entity did this.  I.e. I want to be able to
have 2 portlets in a consumer that share the same persistence record.  I have noticed that transient enitites (and objects in general) seem to be
leading to a lot of confusion in our expert group.  My proposal is an attempt to look at our problem from a different perspective to see if we end up
with something less confusing to ourselves and then hopefully to others.  So as I e-mailed in another message, I suggest we look at things less like
objects and more as scopes (references).

Furthermore I wasn't trying to say that one model has fewer references then another.  You are correct that the number of references are the same.
The difference is the number of reference that are maintained/managed.  When the consumer (is a portal) supplies the references, these references
will likely be able to be (er)constructed vs. maintained in some sort of key map table.  Likewise, the producer will only maintain those keys that
are pertinent to it.  I.e. if there is no transient state it merely ignores the reference vs. had to figure out it should manufacture a constant
dummy one for the consumer.

Lastly, I think we are on the same page regarding sessions.  I agree that the session scope is a shared scope between all entities within a producer
that a consumer chooses to group together.  This can be all the entities of the producer, a subset of entities, and even at the extreme one session
per entity.

In the end, my proposal is just a concrete attempt at asking ourselves should we look at the problem a little differently since the current model
continues to generate confusion and concern?  At the least, I hope that looking at this problem from another perspective allows us to clarify/improve
the current draft.  However, I am also open to going down this/a different path if we feel like the end result is simpler or less confusing.
     -Mike-
 
 

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>