You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Roshan Weerasuriya <ro...@opensource.lk> on 2004/06/01 09:00:47 UTC

Re: Ability to add custom headers to SOAP messeges, through the stub

hi all,

With the latest CVS code the users could set SOAP Headers from the 
generated stub. (There was a bug in this but now it is fixed, and is tested 
on windows).

The Stub base class has the following method.

IHeaderBlock * AXISCALL createHeaderBlock (AxisChar * pachLocalName,
                                      AxisChar * pachPrefix,
                                      AxisChar * pachUri);

A example code is provided below.

//--------------------------------example client 
code-----------------------------------------------------------

#include "Calculator.h"
#include <iostream>

int main() {

         Calculator objCalc("http://localhost:5555/axis/Calculator");

         IHeaderBlock* pIHeaderBlock = 
objCalc.createHeaderBlock("myHeaderBlock", "ns1", "http://mysite.com");

         pIHeaderBlock->createImmediateChild(CHARACTER_NODE, "", "", "", 
"testHeaderVal");

         cout<<objCalc.add(10, 20);
         return 0;
}

//--------------------------------end of example client 
code----------------------------------------------------------


Also the Client Axis Engine is capable of accessing the incoming SOAP 
Headers (of the SOAP Response). But a method is not yet implemented in the 
Stub to expose these to the user. But this also could be easily added to 
the Stub.

rgds,
Roshan

At 05:30 PM 5/25/2004 +0100, you wrote:
>Susantha
>
>I guess I wasn't very clear. The Java approach requires two pieces of code 
>that are sort of separate. If you call _setProperty(name, value) by itself 
>nothing happens. So you also have to create a handler, that looks in the 
>properties and uses the values to create a header. You could do this in 
>any way you like. One approach is to pass a SOAPElement. The other 
>approach is to pass one or more strings, and then the handler creates the 
>SOAPElement out of this. That would be like Roshan's suggestion of 
>allowing the stub to modify the MessageData.
>
>In fact Roshan - that is a very good idea.
>
>Paul
>
>susantha@opensource.lk wrote:
>
>>>In Axis Java (or JAX-RPC) the way this is done is in two parts.
>>>
>>>Firstly the user calls stub._setProperty("name", valueObject);
>>>
>>
>>Is this setting transport properties ?. Or setting SOAP headers ?.
>>Probably any.
>>
>>
>>
>>>then a handler is defined, which is coded to understand the "name", and
>>>to know the SOAP Header structure. So the handler does:
>>>
>>
>>So this "name" says that it is an object that should be serialized as a
>>SOAP header ?.
>>
>>
>>
>>>value = getProperty("name");
>>>
>>>and then
>>>
>>>SOAPElement el = ..... /// create SOAPElement
>>>
>>
>>So in this case isn't the object passed by stub._setProperty "valueObject"
>>is of derived class of SOAPElement ?
>>
>>
>>
>>>headers.addElement(el);
>>>
>>>This model is nice because the application code isn't concerned with the
>>>XML/SOAP aspect, but has a simple API to pass data across to the handlers.
>>>
>>
>>Does this mean that its a handler who decides whether the data passed
>>across to the handlers are serialized as SOAP headers , transport headers
>>or anything else ?.
>>
>>
>>
>>>Would this be a good model to follow in C/C++?
>>>
>>>Paul
>>>
>>>
>>>Susantha Kumara wrote:
>>>
>>>
>>>
>>>>Hi all,
>>>>
>>>>I think we need some kind of re-structuring of the way that we handle
>>>>SOAP headers in Axis C++. May be I am wrong . Please correct me if so.
>>>>Following is the consideration.
>>>>
>>>>At the moment the Axis C++ code generator (WSDL2WS tool) does not
>>>>generate code for handling SOAP headers. Please look at the attached
>>>>WSDL. There some SOAP headers are described which means that our code
>>>>generator can handle some work for the user. I mean
>>>>Serializing/Deserializing SOAP headers.
>>>>
>>>>So I feel that any API functions that are used to get/set SOAP headers
>>>>should be in line with complex type handling APIs of Serializer and
>>>>Deserializer interfaces.
>>>>
>>>>For an example the WSDL2Ws tool can create a complex type (class or
>>>>struct) for a SOAP header and its serializer/deserializer functions. But
>>>>these classes/structs and the API functions that are used within these
>>>>serializer/deserializer functions will be different from a regular
>>>>complex type and its functions.
>>>>
>>>>Then any handlers or stubs will use those classes/structs/manipulation
>>>>functions.
>>>>
>>>>If we do not do this with code generator the handler/stub writers will
>>>>have to write their own serializers/deserializers.
>>>>
>>>>Instead why cant we just provide API functions to get/set the tool
>>>>generated complex type objects as header blocks ?. I mean functions
>>>>like,
>>>>
>>>>addComplexHeaderBlock(void* cmplxObj, void* szfunct, void* dszfunct,
>>>>......)
>>>>getComplexHeaderBlock(char* blockname, .....);
>>>>
>>>>Thanks
>>>>---
>>>>Susantha Kumara
>>>>Virtusa (pvt) Ltd.
>>>>Office : +94112714385
>>>>Mobile : +94777420453
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Roshan Weerasuriya [mailto:roshan@opensource.lk]
>>>>>Sent: Thursday, May 20, 2004 11:48 AM
>>>>>To: Apache AXIS C Developers List
>>>>>Subject: Ability to add custom headers to SOAP messeges, through the
>>>>>
>>>>>
>>>>>
>>>>stub
>>>>
>>>>
>>>>
>>>>
>>>>>Hi all,
>>>>>
>>>>>I am planing to work on "lProviding an API at the client stub to
>>>>>
>>>>>
>>>>>
>>>>simply
>>>>
>>>>
>>>>
>>>>
>>>>>add
>>>>>headers to SOAP messege". Currently there is a mechanism in Axis C++
>>>>>
>>>>>
>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>add
>>>>>SOAP Headers through Handlers written by the user, i.e writing and
>>>>>configuring a Handler to add SOAP Headers. One possible way of doing
>>>>>
>>>>>
>>>>>
>>>>this
>>>>
>>>>
>>>>
>>>>
>>>>>is that:
>>>>>Provide a function at stub level such as setSoapHeader (SoapHeader*
>>>>>pSoapHeader).
>>>>>
>>>>>I would appreciate any of your ideas/comments on this matter.
>>>>>
>>>>>rgds,
>>>>>Roshan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>