ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Apache Web Services Wiki] Updated: FrontPage/Architecture/OMRequirements
Date Thu, 02 Dec 2004 09:31:24 GMT
   Date: 2004-12-02T01:31:24
   Editor: SrinathPerera <>
   Wiki: Apache Web Services Wiki
   Page: FrontPage/Architecture/OMRequirements

   no comment

Change Log:

@@ -1,54 +1,21 @@
 == Use Cases ==
 See also: OM Use Cases Discussed in [wiki:FrontPage/Architecture/OMUseCases]
+See also: OM Use Cases Discussed in [wiki:FrontPage/Architecture/OMHistory]
-== 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)
-	1. Handlers want to accsess the the message, there are two cases
-	 	* accsess the Headers
-		* accsess the body
-	1. There are two problems
-		* Pull forget what read before
-		* Handlers like to have easier infoset like (DOM like) interface.
-	1. 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.)
-	1. 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
-	1. 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.
- = OM according to the December 2004 .. refer to todays chat =
+= OM according to the December 2004 .. refer to todays chat =
 Only thing we are not decided on OM is does it contains the SAAJ like API or is it just XML
- == Building OM ==
+== Building OM ==
 OM can be build by two ways
  1. Using a StaX pull events, there is a builder that accepts a pull parser and do the differed
  2. Using SAX push events, there is a builder that accept a Objects or Push event generator
and build the OM. 
  3. OM can be build just like DOM tree is build inserting child elements 
- == Using OM ==
+== Using OM ==
  1. OM exposed a XML infoset representation that is  easy to use by the java developers.
That interface is based on iterators.
  2. OM expose the Stax event and is capable of shifting to the stream in the middle if the
OM is half build. 

View raw message