Axis Requirements

Introduction

This is a summary of the Reqirements for Axis 2.0. Since OM is a major part of the the new Axis, it has a dedicated section

General Axis Requirements

* Enable Service isolation

• How far do we want to go?
• Use classloader techniques?

• Some point in the handler chain, save the state, store it away and
  • restore it later
• Runtime configurability of handler chain
• Ability to start/stop/continue handlers in the middle of a chain
• Performance
  • Speed (Glue/WASP)

  • Foot print (axis.jar<1MB)

  • Scalable: Linear threading
• Better composable deployment
• Complete schema (XSD) support
• MTOM compatible Infoset
• Allow binary serialization
• S D Layer independent of WSDL versions
• On the fly validations
• More functional admin API
  • Dependencies
  • Version control
  • Change management
  • Upload WAR (?)
• Hot deploy and upload
• Policy / meta-data (eg. Tx/RM etc)
• Aspect services (WS-RF, WS-M)
• JDK : require J2SE 1.4 and support buildability on J2SE 5 (c.f. Tomcat 5.5 also follows this policy)

OM

As mentioned before this section discusses OM in detail

Use Cases

Since usecases are again a vast section it is moved to a separate page See OM Use Cases Discussed in FrontPage/Architecture/OMUseCases

Axis summmits consensus on OM:

• Performance of Axis Engine has to be improved.
• As a solution the team has agreed on improving the XML info-set representation through XML pull parsing.
• However the use of pull based XML info-set would yield to a problem due to the fact that pull parsing forgets the events and information already read.
• This would happen when the Handlers read part of the message and when somebody else needs to access the same contents using a pull interface. To overcome this issue the team has come up with this idea,

    "Introduce a XML info-set representation which uses streaming but records the events, occurred so far". 

The thing that does the above was called AXIOM (OM)

How the Discussion at the Summit goes

Minuts of the Summit discussion about OM

1. We need to design a pull based Axis engine that do streaming (the start)
2. Handlers want to access the the message, there are two cases
   • access the Headers
   • access the body
3. There are two problems
   • Pull forget what read before
   • Handlers like to have easier infoset like (DOM like) interface.
4. Proposal 1 - Save Headers as DOM elements, the body is accessed via the pull parser. If the handler read the body it is his responsibility to set it back. (TEAM feel this is not enough .. we need to help the users more.)
5. Proposal 2 - Store the Headers in DOM element, if the body is accessed only, the complete body is converted to DOM. Later the pull event will generating travasaling the DOM. (if body not created the pull events read from the stream.) (TEAM feel the fact the complete body parsed when only the part of it may be need is not good)
6. Proposal 3 - OM, OM is a representation of the SOAP Message.
   • provide access to the pull events
   • provide a easy to accessible infoset
   • Differed parsing as much as possible
   • cached the already read information in some form so that thy can be re produce in need.

Goals of OM

• OM is a Streaming XML infoset representation of the SOAP Message. It gives the polymorphic behaviour of ability to act as a pull event generator and DOM like tree model at same time.

• === It should support the following use cases ===

  • 

  === It should support following requirements ===
  1. Deferred the parsing as much as possible/ Streaming
  2. Performance - Low memory usage, speed
  3. Href support
  4. MTOM support

Open issues

1. Does OM have Deserializers and Serializers inbuilt?
2. Does OM implement w3c DOM interfaces or wrapped to support them
3. What is PULL interface, is it StAX+, Typed pull parser interface.
4. what is the OM XML infoset, DOM, JDOM like, our own

Issue outside the direct scope of OM, but relevant

• How the encoding work? (It should handle by the encoding module), the module work on top of OM Pluggable data binding
  • since OM expose the Pull interface
    • xml pull based binding tools can used that interface

    • SAX based binding tools can use PULL->SAX simply

    • DOM based binding tools used w3c DOM support

MTOM/Attachments requirements

• MTOM impact: be able to support MTOM (keep data as base64, data handlers and other stuff).
• Should DIME, SwA be supported?
• General model for attachment streaming from file, database, ...

XML-Java binding requirements

• Provide data binding hooks to allow one to ask for XML chunks in mapped types.

• - For complex types a deserialization environment must be provided. That will be an interface via which a deser environ can be plugged in.

See also comments in described in Jira issue [WWW]AXIS2: pluggable XML transformations (JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)

Pluggability requirements

• Allow storing of deserialized content provided by JAXB, Castor, XmlBeans, ... [Xml-Java]

• Support SAAJ natively (as part of OM impl) - [do we need this ? - Ajith]
• Support DOM2
• Support DOM3
• Simplify task of deserialization done by rest of AXIS2
  • - possibly provide place to store intermediate form of deserialized objects if deserialization is pipelined

Performance requirements

• Good memory footprint: avoid creating of OM copies, ... [this should be taken care of by the wrappers as well]
• Good performance: support streaming in/out of OM content, ...

See also Jira issue [WWW]AXIS2: performance improvements

Other requirements

