Differences between revisions 1 and 2
Revision 1 as of 2004-09-13 04:34:20
Size: 1343
Editor: 106
Revision 2 as of 2009-09-20 22:49:07
Size: 1349
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
 [http://ws.apache.org/~jaliya/Axis2/Diagram1.png http://ws.apache.org/~jaliya/Axis2/Diagram1.png]  [[http://ws.apache.org/~jaliya/Axis2/Diagram1.png|{{http://ws.apache.org/~jaliya/Axis2/Diagram1.png}}]]

Proposed OM Architecture

The following will explain what is in AXIOM and what is out of the AXIOM.

  • http://ws.apache.org/~jaliya/Axis2/Diagram1.png

  • OM is the XML info set representation for Axis 2.
    • Handlers and whoever third parties that needs access to XML info set of the SOAP message, they will have to access it through the OM. OM can be read or changed by those parties, but OM has a facility to make it read only. OM is read only by default.
  • De-serialization and serialization will be handled by other components, which work on top of OM.
    • Within OM itself, it doesn’t have facilities to serialize and de-serialize. Serializers and de-serializers are external components that accesses OM through DOM- or Pull APIs or through wrappers.
  • OM can be represented using any object structure, as far as it exposes DOM- and StAX+ API.
    • If someone needs to access OM through some other XML info set API, one should write his own wrapper on top of 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.

4. When someone accesses the OM , before the provider, the default is cache on. Unlike when the provider accesses OM, which is when cache is off.

FrontPage/Architecture/OMProposedArchi (last edited 2009-09-20 22:49:07 by localhost)