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:49:44 GMT
Glen Daniels wrote:
> 
> Hi Berin:
> 
> I'm not exactly sure what you're talking about here - we do all our SOAP
> message parsing with SAX.  The only DOM is in the Admin, in our
> document-oriented services (i.e. MsgProvider), and as a convenience for
> developers (i.e. MessageElement.getAsDOM()).

And in WSDL generation...

I am not talking about removing DOM support, but removing DOM dependancies.

> As it stands right now, we do parse the entire message at one go, rather
> than triggering incremental functionality as we parse.  A design for doing
> the latter was proposed a while ago [1], but we haven't moved forward on it
> yet.

Hmm.  That is a potential point of resource contention.  We'll see what we
can do with moving toward incremental functionality.

> 
> --Glen
> 
> [1] http://marc.theaimsgroup.com/?l=axis-dev&m=99075118028994&w=2
> 
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Wednesday, September 12, 2001 2:36 PM
> > To: axis-dev@xml.apache.org
> > 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