axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa.abeysin...@gmail.com>
Subject Re: The OpenSSL DLL and SecureChannel parts of Axis2Transpor
Date Mon, 20 Dec 2004 14:22:24 GMT
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
<damitha@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
> > > <damitha@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)
> 
>

Mime
View raw message