Middleware Matters

Stefan Tilkov has written a nice article describing our new Celtix Enterprise release. The response to our announcement so far has been pretty good, with a few hundred downloads over the past 24 hours.

My own little contributions here are in the CXF dynamic language support, which I originally designed and wrote for the Celtix open source project but which has now moved to CXF, and in Qpid, the Apache Incubator implementation of AMQP, where I'm a committer.

Don't let the "ESB" label scare you, BTW. I know many of you dislike ESBs and for good reason: most vendors' ESBs are either just glorified JMS implementations or are big, scary, centralized, and expensive EAI-like monstrosities. With Celtix Enterprise, IONA has again used its extensive pedigree in distributed computing to put together an adaptive and truly distributed SOA offering. While in theory all SOA is distributed, in practice, many ESB solutions force you to use centralized hubs no matter what. With Celtix Enterprise, knowing there's no such thing as a one-size-fits-all enterprise solution, we give you the full range of options, from centralized messaging brokers with Qpid, for example, to smart multi-protocol multi-format SOA endpoints with CXF.

Speaking only for myself, I actually wish IONA wouldn't define Artix or Celtix Enterprise as ESBs, but given that I'm not in marketing, what do I know. Well, I guess I do know that given the features and functions we offer, ESB is, for better or worse, the closest fit for us from a market category perspective. Whatever you want to call it, Celtix Enterprise is about as far away from the "business as usual" ESBs as you can get. But don't take my word for it, check it out for yourself.

These are cool times to be at IONA, I must say. In about three weeks I will have been employed here for 10 years (!), and the release of Celtix Enterprise is in all honesty the most exciting product release I've seen in my time here. It represents a new way of doing things, technically and business-wise, both for our customers and for ourselves. And it's only going to continue to get cooler going forward.

When I was at JAOO 2006 back in October, Markus Voelter interviewed me for Software Engineering Radio. Markus has just posted the interview as a podcast.

I enjoyed this interview more than most because Markus asked such a broad range of questions, rather than just narrowing in on whatever the topic of the day might be. His questions covered the whole range of my career in distributed computing, from pre-CORBA distributed systems all the way through to my current work on Qpid, and it was especially nice to be able to talk about the early days for a change.

Dan Pritchett takes issue with Pete Lacey's characterization in his InfoQ interview of web services being too tightly coupled. Dan's issue seems to be that REST is more tightly coupled than its proponents would have you believe. He writes:

The simple facts though is that REST doesn't make this any better. Resources have formats (schemas if XML). They are located by URI's which is a contract for where they can be found. Change the resource format in an incompatible way and clients break. Move the resource to a new location and the clients break. Contracts are contracts, break them and you break the software.

The "move the resource" issue is bogus, given that you can just redirect clients (e.g., HTTP 301). But more generally, coupling isn't so black-and-white. It's not an on-or-off switch. Rather, coupling is measured in degrees. REST advocates claim that it can allow for more loosely coupled systems than SOA or WS-*. And I agree with them.

Take for example REST's uniform interface constraint. If you consider the client/service interaction equation to consist of factors for interface coupling, data coupling, and semantic coupling, REST's uniform interface constraint effectively removes the entire interface coupling factor. SOA and WS-*, OTOH, actually promote interface coupling as a strength.

As I finish writing this, I see that Pete has already responded to Dan, and he's right on target, as usual.

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.