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:]
Sent:
Thursday, June 13, 2002 9:59 PM
To: wsia; WSRP;
;
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>
