Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 10764 invoked from network); 8 Jan 2004 22:19:19 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 8 Jan 2004 22:19:19 -0000 Received: (qmail 78082 invoked by uid 500); 8 Jan 2004 22:19:03 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 78064 invoked by uid 500); 8 Jan 2004 22:19:03 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 78053 invoked from network); 8 Jan 2004 22:19:02 -0000 Message-ID: From: Tom Jordahl To: "'McLay, Tony'" Cc: "'axis-dev@ws.apache.org'" Subject: RE: Implicit Soap Headers Date: Thu, 8 Jan 2004 14:24:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D636.3590145E" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3D636.3590145E Content-Type: text/plain 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: > 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 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. ------_=_NextPart_001_01C3D636.3590145E Content-Type: text/html Implicit Soap Headers

Tony,

 

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

 

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>

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 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.

------_=_NextPart_001_01C3D636.3590145E--