Thoughts on JiBX

I've written before with Ted Neward on code-first vs WSDL-first contract design for services. We had a lot of fun on the Server Side with that - thanks Ted (and the men in black).

Since then, I've mellowed a lot; I'm quite happy to use JAX-B and JAX-WS annotations where appropriate to generate my WSDL and XSD SOA artifacts. Maybe Ted's mantra of "Code first, contract aware" has rubbed off on me.

Recently thought I've noticed another approach, JiBX, that offers a middle ground. Instead of embedding annotations inside your Java classes (code-first), or writing your own schema (contract first), you put XML binding information into a separate "binding" file. You then run a tool against the Java classes and binding file and out drops the schema.

I look forward to playing with JiBX, but I can't help but feel cautious. One of the compelling reasons to use a code first approach is the idea that it's somewhat simpler than writing XSD or WSDL by hand. JiBX just doesn't look "easy" to me; it seems that if you want to you use JiBX then you need to know about your Java interfaces, your desired schema/XML, and, how to use JIB-X binding files. So, we end up having to learn new stuff (JiBX) to do things we can do already (XML Schema).

I think what I'm lacking is the presence of a "JiBX in Anger" article (remember Ant in Anger?) that shows how JiBX solves the Java/XML problem way better than the approaches I know already. From my own recent experience with the CXF java2wsdl tool (see the previous entry on this blog), I know that JiBX would give me explicit control over how XSD artifacts get generated from pre-JDK 1.5 annotation-free classes. Very nice - but worth the overhead of learning JiBX?