axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <>
Subject Re: [Axis2][OM and Engine] A small (?) confusion
Date Thu, 11 Nov 2004 09:23:02 GMT
+1 .. so are we in agreement on how to make the OM handle Java (or other
non-XML) things?

Clearly the details of the JavaOMBuilder have to be sorted out (to add stuff
like the SerializationContext etc.) but that should not be too hard as we
should be able to re-use a lot of what's in Axis1 there.

  ----- Original Message ----- 
  From: Eran Chinthaka 
  Sent: Thursday, November 11, 2004 9:36 AM
  Subject: RE: [Axis2][OM and Engine] A small (?) confusion

  First of all I would like to mention one thing. OM was initially come in to the picture
to support "deferred building". But now OM does things in addition to that, which IMO should
be the case. 


  So now for me, OM is how engine see IN or OUT SOAP messages. OM can have its own "deferred
building" capabilities, either from a typed pull stream or from a java object. And OM hides
the complexities of handling them, to the engine. The SOAPEnvelope, SOAPBody, etc., kind of
API further help this idea a lot.


  So if one needs to meddle with IN and OUT messages, he can only look at OM things, independent
of the engine or any other part of Axis 2. 


  > Hmmmm. This is what I had in mind at least:


  > - OM is an API with multiple impls (this is what we have now)


  > - There are impls like the TableImpl and the LinkedListImpl which

  >   basically wrap a typed XML pull stream into the OM

  >     => NOTE: In the typed XML pull case the *entire* SOAPEnvelope

  >        is created by reading from the XML stream


  > - I think that the OM should be able to write itself to a typed

  >   XML serializer. This should be possible at any single element level

  >   or at the full envelope level:

  >     SOAPEnvelope.writeTo (TypedXMLSerializer)

  >     OmElement.writeTo (TypedXMLSerializer)

  >   This allows one to ask the OM to generate the "push" events

  >   directly without having to pull them and push them out.


  >   IMO is critical to write *only* to a TypedXMLSerialzier interface

  >   rather than to a raw stream to continue to enable any XML Infoset

  >   serialization, not just XML 1.0 (or XML 1.1).

  [Chinthaka] This suggests that the serialization to be integrated to OM. If we think that
building OM from the typed XML stream is, de-serialization then the above suggestion seems

  Personally, (J) I feel that serialization integrated to OM will ease some of the complexities,
in OM handling. 


  > - We should do another OM impl which allows one to build the body

  >   from a Java object:

  >     - this will take a Java object as an argument and create the

  >       contents of the <soap:Body> element by serializing the Java

  >       object into XML using some data binding architecture.

  >         OMJavaBodyImpl (javaObject[, maybe additional stuff for

  >                         serialization to work])

  >     - Note that the actual impl is an impl of the standard OM

  >       builder interfaces ... so only the *creator* of that (like

  >       a provider that gets a Java object to send) needs to be

  >       aware that its a "Java OM"

  >     - Cool thing is that after I have this OM I can add headers

  >       etc. as if its just a regular OM (because it is!!) and the

  >       real Java object is still hidden underneath .. just itching

  >       to be XMLized.

  >     - When we write the OM into a TypedXMLSerializer now the Java

  >       gizmo gets XMLized with no perf loss.

  [Chinthaka] What you suggests is to have another node type, like OMJavaBody. If I understand
this correct, this seems quite good. This java object must have a SAX event generator interface,
or a util class, so that OM can use that to build the OM structure from that.


  > The cool thing is that this approach can be used to make a call from

  > one service to another service *inside* the same engine without

  > having to actually generate full XML and back out .. more on this

  > later if we agree with this approach.


  > Sanjiva.


  > ----- Original Message -----

  > From: "Ajith Ranabahu" <>

  > To: "Axis developer list" <>

  > Sent: Wednesday, November 10, 2004 5:14 PM

  > Subject: [Axis2][OM and Engine] A small (?) confusion



  > > Hi,

  > > we seem to have a slight problem with the proposed architecture of OM,

  > > engine and encoding. We have sort of a dillema and I will try to

  > > explain that as far as possible. All you guys out there are welcome to

  > > express their views and show us the way :D

  > >

  > > our problem is

  > >    * What is the scope of OM ? is it just an object model and the

  > > defered parsing or something more?

  > >

  > > Here is the series of thoughts that led to the problem.

  > > The issue is the way of serializing at the output path starting from a

  > > java object. How can the Java object be represented into the OM?

  > > several approaches were visible.

  > > 1. Convert the Java object into a OM structure directly.

  > > 2. Keep the object unconverted as far as possible and convert it only

  > > when needed. So most probably the object will be serialized directly

  > > to the output stream.

  > >

  > > (Note - there was an idea to access the object through a pull wrapper

  > > so that the streaming builder may be reused. However wrapping an

  > > object with a pull wrapper seems to be quite an absurd task so it was

  > > decided that objects will always be "pushed" to build the OM or to be

  > > serialized directly)

  > >

  > > the first approach was dropped since it means that a copy of the

  > > object was made.

  > >

  > > The second approach brough out some problems.

  > > How do you wrap the object with a push wrapper and incorporate that

  > > into OM? This means the serailizer had to pass control over to a push

  > > wrapper which uses the serilizers methods to serialize the objects

  > > (that are not already converted). So suddenly you find a plain java

  > > object inside OM !?!

  > >

  > > One explanation to this situation was that the inclusion of SOAP

  > > abstractions (such as SOAPEnvelope and SOAPHeader) was a fundamental

  > > flaw of the architecture. Such abstractions are required by the engine

  > > and they should be part of the engines message handling module rather

  > > than the OM! (this will probaly not make the functionality different

  > > but will make the logic much cleaner and comprehensive)

  > > However the counter argument was that since the purpose of OM is to

  > > represent SOAP, it would be most natural for it to have an API that

  > > represents the parts of a SOAP message. This has the added advantage

  > > of the ability to directly create SOAP objects out of the parser.

  > > However the OM handling objects internally seems "ugly" !

  > >

  > > So what is the proper way to deal with this? Any ideas?

  > >

  > > --

  > > Ajith Ranabahu

  > >


View raw message