Just pick up two OXM-implementations at first, one schema-first and one code-first oriented. Castor and JAXB2/XMLbeans are fine canditates. The rest will follow very soon. If the abstraction layer works the integration for other (great) OXM-implementations is trivial.

I’m in the situation that I’m using one XML-model internally and other for exposing web services. It would be great to share same model between the ws and other system. I’m using code-first approach because my POJOs are the first class citizens in this particular system. So XMLBeans or JAXB are out of question.

Spring OXM and WS is very very interesting move…

We’ll definitely look into XStream, and possibly others too!

Thanks for your interest!

What about also using XStream as implementation for your O/X interfaces? It’s simple, quite efficient and most of time sufficient for the applications needs. Anyway, the Spring WS is an excellent move and I’m waiting for it .

Like I wrote to Dan, this particular topic is not very much related to Web services. Rather, it is about Object/XML mapping. Spring already offers an excellent abstraction for Object/Relational mapping, consisting of templates and a unified runtime exception hierarchy. What we’re trying to do here is offer something similar for OXM. For this, we are using existing frameworks only, and not creating our own XML marshalling framework.

I’ll definately check out the JBI suggestions you made.

This particular topic (OXM) does not relate to SOAP much. However: both SOAP stacks offer a XML marshalling engine (Axis’s Serializers and XFire’s Aegis). With the above abstraction, it would be possible to use these marshalling engines in other places, even those not related to Web services at all. And with regard to integration with regard to Web services, I’ll get back on that in a future post. At the very least, I am thinking about integration on the handler front, so that you can intermingle Axis (JAX-RPC) and XFire handlers.

We are focussing on a contract-first development style at first. Preferably, we don’t want to create another JSR 181 implementation, because implementations already exist, for instance in XFire!

Maybe you should start with JSR 181 / JAX-WS – which is where its at – and work backwards rather than focussing on JBI-like APIs working with TrAX Source?

If you want an example of a clean API for working with web services which use TrAX Source, just reuse MessageExchange and NormalizedMessage from JBI.