uddi-spec message

Subject: RE: [uddi-spec] Status of JAX-RPC work
From: Luc Clément <luc@iclement.net>
To: "'John Colgrave'" <colgrave@hursley.ibm.com>,<uddi-spec@lists.oasis-open.org>
Date: Thu, 1 Apr 2004 17:58:39 -0800
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.