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 Damitha Kumarage <da...@opensource.lk> on 2004/12/20 12:30:48 UTC
Re: The OpenSSL DLL and SecureChannel parts of Axis2Transpor
Hi Samisa,
On Mon, 2004-12-20 at 15:28, Susantha Kumara wrote:
Samisa Abeysinghe wrote:
> Damitha,
> > Regarding dynamically loading only the channel:
> >
> >
> > One other thing. Currently we support dynamically loadble transport support.
> > > That means that one can write his own tranport
> > > implementing SOAPTransport.hpp and plug it into axis c++. I think this
should
> > > be changed. Axis2Transport transport implementation should statically
bind to
> > > axis client engine and it should be the channel that should be dynamically
> > > loaded. One can write his channel library implementing Channel.hpp I
proposed
> > > above and plug it into axis c++.
> > > What do you think?.
> > >
> > >
> > I think, it is not only the channel, but the whole of Axis2Transport
> > should be loaded dynamically. It is tue that the Channel class handles
> > the socket connection stuff. However, one could choose to implement,
> > use another HTTP handling lib. The best example I can think of is
> > LibWWW - if that is to be used, no need of current Axis2Transport
> > class.
> >
Yes I know that using the api one can implement/use different HTTP handling
capablities. What I need to point out is whether axis need to provide this
much flexiblity. Because this kind of unncessary flexiblity we have wasted lot
of our developer time. To me this should have been an initial design
decision.We wanted support to libwww support and it is now in the graveyard.
Expat is now resting in graveyard.
I think we should decide where we should provide pluggablity. We can make
HTTP handling as robust as possible whith our new transport. So selecting Axis
C++ client means one select our http handling
capblities as well. But we should let him select his own channel for security
reasons etc.
So still I have the feeling that transport is part of client engine and it is
the channel we should make a dll. I am not proposing this change to our
existing architecture. I'm just interested to know what you think.
> > Samisa...
> >
> >
> > On Fri, 17 Dec 2004 11:47:19 +0600, Damitha Kumarage
> > <da...@opensource.lk> wrote:
> >
> > Hi Fred, Samisa,
> > >
> > > Although this is too late I think the cleanest solution should be something
> > > like this
> > >
> > > We have a base class called Channel.hpp which has pure virtual methods
> > > It have all the methods exepected from a tcp channel, secure or unsecure.
> > > Now any body can write his own secure or unseucure channel implementing this
> > > interface. .
> > >
> > > One can write a channel dll implementing this Channel.hpp interface.
> > > This dll can be for a seucure channelling or unsecure channelling.
> > >
> > > For default unsecure channeling we derive TCPChannel.hpp from
Channel.hpp for
> > > unsecure channelling(statically). The unused secure methods can have dummy
> > > implementations.
> > >
> > > For default secure channeling we can write a dll which uses OpenSSL and
secure
> > > channel class derive from Channel.hpp interface.
> > >
> > > This way it is very clear and I'm sure that I can make this work both on
> > > windows and linux because I have tested this functionlity on both platforms.
> > >
> > > Maybe we can do this for 1.5 because it is now too late for 1.4. The reason
> > > that I could not come up with this is that I tried to keep now existing
> > > Channel.hpp and SecureChannel.hpp unchanged.
> > >
> > > However note that in this way it is not possible to reuse the tcp
channel open
> > > functionality from Channel.cpp for secure channel, like we earlier wanted,
> > > because now Channel.hpp has all pure virtual functions.
> > > and it is neccessary for loading a dll in a seperate space(I guess)
> > >
> > > One other thing. Currently we support dynamically loadble transport
support.
> > > That means that one can write his own tranport
> > > implementing SOAPTransport.hpp and plug it into axis c++. I think this
should
> > > be changed. Axis2Transport transport implementation should statically
bind to
> > > axis client engine and it should be the channel that should be dynamically
> > > loaded. One can write his channel library implementing Channel.hpp I
proposed
> > > above and plug it into axis c++.
> > > What do you think?.
> > >
> > > thanks
> > > damitha
> > > --
> > > Damitha Kumarage
> > > hSenid Software International (PVT) Ltd
> > > damitha@hSenid.lk
> > >
> > > Lanka Software Foundation (http://www.opensource.lk)
> > >
> > >
> > >
> > >
> >
> >
> > Yes the transport can be of some other protocol than HTTP. So this
AxisTransport API should be protocol independent.
>
Providing support for other transports is also our responsiblity. But this
need not necessary make our whole transport a dll. This is just a thought.
Please give more thoughts
thanks
damitha
--
Damitha Kumarage
hSenid Software International (PVT) Ltd
damitha@hSenid.lk
Lanka Software Foundation (http://www.opensource.lk)
Re: The OpenSSL DLL and SecureChannel parts of Axis2Transpor
Posted by Susantha Kumara <su...@opensource.lk>.
Samisa Abeysinghe wrote:
>The fact that Expat, and LibWWW are in graveyard is not because that
>Abstraction layers are bad designs or over designs, rather because
>maintanance is problamatic because of lack of resources. However,
>keeping them in place keeps the windows open for much needed
>flexibility.
>
>I remember couple or more users asking over the mailing list, if they
>could use their own transport lib with the core Axis C++ engine. This
>means that users do want to use their own transport. Hence I do not
>agree binding HTTP into client engine - IMHO, the way it is now is the
>best.
>
>LibWWW is not thread safe, however, if one wants a feature rich
>transport, I still suggest that one uses LibWWW based transport. Also,
>there are thread safe alternatives such as libCurl - which could be
>integrated using the transport abstraction option available.
>
>I do not see any advantage of removing the abstraction layer at all -
>I see many advantages keeping it in place.
>
>Thanks,
>Samisa...
>
>
>
>On Mon, 20 Dec 2004 17:30:48 +0600, Damitha Kumarage
><da...@opensource.lk> wrote:
>
>
>>Hi Samisa,
>>On Mon, 2004-12-20 at 15:28, Susantha Kumara wrote:
>>Samisa Abeysinghe wrote:
>>
>>
>>>Damitha,
>>>
>>>
>>>> Regarding dynamically loading only the channel:
>>>>
>>>>
>>>>One other thing. Currently we support dynamically loadble transport support.
>>>>
>>>>
>>>>>That means that one can write his own tranport
>>>>>implementing SOAPTransport.hpp and plug it into axis c++. I think this
>>>>>
>>>>>
>>should
>>
>>
>>>>>be changed. Axis2Transport transport implementation should statically
>>>>>
>>>>>
>>bind to
>>
>>
>>>>>axis client engine and it should be the channel that should be dynamically
>>>>>loaded. One can write his channel library implementing Channel.hpp I
>>>>>
>>>>>
>>proposed
>>
>>
>>>>>above and plug it into axis c++.
>>>>>What do you think?.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I think, it is not only the channel, but the whole of Axis2Transport
>>>>should be loaded dynamically. It is tue that the Channel class handles
>>>>the socket connection stuff. However, one could choose to implement,
>>>>use another HTTP handling lib. The best example I can think of is
>>>>LibWWW - if that is to be used, no need of current Axis2Transport
>>>>class.
>>>>
>>>>
>>>>
>>Yes I know that using the api one can implement/use different HTTP handling
>>capablities. What I need to point out is whether axis need to provide this
>>much flexiblity. Because this kind of unncessary flexiblity we have wasted lot
>>of our developer time. To me this should have been an initial design
>>decision.We wanted support to libwww support and it is now in the graveyard.
>>Expat is now resting in graveyard.
>>I think we should decide where we should provide pluggablity. We can make
>>HTTP handling as robust as possible whith our new transport. So selecting Axis
>>C++ client means one select our http handling
>>capblities as well. But we should let him select his own channel for security
>>reasons etc.
>>
>>So still I have the feeling that transport is part of client engine and it is
>>the channel we should make a dll. I am not proposing this change to our
>>existing architecture. I'm just interested to know what you think.
>>
>>
>>
>>>>Samisa...
>>>>
>>>>
>>>>On Fri, 17 Dec 2004 11:47:19 +0600, Damitha Kumarage
>>>><da...@opensource.lk> wrote:
>>>>
>>>>Hi Fred, Samisa,
>>>>
>>>>
>>>>>Although this is too late I think the cleanest solution should be something
>>>>>like this
>>>>>
>>>>>We have a base class called Channel.hpp which has pure virtual methods
>>>>>It have all the methods exepected from a tcp channel, secure or unsecure.
>>>>>Now any body can write his own secure or unseucure channel implementing this
>>>>>interface. .
>>>>>
>>>>>One can write a channel dll implementing this Channel.hpp interface.
>>>>>This dll can be for a seucure channelling or unsecure channelling.
>>>>>
>>>>>For default unsecure channeling we derive TCPChannel.hpp from
>>>>>
>>>>>
>>Channel.hpp for
>>
>>
>>>>>unsecure channelling(statically). The unused secure methods can have dummy
>>>>>implementations.
>>>>>
>>>>>For default secure channeling we can write a dll which uses OpenSSL and
>>>>>
>>>>>
>>secure
>>
>>
>>>>>channel class derive from Channel.hpp interface.
>>>>>
>>>>>This way it is very clear and I'm sure that I can make this work both on
>>>>>windows and linux because I have tested this functionlity on both platforms.
>>>>>
>>>>>Maybe we can do this for 1.5 because it is now too late for 1.4. The reason
>>>>>that I could not come up with this is that I tried to keep now existing
>>>>>Channel.hpp and SecureChannel.hpp unchanged.
>>>>>
>>>>>However note that in this way it is not possible to reuse the tcp
>>>>>
>>>>>
>>channel open
>>
>>
>>>>>functionality from Channel.cpp for secure channel, like we earlier wanted,
>>>>>because now Channel.hpp has all pure virtual functions.
>>>>>and it is neccessary for loading a dll in a seperate space(I guess)
>>>>>
>>>>>One other thing. Currently we support dynamically loadble transport
>>>>>
>>>>>
>>support.
>>
>>
>>>>>That means that one can write his own tranport
>>>>>implementing SOAPTransport.hpp and plug it into axis c++. I think this
>>>>>
>>>>>
>>should
>>
>>
>>>>>be changed. Axis2Transport transport implementation should statically
>>>>>
>>>>>
>>bind to
>>
>>
>>>>>axis client engine and it should be the channel that should be dynamically
>>>>>loaded. One can write his channel library implementing Channel.hpp I
>>>>>
>>>>>
>>proposed
>>
>>
>>>>>above and plug it into axis c++.
>>>>>What do you think?.
>>>>>
>>>>>thanks
>>>>>damitha
>>>>>--
>>>>>Damitha Kumarage
>>>>>hSenid Software International (PVT) Ltd
>>>>>damitha@hSenid.lk
>>>>>
>>>>>Lanka Software Foundation (http://www.opensource.lk)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Yes the transport can be of some other protocol than HTTP. So this
>>>>
>>>>
>>AxisTransport API should be protocol independent.
>>
>>
>>Providing support for other transports is also our responsiblity. But this
>>need not necessary make our whole transport a dll. This is just a thought.
>>Please give more thoughts
>>
>>thanks
>>damitha
>>
>>--
>>Damitha Kumarage
>>hSenid Software International (PVT) Ltd
>>damitha@hSenid.lk
>>
>>Lanka Software Foundation (http://www.opensource.lk)
>>
>>
>>
>>
>
>
>
>
I agree with Samisa to keep these abstraction layers in place. Also this
abstraction layers help anyone to develop his/her own transports and/or
parsers without much knowladge on the rest of Axis. For example one can
write a transport that compresses the packet before sending and
decompresses the packet after it reads from socket or what ever.
Regards,
Susantha.
Re: The OpenSSL DLL and SecureChannel parts of Axis2Transpor
Posted by Samisa Abeysinghe <sa...@gmail.com>.
The fact that Expat, and LibWWW are in graveyard is not because that
Abstraction layers are bad designs or over designs, rather because
maintanance is problamatic because of lack of resources. However,
keeping them in place keeps the windows open for much needed
flexibility.
I remember couple or more users asking over the mailing list, if they
could use their own transport lib with the core Axis C++ engine. This
means that users do want to use their own transport. Hence I do not
agree binding HTTP into client engine - IMHO, the way it is now is the
best.
LibWWW is not thread safe, however, if one wants a feature rich
transport, I still suggest that one uses LibWWW based transport. Also,
there are thread safe alternatives such as libCurl - which could be
integrated using the transport abstraction option available.
I do not see any advantage of removing the abstraction layer at all -
I see many advantages keeping it in place.
Thanks,
Samisa...
On Mon, 20 Dec 2004 17:30:48 +0600, Damitha Kumarage
<da...@opensource.lk> wrote:
> Hi Samisa,
> On Mon, 2004-12-20 at 15:28, Susantha Kumara wrote:
> Samisa Abeysinghe wrote:
> > Damitha,
> > > Regarding dynamically loading only the channel:
> > >
> > >
> > > One other thing. Currently we support dynamically loadble transport support.
> > > > That means that one can write his own tranport
> > > > implementing SOAPTransport.hpp and plug it into axis c++. I think this
> should
> > > > be changed. Axis2Transport transport implementation should statically
> bind to
> > > > axis client engine and it should be the channel that should be dynamically
> > > > loaded. One can write his channel library implementing Channel.hpp I
> proposed
> > > > above and plug it into axis c++.
> > > > What do you think?.
> > > >
> > > >
> > > I think, it is not only the channel, but the whole of Axis2Transport
> > > should be loaded dynamically. It is tue that the Channel class handles
> > > the socket connection stuff. However, one could choose to implement,
> > > use another HTTP handling lib. The best example I can think of is
> > > LibWWW - if that is to be used, no need of current Axis2Transport
> > > class.
> > >
> Yes I know that using the api one can implement/use different HTTP handling
> capablities. What I need to point out is whether axis need to provide this
> much flexiblity. Because this kind of unncessary flexiblity we have wasted lot
> of our developer time. To me this should have been an initial design
> decision.We wanted support to libwww support and it is now in the graveyard.
> Expat is now resting in graveyard.
> I think we should decide where we should provide pluggablity. We can make
> HTTP handling as robust as possible whith our new transport. So selecting Axis
> C++ client means one select our http handling
> capblities as well. But we should let him select his own channel for security
> reasons etc.
>
> So still I have the feeling that transport is part of client engine and it is
> the channel we should make a dll. I am not proposing this change to our
> existing architecture. I'm just interested to know what you think.
>
> > > Samisa...
> > >
> > >
> > > On Fri, 17 Dec 2004 11:47:19 +0600, Damitha Kumarage
> > > <da...@opensource.lk> wrote:
> > >
> > > Hi Fred, Samisa,
> > > >
> > > > Although this is too late I think the cleanest solution should be something
> > > > like this
> > > >
> > > > We have a base class called Channel.hpp which has pure virtual methods
> > > > It have all the methods exepected from a tcp channel, secure or unsecure.
> > > > Now any body can write his own secure or unseucure channel implementing this
> > > > interface. .
> > > >
> > > > One can write a channel dll implementing this Channel.hpp interface.
> > > > This dll can be for a seucure channelling or unsecure channelling.
> > > >
> > > > For default unsecure channeling we derive TCPChannel.hpp from
> Channel.hpp for
> > > > unsecure channelling(statically). The unused secure methods can have dummy
> > > > implementations.
> > > >
> > > > For default secure channeling we can write a dll which uses OpenSSL and
> secure
> > > > channel class derive from Channel.hpp interface.
> > > >
> > > > This way it is very clear and I'm sure that I can make this work both on
> > > > windows and linux because I have tested this functionlity on both platforms.
> > > >
> > > > Maybe we can do this for 1.5 because it is now too late for 1.4. The reason
> > > > that I could not come up with this is that I tried to keep now existing
> > > > Channel.hpp and SecureChannel.hpp unchanged.
> > > >
> > > > However note that in this way it is not possible to reuse the tcp
> channel open
> > > > functionality from Channel.cpp for secure channel, like we earlier wanted,
> > > > because now Channel.hpp has all pure virtual functions.
> > > > and it is neccessary for loading a dll in a seperate space(I guess)
> > > >
> > > > One other thing. Currently we support dynamically loadble transport
> support.
> > > > That means that one can write his own tranport
> > > > implementing SOAPTransport.hpp and plug it into axis c++. I think this
> should
> > > > be changed. Axis2Transport transport implementation should statically
> bind to
> > > > axis client engine and it should be the channel that should be dynamically
> > > > loaded. One can write his channel library implementing Channel.hpp I
> proposed
> > > > above and plug it into axis c++.
> > > > What do you think?.
> > > >
> > > > thanks
> > > > damitha
> > > > --
> > > > Damitha Kumarage
> > > > hSenid Software International (PVT) Ltd
> > > > damitha@hSenid.lk
> > > >
> > > > Lanka Software Foundation (http://www.opensource.lk)
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > Yes the transport can be of some other protocol than HTTP. So this
> AxisTransport API should be protocol independent.
> >
> Providing support for other transports is also our responsiblity. But this
> need not necessary make our whole transport a dll. This is just a thought.
> Please give more thoughts
>
> thanks
> damitha
>
> --
> Damitha Kumarage
> hSenid Software International (PVT) Ltd
> damitha@hSenid.lk
>
> Lanka Software Foundation (http://www.opensource.lk)
>
>