Axis hierarchy

[Berin Loritsch <bl...@apache.org>]

I am wrapping my head around Axis to try to figure out
how to best provide hooks for Avalon/Cocoon.  To my best
surmizings, I would provide the following:

CocoonHandler  (to intercept requests that Cocoon would
                process)

ServiceHandler (to intercept requests that Avalon Phoenix
                would process)

CocoonProvider (to process the requests in the Cocoon
                environment)

ServiceProvider (to process the requests in the Avalon
                 Phoenix environment)

If I am way of track here, let me know.

What I am going to do is to throw together a quick structural
UML diagram to get an idea for the Axis architecture.  I would
be more than happy to donate it to the Axis team.  After that
is done, I would like to make sure that each component of Axis
has a work interface--as opposed to simply an Abstract Class.

This is the first step in Avalon integration--but even better,
it provides a well understood framework for new people who want
to help upgrade.

Next, I want to remove your dependence on DOM.  I have found
it to be very resource intensive in high transaction sites.  You
may be surprised at how easy it is to do away with DOM, that
you may not even miss it.  It would remove the necessity of
many of the methods in the Admin class.  Basically the approach
is to remove the DOM and use Avalon's Configurable class.  It
is light weight and type safe.  It has a hierarchical structure
so it can represent XML configurations quite well.  For components
that do not require hierarchical configurations, Avalon has a
Parameters class (much like the Java properties but with type
safe accessors).

Also, the WSDL generation can be done with SAX.  It requires
a different mind-set to use SAX, but it is pretty smooth once
you get use to it.  I have been working with Cocoon 2 for a
while now, and am very familiar with it.