axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Susantha Kumara <susan...@opensource.lk>
Subject Re: The OpenSSL DLL and SecureChannel parts of Axis2Transpor
Date Tue, 21 Dec 2004 04:36:09 GMT
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.

Regards,

Susantha.


Mime
View raw message