you’ll note that I said that because SOA has no documented constraints, the only constraints you get are those provided by whatever SOA platform you choose to use. I think that’s actually the same thing you’re saying.But you’ve also been trying to assert that because SOA platforms have constraints, SOA itself must have constraints too, but that’s just flawed logic.

I think I get your point now. SOA platforms may have constraints but you cannot argue that it is so just bcos SOA itself has constraints.

The Null style is simply an empty set of constraints.

SOA has no constraints, therefore it is the null style. If SOA has constraints, please, as I’ve already repeatedly requested, point me to the standard document — official, de facto, or otherwise — where they’re defined.

What you’ve been arguing (and James too, actually) is that SOA as practiced has constraints. If you re-read my original posting a little more carefully, you’ll note that I said that because SOA has no documented constraints, the only constraints you get are those provided by whatever SOA platform you choose to use. I think that’s actually the same thing you’re saying. But you’ve also been trying to assert that because SOA platforms have constraints, SOA itself must have constraints too, but that’s just flawed logic.

So, for the last time: unless and until someone documents the same for SOA — and note that Dave Orchard tried but IMO his doc still needs a lot of work — then the only architectural style that SOA can formally claim to be is the null style.

Very sorry Steve, I don’t agree. The Null Style is concretely defined in Roy’s dissertation as follows.

“From an architectural perspective, the null style describes a system in which there are no distinguished boundaries between components. It is the starting point for our description of REST”.

In SOA, Services do have distinguished boundaries between them (at least to a certain extent).Isn’t that the whole idea of a Service Oriented Architecture?. I agree that the OASIS SOA Reference Model you quoted does not define any constraints. However it clearly describes several desirable properties for SOA systems which does contradict the definition of a Null Style.

So clearly SOA doesn’t fit, Roy’s definition of a Null Style. In other words you cannot claim that SOA has no constraints.

Do you agree?

Rajith: do we really “all agree” on precisely what SOA’s constraints are? Sorry, but there’s simply no way that that’s true. How can you possibly make such a claim?

Steve, either I didn’t express my self clearly, or you misread me completely. I never claimed that we all agree across the industry what the SOA constraints are, or made any such claim as to what these constraints are. That is not the point I am trying to make here. Lets first agree on what I said.

All I said was that we seem to have some general agreement on a few things about SOA. Namely “separation of concerns,minimizing coupling, and maximizing cohesion ..etc” which you also noted in your post. To what degree they do so is a different story.

Again, the main argument that I am making here is not that SOA has constraints x,y,z ..and that we all agree on them. Rather that SOA is not a Null Style or that I don’t agree that it doesn’t have any constraints. (What these constraints are and the degree of agreement – I make no such claims)

Say I’m new to SOA. Where exactly do I go to learn about these SOA architectural constraints that you claim not only exist, but are fully agreed upon across the industry? We already know they’re not in the OASIS SOA RM spec, so where do I look? InfoWorld? Gartner? A collection of certain blogs? The Yahoo SOA mailing list?

Please go read Roy’s thesis. If you’ve already read it, read it again. It’s not really primarily about REST; rather, it’s about principled design. Much of his dissertation is about architectural elements, principles, constraints, properties, and the relationships between them all. REST is used as a very clear example in chapter 5 of what principled design is all about.

The definition of constraints that Roys presents is exactly what the points in question from my QCon slides are about, so don’t try to hand-wave the argument into something about intangible benefits and informal implied constraints. That’s not at all what I’m talking about, nor what this discussion is about.

So, for the last time: unless and until someone documents the same for SOA — and note that Dave Orchard tried but IMO his doc still needs a lot of work — then the only architectural style that SOA can formally claim to be is the null style.

I don’t know how I can make this any clearer.