axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Preston <PREST...@uk.ibm.com>
Subject RE: Fw: Proposed new AxisClient/AxisTransport/TransportFactory/Channel implementation.
Date Tue, 04 Jan 2005 17:20:40 GMT




Hi Damitha,
      I'm having trouble with SecureChannel.hpp because it still tries to
include 'Channel.h'.  When I replace with 'Channel.hpp' there are problems
overriding the operators (this is all in Windows)... Can I make a
suggestion about trying to change axis2 and do as Samisa (I think) said
before Christmas.  That is to create an axis3 from the ground up.  Start
with the existing Transport API (i.e Axis2Transport and
AxisTransportException), the ChannelFactory class and IChannel class and
then build an implementation from what was described in the code/sequence
models in my previous e-mail.  This way we can keep the code separate and
develop 'off line' (I know there will be places where we need to change
other code (such as call.cpp), but if we can get the new model working in
Linux and Windows first before introducing it into the main code stream
this will have the least effect on other developers and gives us a sandbox
for testing, sharing ideas, etc).  What do you think?

Regards,

Fred Preston.



                                                                                         
                                             
                      "Damitha                                                           
                                             
                      Kumarage"                To:       Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
                     
                      <damitha@opensour        cc:                                    
                                                
                      ce.lk>                   Subject:  RE: Fw: Proposed new AxisClient/AxisTransport/TransportFactory/Channel
       
                                                implementation.                          
                                             
                      27/12/04 08:20                                                     
                                             
                      Please respond to                                                  
                                             
                      "Apache AXIS C                                                     
                                             
                      Developers List"                                                   
                                             
                                                                                         
                                             




Hi all,


I thought about this a lot taking everything we discussed into
consideration
and I have come up with a working solution which has minimal impact with
the existing code and agree with our discussion.
I have attached all the code here with


I try to explain this as clear as possible


The code is similar what we had last in cvs(But it is cleared of all the
flaws
ealier one had)


* I agree that there is no point of statically binidng the transport
   and we shall keep it as it is
* We have IChannel class which has methods to implement for a new channel.
  This is class has same method set what we ealier had in Channel.h


* We have ISecureChannel which inherit from IChannel and have extra methods
   needed
   for a secure channel



* ssl default implementation inherit from ISecureChannel. The header file
   derived
   from this is called OpenSSLChannel.hpp


* default channel implementation inherit from IChannel. The header file
derived from IChannel
   is called Channel.hpp. We can dynamically load the normal channel as
well.
But for the time
   being we have it statically bound as before


* In Call class we get the library path and set the value to transport


   char* pcLibraryPath = g_pConfig->getAxisConfProperty(AXCONF_SSLCHANNEL);
   m_pTransport->setTransportProperty(DLL_NAME, pcLibraryPath);
   m_pTransport->setEndpointUri(m_pcEndPointUri);


* in the setTransportProperty method of Axis2Transport

    case DLL_NAME:
    {
        m_strSecureLibPath = value;
        break;
    }


