axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa_abeysin...@yahoo.com>
Subject Re: SSL implementation
Date Fri, 12 Nov 2004 02:34:53 GMT
Hi Fred / Damitha,
 
    I have been thinking of IPV6 support for Axis C++.
    I am yet to do a concrete design, but it looks to me that I would be able to achieve the
job
by specilizing the Channel class to do IPV6 specific stuff and leave Axis2Transport class
as it
is.

    Going through your discussions on SSL support, I guess what you guys also nees is a specilized
Channel class to work with Axis2Transport. Axis2Transport class handles more HTTP specific
stuff,
and gets the support from channel class to send them over to server side (hence I think it
is
better to change the name). 
    
    Please take my requirement into account wehn you guys design the class hierarchy for Channels.

Thanks,
Samisa...    
     

--- Damitha Kumarage <damitha@opensource.lk> wrote:

> Hi Fred,
> It seems that what I have in mind is somewhat different. Yet we are closer
> See below
> >
> >
> >
> >
> > Hi Damitha,
> >       I've been playing around with an implementation and have been able
> > to clarify a few ideas from yesterday's e-mail.  Let me run this past
> > you to see what you think...
> 
> I also have been playing around with another implementation and have some
> ideas as below
> 
> >
> > We need a generic way to implement other types of http transport, such as
> > SSL.  I want to minimise the amount of change to the existing
> > Axis2Transport methods and to keep the code as reusable as possible.  The
> > simplest way of doing this is to create a new object based on the existing
> > Channel object that has exactly the same public methods and will interface
> > with other, 'plugable' transport DLLs using a common API between the new
> > object and the DLL. i.e.
> 
> agree
> 
> >
> > 1. Channel is the base object.
> 
> ok
> 
> > 2. PlugInSecureChannel is derived from Channel and is expecting to load a
> >    DLL with a common API  (C, non-decorated).
> 
> In my case I thought of keeping SecureChannel derived from Channel and
> inside the axis2 transport. In SecureChannel we load the pluggable dll
> which implements a generic SSL api provided by Axis C++.
> I Name this as SSLChannel and SSLChannel.h is placed in src/transport
> along with SOAPTransport.h and it has following methods
> 
> openSSLChanel
> closeSSLChannel
> sslRead
> sslWrite
> initSSL etc.
> 
> In my ssl channel library I have C++ class derived from this interface and
> it has  open ssl 's C methods wrapped inside it. In addition it has dll
> interface methods like create, destroy etc.
> 
> I have Factory class called SSLChannelFactory which will load and return a
> SSLChannel object to the SecureChannel.
> 
> SecureChannel's derived methods(From Channel) will call this instance
> methods as neccessary to do ssl stuff.
> 
> Any thoughts regarding this
> 
> thanks
> damitha
> 
> 
> 
> > 3. SecureChannel is a DLL and is the implementation of the SSL over HTTP
> >    and exports its public methods through an API (C, non-decorated).
> >
> > So the DLLs is wrapped as follows:-
> >
> >                 .> PlugInSecureChannel -> (API) -> SecureChannel.dll
> > Axis2Transport /   (derived from Channel)         (Implementation of
> >                \                                   SSL over HTTP)
> >                 .> Channel
> >
> > An example would be as follows:-
> >
> > A call to Axis2Transport.setEndpointUri() creates either a Channel or
> > PlugInSecureChannel object depending on the supplied URL and then calls
> > m_pChannel->SetURL() on the instanciated object.  If the object is a
> > PlugInSecureChannel object, then this call calls
> > PlugInSecureChannel.SetURL()
> > which in turn calls GetProcAddress( SecureChannelLibrary, "SetURL") with
> > the parameter list set to the URL.
> >
> > Below is a mapping from Channel object to library call...
> >
> > PlugInSecureChannel                            DLL API (so far...)
> > ----------------------------------------------+-------------------------
> > PlugInSecureChannel()                          Create()
> > ~PlugInSecureChannel()                         Destroy()
> > void setURL( const char *)
> > void setURL( URL)
> > const char * getURL()
> > URL& getURLObject()
> > bool open()                                    Open()
> > void close()                                   Close()
> > const Channel & operator >> ( string &)        Read( const char *)
> > const Channel & readNonBlocking( string&, bool)
> > const Channel & operator << ( const char *)    Write( const char *)
> > const string & GetLastError()
> > void setTimeout( unsigned int)
> > void setSocket( unsigned int)
> > void setMsgLength( int)
> > int getMsgLength()
> > char * getMsg()
> >
> > On the DLL side, what I've done is blended the C exported calls back into
> > a
> > C++ object that is derived from the Channel class and overridden the
> > methods that
> > require additional SSL calls.  Thus I've ended up with a plugable
> > SecureChannel
> > that will not effect the operation of the existing unsecure Channel
> > implementation.
> >
> > Regards,
> >
> > Fred Preston.
> >
> >
> >
> >
> >                       damitha@opensourc
> >                       e.lk                     To:       "Apache AXIS C
> > Developers List" <axis-c-dev@ws.apache.org>
> >                                                cc:
> >                       09/11/04 03:37           Subject:  Re: SSL
> > implementation
> >                       Please respond to
> >                       "Apache AXIS C
> >                       Developers List"
> >
> >
> >
> >
> > Hi Fred,
> >  I think now it is getting clear to me.
> > I'll put it as I understood it.
> >
> > In SecureChannel we get the instance of ssl implementation(using a ssl
> > factory) that
> > implements(through a wrapper) a ssl api provided by axis2 transport.
> > In SecureChannel methods, this ssl instance's methods are called as
> > necessary.
> >
> > The above mentioned ssl implementation is a shared library we need to
> > write using libraries of a ssl implementation library(wrapping them). Our
> > SecureChannel will laod it using ssl factory.
> >
> > see below
> >
> >>
> >>
> >>
> >>
> >> Hi Damitha,
> >>       I didn't want to create a new Axis2Transport class as this would
> >> lead
> >> to code replication and the problems of supporting two or more versions
> > of
> >> the what will largely be identical code.  I thought that the simplest
> >> way
> >> to link in an additional secure transport would be to use the existing
> >> unsecure transport model and to add a secure channel stub/template that
> >> would link to a library (dll) with a generic API that would implement
> >> the
> >> base set of functions (such as open, close, >>, <<, etc).  The user
> >> would
> >> still be able to get and set transport properties for this transport and
> >> communicate with it in the same way as before.  The existing
> >> Axis2Transport
> >> object need only look at the beginning of the URL ('http://...' or
> >> 'https://...') that it is passed to determine whether it needs to open
> >> an
> >> ordinary, unsecure or secure channel (thus no flag passing is required).
> >>
> >>   The SSL dll could still create an unsecure channel object to handle
> >> basic
> >> transport operations, but would have the ability to extend the operation
> >> of
> >> that object to suit its needs.
> >>
> >>            |
> >>            V                  When Axis2Transport opens a connection, it
> >>      Axis2Transport           already knows the endpoint URI, thus knows
> >>      |            |           whether to open a normal or secure
> >> channel.
> >>      V            V
> >>   Channel    SecureChannel    Assuming that it is a secure channel, then
> >>                   |           create a SecureChannel object (which is
> >> the
> >>                   |           same as a Channel object).  When
> >> Axis2Transport
> >>                 (API)         calls methods on the secure channel
> >> object,
> >>                   |           they are routed down through the generic
> >>                   |           'SSL API' to the underlying library that
> >>                   |           implements the SSL API.
> >>                   V
> >>                SSL.dll        The SSL.dll may create its own instance of
> >> the
> >>                               base unsecure Channel
> 
=== message truncated ===



		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 


Mime
View raw message