RE: Implicit Soap Headers

[Tom Jordahl <to...@macromedia.com>]

Tony,

 

Yes, I know this message is several months old, but I don't think I
responded to it.  :-)

 

I believe Axis is OK with respect to WS-I because headers that are
explicitly listed in the WSDL are added the function signature of the Stub,
which means that the users of the Stub are obligated to include values for
the header the same way they have to provide operation arguments.

 

I hope this addresses your concerns and again sorry for the late response.

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: McLay, Tony [mailto:Tony.McLay@COGNOS.com] 
Sent: Friday, October 24, 2003 11:41 AM
To: 'axis-dev@ws.apache.org'
Subject: RE: Implicit Soap Headers

 

Thanks Tom,

 

I appreciate the informative response. 

I have been doing some more digging to find out how a client interprets a
soap header element that is defined in the bindings section of a wsdl, but
that does not reference a message part in the port type.  Since Axis 1.2 is
aiming to support the WS-I basic profile, the following extract is
interesting (from that specification):

 

//WS-I extract:

 

5.6.22 Required Headers
WSDL 1.1 does not clearly specify whether all soapbind:headers specified on
the wsdl:input or wsdl:output elements of a wsdl:operation element in the
SOAP binding section of a WSDL description must be included in the resultant
SOAP messages when they are transmitted. The Profile makes all such headers
mandatory, as there is no way in WSDL 1.1 to mark a header optional.

 

R2738 A MESSAGE MUST include all soapbind:headers specified on a wsdl:input
or wsdl:output of a wsdl:operation of a wsdl:binding that describes it. 

 

//end WS-I extract

 

For WS-I, a conforming client MUST set the header if specified. Presumably
if the expected header were not present, the service would fail and an
exception detailing the problem would be returned to the client.

 

My concern is that the only way a client will know to call a stub's
setHeader() method is by manually studying the wsdl, or ultimately by
receiving an exception either from an enhanced client stub, or from the
service.

 

So I can also understand the approach of a wsdl2java tool providing some
automatic client guidance or support for wsdl's defined in this way -
enhancing the client stub to set implicit headers as per Sylvian's
interpretation (or similar, following the jaxrpc Service Context
description), or perhaps to simply modify the stub to throw an exception if
the header has not been set prior to a call that requires one etc. Can also
envisage adding an extra call parameter to stub methods, probably not good -
existing applications would get a surprise (but this would explicitly state
the call requirement to the client as per the wsdl).

 

Thanks in advance for any further thoughts on this.

Tony

 

p.s. apologies if I do not respond promptly to any further feedback - I am
on holiday next week.

 

-----Original Message-----
From: Tom Jordahl [mailto:tomj@macromedia.com]
Sent: 23 October 2003 18:52
To: 'axis-dev@ws.apache.org'
Subject: RE: Implicit Soap Headers

 

I believe this is the current state of CVS right now:

 

- Explicit request headers in WSDL are turned in to arguments to the stub
functions (1.0 functionality)

- Non-WSDL headers can be set in the Call and Stub objects using the
setHeader() API

- Response headers can be retrieved from the Call object using
Call.getResponseMessage().getSOAPEnvelope().getHeaderByName()

- Response headers can be retrieved from the Stub after a call using the
(post 1.1) getResponseHeader() API

 

Axis 1.1 had some unfortunate changes made to it so that the getHeader() API
in the stub would only return the headers that were ready to go out in a
request.  I added the getResponseHeader() API so that stub users could get
to the response headers easily.

 

I do NOT think that Axis should have the behavior that Sylvain was
implementing, which is to keep a list of headers that once set, get sent for
every operation called via a Stub.  He also had the header values get
updated when the server returned a header with the same QName as one in the
outgoing list.  This violates the 'principle of least surprise' and can be
accomplished with more control by having the user set any headers for every
request.

 

In summary, I believe that Axis SOAP header support is in good shape and
this bug doesn't address something we want to change.

 

I will update the bug with the above info too.

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: McLay, Tony [mailto:Tony.McLay@COGNOS.com] 
Sent: Thursday, October 23, 2003 12:04 PM
To: 'axis-dev@ws.apache.org'
Subject: Implicit Soap Headers

 

Hi, 
The following axis bug describes required support for soap implicit headers:

<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13618
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13618> > 

A patch was posted but the bug remains at assigned status. What is the
current position/feeling for implicit soap header support?

I have perused the previous threads, and the relevant parts of the jaxrpc
spec, and there seems to be some latitude for interpretation in this respect
(at least to me).

If there are outstanding issues, perhaps I can help. 

Tony 

 

Join us at Cognos' biggest event of the year Enterprise 2003, The Cognos
Business Forum.  Taking place in over 25 cities around the world, it's an
opportunity for Business and IT leaders to learn about strategies for
driving performance. Visit http://www.cognos.com/enterprise03
<http://www.cognos.com/enterprise03>  for more details. 

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.


Join us at Cognos' biggest event of the year Enterprise 2003, The Cognos
Business Forum. Taking place in over 25 cities around the world, it's an
opportunity for Business and IT leaders to learn about strategies for
driving performance. Visit http://www.cognos.com/enterprise03 for more
details. 


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.