axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <>
Subject Re: [Axis2] AXIOM goals
Date Sun, 14 Nov 2004 15:26:31 GMT
"Aleksander Slominski" <> writes:
> i am very interested to hear if this list needs modifications and what
> if the order of items reflect their priority

Excellent list!

> here is my understanding/interpretation:
> * AXIOM API has no dependencies on other modules in AXIS2


> * AXIOM API have dependencies on DOM, SAX, StAX, XmlPull

No- it depends *only* on StAX .. or actually eventually the
"typed" StAX API that's in SVN, which builds on StAX.

> * AXIOM API allows to construct OM representing XML Infoset from input


> * AXIOM API allows to write OM as XML Infoset to output


> * AXIOM API can have multiple implementations with different performance
> characteristics and optimizations


> * AXIOM API provides subset of XML Infoset that is deemed needed for SOAP


> * AXIOM API allows manipulation of XML infoset (adding elements,
> removing etc)

+1, again only that is deemed needed for SOAP.

> * AXIOM API allows to access SOAP:Body directly as event stream and
> avoid building of XML tree for it


> * AXIOM API allows to supports DOM L2 (L3?) as an addon for cases when
> security is used [for example WSS4J implementation XML Security requires
> DOM as it uses libs requiring DOM]; when not DOM is not required then
> AXIOM can be used without DOM APIs to achieve better performance and
> lower memory footprint [configurable feature requested when OM is created]

No. DOM support is a layer on top of AXIOM, not built into AXIOM.

Building the DOM impl is not a requirement to complete AXIOM. However,
we will have to build it when plugging in the WSS4J code for sure and
at that time it may be decided that it makes sense to keep that impl
near/in AXIOM makes sense. Right now I'm -1 to saying the DOM impl is
part of AXIOM because its not needed for Axis2 to complete.

> * AXIOM API supports MTOM with a consistent XML Infoset view (MTOM
> content looks like BASE64), allows direct optimized access to binary
> data, and allows to store references to binary data that is serialized
> according to MTOM/XOP rules (BASE64 if no attachments)


> * AXIOM API is designed to support pluggable XML transformations
> (JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
> discussed in

I can't read AXIS-1498 right now (offline ATM) but data binding is NOT
part of AXIOM. In fact data binding is layered into the engine so that
all of Axis2 can run without any data binding and with the app accessing
the OM directly (maybe via something like JXPath layered on).

The point is that providers which have Java object-ified views of
the incoming XML blob is not the only way to implement a service. For
example, the service may be one or more XSLT scripts.

> * AXIOM API makes possible to store Java objects convertible to XML
> Infoset on demand [for serialization]

+1 .. but that's just a different builder for AXIOM - starts with a
Java object instead of a stream. We'll need a builder from DOM too
in the future.

> * AXIOM API allows other APIs to be built on  top of it including SAAJ


> * AXIOM API is easy to use and follow common XML APIs patterns (like
> JDOM, XOM) but has also if SOAP specific features if needed

What's XOM? +1 for JDOM-like convenience.

> * AXIOM API makes possible to create implementations with good or very
> good performance and used general XML benchmarks (like Sosnoski) and WS
> specific benchmarks developed based on use cases to estimate performance
> and guard against regressions


> * AXIOM API is designed to minimize memory footprint, allows streaming
> and avoids creating wrapper objects if not needed

API enables different implementations - some which optimize memory,
some which optimize for speed. Sometimes these two objectives cannot
be met at the same time obviously.

> * [optional] AXIOM impl that has MTOM binary data streamed in/out of
> external storage to avoid OutOfMemory exceptions for very large content

Sure, +1.

> * [optional] AXIOM impl that uses XBIS <>
> for optimized transport of XML Infoset, especially useful for low memory
> footprint and better performance between two WS nodes that uses XBIS

+1 but not only XBIS- there are several candidates available for
alternate serializations and I'm very interested in enabling these.
Hence my rabid focus on using tStAX for all input and output.

> * [optional] AXIOM impl that uses XBIS (or similar) to store XML events
> for replay from memory (or file? db?),

Not optional .. have to be able to serialize the entire message from
day one. Sandesha cannot work fully without this capability.


View raw message