[prev in list] [next in list] [prev in thread] [next in thread] 

List:       axis-c-dev
Subject:    RE: Ability to add custom headers to SOAP messeges,      through the  stub
From:       "Susantha Kumara" <susantha () opensource ! lk>
Date:       2004-05-26 5:38:41
Message-ID: 000001c442e3$b766bef0$0a65a8c0 () SusanthaNB
[Download RAW message or body]

Hi Roshan,

Yes, I think one approach would be to add facility to MessageData class
to hold value objects (void*) with string keys (char*) and any one
(client app, handler etc) who recognizes it may treat it as a SOAP
header or transport property etc.

---
Susantha 


> -----Original Message-----
> From: Paul Fremantle [mailto:pzf@hursley.ibm.com]
> Sent: Tuesday, May 25, 2004 10:30 PM
> To: Apache AXIS C Developers List
> Subject: Re: Ability to add custom headers to SOAP messeges, through
the
> stub
> 
> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >


[prev in list] [next in list] [prev in thread] [next in thread]