There's no doubt that the first version of the JAX-RPC API has been focused on the RPC convention. It's an artifact of Sun's previously distorted view that SOAP (JAX-RPC) is for RPC-style (i.e., simple, trivial work) and ebXML (JAXM) is for messaging (real business interactions). But I think Sun has come around, and the next version of JAX-RPC (due out in the fall) will be much more focus on doc/literal, and it should include support for asynchronous invocations and message-oriented processing.
The original design goal behind JAX-RPC was to attempt to make SOAP as easy to use as RMI, and I think that's a laudable goal. The problem is that the current version of the JAX-RPC API is too focused on this goal -- hence it doesn't do a good job of supporting messaging. At the moment, the Java standard API for XML messaging is JAXM, but JAXM doesn't support WSDL, so I view it as a dead end. (And it's not part of J2EE 1.4.)Axis doesn't support JAXM. Instead it defined a proprietary messaging API that supports WSDL. >From my point of view, WSDL is the most powerful and essential technology in Web services. It is the core technology that allows applications to negotiate their message formats. SOAP isn't quite as critical as WSDL, but I still think that it brings a lot of value to the picture. The key value-add for SOAP over straight XML over HTTP is the processing model. I agree that the processing model doesn't give you a huge amount of benefit if 1. You don't use the built-in serialization engine 2. You don't use headers 3. You don't use interceptors 4. You don't use intermediaries 5. You don't need the reliability, availability, and scalability features of an app server container model But if you don't use these features, then you're probably doing very simple, point-to-point message passing, and SOAP might be overkill for your application. But as you start trying to do more interesting things with Web services (security, reliability, orchestration, transactions, etc.) the SOAP processing model (or something equivalent) becomes critical. Since the entire industry seems to be backing SOAP, I suggest that you use it (rather than something equivalent). And a decent SOAP engine shouldn't impose a huge amount of overhead if you're using it only for application dispatching, so it's reasonable to use it now, even if it is overkill for your current application. After all, I haven't seen too many WSDL systems that don't use SOAP. Anne ----- Original Message ----- From: "Dennis Sosnoski" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, August 02, 2003 7:40 PM Subject: Re: WSDL2Java... Is all that REALLY necessary? > You can certainly have web services without RMI - RMI is just the model > used by JAX-RPC. Considering that JAX-RPC is oriented toward rpc/encoded > and the Web services trend is toward doc/literal, it's not clear to me > how useful JAX-RPC really is at this point. Perhaps some of the > developers can comment on this issue. > > As I see it, the initial RPC orientation of SOAP was what got the hype > going since it - in theory - allowed transparent calls to interfaces > implemented in any language. In practice it ran into the same > limitations as any other form of RPC, where once you get beyond simple > objects everything breaks down and you're left needing custom > encoding/decoding for each language/platform. That's part of why the > trend is now toward using doc/literal, where the Schema definition gives > the structure of the XML payload and it's up to each implementation to > handle that payload as desired. There's not a lot of value added by SOAP > at that point, though (as opposed to WSDL, which is still very > valuable). Most current applications don't appear to make use of SOAP > headers, so until features like encryption and signing become common the > SOAP part of messages could just as easily be a canned header and > trailer for the XML payload. > > Axis is designed for JAX-RPC compatibility, but most other SOAP > frameworks are not. You may have an easier time with one of those (such > as GLUE or WASP). You can also just go directly to handling XML in a > servlet or client. This is probably the best solution for > high-performance Web services in any case. If you want to convert the > XML payload of a SOAP message to and from objects, you can use a data > binding framework. I'm planning to do a demo of this using my own JiBX > framework sometime soon. > > - Dennis > > Wendy Smoak wrote: > > >I'm looking at the stuff generated by WSDL2Java and wondering... Can't you > >have web services without RMI? I just want to receive a SOAP Message, and > >have the body of it passed to a method. The part where the XML gets turned > >into a Java object (wrapped) is nice, but not necessary. > > > >Perhaps Axis isn't overkill for me. Just as I did not go with EJB's, but > >instead stuck with Servlets & JSP and a simpler persistance layer, is there > >a simpler way to receive and process SOAP messages? Axis (Apache SOAP) is > >certainly what popped up on search after search, so here I am, but maybe I > >should go elsewhere. > > > > > > >
