Axis2: RPC -> Message advantages

[Eugene Prokopiev <pr...@stc.donpac.ru>]

Hi,

In http://ws.apache.org/axis2/ I read:

> Another driving force for Axis2 is to move away from RPC oriented Web services towards more document-oriented, message style asynchronous service interactions. 

Where is adavatages of this approach in case of using HTTP as transport 
layer? Is this approach moving back to POST/GET methods and servlet model?

Re: Axis2: RPC -> Message advantages

[Anne Thomas Manes <at...@gmail.com>]

Eugene,

> Why SOAP implementations do this? I can use another tools for
> transformation between XML and Java objects or database (Castor or
> Hibernate for example - it's better choise because them specialized for
> this task). So SOAP can be only transport for XML created by other
> specific tools.

SOAP engines do this in order to provide developers with an RPC-style
programming experience. Also, the JAX-RPC 1.1 specification requires
them to do so. The next release of JAX-RPC (2.0) delegates XML mapping
to JAXB. Axis 2.0 will support JAX-RPC 2.0, and it will make it much
easier for you to use an external serialization service, but it will
also continue to support automatic serialization using a highly
optimized processor.

One advantage of letting the SOAP engine do the serialization is that
it consumes fewer resources -- the engine can process the message
using SAX or a pull parser. If you want to use an external
serialization engine, then the engine converts the message into a DOM
and passes the DOM to the external serialization engine. There are
serious resource consumption issues with this approach. (JAX-RPC 2.0
will mitigate some of these resource issues, though.)

SOAP does much more than just XML serialization and transport, though.
The real value of SOAP is in the pipeline processing model. The
separation of SOAP header from SOAP body allows for the clean
separation of system-level processing from application-level
processing. SOAP messages may be sent directly from the sender node to
the receiver node, or they may be routed through any number of
intermediaries, which may perform a variety of system-level functions.
Also, within a given SOAP node, the SOAP message processor may invoke
any number of interceptors (handlers) to perform additional
system-level functionality. All of this system level functionality may
be specified using declarative policy statements.

Full support for this advanced SOAP processing model is another goal
of the Axis 2 project.

> One moment, please. Can I automaticaly give same functionality to my
> SOAP clients in rpc style and message style? Can you give me some
> examples of this?

RPC vs message style refers to the programming style. It corresponds
to the differences between RMI and JMS. In Axis terms, it refer to the
provider you use (RPC vs MESSAGE). This programming style is
orthogonal to the message encoding style (rpc/encoded vs
document/literal). In other words, you can use the RPC programming
style to generate both rpc/encoded and document/literal messages.
Likewise, you can use the messaging programming style to generate both
rpc/encoded and document/literal messages (although I don't recommend
using the messaging programming style with rpc/encoded). When using
the RPC programming style, you let Axis do the XML serialization. When
using the messaging programming style, Axis gives you a DOM, and it's
up to you to process it.

> I know that SOAP is not best choise instead of RMI, CORBA and EJB, but I
>   not need full distributed objects support and biggest part of my
> clients (for example Mozilla-based) knows only about HTTP, XML-RPC and SOAP.

I disagree with you. I think that SOAP is far superior to RMI, CORBA,
and EJB. My point is that it is different from distributed objects,
and therefore you need to think about the problem differently. SOAP is
fundamentally a messaging system, not a distributed object system. It
requires a different mindset.

Anne