* ChannelFactory class is the channel loader. Currently I use it just to
   load
   secure channel. I pass the channel path in it's initializer method. We
   can
   use this class to load any custom channel as well.
   In the setEndpointUri method of Axis2Transport


        // Check if the new URI requires SSL (denoted by the https prefix).
        if ((m_pChannel->getURLObject ()).getProtocol () == URL::https)
        {
            m_bChannelSecure = false;


            // URI requires a secure channel.  Delete the existing channel
            // (as it may not be secure) and create a new secure channel.
            delete m_pChannel;
            m_pFactory->initialize(m_strSecureLibPath.c_str());
            m_pChannel = m_pFactory->getSSLChannelObject();


Fred please try running this and make your comments
to run you need to copy
* Makefile.am_axis2 to axis2 folder and rename to Makefile.am
* Makefile.am_ssl to axis2/ssl folder reanem Makefile.am
* Do the above changes to Call.cpp and Axis2Transport.cpp
* In ipv6/IPV6Channel.h change Channel.h to Channel.hpp


I did not test this with windows, but with the previous experience
I'm sure this should work. I'll let you know as I contact Sanjaya to do
this.

thanks
damitha

On Thu, 2004-12-23 at 16:56, Fred Preston wrote:

>
> Hi All,
>       Thanks for your comments.  Here are my replies...
>
> 1. Correct - We had already extended (before we regressed)
> AXIS_TRANSPORT_INFORMATION_TYPE to include SECURE_PROPERTIES and DLL_NAME
> (this will now need to expand to something like NORMAL_CHANNEL_DLL_NAME
and
> SECURE_CHANNEL_DLL_NAME).
> 2. Also +1
> 3. Good idea.  +1 for calling it Axis3Transport (this maintains backward
> compatibility for those who don't care/aren't ready, etc).
> 4. I don't know how it would do this reliably as it would be expecting
the
> Channel DLL filename to be passed to it.  I could make assumptions about
> the Channel DLL name and location, but this would not guarantee success.
>
> Regards,
>
> Fred Preston.
>
>
>
>

>                       "Carsten Blecken"

>                       <cblecken@macrovi        To:       "Apache AXIS C
Developers List" <axis-c-dev@ws.apache.org>
>                       sion.com>                cc:

>                                                Subject:  RE: Fw: Proposed
new AxisClient/AxisTransport/TransportFactory/Channel
>                       23/12/04 03:06            implementation.

>                       Please respond to

>                       "Apache AXIS C

>                       Developers List"

>

>
>
>
> Hi Fred,
>
> I'm also relieved :)
>
> One quick comments:
> On Samisa's 4th point I have to agree, the transport should load
> the channel.
>
> Carsten
>

>
>
>
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa.abeysinghe@gmail.com]
> Sent: Wednesday, December 22, 2004 5:43 PM
> To: Apache AXIS C Developers List
> Subject: Re: Fw: Proposed new
> AxisClient/AxisTransport/TransportFactory/Channel implementation.
>
>
> Hi Fred,
>          I feel much relieved with the new design. This is a very good
> approach.
>
>      Couple of thoughts:
>
>      1. Re: channel configuration will be done using the
> setTransportProperty/setChannelProperty
>      As of now, setTransportProperty is used to deal with transport
> protocol stuff. As an example setting HTTP headers. I am not sure how
> this could be used to configure channel. Are you thinking of extending
> the current implementation in this case, or do we have to rename this
> current method to reflect that it is serving the purpose of setting
> transport protocol properties?
>
>      2. Re: make Channel and SecureChannel the same
>      +1. For IPV6 too, I think this would be a good model
>
>      3. Are we leaving axis2 as it is and implement this new model as
> axis3 transport (a new lib with whatever name)?
>      As we are not going to replace transport abstraction I think it
> would be good that we implement this as a separate new transport.
>
>     4. I wish that we make the dynamic loading of the Channel
> transparent, internal to the transport implementation, so that older
> model would still work with the engine, ensuering backward
> compatibility.
>
> Thanks,
> Samisa...
>
>
> On Wed, 22 Dec 2004 11:36:50 +0000, Fred Preston <PRESTONF@uk.ibm.com>
> wrote:
> >
> >
> > Hi All,
> >       Thanks for all your comments, below is a concatenation of my
> > replies...
> >
> > * The ChannelFactory is only used to load/unload the DLLs.  I have
> changed
> > the sequence diagram to show that when given the DLL filename for a
> > secure/unsecure channel, it will load that DLL and then play no further
> > part. (The DLL will be unloaded when ChannelFactory is deleted).
> > * Backwards compatibility is broken by the fact that the user has to
add
> an
> > additional line to the axiscpp.config file.  But then it may also be
> broken
> > in this respect when we implement IPV6?
> > * All channel configuration will be done using the
> > setTransportProperty/setChannelProperty methods.
> > * Statically binding the transport layer to AxisClient does not seem to
> > produce any benefits.  My view would be to leave it as is.  This will
> > preserve the concept of being able to load other transports.
> > * Damitha - Yes we have the same view, I just want to get the design on
> > paper for review and agreement.  There are some minor changes to the
> > existing implementation to try and define the function of openChannel
> which
> > is currently unused!
> > * There was a big mistake in the sequence diagram in the huge over
> > involvement of ChannelFactory.  Basically, once it has loaded the DLL,
it
> > plays no further part.
> > * I want to make Channel and SecureChannel the same  That is to say,
then
> > are created to a common model.  If we load SecureChannel dynamically,
why
> > not Channel as well? (it may be useful for IPV6 work?)
> > * The DLL is not loaded/unloaded unless the AxisTtransport is unloaded
or
> a
> > new transport is selected through the setTransportProperty method call.
> > This will be rare!
> > * The factory can only get the channel names directly if it is
statically
> > linked to the AxisClient, otherwise it has to get the information
> > indirectly through a method call (setTransportProperty).
> >
> > Here is my updated sequence diagram (See attached file:
> > Sequence_Draft2.jpg)
> >
> > Once agreed, I want to implement this solution ASAP just to try and get
> it
> > done and out of the way!
> >
> > Best regards,
> >
> > Fred Preston.
>
> > ----- Forwarded by Fred Preston/UK/IBM on 22/12/04 11:01 -----
> >
> >                       Fred Preston
> >                                                To:      "Apache AXIS C
> Developers List" <axis-c-dev@ws.apache.org>
> >                       20/12/2004 16:00         cc:
> >                                                From:    Fred
> Preston/UK/IBM@IBMGB
> >                                                Subject: Proposed new
> AxisClient/AxisTransport/TransportFactory/Channel implementation.
> >
> > Hi All,
> >       Here is a very rough draft of the
> > AxisTransport/TransportFactory/Channel model that I want to discuss...
> >
> > Object Model
> > Sequence Model
> >
> > I have missed out a lot of the detail (and 'secondary' methods), as
this
> is
> > not important at this stage.  In this design, AxisTransport and
> > ChannelFactory would be part of AxisClient (i.e, not separately
> loadable).
> > The IChannel Interface would be the template for any Channel
> implementation
> > (in the form of a DLL).  There would be one Channel implementation for
a
> > 'standard', non secure channel that would be built as a separate DLL
> whose
> > file name would be added to the AxisCpp.config file so that it could be
> > loaded by the ChannelFactory.  There would be one SecureChannel
> > implementation for an openSSL secure channel that would also be built
as
> > another separate DLL, whose file name would also be added to the
> > AxisCpp.config file.  Thus if a user requires their own version of
either
> > the Channel or SecureChannel implementation, they need only overwrite
the
> > existing code and build their own Channel or SecureChannel DLL without
> > having to rebuild the core AxisClient code base.
> >
> > Regards,
> >
> > Fred Preston.
> >
> > **** Attachment SSLModel.jpg has been removed from this note on 22
> December
> > 2004 by Fred Preston ****
> > **** Attachment Sequence.jpg has been removed from this note on 22
> December
> > 2004 by Fred Preston ****
> >
> >
>
>
>

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

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

















#### Axis2Transport.cpp has been removed from this note on January 04 2005
by Fred Preston
#### Axis2Transport.h has been removed from this note on January 04 2005 by
Fred Preston
#### Call.cpp has been removed from this note on January 04 2005 by Fred
Preston
#### Channel.cpp has been removed from this note on January 04 2005 by Fred
Preston
#### Channel.hpp has been removed from this note on January 04 2005 by Fred
Preston
#### ChannelFactory.cpp has been removed from this note on January 04 2005
by Fred Preston
#### ChannelFactory.hpp has been removed from this note on January 04 2005
by Fred Preston
#### IChannel.hpp has been removed from this note on January 04 2005 by
Fred Preston
#### ISecureChannel.hpp has been removed from this note on January 04 2005
by Fred Preston
#### Makefile.am_axis2 has been removed from this note on January 04 2005
by Fred Preston
#### Makefile.am_ssl has been removed from this note on January 04 2005 by
Fred Preston
#### OpenSSLChannel.cpp has been removed from this note on January 04 2005
by Fred Preston
#### OpenSSLChannel.hpp has been removed from this note on January 04 2005
by Fred Preston
#### SSLChannelLoader.cpp has been removed from this note on January 04
2005 by Fred Preston


Mime
View raw message