axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Damitha Kumarage" <dami...@opensource.lk>
Subject Re: The OpenSSL DLL and SecureChannel parts of Axis2Transpor
Date Tue, 21 Dec 2004 05:00:18 GMT
Susantha,

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
> <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)
> > 
> > 
> >     
> > 
> 
>   
> 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. 

I think one can write a loadalble channel that compress the packet before
sending and decompresses the packet after it reads

thanks
damitha

Regards,

Susantha.




--
Damitha Kumarage
hSenid Software International (PVT) Ltd
damitha@hSenid.lk

Lanka Software Foundation (http://www.opensource.lk)


Mime
View raw message