axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manohar K Chintala <cmano...@in.ibm.com>
Subject Re: Fw: Proposed new AxisClient/AxisTransport/TransportFactory/Channel implementation.
Date Thu, 06 Jan 2005 09:46:54 GMT




+1 for renaming Axis2Transport  class to HTTPTransport


Manohar Kumar.Ch
IBM C/C++ Web Services Client
India Software Labs,III floor, Golden Enclave,
Airport Road, Bangalore-560017
Ph:- 91-80-25094304
internet id: cmanohar@in.ibm.com


                                                                           
             Andrew Perry2                                                 
             <PERRYAN@uk.ibm.c                                             
             om>                                                        To 
                                       "Apache AXIS C Developers List"     
             01/06/2005 02:55          <axis-c-dev@ws.apache.org>          
             PM                                                         cc 
                                       Apache AXIS C Developers List       
                                       <axis-c-dev@ws.apache.org>          
             Please respond to                                     Subject 
              "Apache AXIS C           Re: Fw: Proposed new                
             Developers List"          AxisClient/AxisTransport/TransportF 
                                       actory/Channel implementation.      
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           








+1 for rename to HTTPTransport

Andrew Perry
IBM C/C++ Web Services Client
perryan@uk.ibm.com
Mail Point 127
IBM UK Laboratories. Hursley Park, Winchester, Hants. SO21 2JN
Tel. Internal 249828  External + 44 (0)1962 819828
Fax. + 44(0)1962 818080



             Samisa Abeysinghe
             <samisa.abeysingh
             e@gmail.com>                                               To
                                       Apache AXIS C Developers List
             06/01/2005 01:53          <axis-c-dev@ws.apache.org>
                                                                        cc

             Please respond to                                     Subject
              "Apache AXIS C           Re: Fw: Proposed new
             Developers List"          AxisClient/AxisTransport/TransportF
                                       actory/Channel implementation.










Hi Fred,
     OK then, I have done most of the fixes that were pending on axis2
transport.
     It could be copied now to axis3 and the res done on axis3.

    BTW, shall we change the name to http instead of axis3 (because it
is an implementation of HTTP transport)? I also would like to rename
the Axis2Transport class to HTTPTransport - because that makes more
sense.

Thanks,
Samisa...


On Wed, 5 Jan 2005 09:53:50 +0000, Fred Preston <PRESTONF@uk.ibm.com>
wrote:
>
>
> Hi Samisa,
>       The intention is that axis3 will supersede axis2 once it is
working.
> When this happens axis2 can be deleted and we will all use axis3...
>
> Regards,
>
> Fred Preston.
>
>                       Samisa Abeysinghe
>                       <samisa.abeysinghe        To:       Apache AXIS C
Developers List <axis-c-dev@ws.apache.org>
>                       @gmail.com>               cc:
>                                                 Subject:  Re: Fw:
Proposed new AxisClient/AxisTransport/TransportFactory/Channel
>                       05/01/05 03:15             implementation.
>                       Please respond to
>                       "Apache AXIS C
>                       Developers List"
>
> +1 for seperate transport (axis3)
> Also, there are confinues fixes done on Axis2Transport class in axis2.
> I guess, in case of axis3, bulk of the work would be on Channel
> related stuff. It would be good if we could have an automated sync up
> between Axis2Transport class in axis2 with the counterpart in axis3.
>
> Thanks,
> Samisa...
>
> On Tue, 4 Jan 2005 17:20:40 +0000, Fred Preston <PRESTONF@uk.ibm.com>
> wrote:
> >
> >
> > 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