axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Blecken" <cblec...@macrovision.com>
Subject RE: Fw: Proposed new AxisClient/AxisTransport/TransportFactory/Channel implementation.
Date Thu, 23 Dec 2004 03:06:30 GMT
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 ****
> 
>

Mime
View raw message