This article outlines some of the different architectural choices and the associated trade offs, alternatives, and best practices that architects and developers should keep in mind when building document-driven web services using JAX-RPC on the J2EE platform.

Interesting paper on "document driven" web-services on the Sun web site. It does a good job at covering the architectural issues in a technically accurate manner without any marketing babble.

Read the article: Patterns and Strategies for Building Document-Based Web Services

this is actually a nice document. However, it is deeply poignant that JAX-RPC is inherently biased towards rpc/enc messaging, and O/X mapping. You arent meant to get hold of the XML payload, and the API makes it very hard to do so.

You can see this when the doc gets into how to use JAXB to represent the incoming message, and requires you to get the DOM from a bit of the message and then have JAXB parse it. Getting the DOM requires (in the only implementation I've seen -Axis- ) to take the serialized objects and recreate the XML as a string, then turn it back into a DOM.

Assuming that doc/lit SOAP messages are a good thing, and that working with these messages at the XML is also a good thing, JAX-RPC (1.x) is the wrong way to work with these messages. Yet this is what we have in Java-land for SOAP work. An API that makes SOAP messages look like RMI calls with a few features missing.

We are using document-centric web services using both JAXB and JAX-RPC (In fact I was a JavaOne speaker on the subject at last years conference). On our project we are using Apache Axis, which is similar to JAX-RPC. W

e treated the RPC layer as simply a transport layer. The API of the web service had simple String arguments/return values. The caller simply uses their RPC-binding to pass the XML document as a String (we have also used byte arrays) to the web service and then inside of the web service we use JAXB to process the document and build the return value.

It has worked pretty well for us.
Dave

How does this differ from what is described in the document? Isn't that just pages 3 and 5 combined?

We are considering usuing axis with JAXB and were wondering if you had any additional thoughts on how this might be done if you spoke at java one do you have any presentations?

Has your stance on how this is done using jaxb to parse up axis web service string input parameters changed?

Thanks in advance,
R
S

Getting the DOM requires (in the only implementation I've seen -Axis- ) to take the serialized objects and recreate the XML as a string, then turn it back into a DOM.

not exactly true. you can use message-style services to get the DOM directly (or soapenvelope, or an array of Elements).

Getting the DOM requires (in the only implementation I've seen -Axis- ) to take the serialized objects and recreate the XML as a string, then turn it back into a DOM.

not exactly true. you can use message-style services to get the DOM directly (or soapenvelope, or an array of Elements).

But if you look under the covers, Axis is actually serializing the request to a String, then feeding that String into a DOM parser and giving you the resulting Nodes.

if thats the case, and perf is a problem, then is it better to register a custom deserializer in Axis where you can use jaxb/xmlbeans/what-have-you to deal with deserialization?

I have been trying to do just that with an Axis to XOM binding. I may not progress with that and go to XMLBeans instead. Part of the process involved javadocing org.apache.axis.MessageElement, explaining what the methods do -highlighting which are the inefficient bits- and marking with @deprecated which interface methods are not yet implemented.

One problem with going from MessageElement instances to third party DOM/XSD representations is that the third party representations usually bind to a sax reader or an input stream; not to take an existing graph and parse it. So I will need to (somehow) glue the sax chains together.

The other options is to have a stack that is entirely built of XMLBeans. I am thinking of that.

The best way to build your web service is good old XML over HTTP. Define your XML schema and share it with those who would use the service. I have found the easiest way to implement the service is to use JAXB to generate classes from the schema and unmarshal directly from the servlet input stream. As long as you do not create a new Unmarshaller each time, it is lightening fast.

It just doesn't get any simpler than that. The analogy between SOAP and EJB is obvious. Both technologies are typically misapplied to problems that do not benefit from the added complexity.

Anyway, if you want to build a fast web service without interoperability nightmares, XML/HTTP is the best way.

-geoff

Oh, cool. Here's a great plan: Just define your message formats with XML Schema, and wrap them with a simple envelope. While you're at it, why not separate functional and non-functional information, put one in a header part and the other one in a body? That should be cool. Then just send it over HTTP.

Wait a moment - I suddenly have a déjà vu feeling ...

Seriously, though, SOAP is a protocol, or rather a protocol framework. Using SOAP doesn't mean you have to use JAX-RPC, or .NET, or an application server. Not using a complicated framework or server is often a good idea. Re-inventing the wheel is not.

Stefan Tilkov
http://www.innoq.com/blog/st/

Fine, use SOAP as a wire format. As such it does address the issues you raise. Just don't reinvent CORBA. The HTTP verb set is more than adequate for most WEB - as in adhering to the architectural principles of the Web - service interactions.

Just don't reinvent CORBA.

Too late. Now we should talk about abandoning all those reinvented ( but square) wheels in favor of earlier round design (CORBA).

Yes, abandon the "new" square wheels. No, don't do CORBA on the WEB.

Let the WEB be the WEB, go REST young man!

The best way to build your web service is good old XML over HTTP. Define your XML schema and share it with those who would use the service. I have found the easiest way to implement the service is to use JAXB to generate classes from the schema and unmarshal directly from the servlet input stream. As long as you do not create a new Unmarshaller each time, it is lightening fast.It just doesn't get any simpler than that. The analogy between SOAP and EJB is obvious. Both technologies are typically misapplied to problems that do not benefit from the added complexity.Anyway, if you want to build a fast web service without interoperability nightmares, XML/HTTP is the best way.-geoff

Even simpler, bail on the whole silly SOAP thing and just use XStream and not JAXB. from my own informal tests with JAXB, it is still limited by the xml parser you use. XStream on the other hand uses XPP3, which is one of the fastest, if not the fastest xml parser out there today.

Even simpler, bail on the whole silly SOAP thing and just use XStream and not JAXB. from my own informal tests with JAXB, it is still limited by the xml parser you use. XStream on the other hand uses XPP3, which is one of the fastest, if not the fastest xml parser out there today.

Are you sure that XStream (even with fastest parser possible) is faster than JAXB? I doubt it. XStream heavily uses reflection during _every_ marshalling/unmarshalling. JAXB precompilation architecture works for its performance.

Even simpler, bail on the whole silly SOAP thing and just use XStream and not JAXB. from my own informal tests with JAXB, it is still limited by the xml parser you use. XStream on the other hand uses XPP3, which is one of the fastest, if not the fastest xml parser out there today.

Are you sure that XStream (even with fastest parser possible) is faster than JAXB? I doubt it. XStream heavily uses reflection during _every_ marshalling/unmarshalling. JAXB precompilation architecture works for its performance.

Dennis sosnoski has several articles comparing JAXB to xerces, xalan, XPP3, Jibx and a few others. Google for his article and read for yourself. The efficiency of the parser plays a bigger roll than the performance of reflection, which actually is quite fast these days. Don't take my word, read the article for yourself and run some benchmarks.

Are you sure that XStream (even with fastest parser possible) is faster than JAXB? I doubt it. XStream heavily uses reflection during _every_ marshalling/unmarshalling. JAXB precompilation architecture works for its performance.

Dennis sosnoski has several articles comparing JAXB to xerces, xalan, XPP3, Jibx and a few others. Google for his article and read for yourself. The efficiency of the parser plays a bigger roll than the performance of reflection, which actually is quite fast these days. Don't take my word, read the article for yourself and run some benchmarks.

Yes, i know these benchmarks. The results are that the only databinding tool faster then jaxb is jibx. and it uses bytecode enhancement instead of reflection, similarly to the jaxb's code generation. so what's you point? and how does it affect my statement about xstream performance?

Yes, i know these benchmarks. The results are that the only databinding tool faster then jaxb is jibx. and it uses bytecode enhancement instead of reflection, similarly to the jaxb's code generation. so what's you point? and how does it affect my statement about xstream performance?

like I said, in my own informal benchmarks, using XStream with xpp3 is faster than stock jaxb with crimson or xerces/xalan. But to be fair, it's not jaxb's fault. When I did my test, the other big difference I saw is using XStream + xpp3 rarely went above 30% cpu usage. In contrast, jaxb with crimson always spiked up to 70% or higher. As you stated, jibx uses bytecode enhancements, but beats jaxb because jibx supported xpp3 from the beginning. my earlier post probably was a bit unclear, but I still believe the underlying xml parser plays a much greater role in overall performance than whether reflection is used or not.

Just because Xstream uses reflection, doesn't mean it is automatically going to be slower. If you have data showing jaxb+xpp3 is faster than xstream, than that's great news. I haven't done an exhaustive benchmark myself, so I won't claim xstream blows away jaxb. Here's some old benchmarks I ran http://woolfel.blogspot.com/2004/05/xstream-is-wonderful-this-week-there.html. Needs to say, take the results with a big grain of salt.

Even simpler, bail on the whole silly SOAP thing and just use XStream and not JAXB. from my own informal tests with JAXB, it is still limited by the xml parser you use. XStream on the other hand uses XPP3, which is one of the fastest, if not the fastest xml parser out there today.

Are you sure that XStream (even with fastest parser possible) is faster than JAXB? I doubt it. XStream heavily uses reflection during _every_ marshalling/unmarshalling. JAXB precompilation architecture works for its performance.

it looks like the latest version shipped with JWSDP can use XPP as the parser. they've also added a bunch of features in the latest, so the differences may be of little to no consequence.

...

re: attachments, is there a problem with just using MIME?

**

What I think is interesting is how web services are build primarily using source code. Why not build document and message based web services with a "page" style paradigm as web pages are built? I have integrated my web development platform with Apache Axis to do just that. I built a sample DSMLv2 (Directory Services Markup Language) example applicaiton as a POC.

http://idrs.sourceforge.net/maven/idrs-axis.html