[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
I would also think it makes sense to move the description-related
operation away from the entity management factor, as the latter supports
(the additional feature of) consumer-managed entities.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, October 09, 2002 1:16 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
Everything returned by getEntityDescription is also returned for POEs by
getServiceDescription. I would also not be against moving this operation
into the ServiceDescription porttype if we rename it to something like
Descriptions (& consider whether getEntityPropertyDescription moves
there also). I thought we included all entities being able to be
referenced multiple times on the same page. If additional clarity would
be helpful, would you be willing to suggest what and where?
"Tamari, Yossi"
<yossi.tamari@sap To:
wsrp-wsia@lists.oasis-open.org
.com> cc:
Subject: RE: [wsrp-wsia]
[I#106] Uniqueness of entityHandles
10/09/2002 01:00
PM
Why would the producer expose the EntityManagement portType? Maybe for
getEntityDescription.
But I think I am finally getting your point: If a consumer does not want
to create different clones of itself it simply needs to not expose this
portType, and the consumer automatically understands that it can use the
POE multiple times. Do you think this is stated clearly enough in the
spec? and what about getEntityDescription? is it unimportant for POEs?
Yossi.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, October 09, 2002 6:45 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
For (2) as you have stated it, I would question whether the Producer
would even expose the EntityManagement portType. I think the more
interesting case is a sophisticated Producer hosting an entity that has
been deployed such that it is not clonable. Actually, in either case I
think it disingenuous for the Producer to lead the Consumer to think it
has successfully cloned an entity when it has not. We could encourage
the Consumer to always check whether or not it got the same handle back,
but why not have the Producer explicitly say that no clone has been
generated?
"Tamari, Yossi"
<yossi.tamari@sap To:
"'wsrp-wsia@lists.oasis-open.org'"
.com>
<wsrp-wsia@lists.oasis-open.org>
cc:
10/09/2002 12:07 Subject: RE: [wsrp-wsia]
[I#106] Uniqueness of entityHandles
PM
Hi Rich,
I also think we have a misunderstanding. Let me describe the flow: 1.
The consumer wants a clone. 2. The producer says to itself: "I am a very
simple producer. I have no personalization or configuration information.
I would have no data to hang off of the new copy. The two copies will be
identical from my point of view. Let me just return ME as a copy of
myself". 3. The consumer receives a handle. It is the same handle that
was sent to the cloneEntity operation but the consumer shouldn't care
(except perhaps to recognize it and append a GUID if it really wants
this to be unique for internal purposes). 4. In consequent operations
the consumer sends the same handle to the producer again. Of course, the
same results will be returned no matter which of the two handles it
used, since they are the same. However, this is the desired behavior for
this portlet, as defined by the producer.
Yossi.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, October 09, 2002 5:40 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
I think we may be confusing two issues here:
1) Due to the way a Consumer wishes to use an entity, it determines it
needs a clone
2) Due to the way a Producer hosts an entity (or the details of the
registration, etc), it determines that an entity may not be cloned
The second covers the semantics you are talking about. From my point of
view, if the Consumer has determined it needs a clone then any failure
to produce such a clone needs appropriate error processing. From the
protocol point of view, how could it not be an error for cloneEntity()
to fail to produce a clone?
"Tamari, Yossi"
<yossi.tamari@sap To:
wsrp-wsia@lists.oasis-open.org
.com> cc:
Subject: RE: [wsrp-wsia]
[I#106] Uniqueness of entityHandles
10/09/2002 11:10
AM
I disagree. The semantics I am referring to are that there is no need to
clone because the entity has no state. Only the producer knows this, and
the producer DOES know this. This is NOT an error. Furthermore, the
consumer doesn't care about this. From its point of view this is a new
entity. The only issue here is that the consumer may run into problems
if it uses the handle as a key. We already saw other places where using
this handle as key limits the protocol, so maybe this is not a very good
idea. This is why I don't think we should throw an exception, and if we
do, it should be a clearly defined exception that does not denote an
error.
Yossi.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, October 09, 2002 4:20 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
But the Producer can not say that a clone was not needed, only that a
clone is not possible. If it is not possible and the operation is
cloneEntity(), then that is an error.
"Tamari, Yossi"
<yossi.tamari@sap To:
wsrp-wsia@lists.oasis-open.org
.com> cc:
Subject: RE: [wsrp-wsia]
[I#106] Uniqueness of entityHandles
10/09/2002 08:54
AM
This seems to send the wrong message. My view on this is that no error
happened. It is simply that a copy operation was not needed.
Yossi.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, October 09, 2002 2:51 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
My preference would be a fault message that says "Entity Not Clonable".
It returns no handle, but explicitly says that the clone failed.
Andre Kramer
<andre.kramer@eu. To:
wsrp-wsia@lists.oasis-open.org
citrix.com> cc:
Subject: RE: [wsrp-wsia]
[I#106] Uniqueness of entityHandles
10/09/2002 08:42
AM
A fault would be better. But is it possible to return Handle A multiple
times for getClone(X) where A <> X? (I would hate to have to go inside a
fault message to get the actual returned handle.)
If it is always a new handle or the handle being cloned then we could
just allow a null return to indicate that:
- no error occurred
- no clone was required
-- Andre
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: 09 October 2002 13:06
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
Another way, which is less weird and more explicit is that in the case a
Producer receives a cloneEntity which is of a type that the clone is not
different than the original, then the Producer _faults_ to indicate to
the Consumer - "look, this clone is useless - go ahead and use the
original".
Gil
-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Wed, October 09, 2002 13:57
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
I still find this a bit strange. Maybe the operation should then be
called "customizeEntity" rather than "cloneEntity"?
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: 09 October 2002 12:17
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
I agree with Yossi, and I think my previous reply solved the problem
conceptually, so I'll copy it here:
It's not that cloneEntity returns a new entity with the same handle,
it's that it returns the same entity (and thus the same handle).
What the spec should say in this case, is that the "cloneEntity CAN
return the same entity in case there is no provider-side difference
between the two".
Thus we get back to the entity <==> handle.
Gil
-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: Wed, October 09, 2002 13:00
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
Or the consumer could attach a GUID to the returned handle and then
remove it before sending the handle back to the producer. Why put the
load of making the life of a specific consumer implementation on every
producer?
Yossi.
-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Wednesday, October 09, 2002 11:29 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
This could get very confusing for consumers as they should be allowed to
test for equality by comparing handles? For your example, the producer
could append a large random number (impacting handle size) on clone and
strip it off when receiving the handle back to make handles appear
unique.
regards,
Andre
-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: 09 October 2002 10:15
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
While Gil is obviously correct in theory, it might useful in practice to
allow a producer to return the same handle as a result of CloneEntity.
If this entity has no persistence, there doesn't seem to be a need for a
different handle, and it removes the need for this simple producer of
dealing with multiple entityHandles.
Yossi.
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Wednesday, October 09, 2002 6:41 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
How can it be other than a MUST? If two entities have the same handle,
then they are, by definition, the same entity. This is not even a MUST -
it is evident by the very nature of the definition of a handle as a
unique identifier of something.
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Wed, October 09, 2002 06:38
To: wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-wsia] [I#106] Uniqueness of entityHandles
Topic: Interface
Class: Technical
Raised by: Rich Thompson
Title: Uniqueness of entityHandles
Date Added: 9-Oct-2002
Document Section: Interfaces/6
Description:
Do we want a statement about uniqueness of entity handles within the
scope of a registration? Would it be a SHOULD or a MUST?
----------------------------------------------------------------
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>
----------------------------------------------------------------
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>
----------------------------------------------------------------
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>
----------------------------------------------------------------
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>
----------------------------------------------------------------
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC