axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Yves Baudy <jy.ba...@free.fr>
Subject Re: SOAP Header manipulation & Handler API
Date Wed, 03 Mar 2004 13:56:41 GMT
Paul,

I agree with you about having a common way to work with headers. But 
when looking in depth in the site (mail before) there is a little 
paragraph named "SOAP headers and WSDL" that discuss about the 
functional, or business interface of the header part.

It seem that if the header referenced part in the input/output binding 
target a message part included in the same message than operation is 
considered as functional. And on the other hand, if header referenced 
part is in other message is considered as business interface.

Java generated client proxy with Apache Axis 1.1, and similar tooling, 
use this "politic". Here the Service Endpoint Interface generated for 
the sample:

public com.ibm.soapheader._getLastSellPriceResponse
getLastSellPrice(com.ibm.soapheader._getLastSellPrice parameters,
com.ibm.soapheader._quote_timestamp request_header) throws
java.rmi.RemoteException {
...
}

If we add a header that reference a part in other message the Service 
Endpoint the Interface still the same as above. But nothing is generated 
about this header (not very good).

<wsdl:input name="getLastSellPriceRequest">
     <wsdlsoap:header message="intf:getLastSellPriceRequest"
	part="request_header" use="literal"/>
     <wsdlsoap:header message="intf:getTestSellPriceRequest"
	part="request_header_test" use="literal"/>
     <wsdlsoap:body use="literal" parts="parameters"/>
</wsdl:input>


C# has a different approaches. For the both cases the Service Endpoint 
Interface still the same without any reference to the header part in the 
method prototype:

public System.Single 
getLastSellPrice([System.Xml.Serialization.XmlElementAttribute(IsNullable=true)] 
string ticker) {
...
}

Two public variables are generated and passed to the SOAP Header. The 
customer only set those variables and didn't have to define specific 
handlers.

 From a user point of view I think (but It is only my opinion) that 
"well defined"  headers (header that target a message part which point 
to an element in the schema definition) should be a simple variable. The 
way passing it to the client stack runtime using SEI method prototype or 
getter/setter in the stub is just a question of choice.

Using Handler should be only use for customer who wants to add header 
block not defined in the WSDL file. As the first Roshan's sample show.

I'm aware that this approach implied two way of working with headers 
block. But for parameter in the WSDL file that are "tagged" to be passed 
throw the SOAP header (input/output) is more "user friendly" to 
manipulate just a variable.

But, as I say, is only my opinion and my experience is not enough 
advanced to be sure that it is the more convenient design.

PS : Sory for my bad english.

Regards,

 >Jean-Yves
 >
 >The only problem with this approach is that the headers are not part of
 >the business logic interface in the WSDL, but they end up as part of it
 >in the Java/C.
 >
 >Ideally, we would have another way of describing headers. Sanjiva
 >Weerawarana made a proposal of such a model to the WSDL working group
 >last year, and there are some ideas that have been discussed there as
 >well. Another approach might be to define a WS-Policy extension. A
 >number of customers use the stub._setProperty("XXX", YYY) option on the
 >JAX-RPC stub instead, and then they write a handler that extracts
 >property XXX and sets it as a header. I know - it sounds like more work!
 >However, it does give a clearer interface between the body and the 
 >headers.
 >
 >Paul

Mime
View raw message