Michael Champion's Blog

SOA: One acronym to bind them all?

I must confess that when I first started hearing about Service Oriented Architectures or SOAs, my reaction was "oh brother, here we go again ... more vague mumbling about 'paradigm shifts' by analysts who have predicted 10 of the last 2 revolutions." The definitions one finds didn't inspire confidence ... usually something along the lines of "a SOA is an architecture in which the components are services and the services interact by invoking other services." Sortof begs the question of what a "service" is.

Another thing that did not inspire confidence was that many people who profoundly disagree about lots of other things all seem to agree that Service Oriented Architectures are a Good Thing. If the term is broad enough to include "everything", is it meaningful enough to exclude anything?

I've overcome a good bit of this cynicism lately. Sure, SOA is a kindof fuzzy concept, but after spending much of the last year trying to rigorously define what a Web service really is and is not, I'm more sympathetic to the recursive use of "servce" in these definitions. Likewise, a lot of the discussion blurs the distinction between the definition of SOA and the characteristics of good architectures, service oriented or otherwise. For example, "loosely coupled" and "standards based" are considered two of the pillars of SOA". These seem more like principles of most successful architectures than principles specific to SOA. But there does seem to be a very powerful idea buried down in the current SOA hype: the idea that the central abstraction is this fuzzy thing called "service."

It's hard to define what a "service" is -- it could be some software component written in an OO language and deployed via an application server, or some "glue" exposing a legacy mass of COBOL , or a plain vanilla Web server providing the, uhh, service of serving up documents. But it's a lot less hard to talk about how one invokes a "service" -- you always (I think!) send it messages. So, to implement a "service," take some discrete chunk of functionality and provide a messaging interface to it. All that consumers of the service have to know to use it is the format of the messages they send it and get back from it, the protocol(s) for transmitting the messages, and the "message exchange pattern" of the interaction between the service provider and service consumer. In other words, the critical definition of a service is its interface to its consumers, not any particular characteristic of its design, implementation, deployment, etc. One can develop SOAs with COM, CORBA, BEEP, JMS, proprietary stuff, XML, HTTP, SOAP, and all sorts of combinations of these and many other technologies. One can describe the service interface using some combination of IDL, WSDL, an XML schema language (there are several!), DAML-S or some other ontology language, or if all else fails, a phone conversation.

This, in my mind anyway, explains why so many people who disagree on other things tend to think of their architectures as "service oriented." What they're disagreeing about are things like whether to encapsuate the service invocation messages behind an API or expose the messages directly to the service consumer, whether to handle reliabiility and transaction integrity down in the service infrastructure or up in the application layer, whether to have the service semantics described by human-readable documents or machine-processable ontologies, and so on. But if one looks at the messages, exchange patterns, and data exchanged, a lot of these differences tend to blur into the background.

I think this view of distributed systems architectures helps maintain focus on what is important for scalability, interoperability, evolveability, etc. and prevents us from becoming distracted by extraneous and politically loaded concerns. For example, there is no intrinsic conflict betweeen REST and SOA or SOAP. One can and should debate the specific conditions under which it makes more sense to directly manipulate "resources" by transferring representations of their state using the "services" supplied by HTTP, and when it makes more sense to hide the resources behind a more complex and customized service interface, but let's not call these alternative "paradigms". They're just different flavors of SOA, and developers are free to mix and match them to meet the needs of a distributed application.

Comments

• Flavours
  "They're just different flavors of SOA, and developers are free to mix and match them to meet the needs of a distributed application."

  Mike, you've said things to this effect a couple of times recently, including in response to Kendall when you said which subsumes REST as a special case.

  I believe this view reflects demonstrates a misunderstanding of one of the key tenets of software architecture. That tenet is that constraints must be applied to achieve desirable properties (see the 2nd law of thermodynamics). The fact that SOA (in general) has a subset of REST's constraints, necessarily means that SOA is *less* valuable as an architectural style than REST, not more, because it has a subset of REST's properties, not a superset. If you're in an environment where you don't need the properties induced by REST's additional constraints, that's fine; in that case, both would be considered "equal". I'd say that on the Intranet, that they are relatively "equal", as some of REST's additional constraints were applied in order to provide properties necessary for the Internet.

  As another example of why I believe it isn't useful to use constraint overlap as a measure of style quality, consider that the null architectural style is a bad thing, not a good thing. A system developed to it is guaranteed to not have the architectural properties required for any environment.

  Posted by: distobj on June 25, 2003 at 06:23 AM

