Differences between revisions 6 and 7
Revision 6 as of 2006-08-17 06:44:32
Size: 3070
Editor: JohnSisson
Comment: Fix url
Revision 7 as of 2009-09-20 22:47:33
Size: 3069
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Goals of [wiki:FrontPage/Architecture/OM AXIOM] Goals of [[FrontPage/Architecture/OM|AXIOM]]
Line 23: Line 23:
 * ''[optional]'' AXIOM impl that uses optimized representation of XML Infoset (such as XBIS [http://xbis.sourceforge.net/]) especially useful for low memory footprint and better performance between two WS nodes that boht uses the same optimized XML Infoset (less parsing and XBIS showed it can be much faster!)  * ''[optional]'' AXIOM impl that uses optimized representation of XML Infoset (such as XBIS [[http://xbis.sourceforge.net/]]) especially useful for low memory footprint and better performance between two WS nodes that boht uses the same optimized XML Infoset (less parsing and XBIS showed it can be much faster!)

Goals of AXIOM

Legened: goals in order of importantce, goals in bold things that are required but no consensus yet, goals in italic are optional or under discussion

  • AXIOM API has no dependencies on other modules in AXIS2
  • AXIOM API have dependency on StAX and typed StAX [TODO link?]
  • 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)
  • 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
  • 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
  • AXIOM API allows to store XML Infoset in persistent storage ((or file? db?) and to replay it [required for Sandesha (WS-RM) otherwise it cannot work fully without this capability]
  • AXIOM API allows to access SOAP : Body directly as event stream and avoid building of XML tree for it

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

  • [Very difficult issues: may be not implemented for now] 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)

  • [more discussion needed] AXIOM API is designed to support data bindings and XML transformations and AXIOM API should work well with any data binding framework (XPath, XSLT, JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...) [discussed in http://nagoya.apache.org/jira/browse/AXIS-1498]

  • [more discussion needed] AXIOM API is designed to make possible to build DOM L2 (L3?) impl on top of AXIS API

  • [optional] AXIOM impl that has MTOM binary data streamed in/out of external storage to avoid OutOfMemoryExceptions for very large content

  • [optional] AXIOM impl that uses optimized representation of XML Infoset (such as XBIS http://xbis.sourceforge.net/) especially useful for low memory footprint and better performance between two WS nodes that boht uses the same optimized XML Infoset (less parsing and XBIS showed it can be much faster!)

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

FrontPage/Architecture/OMGoals (last edited 2009-09-20 22:47:33 by localhost)