Steve Vinoski's Blog

Reusability is often promoted not only as a goal but also as a feature of all kinds of software architectures, designs, and systems. For example, in the CORBA, WS-*, and SOA worlds I formerly haunted, everyone spoke nonchalantly of reuse as if it were a given. You were supposed to simply identify the objects or services required to support your business processes, and then specify their interfaces. Then, anyone wanting to provide one or more of those objects or services was merely supposed to follow the appropriate interfaces and write implementations for them. Applications were written to the interfaces and thus were automatically decoupled from the implementations. As a result of these reusable interfaces, you could also potentially reuse the objects and services that implemented them, as well as the applications that consumed them.

Problem is, it never seemed to work out as easily as that. Most of the time, the interfaces people came up with were just too specific, and nobody could agree to apply them widely. Think of all the time people spent over the years in OMG, JSR, and W3C WS meetings trying to agree on just the infrastructure interfaces and not always succeeding. It’s therefore not surprising that there was never much success at defining broadly-accepted standard interfaces up at the application level; the scope is simply far too wide up there.

So, with technologies that promote interface variability, planned reuse is pretty hard. Consequently, serendipitous reuse, where services and facilities can be combined and reused beneficially in unforeseen ways, is virtually out of the question.

Stu Charlton’s blog was where I first saw those terms used, and I found them very enlightening. So did Bob Warfield.

One of the first things that attracted me to REST was the uniform interface constraint. Mark Baker first brought it to my attention nearly 8 years ago, and before I looked at it, I thought it was just a bad idea, like a totally generic doIt() interface, devoid of any meaningful semantics. But of course, there’s much more to it than that. The HTTP interface, for example, strikes a great balance that allows it to be efficiently reused across a very wide variety of applications. And when such a uniform interface is reused, the applications that use it stand a much better chance of being reusable themselves than if they were written against a non-uniform application-specific interface.

My latest Internet Computing column, entitled Serendipitous Reuse (and here’s the pdf if you prefer), explores how the uniform interface contributes to reuse of both the planned and serendipitous kinds.

Don says he agrees with a lot of what James has to say about Stefan’s recaps of the QCon SOA Track, listed below:

• Dan’s talk
• Pete’s talk
• Sanjiva’s talk
• my talk

I too agree with many of James’s insights. If you don’t regularly read his blog, you should subscribe immediately. I especially like this quote:

When I consider SOA and REST today, I do not see two competing visions, I see an evolution that has brought the industry back to a core set of fundamental design principles that we seemed to have lost sight of for a while.

How very true. However, I disagree with just one small point: his critique of the part of my talk where I said SOA has no constraints (as Mark Baker has been pointing out for years now).

James says that SOA has constraints, it’s just they’re just not well-documented. I know exactly what he’s saying, but I have to stick with what I said. The only official definition of SOA that I know of is the OASIS SOA Reference Model, which mentions several desirable properties for SOA systems, but it documents no constraints for inducing them AFAICS. Later in my talk, as Stefan’s notes indicate, I did say that I was willing to concede that the OASIS SOA RM promotes the client-server constraint. However, I was being really, really generous, since all the specification really does is hint that SOA systems should be distributed, and “distributed” has a lot more meanings than just “client-server.”

Since there are no official standard SOA constraints, the only constraints you get are the ones that each vendor or supplier of SOA platforms and systems decides to give you. Naturally, each different solution in this space will differ in those constraints.

As the quote from James above implies, pitting SOA and REST against each other doesn’t make a lot of sense. The reason I went to the trouble of pointing out in my talk that SOA is missing critical architectural requirements like constraints was to help illustrate the significant differences between SOA and REST. Fundamentally, as I also said in my talk, SOA isn’t really about architecture in the way that REST is. Rather, it’s about IT culture, best practices, breaking down the enterprise organizational and political barriers that needlessly increase IT costs, and following good fundamental software engineering principles like reuse, minimizing coupling, and maximizing cohesion.

I returned home from QCon San Francisco last night. In the SOA track, it was most excellent to finally get to meet Patrick Logan, Stefan Tilkov, Pete Lacey, Jim Webber, Stu Charlton (thanks again for the Dew, Stu!), and Mike Herrick in person, as well as to get to meet up again with Sanjiva Weerawarana, Glen Daniels, and Dan Diephouse. All in all the SOA/REST track was highly informative, with solid presentations through the whole day. Pete’s was especially cool due to the demo he gave of the extreme flexibility and integrability of REST-oriented solutions. It was also reasonably fun, given how much the attendees got into it with their questions, and especially due to Jim’s presentation at the end in which he mixed some serious technical chops with very funny one-liners popping out every second or third sentence.

My talk, “REST Eye for the SOA Guy” (title taken from here), went reasonably well. The only time it didn’t flow as smoothly as I would have liked was when some semi-anti-REST folk started questioning my assertions about specialized interfaces inhibiting scalability, and wondering whether REST just pushes all the coupling problems to the data. I felt like I was being pulled backwards in time by 5 years to the old W3C Web Services Architecture Working Group meetings, where very little was ever accomplished due to arguments like those. I’ll have more to say on those topics in some near-future blog postings.

