WS-CDL literature surveys

I've been on the program committees for too many conferences and workshops to keep count. You almost always see the expected bell-curve of paper submissions (5% are really bad, 90% are ok, and 5% are extremely good). But irrespective of the quality and content of a paper, the one thing that always annoys me is bad citations and references. I think this goes back to when we were doing the initial work around Arjuna and looking at how to leverage object-oriented techniques for fault tolerance. These days it'd be very passe, but back then it was the start of OO and the work we did was cutting edge. We weren't the only ones doing work in that area: there was Camelot/Avalon (later went on to become Encina from Transarc) and Argus (ISIS wasn't really about exploiting OO approaches). Whenever we ran into papers by those teams it was very rare to see them reference us, whereas the inverse was almost never the case (timing permitting). Frustrating to say the least. So I always try to ensure that accepted papers have appropriate references. It benefits the author's work as well as the reader (there's nothing more infuriating than reading a paper, asking yourself "OK, but how does this compare with XYZ?" and then finding that the author's don't mention it.)

What has this to do with WS-CDL? Well I'm on another PC (I won't mention which, though I have posted the CFP on the blog already) and recently received a swathe of papers on orchestration and choreography. All of them mentioned BPMN. Several of them mentioned BPEL. A couple of them mentioned Pi-calculus. None of them mentioned WS-CDL (or its predecessors)! Of those that mentioned Pi-calculus, they all duplicated the effort that has gone into CDL. Plus every single paper mentioned the importance of being "standards compliant". It's not as if it's hard to find a mention of CDL via google (try googling for 'choreography web services'): in the "good 'ol days" we used to wonder if the lack of references to Arjuna was down to the complexity of tracking journal and conference papers - this was before the WWW and in the relative infancy of the internet (oh cr*p, doesn't that make me sound old?!)

Why is it that these papers didn't even mention CDL once? I think it's a combination of factors including: poor research on the part of the authors', excellent publicity on the part of major vendors that CDL is a dead standard, and confusion around the relationship of CDL to BPEL. This does a disservice to the people who have worked on CDL over the years: it's an excellent body of work and brings value to the choreography arena both from a static (development) perspective as well as dynamic (runtime). Of course it's in the vendor's best interests to ignore WS-CDL when they've adopted WS-BPEL heavily, but these things are complimentary (in fact CDL compliments any orchestration implementation, so don't get hung up over the WS part of the name.) But for a researcher, it's not acceptable.

So if you're doing research into choreography (and/or orchestration) and are thinking of writing a paper, you need to look at WS-CDL. Even if it's only to compare and contrast with what you're going to do, it's important. (A cogent argument against it in favour of your own work is fine, as long as the literature survey is complete.) Otherwise you could be disappointed when your paper is rejected.

What's the point?

I've had the pleasure of working with some very smart people over the years in the area of fault tolerant distributed systems. As a result I've performed research and development in a number of different techniques, including replication (for high availability) and transactions (for consistency). In all that time I've been conscious of the fact that a lot of time and effort has been spent proving that whatever was done worked in the case of failures (whatever the specific definition may be for the particular environment): after all, that's the point of the whole exercise. Yes I know that failures don't happen that often (try selling a transaction manager to people who haven't used one for years and explaining why they really really need to buy one!) But they do happen and that's why fault tolerance techniques (and testing they work in the presence of failures) are so important.

