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/05/20 07:47:48 UTC
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
RE: Ability to add custom headers to SOAP messeges, through the stub
Posted by Susantha Kumara <su...@opensource.lk>.
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 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
>
Re: destructor macros in Gdefine.h (and AXISCALL)
Posted by da...@opensource.lk.
Hi Samisa,
There were supposed to be an ugly hack to cater with differnt gcc versions.
But there are no longer needed. Remove them and run. May be I'll do it if
I find time
damitha
> Hi All,
> In include/axis/server/GDefine.h I see the following lines of code.
>
> 105 #if defined (__GNUC__)
> 106 #if __GNUC_VERSION__ > 30000
> 107 #define AXISDESTRUCTOR void* unused; void
> AXISAPI(destructor,(APINOPARAMS))
> 108 #else
> 109 #define AXISDESTRUCTOR void* unused; void*unused1;
> 110 void AXISAPI(destructor,(APINOPARAMS))
> 111 #endif
> 112 #else
> 113 #define AXISDESTRUCTOR void AXISAPI(destructor,(APINOPARAMS))
> 114 #endif
> 115 #endif
>
> What is the purpose of this code segment? Is line 110 correct, or should
> it be appended to line
> 109? I get an error on line 110 when I compile this source on Rehat
> Advanced server 2.1
>
> BTW: I sent another question on GDefine macros earlier as well. Can we
> replace
> #define AXISCALL __attribute__((stdcall))
> with
> #define AXISCALL __attribute__((cdecl))
> (in aother words why are we using stdcall and not cdecl? Any perticular
> reasons?)
>
> Would be of great help if someone could answer these.
>
> Thanks,
> Samisa...
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
>
>
destructor macros in Gdefine.h (and AXISCALL)
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi All,
In include/axis/server/GDefine.h I see the following lines of code.
105 #if defined (__GNUC__)
106 #if __GNUC_VERSION__ > 30000
107 #define AXISDESTRUCTOR void* unused; void AXISAPI(destructor,(APINOPARAMS))
108 #else
109 #define AXISDESTRUCTOR void* unused; void*unused1;
110 void AXISAPI(destructor,(APINOPARAMS))
111 #endif
112 #else
113 #define AXISDESTRUCTOR void AXISAPI(destructor,(APINOPARAMS))
114 #endif
115 #endif
What is the purpose of this code segment? Is line 110 correct, or should it be appended to line
109? I get an error on line 110 when I compile this source on Rehat Advanced server 2.1
BTW: I sent another question on GDefine macros earlier as well. Can we replace
#define AXISCALL __attribute__((stdcall))
with
#define AXISCALL __attribute__((cdecl))
(in aother words why are we using stdcall and not cdecl? Any perticular reasons?)
Would be of great help if someone could answer these.
Thanks,
Samisa...
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Use of ios header in AxisException
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi Damitha,
The ios header does not exist on platforms with older libraries and tools.
Please remove this from AxisException.h. I hope you could find a backward compatible set of
headers.
Thanks,
Samisa...
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Re: Ability to add custom headers to SOAP messeges, through
the stub
Posted by Roshan Weerasuriya <ro...@opensource.lk>.
hi,
>Also of course we need to check whether we could shift all these Call
class related methods to a Base class, and provide wraparound functions to
those, because currently Call class has a flat structure >and let the user
access the Call object if he need.
I need to correct this above statement a bit.
Also of course we need to check whether we could shift all these Call class
related methods to a Base stub class, (eg, instead of user calling
pCall->setSoapHeader (SoapHeader* pSoapHeader), he would call setSoapHeader
(SoapHeader* pSoapHeader) of the base stub class), and provide wraparound
functions to those to be accessed by the user (i.e to be accessed by the
generated stub), because currently the generated stub has a flat structure.
Because one could argue that the Call class was developed in place, to be
used directly by the user, to set the related properties of his choise.
rgds,
Roshan
At 04:20 PM 5/21/2004 +0600, you wrote:
>hi John,
>
> >At the moment, handlers can be used to set SOAP headers. However stub
> class generated through
> >wsdl2ws tool does not provide an interface to access SOAP headers.
> >Further, a Call object is wrapped by the generated stub class. And Call
> class has access to
> >transport/SOAP payload and parser etc.
>
>The call "Call" is having methods such as:
>-createHeaderBlock()
>-createHeaderBlock (AxisChar* pachLocalName, AxisChar* pachPrefix,
>AxisChar* pachUri)
>-setSoapHeader (SoapHeader* pSoapHeader)
>
>which could be used to add/set SOAP Headers. (/*Underline
>Implementation*/: These methods set the relavent SOAP Headers to the
>Serializer Object). (Which the Handlers also use a similar mechanism,
>/*Underline Implementation*/: Handlers also get access to the Serializer
>object to add/set SOAP Headers.) So curretnly if a user needs to add SOAP
>Headers, he can do it through a call class.
>
>It would be good idea, not to expose all the additional methods which are
>used by the call class to the user. It is better to provide a high lavel
>Base class as Samisa has suggested, and let the user call api methods
>which are at this base class, such as "setSoapHeader (SoapHeader*
>pSoapHeader)". This will not directly let the user touch the Call object
>for these standard activities.
>
>Also of course we need to check whether we could shift all these Call
>class related methods to a Base class, and provide wraparound functions to
>those, because currently Call class has a flat structure and let the user
>access the Call object if he need.
>
>rgds,
>Roshan
>
>
>At 02:39 AM 5/21/2004 -0700, you wrote:
>>Let me add few ideas.
>>
>>At the moment, handlers can be used to set SOAP headers. However stub
>>class generated through
>>wsdl2ws tool does not provide an interface to access SOAP headers.
>>
>>Further, a Call object is wrapped by the generated stub class. And Call
>>class has access to
>>transport/SOAP payload and parser etc.
>>
>>Therefore, if we are to give access to seting transport and message
>>properties at stub level,
>>either we have to give access to the Call object throuhg the stub, or we
>>have to provide an API at
>>stub class level that wraps the Call object. With the current API of Call
>>class, it is not a good
>>idea to expose the Call object to the user, as it does too many things,
>>hence I propose an API at
>>stub class level.
>>
>>The generated stub is a flat class, meaning that it is a single class
>>doing everything. I think it
>>will be a good idea to abstract things to a base Stub class, which would
>>define the base API at
>>stub level. Let the class generated by wsdl2ws tool inherit from the base
>>Stub class and add only
>>wsdl specific stuff to the generated class. This way it would make it
>>easy to add functionality
>>at stub level.
>>
>>This base Stub class should consist of an API where it would allow:
>> - get/set trasport properties e.g. HTTP headers
>> - get/set SOAP headers
>> - get/set endpoint
>> - get/set proxy to tunnel through a proxy server(optinal)
>>
>>Thnaks,
>>Samisas...
>>
>>
>>--- John Hawkins <HA...@uk.ibm.com> wrote:
>> >
>> >
>> >
>> >
>> > Hi Roshan,
>> >
>> > could you get back to me please?
>> >
>> > It's really hard for me to get an idea of what the final interface is
>> going
>> > to be if we keep talking about methods and not Objects.
>> >
>> > thankyou very much,
>> > John.
>> >
>> >
>> >
>> >
>> >
>> > John
>> > Hawkins/UK/IBM@IB
>> > MGB To
>> > "Apache AXIS C Developers List"
>> > 20/05/2004 15:49 <ax...@ws.apache.org>
>> > cc
>> >
>> > Please respond to Subject
>> > "Apache AXIS C Re: Ability to add custom headers
>> > Developers List" to SOAP messeges, through the stub
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Let me get this straight:
>> >
>> > Today I can write a client who can add things to the SOAP header?
>> >
>> > You are proposing adding a method which does not involve a handler? This
>> > method being the one below: setSoapHeader (SoapHeader*
>> > pSoapHeader).
>> >
>> > Which Object is this on? The Call object?
>> >
>> >
>> > John
>> >
>> >
>> >
>> >
>> >
>> > Roshan
>> > Weerasuriya
>> > <roshan@opensourc To
>> > e.lk> "Apache AXIS C Developers List"
>> > <ax...@ws.apache.org>
>> > 20/05/2004 06:47 cc
>> >
>> > Subject
>> > Please respond to Ability to add custom headers to
>> > "Apache AXIS C SOAP messeges, through the stub
>> > Developers List"
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > 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
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>>
>>__________________________________
>>Do you Yahoo!?
>>Yahoo! Domains Claim yours for only $14.70/year
>>http://smallbusiness.promotions.yahoo.com/offer
>
>
>
Re: Ability to add custom headers to SOAP messeges, through
the stub
Posted by Roshan Weerasuriya <ro...@opensource.lk>.
hi John,
>At the moment, handlers can be used to set SOAP headers. However stub
class generated through
>wsdl2ws tool does not provide an interface to access SOAP headers.
>Further, a Call object is wrapped by the generated stub class. And Call
class has access to
>transport/SOAP payload and parser etc.
The call "Call" is having methods such as:
-createHeaderBlock()
-createHeaderBlock (AxisChar* pachLocalName, AxisChar* pachPrefix,
AxisChar* pachUri)
-setSoapHeader (SoapHeader* pSoapHeader)
which could be used to add/set SOAP Headers. (/*Underline Implementation*/:
These methods set the relavent SOAP Headers to the Serializer Object).
(Which the Handlers also use a similar mechanism, /*Underline
Implementation*/: Handlers also get access to the Serializer object to
add/set SOAP Headers.) So curretnly if a user needs to add SOAP Headers, he
can do it through a call class.
It would be good idea, not to expose all the additional methods which are
used by the call class to the user. It is better to provide a high lavel
Base class as Samisa has suggested, and let the user call api methods which
are at this base class, such as "setSoapHeader (SoapHeader* pSoapHeader)".
This will not directly let the user touch the Call object for these
standard activities.
Also of course we need to check whether we could shift all these Call class
related methods to a Base class, and provide wraparound functions to those,
because currently Call class has a flat structure and let the user access
the Call object if he need.
rgds,
Roshan
At 02:39 AM 5/21/2004 -0700, you wrote:
>Let me add few ideas.
>
>At the moment, handlers can be used to set SOAP headers. However stub
>class generated through
>wsdl2ws tool does not provide an interface to access SOAP headers.
>
>Further, a Call object is wrapped by the generated stub class. And Call
>class has access to
>transport/SOAP payload and parser etc.
>
>Therefore, if we are to give access to seting transport and message
>properties at stub level,
>either we have to give access to the Call object throuhg the stub, or we
>have to provide an API at
>stub class level that wraps the Call object. With the current API of Call
>class, it is not a good
>idea to expose the Call object to the user, as it does too many things,
>hence I propose an API at
>stub class level.
>
>The generated stub is a flat class, meaning that it is a single class
>doing everything. I think it
>will be a good idea to abstract things to a base Stub class, which would
>define the base API at
>stub level. Let the class generated by wsdl2ws tool inherit from the base
>Stub class and add only
>wsdl specific stuff to the generated class. This way it would make it
>easy to add functionality
>at stub level.
>
>This base Stub class should consist of an API where it would allow:
> - get/set trasport properties e.g. HTTP headers
> - get/set SOAP headers
> - get/set endpoint
> - get/set proxy to tunnel through a proxy server(optinal)
>
>Thnaks,
>Samisas...
>
>
>--- John Hawkins <HA...@uk.ibm.com> wrote:
> >
> >
> >
> >
> > Hi Roshan,
> >
> > could you get back to me please?
> >
> > It's really hard for me to get an idea of what the final interface is going
> > to be if we keep talking about methods and not Objects.
> >
> > thankyou very much,
> > John.
> >
> >
> >
> >
> >
> > John
> > Hawkins/UK/IBM@IB
> > MGB To
> > "Apache AXIS C Developers List"
> > 20/05/2004 15:49 <ax...@ws.apache.org>
> > cc
> >
> > Please respond to Subject
> > "Apache AXIS C Re: Ability to add custom headers
> > Developers List" to SOAP messeges, through the stub
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Let me get this straight:
> >
> > Today I can write a client who can add things to the SOAP header?
> >
> > You are proposing adding a method which does not involve a handler? This
> > method being the one below: setSoapHeader (SoapHeader*
> > pSoapHeader).
> >
> > Which Object is this on? The Call object?
> >
> >
> > John
> >
> >
> >
> >
> >
> > Roshan
> > Weerasuriya
> > <roshan@opensourc To
> > e.lk> "Apache AXIS C Developers List"
> > <ax...@ws.apache.org>
> > 20/05/2004 06:47 cc
> >
> > Subject
> > Please respond to Ability to add custom headers to
> > "Apache AXIS C SOAP messeges, through the stub
> > Developers List"
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Domains Claim yours for only $14.70/year
>http://smallbusiness.promotions.yahoo.com/offer
Re: Ability to add custom headers to SOAP messeges, through the stub
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Damitha,
I am working on a stub class. However I am facing problems when it comes to dealing with
trasport as I mentioned in my earlier email. I am fixing those problems while I am building the
Stub class.
Samisa...
--- damitha@opensource.lk wrote:
> Hi Samisa,
>
> > The generated stub is a flat class, meaning that it is a single class
> > doing everything. I think it
> > will be a good idea to abstract things to a base Stub class, which would
> > define the base API at
> > stub level. Let the class generated by wsdl2ws tool inherit from the base
> > Stub class and add only
> > wsdl specific stuff to the generated class. This way it would make it
> > easy to add functionality
> > at stub level.
> >
> > This base Stub class should consist of an API where it would allow:
> > - get/set trasport properties e.g. HTTP headers
> > - get/set SOAP headers
> > - get/set endpoint
> > - get/set proxy to tunnel through a proxy server(optinal)
>
> Idea of abstracting a base class that do certain tasks seems to be
> very good. That also reduces the burden of the tool
>
> damitha
>
> >
> >
> > --- John Hawkins <HA...@uk.ibm.com> wrote:
> >>
> >>
> >>
> >>
> >> Hi Roshan,
> >>
> >> could you get back to me please?
> >>
> >> It's really hard for me to get an idea of what the final interface is
> >> going
> >> to be if we keep talking about methods and not Objects.
> >>
> >> thankyou very much,
> >> John.
> >>
> >>
> >>
> >>
> >>
> >> John
> >> Hawkins/UK/IBM@IB
> >> MGB
> >> To
> >> "Apache AXIS C Developers List"
> >> 20/05/2004 15:49 <ax...@ws.apache.org>
> >> cc
> >>
> >> Please respond to
> >> Subject
> >> "Apache AXIS C Re: Ability to add custom headers
> >> Developers List" to SOAP messeges, through the
> >> stub
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Let me get this straight:
> >>
> >> Today I can write a client who can add things to the SOAP header?
> >>
> >> You are proposing adding a method which does not involve a handler? This
> >> method being the one below: setSoapHeader (SoapHeader*
> >> pSoapHeader).
> >>
> >> Which Object is this on? The Call object?
> >>
> >>
> >> John
> >>
> >>
> >>
> >>
> >>
> >> Roshan
> >> Weerasuriya
> >> <roshan@opensourc
> >> To
> >> e.lk> "Apache AXIS C Developers List"
> >> <ax...@ws.apache.org>
> >> 20/05/2004 06:47
> >> cc
> >>
> >> Subject
> >> Please respond to Ability to add custom headers to
> >> "Apache AXIS C SOAP messeges, through the stub
> >> Developers List"
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 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
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Domains � Claim yours for only $14.70/year
> > http://smallbusiness.promotions.yahoo.com/offer
> >
> >
>
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Re: Ability to add custom headers to SOAP messeges,
through the stub
Posted by da...@opensource.lk.
Hi Samisa,
> The generated stub is a flat class, meaning that it is a single class
> doing everything. I think it
> will be a good idea to abstract things to a base Stub class, which would
> define the base API at
> stub level. Let the class generated by wsdl2ws tool inherit from the base
> Stub class and add only
> wsdl specific stuff to the generated class. This way it would make it
> easy to add functionality
> at stub level.
>
> This base Stub class should consist of an API where it would allow:
> - get/set trasport properties e.g. HTTP headers
> - get/set SOAP headers
> - get/set endpoint
> - get/set proxy to tunnel through a proxy server(optinal)
Idea of abstracting a base class that do certain tasks seems to be
very good. That also reduces the burden of the tool
damitha
>
>
> --- John Hawkins <HA...@uk.ibm.com> wrote:
>>
>>
>>
>>
>> Hi Roshan,
>>
>> could you get back to me please?
>>
>> It's really hard for me to get an idea of what the final interface is
>> going
>> to be if we keep talking about methods and not Objects.
>>
>> thankyou very much,
>> John.
>>
>>
>>
>>
>>
>> John
>> Hawkins/UK/IBM@IB
>> MGB
>> To
>> "Apache AXIS C Developers List"
>> 20/05/2004 15:49 <ax...@ws.apache.org>
>> cc
>>
>> Please respond to
>> Subject
>> "Apache AXIS C Re: Ability to add custom headers
>> Developers List" to SOAP messeges, through the
>> stub
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Let me get this straight:
>>
>> Today I can write a client who can add things to the SOAP header?
>>
>> You are proposing adding a method which does not involve a handler? This
>> method being the one below: setSoapHeader (SoapHeader*
>> pSoapHeader).
>>
>> Which Object is this on? The Call object?
>>
>>
>> John
>>
>>
>>
>>
>>
>> Roshan
>> Weerasuriya
>> <roshan@opensourc
>> To
>> e.lk> "Apache AXIS C Developers List"
>> <ax...@ws.apache.org>
>> 20/05/2004 06:47
>> cc
>>
>> Subject
>> Please respond to Ability to add custom headers to
>> "Apache AXIS C SOAP messeges, through the stub
>> Developers List"
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Domains Claim yours for only $14.70/year
> http://smallbusiness.promotions.yahoo.com/offer
>
>
RE: Ability to add custom headers to SOAP messeges, through the stub
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Susantha,
I am working on such a class.
Samisa...
--- Susantha Kumara <su...@opensource.lk> wrote:
> Hi Samisa,
>
> Yes having a base class with WSDL independent functionalities is very
> good.
>
> ---
> Susantha.
>
>
> > -----Original Message-----
> > From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> > Sent: Friday, May 21, 2004 3:39 PM
> > To: Apache AXIS C Developers List
> > Subject: Re: Ability to add custom headers to SOAP messeges, through
> the
> > stub
> >
> > Let me add few ideas.
> >
> > At the moment, handlers can be used to set SOAP headers. However stub
> > class generated through
> > wsdl2ws tool does not provide an interface to access SOAP headers.
> >
> > Further, a Call object is wrapped by the generated stub class. And
> Call
> > class has access to
> > transport/SOAP payload and parser etc.
> >
> > Therefore, if we are to give access to seting transport and message
> > properties at stub level,
> > either we have to give access to the Call object throuhg the stub, or
> we
> > have to provide an API at
> > stub class level that wraps the Call object. With the current API of
> Call
> > class, it is not a good
> > idea to expose the Call object to the user, as it does too many
> things,
> > hence I propose an API at
> > stub class level.
> >
> > The generated stub is a flat class, meaning that it is a single class
> > doing everything. I think it
> > will be a good idea to abstract things to a base Stub class, which
> would
> > define the base API at
> > stub level. Let the class generated by wsdl2ws tool inherit from the
> base
> > Stub class and add only
> > wsdl specific stuff to the generated class. This way it would make it
> > easy to add functionality
> > at stub level.
> >
> > This base Stub class should consist of an API where it would allow:
> > - get/set trasport properties e.g. HTTP headers
> > - get/set SOAP headers
> > - get/set endpoint
> > - get/set proxy to tunnel through a proxy server(optinal)
> >
> > Thnaks,
> > Samisas...
> >
> >
> > --- John Hawkins <HA...@uk.ibm.com> wrote:
> > >
> > >
> > >
> > >
> > > Hi Roshan,
> > >
> > > could you get back to me please?
> > >
> > > It's really hard for me to get an idea of what the final interface
> is
> > going
> > > to be if we keep talking about methods and not Objects.
> > >
> > > thankyou very much,
> > > John.
> > >
> > >
> > >
> > >
> > >
> > > John
> > > Hawkins/UK/IBM@IB
> > > MGB
> > To
> > > "Apache AXIS C Developers
> List"
> > > 20/05/2004 15:49 <ax...@ws.apache.org>
> > >
> > cc
> > >
> > > Please respond to
> > Subject
> > > "Apache AXIS C Re: Ability to add custom
> headers
> > > Developers List" to SOAP messeges, through the
> > stub
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Let me get this straight:
> > >
> > > Today I can write a client who can add things to the SOAP header?
> > >
> > > You are proposing adding a method which does not involve a handler?
> This
> > > method being the one below: setSoapHeader (SoapHeader*
> > > pSoapHeader).
> > >
> > > Which Object is this on? The Call object?
> > >
> > >
> > > John
> > >
> > >
> > >
> > >
> > >
> > > Roshan
> > > Weerasuriya
> > > <roshan@opensourc
> > To
> > > e.lk> "Apache AXIS C Developers
> List"
> > > <ax...@ws.apache.org>
> > > 20/05/2004 06:47
> > cc
> > >
> > >
> > Subject
> > > Please respond to Ability to add custom headers
> to
> > > "Apache AXIS C SOAP messeges, through the
> stub
> > > Developers List"
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Domains - Claim yours for only $14.70/year
> > http://smallbusiness.promotions.yahoo.com/offer
>
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
RE: Ability to add custom headers to SOAP messeges, through the stub
Posted by Susantha Kumara <su...@opensource.lk>.
Hi Samisa,
Yes having a base class with WSDL independent functionalities is very
good.
---
Susantha.
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Friday, May 21, 2004 3:39 PM
> To: Apache AXIS C Developers List
> Subject: Re: Ability to add custom headers to SOAP messeges, through
the
> stub
>
> Let me add few ideas.
>
> At the moment, handlers can be used to set SOAP headers. However stub
> class generated through
> wsdl2ws tool does not provide an interface to access SOAP headers.
>
> Further, a Call object is wrapped by the generated stub class. And
Call
> class has access to
> transport/SOAP payload and parser etc.
>
> Therefore, if we are to give access to seting transport and message
> properties at stub level,
> either we have to give access to the Call object throuhg the stub, or
we
> have to provide an API at
> stub class level that wraps the Call object. With the current API of
Call
> class, it is not a good
> idea to expose the Call object to the user, as it does too many
things,
> hence I propose an API at
> stub class level.
>
> The generated stub is a flat class, meaning that it is a single class
> doing everything. I think it
> will be a good idea to abstract things to a base Stub class, which
would
> define the base API at
> stub level. Let the class generated by wsdl2ws tool inherit from the
base
> Stub class and add only
> wsdl specific stuff to the generated class. This way it would make it
> easy to add functionality
> at stub level.
>
> This base Stub class should consist of an API where it would allow:
> - get/set trasport properties e.g. HTTP headers
> - get/set SOAP headers
> - get/set endpoint
> - get/set proxy to tunnel through a proxy server(optinal)
>
> Thnaks,
> Samisas...
>
>
> --- John Hawkins <HA...@uk.ibm.com> wrote:
> >
> >
> >
> >
> > Hi Roshan,
> >
> > could you get back to me please?
> >
> > It's really hard for me to get an idea of what the final interface
is
> going
> > to be if we keep talking about methods and not Objects.
> >
> > thankyou very much,
> > John.
> >
> >
> >
> >
> >
> > John
> > Hawkins/UK/IBM@IB
> > MGB
> To
> > "Apache AXIS C Developers
List"
> > 20/05/2004 15:49 <ax...@ws.apache.org>
> >
> cc
> >
> > Please respond to
> Subject
> > "Apache AXIS C Re: Ability to add custom
headers
> > Developers List" to SOAP messeges, through the
> stub
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Let me get this straight:
> >
> > Today I can write a client who can add things to the SOAP header?
> >
> > You are proposing adding a method which does not involve a handler?
This
> > method being the one below: setSoapHeader (SoapHeader*
> > pSoapHeader).
> >
> > Which Object is this on? The Call object?
> >
> >
> > John
> >
> >
> >
> >
> >
> > Roshan
> > Weerasuriya
> > <roshan@opensourc
> To
> > e.lk> "Apache AXIS C Developers
List"
> > <ax...@ws.apache.org>
> > 20/05/2004 06:47
> cc
> >
> >
> Subject
> > Please respond to Ability to add custom headers
to
> > "Apache AXIS C SOAP messeges, through the
stub
> > Developers List"
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
> >
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Domains - Claim yours for only $14.70/year
> http://smallbusiness.promotions.yahoo.com/offer
Re: Ability to add custom headers to SOAP messeges, through the stub
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Let me add few ideas.
At the moment, handlers can be used to set SOAP headers. However stub class generated through
wsdl2ws tool does not provide an interface to access SOAP headers.
Further, a Call object is wrapped by the generated stub class. And Call class has access to
transport/SOAP payload and parser etc.
Therefore, if we are to give access to seting transport and message properties at stub level,
either we have to give access to the Call object throuhg the stub, or we have to provide an API at
stub class level that wraps the Call object. With the current API of Call class, it is not a good
idea to expose the Call object to the user, as it does too many things, hence I propose an API at
stub class level.
The generated stub is a flat class, meaning that it is a single class doing everything. I think it
will be a good idea to abstract things to a base Stub class, which would define the base API at
stub level. Let the class generated by wsdl2ws tool inherit from the base Stub class and add only
wsdl specific stuff to the generated class. This way it would make it easy to add functionality
at stub level.
This base Stub class should consist of an API where it would allow:
- get/set trasport properties e.g. HTTP headers
- get/set SOAP headers
- get/set endpoint
- get/set proxy to tunnel through a proxy server(optinal)
Thnaks,
Samisas...
--- John Hawkins <HA...@uk.ibm.com> wrote:
>
>
>
>
> Hi Roshan,
>
> could you get back to me please?
>
> It's really hard for me to get an idea of what the final interface is going
> to be if we keep talking about methods and not Objects.
>
> thankyou very much,
> John.
>
>
>
>
>
> John
> Hawkins/UK/IBM@IB
> MGB To
> "Apache AXIS C Developers List"
> 20/05/2004 15:49 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C Re: Ability to add custom headers
> Developers List" to SOAP messeges, through the stub
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Let me get this straight:
>
> Today I can write a client who can add things to the SOAP header?
>
> You are proposing adding a method which does not involve a handler? This
> method being the one below: setSoapHeader (SoapHeader*
> pSoapHeader).
>
> Which Object is this on? The Call object?
>
>
> John
>
>
>
>
>
> Roshan
> Weerasuriya
> <roshan@opensourc To
> e.lk> "Apache AXIS C Developers List"
> <ax...@ws.apache.org>
> 20/05/2004 06:47 cc
>
> Subject
> Please respond to Ability to add custom headers to
> "Apache AXIS C SOAP messeges, through the stub
> Developers List"
>
>
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>
__________________________________
Do you Yahoo!?
Yahoo! Domains � Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer
Re: Ability to add custom headers to SOAP messeges, through the stub
Posted by John Hawkins <HA...@uk.ibm.com>.
Hi Roshan,
could you get back to me please?
It's really hard for me to get an idea of what the final interface is going
to be if we keep talking about methods and not Objects.
thankyou very much,
John.
John
Hawkins/UK/IBM@IB
MGB To
"Apache AXIS C Developers List"
20/05/2004 15:49 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: Ability to add custom headers
Developers List" to SOAP messeges, through the stub
Let me get this straight:
Today I can write a client who can add things to the SOAP header?
You are proposing adding a method which does not involve a handler? This
method being the one below: setSoapHeader (SoapHeader*
pSoapHeader).
Which Object is this on? The Call object?
John
Roshan
Weerasuriya
<roshan@opensourc To
e.lk> "Apache AXIS C Developers List"
<ax...@ws.apache.org>
20/05/2004 06:47 cc
Subject
Please respond to Ability to add custom headers to
"Apache AXIS C SOAP messeges, through the stub
Developers List"
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
Re: Ability to add custom headers to SOAP messeges, through the stub
Posted by John Hawkins <HA...@uk.ibm.com>.
Let me get this straight:
Today I can write a client who can add things to the SOAP header?
You are proposing adding a method which does not involve a handler? This
method being the one below: setSoapHeader (SoapHeader*
pSoapHeader).
Which Object is this on? The Call object?
John
Roshan
Weerasuriya
<roshan@opensourc To
e.lk> "Apache AXIS C Developers List"
<ax...@ws.apache.org>
20/05/2004 06:47 cc
Subject
Please respond to Ability to add custom headers to
"Apache AXIS C SOAP messeges, through the stub
Developers List"
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
Re: Ability to add custom headers to SOAP messeges, through
the stub
Posted by Roshan Weerasuriya <ro...@opensource.lk>.
hi,
>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.
>Would this be a good model to follow in C/C++?
Axis C++ currently has this implementation in the MessageData class, i.e
setProperty (AxisChar* pachName, const AxisChar* pachValue), getProperty
(AxisChar* pachName) to get and set string properties. This MessageData
class (i.e the current MessageData instance) is accessible by all the
Handlers, since the MessageData instance is passed throughout the flow.
As you suggest we could let this open to the stub object, so that client
handlers could use this.
rgds,
Roshan
At 11:07 AM 5/25/2004 +0100, you wrote:
>In Axis Java (or JAX-RPC) the way this is done is in two parts.
>
>Firstly the user calls stub._setProperty("name", valueObject);
>
>then a handler is defined, which is coded to understand the "name", and to
>know the SOAP Header structure. So the handler does:
>
>value = getProperty("name");
>
>and then
>
>SOAPElement el = ..... /// create 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.
>
>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
>>>
>>>
>>
>>
>
Re: Ability to add custom headers to SOAP messeges, through
the stub
Posted by Roshan Weerasuriya <ro...@opensource.lk>.
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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
RE: Ability to add custom headers to SOAP messeges, through the stub
Posted by Susantha Kumara <su...@opensource.lk>.
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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
Re: Ability to add custom headers to SOAP messeges, through
the stub
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
Re: Ability to add custom headers to SOAP messeges,
through the stub
Posted by su...@opensource.lk.
> 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
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: Ability to add custom headers to SOAP messeges, through the
stub
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
In Axis Java (or JAX-RPC) the way this is done is in two parts.
Firstly the user calls stub._setProperty("name", valueObject);
then a handler is defined, which is coded to understand the "name", and
to know the SOAP Header structure. So the handler does:
value = getProperty("name");
and then
SOAPElement el = ..... /// create 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.
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
>>
>>
>>
>
>
>
RE: Ability to add custom headers to SOAP messeges, through the stub
Posted by Susantha Kumara <su...@opensource.lk>.
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
>