An interesting thought struck me as the track progressed: in my experience it seems that most SOA/WS proponents who argue against REST on technical merits have never actually tried to build any RESTful applications. Many of their objections seem to be heavily based on emotional reactions, or based on conclusions reached only by blowing issues out of proportion (for example, I felt that many of the points in Sanjiva’s talk fell into this category). So it led me to wonder about how many, if any, dyed-in-the-wool WS advocates ever seriously, honestly, and fairly looked at REST, actually tried it, but then decided it didn’t work and so willingly chose to go back to WS. I don’t want to count those who had to go back to WS only to integrate with something else already implemented using WS, because that doesn’t fit the “willingly” part. (For example, I recently had to write a client to access a SOAP service, and I was definitely not in the “willingly” camp because the service was way more complicated than it needed to be, only because of SOAP.) I personally know of nobody who has ditched REST for WS like this, but if you have, or if you know of someone who has, I’d love to hear the whole tale, so feel free to leave it in a comment.

The conference itself was much like JAOO, which is not surprising given its JAOO roots. It was smaller, of course, given that this was the first QCon held in the U.S. And just like JAOO, there were times where I wanted to be in multiple places at the same time to see two or three different talks all scheduled concurrently. For example, I very much would have liked to sit all day in the Thursday “Architecture Quality” track, but couldn’t since it ran parallel to the track I was in.

In short, if you didn’t go to QCon, you missed a great conference. Stefan, thanks again for inviting me.

When you read stuff like this, you can’t help but feel that IT is, without a doubt, doomed.

The gist of the posting is

• REST is too hard for the average developer
• Dynamic languages are too hard for the average developer

Along these same lines, a couple of folks told me in person that my recent blog entries about REST, dynamic languages, and ESBs were misguided because today’s enterprises are interested only in approaches, frameworks and platforms that allow average developers to produce quality systems.

This all strikes me as nothing but wrong-headed thinking.

On the dynamic language front, the worst code I have seen in my career has always, always, always been in compiled imperative languages, most often Java and C++. I would much rather let an average developer loose with a dynamic language, because the surface area is smaller, there’s a lot less rope available for self-hanging, and if they’re going to fail, they’ll fail way faster and thus allow much more time for recovery. The fact that dynamic language programs are usually smaller than their compiled counterparts means that they’re easier to read and review, and statistically, they’re likely to have fewer bugs. Furthermore, counting on the static language compiler to save you is simply wishful thinking. To paraphrase Tim Ewald from a conversation he and I had during lunch a week or so ago, compilation really amounts to just another unit test.

On the REST front, if you’re claiming that it’s harder than the alternatives, to me that’s just a sign that you don’t understand it. Is REST simple? No, but neither is SOA. However, unlike SOA, which is fairly wishy-washy, noncommittal, and loose, REST’s constraints provide real, actual guidance for developers, and those same constraints also provide opportunities for significant flexibility, extensibility, performance, scalability, and serendipity. SOA’s contracts come with no rules or constraints, and thus can easily result in a system that’s extremely brittle, tightly-coupled, and virtually impossible to upgrade. SOA itself isn’t inherently bad, as it’s certainly a step above the “every application for itself” mode of development that’s so widely practiced. Unlike REST, though, SOA doesn’t go nearly far enough to provide real, useful guidance to the poor developer who has to actually write the stuff, make it work, and keep it running.

And finally, regarding the overall notion that enterprises cater only to average developers, I’m not sure I agree. In my former life I met countless enterprise developers who were extremely sharp. While I have no doubt that there are numerous bean-counting CIOs and middle IT managers out there who think they can build high-quality IT systems with low-quality developers, at the end of the day, businesses generally know better than to think they can get something for nothing. Or to put it another way, they know they get what they pay for, and if they pay only for average developers or worse, they’ll get only average software and average systems, or worse. That’s a no-brainer.

If you’re in a position of technical leadership or project management and you’re asked to come in ahead of schedule and under budget, my advice is that you’re generally more likely to succeed with REST and dynamic languages than with the alternatives because their inherent constraints allow for better focus. Also, if you find yourself in such a position, you owe it to yourself and your team to continually lobby your superiors to help them understand the very real costs of their budgetary stinginess.

A little over a week ago, Ron Schmelzer of ZapThink, who’s pretty well known as an expert SOA analyst, quietly snuck an interesting comment into the ESB brouhaha that developed here recently. The ESB proponents who expressed displeasure at my view of ESBs, especially those who quoted ZapThink in their defense, will want to read what Ron had to say. If you don’t feel like chasing that link, here’s what he said:

The poster (Curt) who says that ZapThink says that ESBs are an enabling technology on the road to SOA has mischaracterized our position. Speaking from ZapThink’s perspective, we don’t believe that ESBs are neither necessary nor sufficient to enable SOA. In fact, we’ve seen plenty of SOA solutions that leverage a wide variety of non-ESB infrastructure. To be as unambiguous as possible: ESB is vendor marketing spin. True, there is certainly capabilities within an ESB that *might* enable companies to produce truly loosely coupled, composite, and heterogeneous Services in an environment of continuous change, but you can just as easily build tightly-coupled, proprietary, point-to-point Service integration with ESBs. There’s nothing about an ESB that substitutes for the need to do architecture. And there’s nothing about architecture that requires the adherence to a particular technological infrastructure.

If you want to make SOA work in a heterogeneous environment, why would you want to limit yourself to one technology, one approach? You’re buying right into their strategy of locking you into a platform. That’s only good if you sell platforms. Wake up folks – architecture is YOUR responsibility, not that of some vendors hawking middleware!

So, don’t put ZapThink in the camp of the ESB bigots. We certainly are not. Implement SOA with intermediaries and REST. Why not?