On Fri, 04 Mar 2005 08:54:58 +0300, Eugene Prokopiev
<pr...@stc.donpac.ru> wrote:
> Thanks for great answer!
> 
> > You should not assume that document/literal means you have to do "raw
> > XML processing". Most SOAP implementations support automatic
> > marshaling of SOAP messages and automatic transformation of XML into
> > Java objects when using document/literal.
> 
> Why SOAP implementations do this? I can use another tools for
> transformation between XML and Java objects or database (Castor or
> Hibernate for example - it's better choise because them specialized for
> this task). So SOAP can be only transport for XML created by other
> specific tools.
> 
> > It helps to understand some history. When SOAP 1.1 was first developed
> > (circa 1999/2000), XML Schema was not yet finalized, so the SOAP spec
> > authors had to define their own typing scheme: SOAP encoding. Now that
> > the XML Schema data typing system is fully specified, SOAP
> > encodingreally isn't necessary any more. Meanwhile, the web services
> > community has been moving steadily aware from rpc/encoded style
> > services to document/literal style services because rpc/encoded wasn't
> > sufficiently specified,and therefore it caused many interoperability
> > issues.
> >
> > One of the primary goals of Axis 1.2 has been to implement much better
> > support for document/literal and the XML Schema type system -- which
> > also ensures compliance with the WS-I Basic Profile.
> 
> So, main goal of Axis 1.2 is supporting XML Schema instead of encoding?
> It's fine.
> 
> > If your goal is
> > to enable rpc-style interoperability between heterogeneous systems,
> > then you should be using document/literal with the wrapped programming
> > style. (it simulates rpc).
> 
> One moment, please. Can I automaticaly give same functionality to my
> SOAP clients in rpc style and message style? Can you give me some
> examples of this?
> 
> > Axis 2 is building on the XML Schema work
> > done for Axis 1.2 and will also support more complex interaction
> > styles, which requires support of asynchronous service invocations.
> >
> > But -- you should not assume that SOAP works like a remote object
> > facility (like RMI). SOAP does not support remote references. It does
> > not manage remote objects for you, and that is not its intention. SOAP
> > is fundamentally a message exchange system -- not a distributed object
> > system. If you want heterogeneous distributed objects, then I suggest
> > you use CORBA.
> 
> I know that SOAP is not best choise instead of RMI, CORBA and EJB, but I
>   not need full distributed objects support and biggest part of my
> clients (for example Mozilla-based) knows only about HTTP, XML-RPC and SOAP.
> 
> Thanks
> Eugene
>

Re: Axis2: RPC -> Message advantages

[Eugene Prokopiev <pr...@stc.donpac.ru>]

Thanks for great answer!

> You should not assume that document/literal means you have to do "raw
> XML processing". Most SOAP implementations support automatic
> marshaling of SOAP messages and automatic transformation of XML into
> Java objects when using document/literal.

Why SOAP implementations do this? I can use another tools for 
transformation between XML and Java objects or database (Castor or 
Hibernate for example - it's better choise because them specialized for 
this task). So SOAP can be only transport for XML created by other 
specific tools.

> It helps to understand some history. When SOAP 1.1 was first developed
> (circa 1999/2000), XML Schema was not yet finalized, so the SOAP spec
> authors had to define their own typing scheme: SOAP encoding. Now that
> the XML Schema data typing system is fully specified, SOAP
> encodingreally isn't necessary any more. Meanwhile, the web services
> community has been moving steadily aware from rpc/encoded style
> services to document/literal style services because rpc/encoded wasn't
> sufficiently specified,and therefore it caused many interoperability
> issues.
> 
> One of the primary goals of Axis 1.2 has been to implement much better
> support for document/literal and the XML Schema type system -- which
> also ensures compliance with the WS-I Basic Profile. 

So, main goal of Axis 1.2 is supporting XML Schema instead of encoding? 
It's fine.

> If your goal is
> to enable rpc-style interoperability between heterogeneous systems,
> then you should be using document/literal with the wrapped programming
> style. (it simulates rpc). 

One moment, please. Can I automaticaly give same functionality to my 
SOAP clients in rpc style and message style? Can you give me some 
examples of this?

> Axis 2 is building on the XML Schema work
> done for Axis 1.2 and will also support more complex interaction
> styles, which requires support of asynchronous service invocations.
> 
> But -- you should not assume that SOAP works like a remote object
> facility (like RMI). SOAP does not support remote references. It does
> not manage remote objects for you, and that is not its intention. SOAP
> is fundamentally a message exchange system -- not a distributed object
> system. If you want heterogeneous distributed objects, then I suggest
> you use CORBA.

I know that SOAP is not best choise instead of RMI, CORBA and EJB, but I 
  not need full distributed objects support and biggest part of my 
clients (for example Mozilla-based) knows only about HTTP, XML-RPC and SOAP.

Thanks
Eugene

Re: Axis2: RPC -> Message advantages

[Anne Thomas Manes <at...@gmail.com>]

Eugene,

You should not assume that document/literal means you have to do "raw
XML processing". Most SOAP implementations support automatic
marshaling of SOAP messages and automatic transformation of XML into
Java objects when using document/literal.

