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