See inline.
-----Original Message-----
From: Dittmann Werner [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 18, 2002 3:00 AM
To: '[EMAIL PROTECTED]'
Subject: AW: soap:header
Sylvain,
sorry about the confusion. I was looking at the SOAP specs
only. Now having a look at the WSDL specs I tried to match
these two. Here what I found and think what it may be:
1st: the pure SOAP (1.2) does not provide a direct binding
between header contents and body contents. Both parts
of a SOAP message can be addressed to different entities,
can processed independently, and there is no protocol
element which relates them. If there shall be a relation
between header and body elements that must be done by
application specific elements and/or attributes.
[sylvain] Sounds fine.
2nd: WSDL defining headers inside the operation part may
be interpreted like: if this operation is called then
the defined headers must be transmitted also. This is
just my interpretation because the SOAP spec does not
mandate this. Using the header definition inside the
operation may be used to generate implemetation code
on the server side, and/or code on the client side that
checks if all "required" headers are set.
[sylvain] Also, soap:header has an attribute called required.
However, there should also be a way to set additional headers
in the SOAP message that are not defined in WSDL but are necessary
for other purposes, e.g. SOAP routing, transfer of service licensing
data, etc.
[sylvain] In my mind your WSDL should define all the service's header
requirement because that is the only way that an external consumer of your
service will know that a header is mandatory or not.
This being said, if your service is internal, you can do:
call.addHeader(new SOAPHeaderElement(...))
About overwriting received SOAP headers: you are right.
There are different level of abstraction in .NET and the SOAP toolkit.
I was looking from a pure SOAP point of view. Here the headers
contained in a request are not related to headers contained
in a response. Because of that I'm somewhat reluctant to
automatically overwrite headers.
[sylvain] Maybe those distinct headers should be different parts. This way
the response one would not overwrite the request one.
I've seen an example where the request contained some security
info (name/password) in a header and the response contained also
a header with security info (name/password) but both where
different, i.e. first it was the requestors name/password
and then it was the name/password of the responder (support of
mutual authentication). They used the same header element name,
encoding, etc. In this case overwriting complicates the whole matter.
[sylvain] Anything makes you think that the header implementation of this
service was well done?
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.
