Wow, someone questioning papa Sun? And here I thought I was the only one. :)
Actually, from what the Axis2 crew has informed me the JAX-RPC 2.0 implementation piece will actually be layered atop a completely independent Axis2 core. Check out section 1.1: http://wiki.apache.org/ws/FrontPage/Axis2 Indeed, JAX-RPC 2.0 is tied to JAXB 2.0. From JAX-RPC 2.0 Early Draft R2 section 1.2: "Pluggable data binding JAX-RPC 2.0 will defer data binding to JAXB[10]; it is not a goal to provide a plug-in API to allow other types of data binding technologies to be used in place of JAXB. However, JAX-RPC 2.0 will maintain the capability to selectively disable data binding to provide an XML based fragment suitable for use as input to alternative data binding technologies." So you will most likely be able to do whatever you want at the JAX-RPC 2.0 layer, and surely you will still be able to do whatever you want down at the Axis2 core layer. My team has been using Axis 1.x "Message Style" for awhile now to go hands on the DOM (tossing all performance advantages of using SAX to StAX based approaches out the door - but hell, we're also doing message level crypto) with Castor (because we don't like defining Castor type mappings in our server-config.wsdd). It's nasty, and we know it. We're looking forward to change. We're even playing with JibxSoap because Dennis Sosnoski seems to have speedy data binding down to a science (https://bindmark.dev.java.net/current-results.html). Axis2's Sanjiva Weerawarana has formed his own opinions about JAX-RPC 2.0 (http://marc.theaimsgroup.com/?l=axis-dev&m=110832841316164&w=2), and plans to write them up at some point. Regards, Jonathan Anderson Booz Allen Hamilton -----Original Message----- From: Dino Chiesa [mailto:[EMAIL PROTECTED] Sent: Friday, March 04, 2005 10:29 AM To: [email protected]; Anne Thomas Manes Subject: RE: JAC-RPC 2.0 (was: Axis2: RPC -> Message advantages) 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:[EMAIL PROTECTED] Sent: Friday, March 04, 2005 9:18 AM To: [email protected] 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 <[EMAIL PROTECTED]> 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 >
smime.p7s
Description: S/MIME cryptographic signature
