axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Adams <>
Subject SOAP Headers and WSDL
Date Tue, 15 Nov 2005 22:51:09 GMT
I'm attempting to create a set of web services that all use the same
mechanism for statefulness:

All client requests must include a state identification header, which
consists of a couple of strings that I use on the server side to associate a
stateful set of resources with the request. The state identification header
information is included in the response so that the client side code can
associate the response with the appropriate context...

I've implemented a Handler, extending from BasicHandler, which for a request
gets the state identification header information described above out of the
soap header portion of the message, and places it in the MessageContext
using MessageContext.setProperty(). For a response it does the reverse,
getting the state identification header information out of the
MessageContext and placing it in the SOAP header.

With a Java client, I have no problems... I can use the JAX-RPC APIs to
insert the required header information and everything works like clockwork.
The problem is that the targeted client of the web services is going to be
implemented in .Net. When I try to create a Web Reference in .Net, it
creates a proxy from the WSDL, which contains no information about the
required SOAP headers.

To put it simply, I need the header information to be included in the WSDL
generated by Axis. I still want to use a handler, but somehow have the
header information "injected" into the WSDL. I found the following page:, which describes
2 methods of getting header information to come out in the WSDL:

1. Identify parameters in the service interface methods with
2. Use the mystical, unknown method, Handler.generateWSDL to somehow get the
header information to come out in the WSDL.

#1 is impractical for my purposes, since it necessitates having the header
elements declared as method parameters in the service interface. There will
be thousands of services using whatever solution works, and forcing service
developers to include pre-requisite header parameters and handle them in
code is not going to go over well.

#2 is the desired solution as far as I can see, since the handler would
become a self-contained entity, that alters the behavior of the service it's
handling, also altering the WSDL for the service to reflect what it does. I
need some guidance on how to programmatically add the header information
into the WSDL from Handler.generateWSDL or possibly, if there's a better way
to do this then I'd appreciate any thoughts.


View raw message