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/21 12:20:15 UTC
Re: Ability to add custom headers to SOAP messeges, through
the stub
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,
>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
>
>
>