Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The "Axis2/Requirements" page has been changed by newacct. http://wiki.apache.org/ws/Axis2/Requirements?action=diff&rev1=3&rev2=4 -------------------------------------------------- As mentioned before this section discusses OM in detail == Use Cases == - Since usecases are again a vast section it is moved to a seperate page + Since usecases are again a vast section it is moved to a separate page See OM Use Cases Discussed in [[FrontPage/Architecture/OMUseCases]] - == Axis summmits concensus on OM: == + == Axis summmits consensus on OM: == {{http://ws.apache.org/~hemapani/images/axiom.png}} @@ -60, +60 @@ Minuts 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 + 1. Handlers want to access the the message, there are two cases - * accsess the Headers + * access the Headers - * accsess the body + * access 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 1 - Save Headers as DOM elements, the body is accessed via the pull parser. If the handler read the body it is his responsibility 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.) + 1. Proposal 2 - Store the Headers in DOM element, if the body is accessed 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) 1. Proposal 3 - OM, OM is a representation of the SOAP Message. - * provide accsess to the pull events + * provide access 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. + * cached the already read information in some 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 is a Streaming XML infoset representation of the SOAP Message. It gives the polymorphic behaviour of ability to act as a pull event generator and DOM like tree model at same time. === It should support the following use cases === {{http://ws.apache.org/~hemapani/images/OMusecases.png}} === It should support following requirements === - 1. Deffered the parsing as much as possible/ Streaming + 1. Deferred the parsing as much as possible/ Streaming 1. Performance - Low memory usage, speed 1. Href support 1. MTOM support @@ -93, +93 @@ 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 == + == Issue outside the direct scope of OM, but relevant == 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 @@ -156, +156 @@ 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 === + === Does OM support serializing and deserializing === * 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? + Does this involving a performance penalty? [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. + (To allow handlers access the raw stream) So with this perspective I don't 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.] @@ -196, +196 @@ === 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] + - should we consider more Java specific or more XML Infoset friendly API? [java specific one is preferred, 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.) + - should there be read-only mode? (Lets accommodate this in to OM. When handler accesses OM, default 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: @@ -238, +238 @@ * 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) - -
