Architectural improvements

[Glyn Normington <gl...@uk.ibm.com>]

Given the perturbation to Axis proposed  by James's async. plan, it is an
appropriate time to gauge whether or not proposals (e.g. [1], [2]) for
architectural improvements are likely to be accepted. Either one would
require significant involvement from multiple committers, so I must admit
to being pessimistic given that the prevailing tone of the project
continues to be code-centric.

But let's have the discussion now so we can either plan to improve the
modularity of Axis or accept that this isn't going to happen in the
foreseeable future. Currently, I feel that this thread needs tying up -
especially as I'm hoping to move jobs in the next few weeks and will then
have (even) less time to give to Axis.

Thoughts?

Glyn
[1]
http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/proposals/arch/docs/architecture-guide.html
[2]
http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/proposals/arch/docs/modular-build.html

Re: Architectural improvements

[James M Snell <ja...@us.ibm.com>]

Glyn,

Responding to your points in [1]


   1. Configuration
      I agree that there are some big problems with the current mechanism. 
 Not only does the engine mutability cause problems, the design pattern is 
a bit unnatural.  My recommendation would be for us to create an 
AxisEngineFactory and takes an EngineConfiguration parameter.  The factory 
would return an immutable, configured engine.

    AxisClient client = 
AxisEngineFactory.createEngine(configFactory.getClientEngineConfig());
    AxisServer server = 
AxisEngineFactory.createEngine(configFactory.getServerEngineConfig());

  2. Pivots
     My Internal Message Exchange proposal will completely remove the idea 
of a "Pivot".  Rather, Transport and Providers will each implement the 
MessageExchange interface.

  3. Fault Handling 
     I agree that this really isn't useful.  Unfortunately, this type of 
behavior has been included in JAX-RPC handlers.  Not sure what we can do 
here.

  4. MessageContext
     I see a number of changes that can be done with Axis' message model.
        a) MessageContext needs to be serializable
        b) The Message object current relies directly on the SOAP 
implementation.. that needs to be reversed.  We need the SOAP stuff to 
rely on the abstract message classes, not the other way around.  I am 
currently considering a proposal for this that I won't introduce until 
after the async stuff is done.  If you'd like to chat about it, please 
give me a call.
        c) The programming model for getting the message in specific 
formats should be improved, the current model is a bit wierd to work with

[1] 
http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/proposals/arch/docs/architecture-guide.html

- James Snell
     IBM Emerging Technologies
     jasnell@us.ibm.com
     (559) 587-1233 (office)
     (700) 544-9035 (t/l)
     Programming Web Services With SOAP
         O'Reilly & Associates, ISBN 0596000952

     Have I not commanded you? Be strong and courageous. 
     Do not be terrified, do not be discouraged, for the Lord your 
     God will be with you whereever you go.    - Joshua 1:9

Glyn Normington/UK/IBM@IBMGB wrote on 10/24/2002 01:28:10 AM:

> Given the perturbation to Axis proposed  by James's async. plan, it is 
an
> appropriate time to gauge whether or not proposals (e.g. [1], [2]) for
> architectural improvements are likely to be accepted. Either one would
> require significant involvement from multiple committers, so I must 
admit
> to being pessimistic given that the prevailing tone of the project
> continues to be code-centric.

> But let's have the discussion now so we can either plan to improve the
> modularity of Axis or accept that this isn't going to happen in the
> foreseeable future. Currently, I feel that this thread needs tying up -
> especially as I'm hoping to move jobs in the next few weeks and will 
then
> have (even) less time to give to Axis.

> Thoughts?

> Glyn
> [1]
> http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-
> axis/proposals/arch/docs/architecture-guide.html
> [2]
> http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-
> axis/proposals/arch/docs/modular-build.html