Middleware Matters

In the ongoing WSDL vs. REST debate, Steve takes Mark to task for seeming to ignore the data side of the interoperability equation. Steve is right that regardless of whether you write WSDLs or use REST-based approaches, both sides need some understanding of the data being exchanged to be able to interact in any meaningful way. However, in Mark's defense, he has not ignored this part of the problem. He's talked about it a few times, such as in the comments he made over in Ted's blog last October.

Invoking a service or object basically requires an understanding of three pieces of information:

1. Where to send the request.
2. Input data for the request.
3. Output data from the request.

You can view item 1 as a combination of address and operation. With HTTP, this is the URL of the target resource together with the HTTP operation you're invoking, such as GET or POST. Items 2 and 3 are pretty obvious.

Having a fixed, uniform set of operations or verbs ala HTTP greatly reduces the total amount of possible variability for item 1. Since the forms of items 2 and 3 are going be highly variable for pretty much any approach, be it WSDL, REST, IDL, or whatever, the amount of variability for item 1 really matters. Clearly, the chances for interoperability are greater when you know a fixed uniform interface up front vs. having to somehow discover specialized interfaces and adapt to them on the fly.

In his ZDNet.com blog, Dion Hinchcliffe takes issue with my most recent IEEE Internet Computing column, entitled The Social Side of Services (PDF). He even emailed me a pointer to his article so I wouldn't miss it, which I greatly appreciate. I sincerely appreciate Dion taking the time to write his comments, and in general, I always appreciate any and all feedback on my columns. Below are my comments on his comments.

Dion says:

Vinoski is recommending social approaches to selling and marketing a SOA internally, yet not addressing the core problems that hinder adoption. He does highlight the usual suspects: not be [sic] aligned to the business or failing to have a registry, two classic solutions that many would agree don't help solve the problem when stated this way.

First, my article didn't say that failing to have a registry is a key problem. What it said was that believing that deploying a registry will solve all your problems is itself a problem. In other words, I said that many fall into the trap of believing that if they just deploy a registry, folks across their enterprise will just start adding reusable services to it, and your SOA adoption problems will be solved. Ain't gonna happen.

Second, Dion says I didn't address the core issues that hinder adoption. This assumes that everyone knows and agrees on what those core issues are. Oddly enough, I don't believe Dion clearly stated exactly what he believes the "core problems hindering adoption" are, either. But either way, if I simply wrote about the same old thing that everyone else writes about, then I wouldn't be adding much value, would I? Instead, I tried to describe the issues from a different, and yet still very valid, viewpoint.

My point about using wikis and blogs, which I can't decide whether Dion has an issue with or not, is that it's a good way of conveying the right messages and information from the bottom up. Most enterprise SOA initiatives fail miserably when the CIO stands up and says, "OK minions, though shalt adopt SOA and deploy it throughout the land. Now go make it happen!" To make SOA successful, you need to gain the buy-in of the folks on the ground who do the real work to keep the business running on a daily basis. For example, this article talks quite a bit about how getting developers on board was critical to Verizon's success with SOA.

Dion also talks about Web 2.0, and I believe what he's getting at is that he feels Web 2.0 approaches are better, faster, and easier than SOA. This is essentially the old WSDL vs. REST argument, and personally I think each approach has its place. There's no way that one of these will completely replace the other. What matters to a very significant degree, though, is what your developers are comfortable with. Forcing them to use approaches that they're not familiar with, regardless of how technically superior someone might consider them to be, is a recipe for disaster.

Dion also says:

For one thing, most SOAs actually have relatively little competition inside a given organization. Sure, some services could be obtained from other departments or from an outside supplier, but in reality there's little other choice most of the time. Yet, despite having no place to go, many SOA and EAI projects still fail to get engagement from their internal customers, despite the socialization and communication that Vinoski claims is key to adoption. They just don't want it or they can't use it.

First, I'm not sure I agree that SOAs have no internal competition. Their competition is the status quo. In general, people don't like change. Also, I guess I don't understand the latter part of the above quote. If people aren't engaging with SOA because "they just don't want it or they can't use it," then they clearly have not been convinced of the benefits. The answer to that is indeed better communication, especially from other teams who have adopted SOA and have succeeded with it.

And finally, Dion states:

What I don't want to convey is that socializing SOA is undesirable or unimportant, far from it. But it's not the first order of business or the most important aspect of adoption.

Nowhere does my column claim that socializing SOA and communicating about it is the most important aspect of SOA adoption. Rather, I present it as something that folks at certain levels of a company can do to help get their services adopted and used by other teams. And judging from the first part of the above quote, it seems that Dion agrees with that. The fact is, getting any new approaches or changes adopted within an enterprise requires socializing the ideas and communicating about them -- I really don't see how anyone could argue with that.

Over on his blog, Todd Biske comments, in two entries, on the "socialization of SOA" discussion. He provides a nice balanced viewpoint that's well worth reading.

I think that in this discussion, Dion may have partially fallen right into the trap that my column warned about, which is believing that the "best" technical answer is the best overall answer. Having a team or organization adopt a new approach, regardless of its technical merit, is rarely a technical problem.

Many of you are probably aware that with somewhere around 350 employees, IONA is not a large company. However, what you may not know is that our employees are located at a variety of sites across the planet, and it's been this way for most of the past decade. For example, we have developers in Dublin, St. Johns in Newfoundland, Boston, Beijing, and a number of home offices in other countries. We have sales engineers in all those sites and more. If there's anything I've learned over the past 6 or 7 years of being IONA's chief architect/engineer, it's that far-flung developers have a much larger variety of skills and experiences than you might expect. I wish I had a dollar for every time I mistakenly assumed that even the developers around the corner, let alone those on the other side of the planet, shared my opinions and experiences regarding a particular technology. When your development team represents as many countries, cultures, and backgrounds as ours does, you quickly learn not to make assumptions about such things. You always have to keep in mind that not everyone shares your assumptions about what the "best" technologies and approaches are.

For someone in my position, simply decreeing that "this technology is better than that one" doesn't solve this issue. The only way to get folks to agree to move in a particular direction (assuming you're not running a sweatshop) is to get their buy-in. Part of getting their buy-in is to make sure they're informed. Making sure they're informed relies, at least in part, on the communication and socialization of the ideas, concepts, strategies, and tactics involved.