• Make sure XMLSecurity works over that DOM for encryption, decryption, signing and verification. This is at the XML level.
• Has to have sufficient stuff to allow graph deserialization (for SOAP-Enc support)

OLD doc

if new one cover everything we can remove this

AXIOM Requirements

Open questions

• what is exactly role of DeserializationContext?

• how getObejctValue works?
• put your question here / ideas ..

wording

XML infoset interface (put a better name) - this is something like DOM, or JDOM that represent all the information in the XML file

Streaming Parsing - this is StAx+ - .. some pull parser interface, the "Typed pull parser interface" may do TypedXMLStream

Streaming Tree Walking - this is incremental XML Tree (like Python PullDom or XPP2 XmlPullNode) that has nodes is created on demand and deallocated when not needed

Things to decide

• === Does OM support serializing and deserializing ===
  • Option1 - OM support deserialize and serializing internally
  • Option2 - OM support DOM like XML infoset interface and Streaming interface, encoding is top of them
    • Does this involving a performance penalty? [As far as OM is concerned it is another model for an XML infoset and purely a representation of the underlying XML document.
    • The difference is that it is lightweight and uses a pull model underneath to get to the elements AS AND WHEN required. OM exposes onl two API's ,the DOM like API and the raw stream API (like StAX). Ideally OM should hide its stream underneath but it is exposed for performance Reasons. (To allow handlers access the raw stream) So with this perspective I don't think it is "clean" to have serilaizers and deserializers merged with OM. They should be external components that access OM through the provided API's. if a different representation of OM is needed (like DOM3) it is provided through a wrapper that does not necessarily duplicate OM objects but provide access to OM objects through a DOM interface.]
  === what is minimal core (OM model?) and what are required extensions ===
  • 2.1 DOM support
    • Option1 - OM implements DOM interfaces
    • Option2 - OM is wrapperd for implement DOM interfaces (this should be s.t.it minimize creating new objects) what happens to deserialized stream - how AXIS engine can request OM representation of XML Infoset to be "replaced" by deserialized content?
    2.2 MTOM - yes how 2.3 SAAJ ?? are we ever
  === support to interact with existing Xml-Java binding libraries ===
  • [pluggable Xml-Java requirement] -- This is REALLY important requirement - building (dese/se)rializing in will make this complex
  === low memory footprint and good performance - ibid. about AXIS1 === design API so it can be implemented as streamable (on-demand loading and creating of XML trees) - avoid use of size() in favor of Iterator etc.

What OM Does?

• accept a Input Stream
• create a XML infoset that had differed the parsing to as much as possible
• provide a accsess to users through XML infoset interface (unless at the provider the information/pull event read will be stored in the some way)
• provide accsess to the data via a streaming interface (iterator) (if data is not read the events read from the stream or else reply stored streaming events)
• Support for serialize and Deserialize ???

What OM Does not do?

• Support for serialize and Deserialize ???

General requirements ("boil ocean" ...)

• OM is lightweight XML Infoset model, currently aiming at subset of DOM [lightweight]
  • - should we consider more Java specific or more XML Infoset friendly API? [java specific one is preferred, should be jDom like API -- Ajith]
• Both read and write must be done
  • - should there be read-only mode? (Lets accommodate this in to OM. When handler accesses OM, default is read only. if accessed by a provider, default is not read only.)
• Provide full access to XML Infoset representing SOAP message
• Provide access for rest of AXIS2 modules through internal OM API
• Provide access for rest of AXIS2 modules other XML APIs such as:
  • - SAX2, - DOM2/3, - StAX event stream

    - XmlPull event stream - whatnot (pluggable)

  • [OM has DOM- API and Xmlpull event stream API. But if someone needs some other API, he needs to wrap the OM. This wrapper should not create another object model in the memory, but it should convert the required API methods in to the APIs exposed in OM.]

MTOM/Attachments requirements

• MTOM impact: be able to support MTOM (keep data as base64, data handlers and other stuff).
• Should DIME, SwA be supported?
• General model for attachment streaming from file, database, ...

XML-Java binding requirements

• Provide data binding hooks to allow one to ask for XML chunks in mapped types.
  • - For complex types a deserialization environment must be provided. That will be an interface via which a deser environ can be plugged in.

See also comments in described in Jira issue AXIS2: pluggable XML transformations (JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)

Pluggability requirements

• Allow storing of deserialized content provided by JAXB, Castor, XmlBeans, ... [Xml-Java]

• Support SAAJ natively (as part of OM impl) - [do we need this ? - Ajith]
• Support DOM2
• Support DOM3
• Simplify task of deserialization done by rest of AXIS2
  • - possibly provide place to store intermediate form of deserialized objects if deserialization is pipelined

Performance requirements

• Good memory footprint: avoid creating of OM copies, ... [this should be taken care of by the wrappers as well]
• Good performance: support streaming in/out of OM content, ...

See also Jira issue AXIS2: performance improvements

Other requirements

• Make sure XMLSecurity works over that DOM for encryption, decryption, signing and verification. This is at the XML level.
• Has to have sufficient stuff to allow graph deserialization (for SOAP-Enc support)