Differences between revisions 1 and 2
Revision 1 as of 2004-12-02 09:34:08
Size: 2075
Revision 2 as of 2009-09-20 22:48:13
Size: 2079
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
http://ws.apache.org/~hemapani/images/axiom.png {{http://ws.apache.org/~hemapani/images/axiom.png}}

Axis summmits concensus 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

  • Minuits 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 accsess the the message, there are two cases
    • accsess the Headers
    • accsess 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 accsess via the pull parser. If the handler read the body it is his responsiblity 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 accsessed 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 accsess to the pull events
    • provide a easy to accessible infoset
    • Differed parsing as much as possible
    • cached the already readed information insome form so that thy can be re produce in need.

FrontPage/Architecture/OMHistory (last edited 2009-09-20 22:48:13 by localhost)