RE: JAC-RPC 2.0 (was: Axis2: RPC -> Message advantages)

[Dino Chiesa <di...@microsoft.com>]

And now for something Totally Off Topic. . . 

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


So what happens to 
 - Castor
 - XMLBeans
 - all the other Java-to-XML mapping frameworks
?

I had assumed that with the donation of XMLBeans to Apache, there would
be a consolidation or convergence, at least within Apache, on a common
Java-to-XML binding framework.  That XMLBeans would replace the
serialization schtuff within AXIS.  I assumed wrong, I guess? 

The problem with JAXB is it is so darn ... Heavy.  I think there are 24
classes or something, generated at build time, for each class you want
to be able to de/serialize.  With AXIS it is pretty simple and implicit.


-D


-----Original Message-----
From: Anne Thomas Manes [mailto:atmanes@gmail.com] 
Sent: Friday, March 04, 2005 9:18 AM
To: axis-user@ws.apache.org
Subject: Re: Axis2: RPC -> Message advantages

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: JAC-RPC 2.0 (was: Axis2: RPC -> Message advantages)

[Dennis Sosnoski <dm...@sosnoski.com>]

Dino Chiesa wrote:

>And now for something Totally Off Topic. . . 
>
>  
>
>>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. 
>  
>
Re Anne's comment above: The "highly optimized processor" idea for 
automatic serialization doesn't appear to have worked out well so far, 
as can be seen in the performance results of frameworks using this type 
of approach.

>
>So what happens to 
> - Castor
> - XMLBeans
> - all the other Java-to-XML mapping frameworks
>?
>
>I had assumed that with the donation of XMLBeans to Apache, there would
>be a consolidation or convergence, at least within Apache, on a common
>Java-to-XML binding framework.  That XMLBeans would replace the
>serialization schtuff within AXIS.  I assumed wrong, I guess? 
>  
>
I think it's likely that alternative XML data binding frameworks for 
Java will continue to flourish, though we may start to see some 
convergence. For example, I'd like to add support for working with JAXB 
2.0 source code annotations to JiBX 2.0. Part of the problem here is 
that there are a number of different use cases (Need to work with XML as 
XML, and only secondarily as data-bound objects? Use XML Beans. Need 
data binding and don't care about XML fluff such as comments? Then use 
Castor or JAXB if you're starting from a schema, or JiBX if you're 
starting from Java code. Need performance? Then use JiBX :-D ).

>The problem with JAXB is it is so darn ... Heavy.  I think there are 24
>classes or something, generated at build time, for each class you want
>to be able to de/serialize.  With AXIS it is pretty simple and implicit.
>  
>
Many of the issues with JAXB 1.0 will be corrected in 2.0, probably 
including the number of generated classes.

  - Dennis