SOS

Usually when I think of JAX-WS application development I like to think in terms of the classic contract-first development model: generate your stubs from the WSDL file using wsdl2java, then implement your endpoint in Java. The endpoint can then be deployed from a standalone server mainline, or any of the containers supported by Celtix such as ServiceMix (JBI) or Spring. I was happily surprised recently when an inventive customer recently suggested an interesting alternative. They proposed the following (non-obvious) development scenario: why not design your application as a route and deploy in the Celtix router?

The idea is beautiful in its simplicity: write your application logic as a set of Plain Old Java Objects (POJOs), and then use the Celtix Router (based on the Mule container) to string them all together. At the start of the route, deploy a Celtix listener, based on a formal WSDL contract: the router can listen for requests, unmarshall incoming data to Java objects (using JAX-B), and then forward these objects to your business logic. The router will let you chain a whole set of POJOs, allowing you to design your application as a pipeline of modular and reusable POJO-based business components. And, at the end of the chain, you can let Celtix consume the POJO results and marshal them back onto the wire, either as a synchronous response to the original invocation, or onward to another remote service in an asynchronous application.

I worked with the customer to put together a POC, and we're building on this POC towards a production-ready deployment.

Ultimately, this approach allows you to design applications as mini orchestrations, providing the flexibility of an orchestration engine without the penalty of remote message invocations between each component. I like it.