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

[Ajith Ranabahu <aj...@gmail.com>]

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

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

[Eran Chinthaka <ch...@opensource.lk>]

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 ok. 

Personally, (:-)) 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" <aj...@gmail.com>

> To: "Axis developer list" <ax...@ws.apache.org>

> 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

> >

 

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

[Sanjiva Weerawarana <sa...@opensource.lk>]

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). 

- 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.

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" <aj...@gmail.com>
To: "Axis developer list" <ax...@ws.apache.org>
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
>