We have currently done the most of
our implementation of UDDI V3 registry based on 3.0.1 errata.
We also understand this change may cause
an interoperability issue in our future updates to version 3.0.2 but
we see this change as nice and necessary UDDI API cleanup so I would vote for
introducing it into 3.0.2 errata.
Our client implementation for version based on
3.0.1 will support both E_success dispossitionReport and empty return
messages (if we agree on empty message as a solution) so this client
will understand such responses both from 3.0.1 and 3.0.2. We will also
add recommendation to our current documentation about how
to develop a client side applications with concern of this
change in future to ensure source code compatibility.
Regards,
Mirek
----- Original Message -----
Sent: Monday, April 19, 2004 12:35
PM
Subject: RE: [uddi-spec] Status of
JAX-RPC work
Rob,
I believe IBM has
invested as much as any company in the development of the V3 UBR, but I also
believe that this issue is too important to leave to V.Next. I believe
we have to resolve this issue before we standardize UDDI V3, which means that
it has to be resolved in 3.0.2.
I think it is
inevitable that further development work will be needed, both for the UBR and
UDDI products, as we finish off 3.0.2 and go through the OASIS standardization
process.
I have a different
recollection of Mirek’s comments than you do but I will let him speak for
himself (and Systinet).
-----Original
Message----- From: Rob
Kochman [mailto:robko@microsoft.com] Sent: 18 April 2004 20:50 To: Rogers, Tony; Luc Clément; John
Colgrave; uddi-spec@lists.oasis-open.org Cc: Rob Kochman Subject: RE: [uddi-spec] Status of
JAX-RPC work
As those of you who were at the
last FTF already know, I oppose adopting this CR because I believe it’s too
late in the v3 process for such a significant change. We (Microsoft)
have already gone to great expense to develop and test our v3 UBR
implementation, which is practically done. As such, we would most likely
have to oppose this CR’s adoption for the UBR. Also, Mirek can correct
me if I’m wrong, but I believe he said at the FTF that Systinet would not
support this change in their v3 product. Do we really want to introduce
this kind of fragmentation within v3?
I understand the importance of
Java support, so I wouldn’t oppose this change for v.Next if JAX-RPC can’t be
fixed before then. It’s just too late for this round.
-Rob
From: Rogers,
Tony [mailto:Tony.Rogers@ca.com] Sent: Saturday, April 03, 2004 12:47
PM To: Luc Clément; John
Colgrave; uddi-spec@lists.oasis-open.org Subject: RE: [uddi-spec] Status of
JAX-RPC work
Actually JAX-RPC's problem is simpler: it fails if the
success message is the same as the object returned in a SOAP Fault. That was
the original problem John set out to address.
The use of the empty message rather than one with
constant content (which is essentially meaningless) is a separate issue, and
one that I will graciously allow someone else to
explain...
-----Original Message----- From: Luc Clément
[mailto:luc@iclement.net] Sent: Sun 04-Apr-04 5:40 To: Rogers, Tony; 'John Colgrave';
uddi-spec@lists.oasis-open.org Cc: Subject: RE: [uddi-spec] Status of
JAX-RPC work
Show
me...
1. Perhaps I
glanced too quickly, but I did not find evidence of "empty message" for "success without
any significant return value" in
the WS-I BP or SOAP
2. I'll accept as a
given that JAX-RPC flames out in the presence of a non-empty message.
Given that we are "adjusting the spec" due implementation-specific issues,
did anyone verify that other implementations will not go catatonic in the
presence of an empty response message?
From:
Rogers, Tony [mailto:Tony.Rogers@ca.com] Sent: Saturday, April 03, 2004
02:46 To: Luc Clément; John
Colgrave; uddi-spec@lists.oasis-open.org Subject: RE: [uddi-spec] Status of
JAX-RPC work
Ya know, this was my initial reaction, prior to the
FTF. However, at the FTF John (and others) was quite convincing that JAX-RPC
will explode into a thousand flaming pieces (I think that's what they said,
or it might have been a plague of locusts...) if anything other than an
empty message is returned, so I guess we have to go along with them.
Apparently "empty message" for "success without any
significant return value" is part of the WS-I Basic Profile,
too.
-----Original
Message----- From: Luc
Clément [mailto:luc@iclement.net] Sent: Fri 02-Apr-04 11:58
To: 'John Colgrave';
uddi-spec@lists.oasis-open.org Cc: Subject: RE: [uddi-spec] Status of
JAX-RPC work
John,
I reviewed the CR. I'm warming up to
the idea of making this change though I don't agree with your use of an
empty message being returned which is to be interpreted as "Success".
If I understand your proposal correctly what you intend to return is
the following:
<?xml version="1.0" encoding="UTF-8"
?> <Envelope xmlns="http://schemas.xmlsoaporg.org/soap/envelope/">
<Body/> </Envelope>
This is umbiguous; why not
simply return a "uddi:result" element as follows:
<?xml
version="1.0" encoding="UTF-8" ?> <Envelope xmlns="http://schemas.xmlsoaporg.org/soap/envelope/">
<Body>
<uddi:result errno="0"
xmlns="urn:uddi-org:api_v3">
<errInfo errCode=“E_success"
/>
</uddi:result>
</Body> </Envelope>
This isn't any more work either
on the server or client. Taking this approach significantly improves
testability; the test folks would not be happy with <Body/>. This
approach also does not require inventing a new attribute -- it simply
calls for the reuse of an existing one that allows the response to be
interpreted unambiguously yet satisfies JAX-RPC's inability to map to
Java an element that is used as both an output and
a fault.
Unless there are precedents to interpreting an empty
SOAP:body element as success, I ask that you change the CR to use the
uddi:result element instead of what you proposed.
Luc
Clément Web:
www.iclement.net/luc Cell:
425.941.0150
-----Original Message----- From: John Colgrave
[mailto:colgrave@hursley.ibm.com] Sent:
Tuesday, March 23, 2004 08:27 To:
uddi-spec@lists.oasis-open.org Subject: [uddi-spec] Status of JAX-RPC
work
We said that we would revisit the JAX-RPC work I have been
doing in March.
As I feared, the fact that dispositionReport is
used for both normal success responses and all faults causes
incompatibilities in the code generated by different JAX-RPC 1.1
implementations.
I have therefore submitted CR-046 which suggests
restricting dispositionReport to faults only.
I have a Technical
Note ready describing the changes to the schemas that are required, but
there is no point in progressing it any further unless CR-046 is
accepted as the handling of responses and errors affects
every method/operation in the JAX-RPC client interfaces.
John
Colgrave IBM
To unsubscribe from this mailing list
(and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro up.php.
To
unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.
|