axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Preston <>
Subject Fw: Proposed new AxisClient/AxisTransport/TransportFactory/Channel implementation.
Date Wed, 22 Dec 2004 11:36:50 GMT

Hi All,
      Thanks for all your comments, below is a concatenation of my

* 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:

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" <>
                      20/12/2004 16:00         cc:                                       
                                               From:    Fred Preston/UK/IBM@IBMGB        
                                               Subject: Proposed new AxisClient/AxisTransport/TransportFactory/Channel

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.


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 ****
View raw message