SOA and Architectural Constraints
November 11th, 2007 | Published in enterprise, REST, services, SOA | 10 Comments | Bookmark on Pinboard.in
Don says he agrees with a lot of what James has to say about Stefan’s recaps of the QCon SOA Track, listed below:
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.
November 11th, 2007 at 10:52 am (#)
I just got back from the latest InfoWorld SOA forum in New York, and it was very clear from the customer presentations (the best thing about this forum BTW) that the problems they are grappling with have much less to do with technology than finding the right approach to solving their problems.
SOA is much more about helping people who are trying to find the right approach to IT than it is about software system architecture. I did not hear customers worrying about the REST vs SOAP stuff, more about the best way to meet their business requirements for improved IT.
Web services and more purely HTTP based systems like REST can both play a role. I doubt that we will ever see a single technology solve all IT problems.
November 11th, 2007 at 3:01 pm (#)
Steve,
I closely followed Stefan’s notes on the SOA track and also read the comments made by James.
I agree with Eric that both has a role to play. We have been burnt far too much in looking for the One True Architecture. I see that REST could really simplify a lot of things out there. Also as Steve pointed out in a previous post, the REST constraints can better guide a developer/architect when designing systems.
However I have yet to see a clear strategy in answering the reliability and security concerns with REST. Steve I don’t think Sanjiva blew things out of proportion. I certainly think they are valid concerns. Enterprise interactions are not always just p2p, TLS is not good enough and you may have multiple transports involved. Also interactions can be more complex MEP’s than a simple request/reply. WS-* space has more mature strategies in answering these concerns.
What do you think? I like to hear your comments on this.
As an architect you need to use the right strategy that will help you achieve your goals, rather than being religious about one thing and end up being a one trick pony. I like to have both REST and WS-* up my sleve and will always keep an open mind and will use what make more sense in a given environment.
November 11th, 2007 at 3:27 pm (#)
I don’t think I agree at all. Roy defines an architectural style with no constraints as a “Null Style”. Quoting from his dissertation, “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”.
Clearly in SOA we talk about separation of concerns,minimizing coupling, and maximizing cohesion etc. Isn’t that a constraint on it’s own ???. So this itself says that SOA has some constraints and is not a Null Style. Also most Web Service implementations does follow a client-server pattern. And many WS purists will emphasize, that your Web Services needs to be stateless.
If you think pragmatically, you cannot build any system without a set of constraints. These constraints are the key decisions you make in your architecture. Building a system without constraints is like building a house without a plan.
November 11th, 2007 at 3:44 pm (#)
Rajith: please point me to a standard document that purports to define SOA, and show me where it defines the architectural constraints. You won’t be able to, and that’s my point. Unless those constraints are standardized or at least clearly documented in a document that’s generally accepted as the definition of SOA, you can’t claim that they exist, because until then, there’s no wide agreement about what they are.
November 11th, 2007 at 4:19 pm (#)
Steve,
The lack of a standard document doesn’t imply that SOA has no constraints either. It is one thing to say that SOA has no clearly documented constraints (or an agreement as to what they are) and I accept that, but it’s an entirely different thing to say that SOA has no constraints.
My point is, (with all due respect) that without proper evidence/standard documentation that is generally accepted within the industry, you (Mark/Roy or whoever) cannot claim that SOA has no constraints either.
We all agree that SOA promotes “separation of concerns,minimizing coupling, and maximizing cohesion ..etc”. Doesn’t this at least implicitly say that there are constraints ? Sure, we all might disagree what exactly these constraints are. But there is enough understanding within the industry about what SOA is in general, and the benefits of SOA right?? And in order to realize these benefits we need to have some sort of constraints in our architecture. We cannot expect to build our system in any which way we want and expect to realize those benefits. Isn’t this enough to suggest that there are constraints? What exactly those constraints are is a different debate and should not be confused with this one.
November 11th, 2007 at 5:38 pm (#)
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? I’m afraid the burden of proof is on you, not Mark, Roy, or me. How can you prove they exist and that everyone agrees on them? If that were true, wouldn’t they already be officially written down somewhere?
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.
November 11th, 2007 at 7:29 pm (#)
Very sorry Steve, I don’t agree. The Null Style is concretely defined in Roy’s dissertation as follows.
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?
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)
November 11th, 2007 at 11:01 pm (#)
Rajith: check the sentence in Roy’s thesis that immediately precedes the one you quoted:
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.
November 12th, 2007 at 9:47 am (#)
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.
November 23rd, 2007 at 6:32 pm (#)
[…] Vinoksi summarised it very well in one of his comments while answering a comment I made on his blog. It’s(Roy’s dissertation) not really primarily about REST; rather, it’s about principled […]