axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Butek <bu...@us.ibm.com>
Subject soap:header support
Date Mon, 30 Sep 2002 20:23:10 GMT




There are a lot of nuances to supporting soap:header in AXIS.  Some of the
quirks that concern me are:
- explicit headers are SEI parameters that are sent as headers, implicit
headers are messages that aren't used by the portType.  How are implicit
headers implemented?  Via handlers, presumably.  Where do the values come
from?  Are implicit headers required to be on the message?  Are explicit
headers required to be on the message?
- For explicit headers, inout parameters COULD have their input component
in the header and their output component in the body.  Yuck.
- I'm still rather fuzzy on soap:headerfault.  What is its relationship to
soap:fault?  When would a soap:headerfault come back rather than a
soap:fault?  If the headerfault is an implicit header, then how can the SEI
deal with it since its Exception isn't on the method signature?
- can multirefs cross the body/header boundary?  Right now multirefs reside
in the soap:body.  Can they be moved out a level to the soap:envelope?  Or
can they indeed cross the boundary?

Some assumptions that I'll probably make in the implementation (at least
initially).
- Only support WSDL's explicit headers.  Implicit headers in the WSDL will
be ignored.
- Don't support splitting inout parameters into header/body parameters.
- (I wanted to exclude soap:headerfault, but WS-I WSDL uses it.  Bummer.)
- don't support multiref across the header/body boundary.

These are the bits of AXIS that must be tweaked ('tweak' could be a rather
weak description - 'pummelled', perhaps?):
- WSDL2Java (I hope we don't want Java2WSDL to do this stuff!)
- Call?  (we've got Call.addHeader.  Do we need readHeader?  Or shouldn't
the stub use addHeader?  Should the header/body nature be dealt with within
the Call object (or even lower)?)
- RPCProvider?  we have to recognize that parameters may come from headers,
and may have to go back to headers.
- The previous 2 points suggest that ser/deser may have to change
- WSDD must describe which parameters are headers
- ParameterDesc (and others?) must describe which parameters are headers

Russell Butek
butek@us.ibm.com


Mime
View raw message