Return-Path: Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org Received: (qmail 37863 invoked from network); 21 Dec 2004 07:56:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 21 Dec 2004 07:56:32 -0000 Received: (qmail 72398 invoked by uid 500); 21 Dec 2004 07:56:31 -0000 Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org Received: (qmail 72382 invoked by uid 500); 21 Dec 2004 07:56:31 -0000 Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: List-Id: "Apache AXIS C Developers List" Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list axis-c-dev@ws.apache.org Received: (qmail 72361 invoked by uid 99); 21 Dec 2004 07:56:30 -0000 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=DNS_FROM_RFC_POST X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from fw.macrovision.com (HELO min.macrovision.com) (192.156.198.62) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 20 Dec 2004 23:56:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed new AxisClient/AxisTransport/TransportFactory/Channel implementation. Date: Mon, 20 Dec 2004 23:57:04 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed new AxisClient/AxisTransport/TransportFactory/Channel implementation. Thread-Index: AcTmruOULunBZH2bTw6byvoLN2pzHAAf4nXQ From: "Carsten Blecken" To: "Apache AXIS C Developers List" X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N If I read this correctly then this design intends to replace the current SOAPTransport extension point with the IChannel extension point. With an extension point I mean that it allows a third party to write an external plug in. The current SOAPTransport/AxisTransport=20 interface should be an internal interface according to this design. There are two concerns I have with that: 1) The channel (as far as my understanding goes) is only a connection establishment and bit transmitting facility and does not have a=20 concept of message and the metadata associated with a message. Typically having the transport interface being the extension point (i.e the loadable module) brings more flexibility, let me mention =20 the option of using message queues, SMTP, file system for message transport in addition to using HTTP.=20 If we make the IChannel the extension point we have the standard channel and secure channel and then this is pretty much it. =20 2) Backward compatibility with 1.2, 1.3 and 1.4 is broken. For example we have developed our own transport library, which is dynamically loaded. In the new scheme I'm not sure how we could keep that. I'm also not quite sure how you want to communicate the configuration parameters for the secure channel (location of key store, default cert and private key). Is this external configuration? Carsten -----Original Message----- From: Fred Preston [mailto:PRESTONF@uk.ibm.com] Sent: Monday, December 20, 2004 8:00 AM To: Apache AXIS C Developers List 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 (See attached file: SSLModel.jpg) Sequence Model (See attached file: Sequence.jpg) 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. = =20 Fred = =20 Preston/UK/IBM@IB To: "'Apache AXIS C = Developers List'" =20 MGB cc: = =20 Subject: 1.4 release = still does not work with SSL channels. =20 20/12/04 13:09 = =20 Please respond to = =20 "Apache AXIS C = =20 Developers List" = =20 = =20 Hi All, I've just tried to use SSL in the 1.4 release and it still does = not work on Linux or Windows... I'm in the process of coming up with a = model that will try to explain how I think the whole Channel/Transport area should be organised and will be looking for comment. I hope to send out = a rough draft this afternoon. Regards, Fred Preston.