Russell,
I have been quite silent the past few months however I have been monitoring
the list on a weekly basis about soap:header.
Since our application make extensive uses of implicit soap:header and that
soap:header somehow are still misunderstood (I had to figure out most of it
by myself when implementing it in Axis). At that time, one of my main
concerns was interoperability with dotNet therefore what I have implemented
in Axis behaves the same way.
I cannot currently spend much time on this, but I am definitely interested
as in contributing in some form or another. What kind of time frame are you
looking for the implementation?
Here are a few thoughts and more questions... (which hopefully will not make
this more confusing...;-))
- I did not use handlers to handle headers, can you achieve persistence of
headers between calls when using handlers? ( my implementation caches the
header objects in the portType)
- What do you mean about implicit/explicit "...headers required to be on the
message" ?
- A soap:headerfault is returned when a fault is generated because of a
bogus header.
- About 'If the headerfault is an implicit header...' : The soap:headerfault
is simply the mechanism to notify to the WS consumer that an exception
occurred when processing the header. It does not belong to the api per
say.
- dotNet does keep Header refs in the header and Body's ones in the body.
- Does document style applies to headers?
- IMHO explicit headers are evil, they pollute the interface - what is the
difference between a explicit header and a simple INOUT param? Aren't they
the same? (beside the fact that they are carried in different places in the
SOAP message...)
FYI here is a snippet of a generated stub with *my* WSDL2Java...
public java.math.BigInteger delete(
com.cognos.developer.BaseClass[] objects,
com.cognos.developer.DeleteOptions options)
throws java.rmi.RemoteException{
[standard stuff here... ]
call.setOperationName(new
javax.xml.rpc.namespace.QName("http://developer.cognos.com/schemas/bibus/2/";
, "delete"));
// My additions start here
call.addHeader( getHeader(
"http://developer.cognos.com/schemas/bibus/2/";, "biBusHeader"));
Object resp = null;
try {
resp = call.invoke( new Object[] {objects, options});
} catch ( org.apache.axis.AxisFault af ) {
throw af;
} finally {
updateHeader( call,
"http://developer.cognos.com/schemas/bibus/2/";, "biBusHeader");
}
// My additions end here
if (resp instanceof java.rmi.RemoteException) {
[standard stuff here... ]
}
IMNSHO implicit headers are the one that Axis is lacking support for. At
least this is what I see value for and that I see people asking about.
Haven't seen much traffic about explicit headers. Anyone has?
--
Sylvain St-Germain
Macadamian Technologies
-----Original Message-----
From: Russell Butek [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 30, 2002 4:23 PM
To: [EMAIL PROTECTED]
Subject: soap:header support
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
[EMAIL PROTECTED]
This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so. Thank you.
