The term architectural style moved out of the research literature and into the lexicon on practitioners after the Fielding thesis positioned Representational State Transfer (or REST) as the architectural style of the Web. I've always been hesitant to adopt this line of thinking because REST struck me as more of a philosophy -- and a not-quite-accurate description of how the Web works in practice. Now a-days its popular, at least on blogs, to call SOA an architectural style, sometimes coupled with a statement to the effect: Yeah, and we've been doing this for years with [insert your favorite middleware framework here]. I think this misses the point somewhat radically as I'll explain below.
The second related tendency I've seen is the claim that Web services are an instance of this architectural style. I don't think either claim is right, but I'll dispense with the latter first: Web services can be used without reference or respect to any stable model. The beauty of Web services is their use to support SOA, but they can certainly be used for straightforward client server modeling as well. I happen to prefer vanilla HTTP for this kind of interaction, with POX payloads where required (its not just for AJAX), but Web services will work, especially since there is reasonable tooling available to make this pain free for developers.
The problem with the claim that SOA is just an architectural style is that it reduces SOA to an abstract model, when what most people are trying to convey is a new (or at least evolutionary) approach to organizing the data-center. This approach involves, among other things, business-contract driven services, centralized and managed policy enforcement, leveraging ubiquitous Web protocols, process-oriented modeling, etc. Only one of those listed items is technology oriented, but it has clear business benefits as well.
SOA is the tag we wound up with, but perhaps its not so accurate. If I had to come up with something of my own, it would probably be Rationalized Business-Oriented Data Center Organization Amenable to Process Orchestration For Agility and Value. Somehow I don't think RBODCOATPOFAV is going to catch on like wildfire. (But you never know, so if it does, you read it here first!)
But what I want to suggest is that what we're really talking about is a way to better organize software assets to achieve business goals. And this is not what people mean by an architectural style at all. Now you might say this is a chicken or the egg problem. Don't we need to understand the architectural style that supports this before we can talk about serving business needs effectively? In my opinion, the answer is no. I think we will be doing ourselves a tremendous disservice if the SOA tech stack is not driven from the business needs down. The tendency to develop bottom up technologies with the idea that the interests and insights of middleware software folks will solve the needs of business is flawed. We've had a generation of distributed object middleware that suggests as much. And in fact it wasn't even that good for techie solutions.
I'm very interested in qualifying this problem but I think it will take some time to reach a broad consensus among all interested parties. In the meantime, you'll see terms like SOA 2.0 emerging precisely because people are trying to find a way to force the discourse away from the discontinuities that exist today. Long time associates know I have a morbid interest in semiotics: to me, this is an attempt to align an understanding between sign, signifier and signified that does not have stability today. And the quest for clear meaning is a good thing.
7 comments:
First of all I agree that Web Services is no more SOA applicable than CORBA or DCE when you drill down. However, I think that the current approaches to Web Services evolution (one way messages, concentrating on the message format etc.) make it easier to use Web Services as a SOA implementation. But yes, Web Services can be used without reference to SOA and it's pretty easy to produce a CORBA-with-angle-brackets approach, as we both know: just look at OASIS WS-RF. So I don't think there's any disagreement: Web Services can support SOA, but just because you're using Web Services doesn't mean your "doing SOA". Hey, you should have come to my JavaOne panel session - I said exactly the same thing and I was surprised by the number of people who afterwards thought I was wrong!
Secondly, I think SOA is an architectural approach if you take it to mean: loose coupling and message-oriented. Take a look at the work of the OASIS SOA-RM group, for example. BTW, on that basis: we have been doing it for years ;-) We just didn't need a TLA to describe it.
Thirdly (;-)) I prefer HTTP too, but unfortunately POX payloads don't scale unless you can get everyone to agree on the message exchange format: which is pretty much where Web Services succeed. I'm sure we've talked about this before, but I still think the two main advantages of Web Services are (fairly) universal adoption and XML/HTTP (the latter influenced the former). If you go the POX route, then you're back to trying to force everyone to agree with your way of interacting with services, which is hard.
And finally, I agree with your last sentiments, right up to the SOA 2.0 bit ;-) Yes, the way we're using SOA to build "things" is way more than just services and messages and loose coupling, but I'd argue that we do need a different term for it. In the same way that RPC meant synchronous invocations and yet J2EE, CORBA, DCE or DCOM went way beyond RPC (and yet leveraged it), adding process-oriented workflow, data-oriented interactions, distributed management, distributed transactions etc. but weren't termed RPC 2.0.
I still think SOA is an architectural approach, in the same way OO is an architectural approach. I just don't think it goes far up the stack. To describe everything else, you may need another term, but I'd prefer it wasn't SOA, or SOA 2.0.
As a slight aside, but it may be relevant to where I'm coming from with this, I often wonder if SOA is a confusing term to some because they've been doing that loose-coupling "thing" way before Web Services hit the hype-curve. It's close to MOMs (though MOMs imply a level of persistence and reliability that SOA doesn't). You only have to look at some major messaging deployments (J2EE, CORBA or DCE based) and it's easy to see what I mean.
One basic and persistent problem is, I think, that the term SOA is used to mean different things when its presented to systems implementors vs. IT adopters. Some of the high level presentations you see from companies working in this space do a good job of building a layered stack that provides differentation in this regard, but the stacks tend to lump together under a blob called SOA. At this point, we still wind up with this persistent conceptual disconnect.
Anyway, I take it you like my new acronym better?
Yeah, I love the new acronym. Now all I have to do is make sure I use an 8 point font on my slide-ware ;-)
The OASIS SOA RM TC came the same basic conclusion and defined SOA as an abstract model for architecture. Although the group focused on software architecture practices, it is equally applicable to other domains such as setting up coffee shops etc. The model is at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
I'm a little suspect that setting up a coffee house may in practice be different than organizing a data center's software assets. The concern I have is that we both clear about what we are saying and that we are directly solving problems related to business information systems.
On the Internet, the Domain Name System (DNS) associates various sorts of information with so-called domain names; most importantly, it serves as the "phone book" for the Internet by translating human-readable computer hostnames, sportsbook, into the IP addresses, e.g. 66.230.200.100, that networking equipment needs to deliver information. It also stores other information such as the list of mail exchange servers that accept email for a given domain. In providing a worldwide keyword-based redirection service, the Domain Name System is an essential component of contemporary Internet use.
http://www.enterbet.com
I want to inderstande the difference between SOA and REST? and can we use REST as an architectural style for SOA,
Post a Comment