For about the past year or so, Dave Orchard has been using principled design techniques, and in particular Roy Fielding‘s interpretation of software architecture, in his effort to build out and improve the Web services infrastructure. That is indeed worthy of very high praise, as he’s the first Web services proponent to have done it. But unfortunately, it seems he (and he’s not alone in this, of course) is missing one very important aspect of software architecture and large scale architectures in particular; an appreciation that some properties can totally make or break an architectural style.
Dave talks a lot about the pros, cons, tradeoffs, etc.. of particular architectural choices, and that’s all good. More often than not, he’s totally bang-on too. He gets, for example, that not adopting an interface constraint necessarily reduces visibility and simplicity, and has even gone so far, risking ridicule from colleagues, to suggest that a limited form of interface constraint (GET) would be a good thing Yet, at the same time, he fails to recognize the implications of the loss of these properties. Though it’s certainly not the case for all properties, some are so important that they can make or break the suitability of an architectural style for some particular task or environment. In the context of Internet scale systems for example, high degrees of visibility are simply mandatory (unlike LAN scale systems) due to the prevalence of trust boundaries (aka agency). It’s the whole integration complexity thing again; do you want to budget development resources along an O(Nlog(N)) (or worse, O(N^2)), or O(N) curve?
All architectural styles on the Internet, past and present, have large degrees of visibility. Even some non-REST forms of SOA do too, for example MEST. I therefore suggest that all future architectural styles that we’ll see on the Internet will have large degrees of visibility too.
Does your flavour of SOA have it?
no comment until now