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:29:22 GMT
   Date: 2004-12-02T01:29:22
   Editor: SrinathPerera <>
   Wiki: Apache Web Services Wiki
   Page: FrontPage/Architecture/OMRequirements

   no comment

Change Log:

@@ -37,68 +37,40 @@
 		* Differed parsing as much as possible
 		* cached the already readed information insome 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 polymophic
behaviour of ability to act as a pull event generater and DOM like tree model at same time.

+ = OM according to the December 2004 .. refer to todays chat =
-	=== It should support the following use cases ===
+Only thing we are not decided on OM is does it contains the SAAJ like API or is it just XML
-	=== It should support following requirements ===
-		1. Deffered the parsing as much as possible/ Streaming
-		1. Performance - Low memory usage, speed
-		1. Href support
-		1. MTOM support
-== Open issues ==
- 1. Does OM have Deserializers and Serializers inbuilt?
- 1. Does OM implement w3c DOM interfaces or wrapped to support them
- 1. What is PULL interface, is it StAX+, Typed pull parser interface. 
- 1. what is the OM XML infoset, DOM, JDOM like, our own 
-== Issue outside the direct scope of OM, but relevent ==
- 	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
-    * 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)
+ == 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 ==
+ 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. 
+ 3. OM support writing itself in to the Output stream. We like OM to fed information to a
Push interface so the PushEvent handler may write them to stream. This leave room for binary
serialization in future. 
+ * OM support DOM by wrapping it ==
+ * OM support the StAX interface
+ * OM support turning on -off caching
+ * Serializing and Deserializing is pull out of OM, we will provide the the utilities to
used by the developers so that they can programming like getObjectValue(), setObjectValue(...)
but that is encoding and out of scope for M1. (see the chat)
+== OM Support following  ==
+ === The MTOM support ===
+The binary information in the OM element can be taken from the OM element. There are few
proposals the Glen's MTOM toy, Alek's includes, Ajith's Binary node. We differ this for the
+=== Href support ===
+But it is differed
+=== XML Security Support ===
+Make sure XMLSecurity works over that DOM for encryption, decryption, signing and verification.
This is at the XML level

View raw message