Certainly development work will be needed
on v3 implementations to accommodate the refinements of v3.0.2, but none of the
changes we have discussed thus far have such a high-impact. I understand the
desire to get this change through quickly, but I believe it’s
inappropriate to make such a change so late in the v3 process. This is more
fundamental, and thus should be accounted for early in the spec process.
I’ve cc’d Mirek directly, so
hopefully he can let us know whether Systinet plans on supporting this in their
v3 release.
-Rob
From: John Colgrave
[mailto:colgrave@hursley.ibm.com]
Sent: Monday, April 19, 2004 3:36
AM
To: uddi-spec@lists.oasis-open.org
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.
|