• Constraints
  Yech, sorry about the botched HTML, which I can't seem to edit. That was an attempt to link to http://www.w3.org/TR/ws-arch/

  Posted by: mchampion on June 25, 2003 at 07:13 AM

• Constraints
  Hi Mark (I presume),

  Well, that's the point of my query: if "SOA" is completely unconstrained, it's just another marketing concept / analyst smoke. I thought so at one time, but have come to disagree that it exhibits the "null architectural style" for the reasons described above.

  Let's drill down a bit. I say "REST is a special case of SOA", you say "SOA has a subset of REST's constraints." I think we're agreeing, but with a different "spin." Right? REST is_a SOA at least in my definition of SOA, agree? Or maybe you would assert that REST incorporates new concepts such as "resources" and "representations" and thus is somewhat disjoint?

  If you disagree that REST is SOA-ish, how about the actual HTTP Web as opposed to the REST architectural style?. I say that it's an example of a SOA because it provides the service described by the GET/POST (and sometimes PUT/DEL:ETE) verbs operating on URIs. I'm pretty sure, for example, that it's possible to describe HTTP in WSDL.

  Anyway, the point I was trying to make above (and try to make in the " Web Services Architecture document I work on) is that it's not meaningful to talk about one architectural style / set of constraints being more or less "valuable" in the abstract. What is important is to understand the full range of options one has within the SOA framework for describing and implementing "services " and the implications of various constraints. REST imposes one set of constraints; SOAP, WSDL, various ontology languages, etc. impose (in isolation or in combination) other sets of constraints. I suggest that the best way forward is to more fully understand all this rather than making blanket assertions as to which is most valuable. In many (probably most) cases involving simple retrieval of public information over the Web, such as querying Google or Amazon.com, REST is going to be the best approach (as the SOAP 1.2 Recommendation says clearly). That doesn't make it the best approach for choreographed services involving mission-critical manipulation of confidential information over multiple networks ... but the latter scenario *is* within the domain of SOA.

  Posted by: mchampion on June 25, 2003 at 07:13 AM

• Constraints
  Hey Mike - sorry for going incognito - I thought my name would have been listed. How did you guess it was me? 8-)

  "have come to disagree that it exhibits the "null architectural style" for the reasons described above."

  I wasn't suggesting that SOA *was* the null style, I was only comparing them, effectively saying that SOA is to the null style, as REST is to SOA (i.e. an extension with a superset of architectural properties), so it isn't useful to say that SOA "subsumes" REST any more than it is to say that the null style subsumes SOA.

  " think we're agreeing, but with a different "spin." Right?"

  Yep, definitely.

  "REST is_a SOA at least in my definition of SOA, agree? "

  Not exactly, no. I don't think that's a useful "is_a" semantic in this context, for the reasons I outlined before, and above. I agree that, in other contexts, it might be useful, the same way that a square is a kind of rectangle.

  "Or maybe you would assert that REST incorporates new concepts such as "resources" and "representations" and thus is somewhat disjoint?"

  Not really.

  "If you disagree that REST is SOA-ish, how about the actual HTTP Web as opposed to the REST architectural style?. "

  Same opinion.

  
  I agree that I did a poor job at presenting "valuable"; I tried to qualify it later as valuable in a given environment, but didn't get that across too well. But I agree that it's only useful to evaluate styles in the context of a given environment. So I'd say that n the environment that is the Internet, REST is more valuable than SOA because REST's additional constraints provides properties which are required there.

  Posted by: distobj on June 25, 2003 at 09:38 AM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件网络推广软件网站推广软件下载引擎登陆软件论坛群发软件下载免费版
  论坛群发软件,信息群发软件,群发软件,网络营销软件,网站推广软件引擎登陆软件下载
  网站排名软件网站推广软件信息群发软件博客群发软件论坛群发软件免费下载
  群发软件,信息群发软件,博客群发软件,论坛群发软件,免费下载:群发软件系统
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件博客群发软件网络营销软件网络营销软件
  网站排名软件网站排名软件网站优化软件信息群发软件信息群发软件信息群发软件论坛群发软件网站推广软件网站推广软件博客群发软件博客群发软件

  群发软件群发软件博客群发软件论坛群发软件网络营销软件论坛群发软件
  信息群发软件推广软件网站推广软件网络营销软件网站推广软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件
  网站排名软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  网站推广软件

  群发软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  博客群发软件
  

  Posted by: 3ufblog9 on November 28, 2007 at 09:38 PM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowpower on December 11, 2007 at 09:39 PM

This work is licensed under a Creative Commons License.