It helps to understand some history. When SOAP 1.1 was first developed
(circa 1999/2000), XML Schema was not yet finalized, so the SOAP spec
authors had to define their own typing scheme: SOAP encoding. Now that
the XML Schema data typing system is fully specified, SOAP
encodingreally isn't necessary any more. Meanwhile, the web services
community has been moving steadily aware from rpc/encoded style
services to document/literal style services because rpc/encoded wasn't
sufficiently specified,and therefore it caused many interoperability
issues.

One of the primary goals of Axis 1.2 has been to implement much better
support for document/literal and the XML Schema type system -- which
also ensures compliance with the WS-I Basic Profile. If your goal is
to enable rpc-style interoperability between heterogeneous systems,
then you should be using document/literal with the wrapped programming
style. (it simulates rpc). Axis 2 is building on the XML Schema work
done for Axis 1.2 and will also support more complex interaction
styles, which requires support of asynchronous service invocations.

But -- you should not assume that SOAP works like a remote object
facility (like RMI). SOAP does not support remote references. It does
not manage remote objects for you, and that is not its intention. SOAP
is fundamentally a message exchange system -- not a distributed object
system. If you want heterogeneous distributed objects, then I suggest
you use CORBA.

- Anne

- Anne

On Wed, 02 Mar 2005 09:38:19 +0300, Eugene Prokopiev
<pr...@stc.donpac.ru> wrote:
> > I am not much sure about what you mean; anyway I will try
> 
> Sorry for my english ;)
> I try to know about SOAP and Axis evolution and about reasons of it
> 
> >>>Another driving force for Axis2 is to move away from RPC oriented Web services towards >>more document-oriented, message style asynchronous service interactions.
> >>
> >>Where is adavatages of this approach in case of using HTTP as transport
> >>layer? Is this approach moving back to POST/GET methods and servlet model?
> >
> >
> > not much change in the how the HTTP transport layer is handled (expect
> > to send HTTP one way 202 OK). It is about how the SOAP message is
> > processed.
> 
> As for me, mainly SOAP is object-oriented and procedure-oriented
> transport layer between heterogeneous systems. So, main part of SOAP is
> RPC services as the next generation of XML-RPC
> 
> If I need to exchange raw XML data I can use many other tools to process
> SOAP message because is't XML. Can you give me a some examples of
> adavatages new built-in Axis tools for SOAP procesing instead of XSLT,
> DOM4J and others?
> 
> Thanks
> Eugene Prokopiev
>

Re: Axis2: RPC -> Message advantages

[Eugene Prokopiev <pr...@stc.donpac.ru>]

> I am not much sure about what you mean; anyway I will try

Sorry for my english ;)
I try to know about SOAP and Axis evolution and about reasons of it

>>>Another driving force for Axis2 is to move away from RPC oriented Web services towards >>more document-oriented, message style asynchronous service interactions.
>>
>>Where is adavatages of this approach in case of using HTTP as transport
>>layer? Is this approach moving back to POST/GET methods and servlet model?
> 
> 
> not much change in the how the HTTP transport layer is handled (expect
> to send HTTP one way 202 OK). It is about how the SOAP message is
> processed.

As for me, mainly SOAP is object-oriented and procedure-oriented 
transport layer between heterogeneous systems. So, main part of SOAP is 
RPC services as the next generation of XML-RPC

If I need to exchange raw XML data I can use many other tools to process 
SOAP message because is't XML. Can you give me a some examples of 
adavatages new built-in Axis tools for SOAP procesing instead of XSLT, 
DOM4J and others?

Thanks
Eugene Prokopiev

Re: Axis2: RPC -> Message advantages

[Srinath Perera <he...@gmail.com>]

Hi Eugene; 
I am not much sure about what you mean; anyway I will try

> > Another driving force for Axis2 is to move away from RPC oriented Web services towards >>more document-oriented, message style asynchronous service interactions.
> 
> Where is adavatages of this approach in case of using HTTP as transport
> layer? Is this approach moving back to POST/GET methods and servlet model?

not much change in the how the HTTP transport layer is handled (expect
to send HTTP one way 202 OK). It is about how the SOAP message is
processed.

Thanks
Srinath