jaxb for jboss

[matt_furness]

Hi,

Is there a good jaxb implementation that integrates with jboss/axis.

Thanks in advance
-Matt.

[jonlee]

Normally, you would not mix JAXB with SOAP/Axis. I'm trying to think of a situation where you would combine the two. JAXB, and please correct me if I am wrong, materialises and dematerialises physical XML documents. SOAP/Axis transports data as a SOAP compliant message.

Normally data is already in a Java compliant format having been assembled from data sources such as a database. Axis can convert beans into a SOAP compliant format and vice-versa. Or give you the Java DOM expression of the data. XML in a SOAP transmission is purely a format to ship the data between client and Web Service.

The other drawback with JAXB in a J2EE container environment is that EJBs should not directly access files (should not use java.io). EJBs should access external resources via the container's resource managers. I haven't seen any JMX-enabled JAXB implementations that would give you that capability in JBoss though you could write one.

In a straight servlet container, you could interface JAXB to transform the XML document to either a DOM or a set of beans, that Axis then transforms back into a SOAP-wrapped XML document. But the transformations to and from the native form seem rather processor expensive.

I think Sun currently has the only JAXB implementation if you really want to do this. Sorry if this wasn't much help but I was just trying to work through why you would integrate these technologies.

[matt_furness]

Hi,

Sorry i should have been more clear. The reason that i discussed it in terms of axis is that sun packages jaxb with there web services development pack.

your answer did clear up the question i was asking however, especially in terms of the resource manager availability.

thanks for your help,
-Matt.

[jonlee]

Glad that helped - though to be honest, I was just fishing around since the intent was not clear.

Thinking some more, even if you did have a document, because you would deploy this through Axis as an XML element collection, you would just parse the document through Xerces to create a collection of elements - look at the Axis example for a message based Web Service to get an idea of what Axis requires.

Also, you would probably store documents in a database for indexing and retrieval through an EJB architecture.

[colinbendell]

I disagree - JAXB is more than ever relevant for SOAP / JBOSS.NET / AXIS. JAXB allows you to marshal and unmarshal a java object into a coherent xml feed. JAXB is a natural serializer/deserialzer for axis. Axis has a bean serializer - but it is far from complete and is horribly broken.

This is how we use (will be using) jaxb : we return a data object representing the bean to the session layer - the bean is then serialized into xml to and from the soap layer and then returned to the bean layer.

If you are using jaxb within an entity been or a j2ee process you should be using the classloader to load the resources.

/colin

[jonlee]

It's true that JAXB can be used for RPC style Web services bean serialization. That consumption method will be relevant for some services - those that are producers and consumers of (currently) Java data. But SOAP/XML is pretty inefficient (verbosity and conversion overhead) compared to available native methods - so there are going to have to be pretty compelling business reasons to deploy such services.

Also, if you bypass the Axis RPC style services to directly intercept the SOAP messages (Message style service), they come in as a processed DOM (a set of document elements) once Axis has stripped the envelope - assuming that you are happy to use a message style Service. You need to translate this to a form JAXB can use - since JAXB provides an alternative representation to the DOM view that gives it the often cited adaptability advantage over DOM - if you are to use the standard Axis Web service interfaces. This is largely my query over JAXB and its integration with Axis. The Axis API introduces constraints that might not make it fit too well with JAXB. For direct insertion into the SOAP message content if the API allows raw XML insertion, this would make sense.

RPC messages are but one deployment style for Web services. There remain three other styles: Documents, Wrapped and Messages. Document and Wrapped may be circumvented by generating your WSDL bindings. I haven't seen enough complex bindings to determine if the mapping patterns are sustainable.

The Messages style is probably going to be a widely used Web Service style - it does give you direct access to the elements (DOM type elements) which will give you capability to process and act on information you are receiving. It will allow for indication of status, internal checksums and other pertinent information, and status based processing, particularly if you are validating long business transactions - intelligent data consumption, if you like. Here, translating from DOM to a JAXB representation doesn't seem to give you too much of an advantage.

Finally, I do understand the engineering requirement to have a workable communication system now rather than later. And if JAXB gives you the serialization processing you require now then that is the design decision you need to make.

[maarten.verbeek]

All,

I'm new to J2EE and JBoss and do not understand what Collin means by using the classloader to load the JAXB classes.
Can anyone explain to me how to do that?

Maarten