Middleware Matters

Most people who have been around distributed systems development for awhile recommend against code-first services. These are services where someone writes a normal programming language artifact, usually a Java or C++ object, and then turns it directly into a distributed service. Among the reasons to avoid this are that such objects are not designed to deal with distributed system issues, such as partial failure, and also because the approach more easily allows language-specific features to creep into the service contract, potentially giving service consumers no choice but to implement using the same programming language.

Despite such recommendations, however, sometimes developers still want to take the code-first approach. Many see it as convenience, and are unaware of the long-term ill effects that it can create. Others choose the development convenience even when they know that what they're doing could cause problems down the road.

And because developers demand to be able to do code-first development, suppliers and vendors have to support it in their products, and eventually even standards support it too. JAX-WS 2.0, for example, specifies standard annotations that allow programmers to turn POJOs into web services. Microsoft supports similar stuff in their tools and languages as well.

Through a recent Joe McKendrick blog posting, I see that our old friend Ronan Bradley has issues with Celtix Enterprise for supporting code-first services through JAX-WS 2.0. Ronan, a former IONA employee, says that he's not intentionally singling us out for this, given that we're not alone in supporting that standard, but I'm not sure why he also chooses to ignore all the contract-first service support that Celtix Enterprise also offers.

Orbix has long promoted contract-first development, which may in fact be where Ronan first learned about it. Our Artix GUI tools strongly push customers toward contract-first services, and our experiences there have helped create the Eclipse SOA Tools Platform Project (STP) to promote open implementations for such tools. All of our training courses recommend contract-first services over code-first services. But ultimately, our WS products support both approaches because that's what our customers want them to do. It would be helpful to neither our customers nor ourselves if we held back useful features from them in the name of some sort of SOA purity.