-----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.