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
[EMAIL PROTECTED]
(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
