You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by ge...@ws.apache.org on 2004/12/02 10:01:36 UTC
[Apache Web Services Wiki] Updated: FrontPage/Architecture/OMRequirements
Date: 2004-12-02T01:01:36
Editor: SrinathPerera <he...@opensource.lk>
Wiki: Apache Web Services Wiki
Page: FrontPage/Architecture/OMRequirements
URL: http://wiki.apache.org/ws/FrontPage/Architecture/OMRequirements
no comment
Change Log:
------------------------------------------------------------------------------
@@ -102,104 +102,3 @@
----------------------------------------------------------------------------------------------------------
-= 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 [http://wiki.apache.org/ws/FrontPage/Architecture/OM/TypedXMLStream 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 deserialing ===
- * 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 panalty?
-
- [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 dont 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 prefered, should be jDom like API -- Ajith]
- * Both read and write must be done
- - should there be read-only mode? (Lets accomodate this in to OM. When handler accesses OM, deault 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 [http://nagoya.apache.org/jira/browse/AXIS-1498 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 [http://nagoya.apache.org/jira/browse/AXIS-1497 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)
-