axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roshan Weerasuriya <ros...@opensource.lk>
Subject Re: The OpenSSL DLL and SecureChannel parts of Axis2Transpor
Date Tue, 21 Dec 2004 07:07:17 GMT
hi All,

I too don't think the following is a good idea:
"Axis2Transport transport implementation should statically bind to axis
client engine a ...."

In my openion I think it is better to keep the transport abstraction
layers and I too agree with keeping these abstraction layers in place.


Roshan

On Tue, 2004-12-21 at 11:25, Susantha Kumara wrote:
> Damitha Kumarage wrote:
> > 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)
> > 
> > 
> > 
> >   
> Yes loadable channels can be done. But why dont we statically compile
> them all in to the Transport DLL ?. 
> 
> Anyway one reason that I see for making loadable channels is to avoid
> loading unused channels. This is logical only if those channels are
> very memory expensive (if at least >50K). 
> 
> Susantha.


Mime
View raw message