Title: Message
Hi
Eilon,
It
seems to me the Consumer still doesn't really need a say in how the Producer
implements the search service runtime model. It's true that if the
Producer creates all of these transient entities, there is the issue of when it
is "safe" to destroy them. Transient entities don't have an
inherent lifecycle, but the sessions which talk to them do...so, when these
sessions have timed out, the Producer is able to determine that a transient
entity is no longer a party to any active session. Would it be valid
to say that the Producer, at that point, may assume the transient entity is
stale and destroy it? I guess this is a variation on reference counting/GC
that Java developers are already familiar with.
I
don't think it's unrealistic to expect the Producer to employ intelligence like
this to efficiently manage its entities.
Alan
-----Original Message-----
From: Eilon Reshef
[mailto:]
Sent: Tuesday, June 11, 2002
11:36 AM
To: 'Alan Kropp'; ;
Subject: RE: [wsrp] [wsia] [wsrp-wsia
joint interfaces] agenda for Tuesday 11 June
Alan,
I think that one example scenario is a search results page, say for
hotels, that dynamically displays multiple maps - a map for each hotel found.
Assuming that maps are remote services, and assuming that the number of
results is dynamic, the Consumer needs to create multiple copies of the map
service. If we allow the Producer to determine the persistence state of those
maps, that would mean that someone will have to take care of the lifetime of
those maps. The Consumer can't, because the page may be gone without the
Consumer never knowing about it (the user closes the browser window). The
Producer can't, because it can't tell whether the Consumer has stored a
reference to those maps as part of a design-time description of a user
page.
Is that along the lines of what you were looking
for?
Eilon
-----Original Message-----
From: Alan Kropp
[mailto:]
Sent: Tuesday, June 11, 2002 2:18
PM
To: '';
''
Subject: RE: [wsrp] [wsia] [wsrp-wsia
joint interfaces] agenda for Tuesday 11 June
I find that the question of a Consumer creating a persistent
vs. a transient
entity to be a little
troubling.
Isn't the Consumer primarily interested in getting a handle
to an _entity_
(be that transient or persistent),
and then using that handle to direct
subsequent
requests to?
Could we not consider persistence and transience to be
entirely Producer
concerns? I understand from
the sequence in the spec (pp. 6-8) that the
only
supporting scenario for the Consumer calling "createTransientEntity"
is
out of an effort to maximize the efficiency of
the conversation with the
Producer. This is a
worthy goal, of course, but the Producer should
advertise its interaction behavior in the meta-data, right?
Presumably the
Producer uses the meta-data to hint
to the Consumer the way(s) the Consumer
SHOULD
structure invocation requests efficiently.
I'd love to see some more convincing scenarios to support
pushing the
persistent/transient aspect of the
conversation out to the Consumer.
Otherwise, I'd
love even more to limit our specification to a single
"createEntity" call.
Alan
-----Original Message-----
From:
Carsten Leue [mailto:]
Sent: Tuesday, June 11, 2002 2:19 AM
To: Gil
Tayar
Cc: thomas klein6;
'';
''
Subject: RE:
[wsrp] [wsia] [wsrp-wsia joint interfaces] agenda for
Tuesday 11 June
Gil -
1-3: the consumer MUST explicitly create entities (transient
or
persistent). It can decide to create sessions
explicitly if it wants to
share them amongs
entities, otherwise it can let the producer create
sessions on the fly.
4: the decision to have
multiple entities per session is up to the consumer
who make this choice based on the producer's metadata. e.g think
of
portlets that form a shop together. These would
want to share a session
with each other. But the
consumer could decide to have two shops of the
same
type on the same page. Then there would be two sessions and only the
consumer could know what portlet shares what
session.
5: The consumer should create a session
before issuing a getFragment call.
The entity is
created whenever necessary.
6: A Session is a bucket
that holds some data (physically on the provider)
and times-out after a while. A transient entity is a remote portlet
that
does not store any data in a DB.
Hope that helped.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
|
| Gil
Tayar |
|
|
<Gil.Tayar@webcol|
|
|
lage.com> |
|
|
|
|
| 06/11/2002
09:28 |
|
|
AM
|
|
| Please respond
to|
|
| Gil
Tayar |
|
|
|
|---------+---------------------------->
>---------------------------------------------------------------------------
------------------------------------------------------------------|
|
|
|
To: Carsten
Leue/Germany/IBM@IBMDE
|
|
cc: "''"
<>,
"''"
<>, Thomas|
|
Klein6/Germany/IBM@IBMDE
|
| Subject: RE:
[wsrp] [wsia] [wsrp-wsia joint interfaces] agenda
for Tuesday 11
June
|
|
|
|
|
>---------------------------------------------------------------------------
------------------------------------------------------------------|
Carsten, could you clarify some things for me?
1. If sessions and entities are orthogonal, what SHOULD the
Consumer do?
2. SHOULD it create a transient entity
_and_ a session?
3. MUST it do so?
4. Who gets to decide whether there are multiple entities per session
or
multiple sessions per entities?
5. When SHOULD a Consumer create a session and when a transient
entity?
6. What _is_ a session, logically? What _is_
a transient entity?
Gil
-----Original Message-----
From:
Carsten Leue [mailto:]
Sent: Tuesday, June 11, 2002 08:45
To: Alan
Kropp
Cc: '';
''; thomas
klein6
Subject: Re: [wsrp] [wsia] [wsrp-wsia joint interfaces]
agenda for
Tuesday 11 June
Alan - some first thoughts
1. the general concept is that entities (transient or
persistent) and
sessions are orthogonal. There might
be mulitple entities per session and
(at least for
persistent entities) multiple sessions per entity. An example
for the first case would be that entities share session
data within the
same user request. An example
for the second case are portlets on a common
page
(group page) that are access simultaneously by multiple users.
A transient entity differs from a persistent entity in that
its data does
not persist and its lifecycle is
coupled with the session life cycle.
2. Eilon pointed out in a comment to the interface proposal
that batch
processing is already part of SOAP. I was
not aware of that and will look
it up until the
call.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
|
| Alan
Kropp |
|
|
<akropp@epicentri|
|
|
c.com>
|
|
|
|
|
| 06/11/2002
01:54 |
|
|
AM
|
|
| Please respond
to|
|
| Alan
Kropp |
|
|
|
|---------+---------------------------->
>
---------------------------------------------------------------------------
------------------------------------------------------------------|
|
|
|
To: "''"
<>,
"''"
<>
|
|
cc:
|
| Subject: [wsrp] [wsia]
[wsrp-wsia joint interfaces] agenda for
Tuesday
11
June
|
|
|
|
|
>
---------------------------------------------------------------------------
------------------------------------------------------------------|
I think we'll have plenty of discussion around the merged
document Rich and
Carsten put together.
The two main issues I see that have arisen on the email
lists are:
1. What is the difference between transient entities
and sessions, and is
there enough of a distinction
to warrant including both in the
specification?
2. There are efficiency concerns around the use of
arrays in the method
signatures, basically to enable
batched requests for network efficiency.
Call-in numbers:
USA Toll Free
Number: 877-718-0936
USA Toll Number:
+1-712-923-6878
PARTICIPANT PASSCODE:
563151
Alan
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
