axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Axis hierarchy
Date Wed, 12 Sep 2001 19:51:36 GMT
Doug Davis wrote:
> 
> Don't disagree, but I would hold off on removing DOM everywhere.
> For Message based services passing in a DOM instead of a SAX
> stream is something that many people would prefer.  Not
> everyone will want to deal with the complexity (or perceived complexity)
> of SAX and would prefer to use DOM instead.  We've had this discussion
> may times and think it deserves to be completely thought out and voted on
> before it happens - this will impact A LOT of people and I know many people
> will have very strong opinions on it.
> -Dug

Let me reclarify:

DOM _dependancy_.  It shouldn't be required--but as Sam said, if they
want to slow themselves down--they should.

> 
> Berin Loritsch <bloritsch@apache.org> on 09/12/2001 11:35:39 AM
> 
> Please respond to axis-dev@xml.apache.org
> 
> To:   axis-dev@xml.apache.org
> cc:
> Subject:  Re: Axis hierarchy
> 
> Doug Davis wrote:
> >
> > Do you mean remove DOM in just the Admin stuff or everywhere?
> > -Dug
> 
> Everywhere.  The Admin stuff is just the first/easiest place
> to do it.  The crux of SOAP is the message on the wire.  The
> method to get it on the wire is orthagonal to the content.
> 
> You can provide a much more scalable, robust, and speedier
> web service platform if you use incremental processing with
> SAX.  That is the lesson the Cocoon folks learned.  The difference
> is really apparent when you have large messages on the order
> of 100k or more.  If the XML message is 100k, the DOM tree
> is going to be a heck of a lot larger.
> 
> The benefit of SAX processing is that while the server is
> chewing on the large message, it can still handle the smaller
> messages without any seeming affect (until we saturate the
> server).
> 
> >
> > Berin Loritsch <bloritsch@apache.org> on 09/12/2001 11:21:29 AM
> >
> > Please respond to axis-dev@xml.apache.org
> >
> > To:   Axis Development <axis-dev@xml.apache.org>
> > cc:
> > Subject:  Axis hierarchy
> >
> > 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.

Mime
View raw message