Now why do I bother mentioning this? Well it's come to my attention over the past few years that some purveyors of fault tolerance solutions either don't bother to test the "edge cases" (which are not really edge cases, but the reason for their product's existence) or don't care (and hence publicize) that their solutions won't work in the case of some (all?) possible failure modes. I'm not going to name-and-shame them (primarily because I haven't been able to confirm those reports myself), but if you are a user of something that purports to offer high availability or data consistency in the presence of failures, you really need to check that that vendor means and how they go about confirming that their product works as they say it should.

SOA 2.0 all over again?

Over two years ago I got frustrated at the announcement of SOA 2.0. Many others were likewise confused and irritated at an attempt to create another hype curve. I'm not going to attribute cause and effect because maybe it would have happened anyway, but SOA 2.0 pretty much bit the dirt subsequently. Well while writing up this article for InfoQ I had a serious case of deja vu.

WTF is WOA? Where did it spring from and more precisely where has it been hiding for the past ten years? At its best it seems to be the same as ROA, i.e., a concrete implementation of REST targeting the Web. (I'm not so keen on ROA either: I prefer REST/HTTP.) At its worst it's an excuse to start generating more terms ('Web-oriented SOA'?! You've got to be joking!) One of the original articles on Web Oriented Architecture (aka WOA) was posted by Dion on April 1st, so maybe that was a Freudian Slip on his part?

But if WOA is not the same as REST (or REST as applied to the Web) then it really needs a different acronym: REST is fundamentally the architecture on which the Web is based and everyone understands that now. Alright you do need to clarify how the concepts are implemented (HTTP, JMS etc.), but that's easy to do without coining a whole new terminology. Independently of Roy's thesis, the W3C has done a good job of defining the Web Architecture. Plus, people have been building RESTful good citizen applications for quite a while. Did they need to coin a new term to make it clear what was happening under the hood? I think not. But then again, maybe the intent is to try to outwit us with an attempt at the Chewbacca Defense? I think it's more a case of The Emperor's New Clothes syndrome and we should just say that WOA is naked and move on!

Look guys, we have REST as a well defined and accepted term. Why do we need yet another acronym to mean the same thing? The answer is that we don't, so let's stop polluting the atmosphere with meaningless or duplicate terms and get on with helping end users and developers figure out the best way in which to deliver business functions and data! I can say 'REST as applied to the Web' in less time than it takes to explain WOA and I can guarantee you that more people will understand what I mean with the first description than the second.

What's it mean to be an architect?

We live in a 19th century station master's house and it's time to either move or add another module (aka extension). We're looking at the latter for a number of reasons. Going this route means we need to have someone come in and draw up plans: the architect. Most people probably think of what an architect does based on the dictionary definition: "One who designs and supervises the construction of buildings or other large structures." But if you think about it more, this person is more than a designer or supervisor: they have to understand a lot about materials and how they fit together in order to assess structural integrity, stress points, resilience to adverse conditions and, of course, the final all-important look. So although they may not get their hands dirty with bricks and mortal (some do), they have to know about the construction as well as the people who will eventually do that work. That doesn't mean they are necessarily as skilled as some others in their team (e.g., I doubt the typical architect would have the skills of a carpenter), but they would need to understand wood, bricks, stone etc.

This requirement for an architect to know how things come together and, if necessary, be able to do some of that development should be common to uses of the term within other sectors and not just building. Whether it be biotechnology, cars or ships, the architect had better be skilled enough to understand how their plans will be affected by the implementation. How they do that may depend upon the industry and the individual (e.g., some building architects have been carpenters in the past).

The software architect needs to be the same. If you've got 'architect' in your title then you need to either be (or have been) a coder. (I think 'be' is better). Whether that means you've coded entire systems, or had to bring together existing modules as well, doesn't really matter as long as you have the understanding of what's possible, practical, reliable and maintainable as a developer. Writing a few XML configuration scripts doesn't cut-it in my opinion, because that does not bring the necessary appreciation for architecture. For instance, how can you understand what it means for a failure to happen in a distributed system if you've never had to implement one (or part of one)? So far I've been in the fortunate position to have only met software architects who fit my definition (I suppose a chicken-and-egg situation could be argued).

However, I know others who have met (suffered) exceptions to this rule. In some companies it appears to be endemic that architects are designers or team managers, with little or no coding experience behind them. Maybe they're just lucky and the development teams pick up the slack, ensuring success of the projects. Or maybe the blame for failed projects just manages to go elsewhere. But I know when we decide to go with an extension on our house I'll be looking for an architect who knows more than how to draw pretty pictures or make sure the work is done on time: I don't want the whole thing collapsing on us months or years later!