uddi-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: CR080 - discard_transferToken behaviour
- From: Katharine Jagger <KJAGGER@uk.ibm.com>
- To: uddi-spec@lists.oasis-open.org
- Date: Thu, 5 Aug 2004 13:24:55 +0100
Hi
I have a question relating to spec CR
080 on discard_transferToken behaviour.
My question is, what error (if any)
should be returned if one of the keys passed to discard_transferToken is
owned by the publisher but the transferToken corresponding to the key is
owned by another publisher?
This situation can occur when:
1. Publisher 1 publishes a business
with key uddi:mycompany.com:key1.
2. Publisher 1 obtains a transferToken
for the business.
3. Publisher 1 deletes the business.
4. Publisher 1 transfers custody
of the keyGenerator tModel uddi:mycompany.com:keygenerator to Publisher
2.
5. Publisher 2 publishes a business
with key uddi:mycompany.com:key1.
6. Publisher 2 attempts to get
a transferToken for the business, but is refused because a transferToken
already exists (owned by Publisher 1).
7. Publisher 2 attempts to discard
the existing transferToken associated with uddi:mycompany.com:key1.
The possible outcomes I see for step
7 are:
A. Publisher 2 is allowed to discard
a transferToken belonging to another publisher, because it covers one of
their own keys.
B. E_userMismatch is returned
because the publisher does not own the transferToken. (This may be
confusing because if the error message contains the key that caused the
error, the publisher may think this means that they don't own the key,
which of course they do.)
C. The transferToken is not discarded
and no error is returned.
D. The problem is actually with
step 6. Publisher 1 should be allowed to obtain a transferToken because
although one exists, it is not theirs. What should then happen to
the existing transferToken?
E. The problem is actually with
step 3. When an entity is deleted that is covered by an existing
transferToken, any associated transferToken should also be deleted. (Presumably
this would apply to businesses only, because it would still make sense
to transfer custody of a "deleted" tModel.) This would
make sense because as soon as an entity is deleted, the transferToken associated
with it becomes unusable anyway, because an attempt to use the transferToken
would result in E_invalidKeyPassed due to the deleted key.
Note that if Publisher 2 is not allowed
to discard the existing transferToken (outcomes B and C) then this presents
a problem because Publisher 1 cannot discard the transferToken either.
If Publisher 1 calls discard_transferToken, passing a keyBag containing
the key uddi:mycompany.com:key1, they will get E_userMismatch because they
do not own the key.
This leads to another question: if
Publisher 1 calls discard_transferToken by passing the transferToken rather
than a keyBag, or by passing a keyBag which includes other keys covered
by the transferToken but does not include the key uddi:mycompany.com:key1,
do they get E_userMismatch because the transferToken covers a key which
is not owned by them, even though it was not included in the discard_transferToken
call? Or does the call succeed regardless?
I would very much welcome your comments.
Many thanks,
Katharine Jagger.
-----------------------------------------------------------------------
Katharine Jagger - Software Engineer
Sun Certified Java Programmer
Web Services Development
MP 208, IBM Hursley
Office location A4133; Tie line: 7-245196
-----------------------------------------------------------------------
Save paper - save orangutans!
Please send me information electronically rather than on paper - many thanks!
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]