(oops! accidentally hit 'send' before I was anywhere near ready!)
There are two types of headers in WSDL:
- explicit - the soap:header message in a binding operation also appears in
the corresponding portType's operation. In other words, a parameter in a
method is sent in the soap message's header instead of the body.
- implicit - the soap:header message in a binding operation does not appear
in the corresponding portType's operation.
I don't really like explicit headers. It goes against modern programming
philosophy. Stuff that appears in the SEI is business logic. Stuff that
appears in headers is middleware logic. Never the twain should meet. But
it's possible to do, JAX-RPC, section 11 talks about them (luckily the TCK
didn't test for them!), and WS-I WSDL's will probably contain them (though
we're fighting that), so we will have to implement them.
Implicit headers I really don't understand. Since they're not declared in
the SEI, they must come from someplace else. Obviously they come from a
handler, but how do we correlate what's in WSDL to a handler that can
supply the info? So I don't know how we implement implicit headers in our
generated code.
I've got some comments to your questions inline in the message below...
Russell Butek
[EMAIL PROTECTED]
Sylvain wrote:
> <...snip...>
>
> - 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)
Sure. You can do just about anything you want with handlers.
> - What do you mean about implicit/explicit "...headers required to be on
the
> message" ?
I'm used to CORBA-like headers where all header stuff is optional. I'm not
quite sure if, because the header is on the WSDL, it MUST appear in the
soap message.
> - A soap:headerfault is returned when a fault is generated because of a
> bogus header.
soap:headerfault is a bit problemmatic as far as I'm concerned. These,
like headers themselves, can be implicit or explicit. Implicit ones really
bother me because it implies exceptions that aren't defined in the SEI can
bubble up to the client. (Actually this works for us because all generated
exception extend RemoteException and all methods throw RemoteException, but
it still seems dubious to me.) But other than that, these should be as
easy (ha) to implement as soap:fault.
> - 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.
That's the problem. Languages like Java demand explicit declaration of all
possible exceptions. They typically have an out, like Java's
RuntimeException. Does that mean headerfaults must extend
RuntimeException? That isn't spec'ed anywhere.
> - dotNet does keep Header refs in the header and Body's ones in the body.
But with explicit headers multirefs could cross this boundary. How we
choose to implement this will be an interop issue.
> - Does document style applies to headers?
Probably.
> - 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...)
HEAR HEAR!!! I wish WSDL 1.1 never allowed them!
> <...snip...>
