OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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>






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC