August 24, 2008
Free your mind and go “WOA!”
Steve Bjorg @ 11:24 pm
I’m so happy to see WOA (web-oriented architecture) gaining steam. I’ve been pitching it for a while as an healthier alternative to SOA since it’s simple enough that a student can understand it and build something with it in a weekend. More importantly, the student did so without requiring a massive tool chain! It’s simple… it’s open… and, it’s proven! What is there not to love? 
Recently, Roger Smith of InformationWeek did a piece comparing SOA and WOA. Roger kindly quoted me on the subject:
One IT exec who’s really been doing his Web-oriented architecture homework is Steve Bjorg, co-founder and CTO of MindTouch (…) “By going the WOA-plus-REST route instead of SOA-plus-SOAP, the requirements for extending the application dropped considerably,” Bjorg says. “There is no SOAP processing stack with complicated WSDL documents, an SOA registry, and what have you. Instead, someone can easily create an extension to Deki Wiki using any number of computer languages.”
Another quote on the benefits of WOA in conjunction with MindTouch Deki was provided by Mike Shaver, Mozilla’s Chief Evangelist:
(…) Mike Shaver, offers this explanation of why Mozilla went the WOA route in adopting MindTouch’s Deki Wiki as the future platform for its developer community. “Mozilla has a large volume of developer-relevant information, ranging from traditional documentation and sample code to test suites and bug-tracking data, as well as a number of active discussion forums and RSS streams,” Shaver says. “More than any other wiki system we looked at, Deki Wiki feels designed to be extended as a platform for Web applications. … Whipping up a new extension or integration point is easy enough that even a chief evangelist can do it.”
Joe McKendrick of ZDNet picked up the story as well. Both Roger and Joe tried to keep a balanced point-of-view, which, in my opinion, doesn’t render justice to WOA. So, I felt compelled to continue the discussion here.
One of the reasons that WOA has the edge over SOA is how agile and distributed it is at its core. Imagine not needing to reach cross-group consensus to get something done! Imagine being able to understand the document schema just by looking at it. Imagine being able to interact with a system just by using your browser. In short, imagine it just works… that should make your mind go “WOA!”
WOA may sound too good to be true at first. Those who defend SOA as the “enterprise solution” claim it is the more mature technology… unfortunately, these people are wrong. The rise in popularity of WOA is undoing the noise and bloat that SOA introduced. The truth is WOA existed first! It is what made the web scale to billions of pageviews across a fully decentralized network of heterogenous machines, known was the Internet. A few years later, SOA was introduced as a way to fix something that was never broken. More importantly though, the fix required lots of new tools and technologies, including compilers, registries, libraries, document standards, and so forth. Not coincidentally, the companies who designed and promoted SOA were those who would benefit the most from it… the tool vendors. Heck, if a solution requires an XML appliance to scale, then it’s not part of the solution, it’s part of the problem!
There is another reason I like WOA. And that reason is that it abides to the “Keep It Sincerely Simple” (KISS) design philosophy. Not only does it make my head hurt less–which is always a big plus in my book–it also empowers my team to move faster from concept to trial to product stage. It doesn’t matter how smart or clairvoyant a software architect is… the odds are he or she was wrong when you look back a few years later. That’s just how it is! Faced with this reality, you may decide to design for infinite extensibility or accepted obsolescence. The former path leads to slipped schedules, bloated code, and mountains of impenetrable specifications. The latter ships incrementally, the code fits today’s problem, and the inner workings can be garnered through simple observations. So it should come at no surprise that most start-ups chose the WOA approach… it gives them a competitive edge!
In the end, I predict that SOA will morph into WOA in a few years. Some remnants of the old SOA will remain and a few unlucky chumps will be tasked to maintain it somehow. A situation not unlike that of the lost souls that keep COBOL code running to this day. So please take a moment to reflect on this and do the right thing. And remember…
Free your mind and go “WOA!”
All Posts
All Feeds
August 25th, 2008 at 8:17 am
You do know that WOA is a substyle of SOA, right? And that both SOA and WOA came from Gartner?
August 25th, 2008 at 8:56 am
Yes. Gartner coined the term WOA. However, WOA is neither a subset, nor a substyle–whatever that is–of SOA. The fact that WOA came first should make this abundantly clear. Also, their design principles are so fundamentally opposites that I don’t see what would make you think that… unless, of course, you didn’t get the point of WOA.
August 25th, 2008 at 9:35 am
Nick Gall coined the term WOA and defined it’s meaning. He specifically states that WOA is a substyle of SOA. See Nick’s comments at http://blog.gartner.com/blog/index.php?itemid=400&catid=31
WOA = SOA + WWW + REST
SOA is a style of architecture. WOA is also a style of architecture, starting with SOA principles (which are precious few) and applying the additional constraints of WWW and REST. Thus, it is a substyle (Nick’s terminology, not mine).
What are the specific SOA design principles that you view are opposed to WOA?
August 25th, 2008 at 9:43 am
Why would anyone be so crazed about a stateless protocol based WOA to begin with? I’m not. I actually think weakness like that is the reason why online apps generate only buzz with no meat.
August 25th, 2008 at 11:45 am
Look, you don’t have to agree with me. Gartner got it wrong, imho. That’s ok. They’ve gotten stuff wrong in the past. It doesn’t really matter, unless you care about the details.
SOA is so not WOA, because REST is fundamentally not SOAP, because there is no enterprise message bus, because there is no registry, and so on… You get rid of all these things and you don’t have SOA anymore… All your SOA value propositions have just gone up in smoke. WOA is realizing that nobody ever really needed SOA (although it did sound good while it lasted). And, just as I concluded in the blog post, I believe SOA will save face by jumping on the WOA bandwagon. However, if you turn the clock back a few years, SOA was specifically marketing against the strong points of WOA. Fate has a sense of irony.
Now to answer a really good question: why stateless protocols? Because they scale! The reason the web works at the scale it does, is because of stateless protocols. Every operation is atomic, carries enough semantics to make sense to intermediaries, and is known to be idempotent or not. Very simple principles. If you look at web apps that scale, they don’t carry much state either. The additional benefit is that almost every page can be bookmarked. Apps that rely on viewstate are just plainly broken imo, because they do not follow proper web design principles. It takes a bit of time to get used to doing thing the RESTful way, but once you do, you never look back. Believe me, I spend a lot of years working on stateful protocols and I’m not going back… ever!
August 25th, 2008 at 12:29 pm
I figured that you may be equating SOA with SOAP, ESB, WS-*, registries and other technologies. That’s a common error with lots and lots a material available on the web backing that point . SOA is not WS-*, SOAP or any other technology. SOA does not require an ESB, although many implementations have one. A registry is not required to be SO. An SO architecture may very well be RESTful (lots of blog stuff in the ether about this, including from Anne Thomas Manes and others).
The SOA principles are very, very simple:
* Service consumers and providers, loosely coupled.
* Services are relatively coarse-grained capabilities.
* Service interface stands separately from service implementation.
That’s it. Everything else is someone’s add-on intended to sell something. Or technical details for implementing a particular architecture definition. It is common that SOAP/WS-*, ESBs and registries are used in SO implementations. But the use of those technologies is not required.
What’s odd is that you’re advocating WOA but then apparently disagreeing with the person that defined it in the first place. I say apparently because I think you have the wrong view of what SOA is. SOA isn’t necessarily WOA but WOA, by definition, is a type of SOA.
Excellent points on the stateless question. Another advantage of stateless is that stateless components tend to be more flexible, more readily composed/aggregated than are stateful components.
August 25th, 2008 at 1:20 pm
Rob, in all fairness, I’ve never seen anyone pitch SOA without the WS-*, ESB, and the other heavyweight junk that comes with it.
That aside, what I don’t understand is how the horse can end up in front of the cart. How is it possible that SOA preceded WOA? The web is a network of loosely coupled consumers and producers. Web pages are coarse grained services. And the web interface is certainly distinct from its implementation. Heck, on the web, it’s impossible to ever act on resources, only their representations. So, where in this can SOA claim precedence?
August 25th, 2008 at 1:25 pm
If you feel Gartner is wrong, then might I suggest using a term other than WOA. Gall’s claim on coining the term seems uncontested–so it gets to mean what he says it does.
He’s the one that says WOA = SOA + WWW + REST.
From Gartner blogs:
[quote]
Web Oriented Architecture:
* Long version: WOA is an architectural style that is a substyle of SOA based on the architecture of the WWW with the following additional constraints: globally linked, decentralized, and uniform intermediary processing of application state via self-describing messages.
* Shorthand version: WOA = SOA + WWW + REST
BTW, Since WOA is a substyle of SOA (ie it imposes additional constraints above and beyond those imposed by SOA), you may be interested in our definition of SOA:
Service-Oriented Architecture:
* Long version: An architectural style in which certain discrete functions are packaged into modular, shareable, distributable elements (”services”), which can be invoked by consumers in a loosely coupled manner.
* Shorthand version: SOA = modular + distributable + sharable + loosely coupled
[/quote]
From the service orientated group on Yahoo:
“Ultimately, its up to the industry to decide if a new term is needed or not. If the term “WOA” is needed it will grow in usage (for example, like Ajax), if not, it won’t (for example, like WSA - Web Services Architecture). I coined the term back around September 2005 and first used in publicly around December 2005. Here it is 2 1/2 years later and its still just kind of kicking around, so who knows.”
August 25th, 2008 at 1:44 pm
“I’ve never seen anyone pitch SOA without the WS-*, ESB, and…”
Yeah, product vendors are quite adept at equating SOA with technologies. Bad mojo, IMO. Analysts pick on the vendors for this, Linthicum being one of the more vocal and snippy.
As terms, SOA precedes WOA by a couple years. Gartner is widely credited with first formalizing the SOA definition in early ‘03. Gall coined WOA in late ‘05. For both, many folks rightly point out that they had been following the described principles for a long time, and the terminology was just catching up.
You’re right that the web precedes both and is a good example of both–many folks point to the web as an example WOA and REST. Not so many point to it as an example of SOA but as you note it isn’t much of a leap to do so.
It seems your beef is more with SOAP and other technologies typically associated with SOA. You’re certainly not alone in the SOAP vs REST debate!
August 25th, 2008 at 2:04 pm
I used the term SODA for Service-Oriented Distributed Architecture. Needless to say, it didn’t catch on but the principles were still the same–the fact that SODA sounds kinda lame didn’t help either.
I don’t think it matters what Gartner says. The fact is that “web-oriented architecture” is a throwback to how the web was built in the first place… It’s nothing more and it simply acknowledges the fact that the whole ESB/WS-*/SOAP junk that came later was an utter waste of time, money, and talent, imho.
August 25th, 2008 at 2:07 pm
Looks like we posted at the same time. Yes, I certainly have a beef with SOAP/ESB/… I think it’s too late to disassociate SOA from these heavy technologies. If that’s a fight you’re willing to stand up for, then my hat goes off to you! I don’t think I have the energy to do so.
August 25th, 2008 at 2:21 pm
“I don’t think it matters what Gartner says.”
Hmm. Interesting position! Many people pay a lot of attention to what Gartner says (and Burton Group, and ZapThink, etc.). It is a throwback and is intended to place the SOA focus on the web and REST, away from SOAP, et al.
“…. I think it’s too late to disassociate SOA from these heavy technologies”
I think so to. I argue more often for abandoning SOA as a term altogether! Too overloaded, too nebulous. But unsurprisingly, that has zero traction.
I don’t think the SOAP, ESB, etc. are a complete waste of time. They have their place. The problem is too many people blindly adopt them in pursuit of SOA, without ever doing the analysis and the A part first. Just blind technology adoption with no sense of guiding principles at all, let alone SO principles.
Oh, well.
August 25th, 2008 at 2:41 pm
Analysts tend to synthesize lots of information without really understanding it–how could they not cut corners? So, in general, I don’t pay too much attention on their final product. Even when I tell them directly that something is “ice cream,” when I read their report later on it may say “body wash.” How? Why? Not the slightest idea… Then again, maybe it’s my communication skills that fail…
August 25th, 2008 at 4:53 pm
Ah, I almost forgot. An important distinction for those working with REST is that the pivot point is data, not behavior. Services are generally thought of as code, while resources are data with transition semantics. The lines can get a bit blurry if you don’t pay attention, but then again the devil is always in the detail.
August 25th, 2008 at 10:25 pm
I can’t possibly read all this tonight, but I wanted to include a post from Dr. Dobbs Journal, which seems to have set off this whole WOA meme around MindTouch: http://www.ddj.com/architect/207600577
For the record, I appreciate Gartner for having coined the term. The gentleman in question may have been a bit off the mark with respect to explaining the concept; specifically relative to SOA, but he surely has hit on an important concept that will shape software development for many years to come. It is clear the MindTouch concept of WOA is indeed the concept he was attempting to communicate given the RESTful nature and benefits yielded. I think the gentleman might not have had the historical perspective or, no offense, the technical acumen to fully appreciate the association to SOA.
August 26th, 2008 at 8:35 am
Thanks for the link Aaron.
It is peculiar that you’re questioning the credentials of Gall. You may want to investigate his background a bit further before reaching any conclusions.
Perhaps a review of how we each define SOA is in order. In an earlier comment, I listed the basic SOA principles that I believe are the core of SOA. These are more or less directly from the ‘03 Gartner paper titled “Introduction to Service-Oriented Architecture” (this is generally credited as the first formal description of SOA).
SOA is a style of architecture. As such, it is not a new, discrete level that supplants other architectures or fits somewhere in between. SO principles are applied to architectures that we’ve be creating for a long, long time. These include business architectures, enterprise architectures, integration architectures, application architectures, etc.
Some, such as Anne Thomas Manes, say SOA is an enterprise level notion only. Undoubtedly that’s where the most potential bang for the buck comes from. But it’s also the reason why many rail against SOA–because they *assume* that it is only applicable at the enterprise level. This is incorrect. SOA doesn’t require boiling the ocean. SO principles can be used “in the small” too, much like Steve is arguing for WOA. Indeed, Gartner originally described SOA as a style of application architecture. Start small and grow out is as applicable to SOA as any other approach.
SOA is definitely an overloaded term, with various parties, um, “adopting” it for their own purposes. Product vendors seem to be the main offenders in this regard. To be fair, there are some vendors that simply present their wares as candidates for implementing an SOA but some analysts and potential clients make the incorrect leap that the vendor is saying “this is required for SOA.” As many have said, SOA is something you do, not something you buy.
Even with all the material now available, many seem to think that SOA means SOAP and ESBs. This is wholly inaccurate. Even when this view isn’t present, other assumptions tend to skew what SOA really is. For example, Steve Vinoski at IONA had an article in IEEE Internet Computing called “REST Eye for the SOA Guy.” In the article he mentions facilities that SOA implementations “usually* depend on: registries, repositories, service definition languages and service platforms.
It is true that many SOA implementations use these things. But the mistake many seem to make is assuming that these are required elements. They are not. They are components that may or may not be helpful, depending on your needs and goals.
Vinoski also wrote:
“SOA proponents regard interfaces and contracts as being critical to service definitions: different services have different interfaces—a normal and desirable characteristic of software systems, whether they’re distributed or not. REST proponents, on the other hand, stand by the uniform interface constraint.”
This is indicative of another common problem–attributing principles to SOA that belong elsewhere. The “different services have different interfaces” view is not an SOA notion. It is generally a SOAP notion (though SOAP could be used to create uniform interfaces as well, but that’s a different topic). The SOA constraint is that the service interface stands separately from the service implementation. Whether the interfaces are uniform or vary from service to service is not an SOA constraint–SOA principles are mum on that topic. The uniform interface constraint of REST is not anathema to SOA. It is a refinement.
There are probably other aspects of SOA that we could explore, but this comment is more than long enough! I look forward to reading your viewpoints.
August 27th, 2008 at 10:27 am
If you strip SOAP/ESB/repositories/etc. from SOA, how is it different from deamon processes on Linux? The notion of writing “modular + distributable + sharable + loosely coupled” is decades old. The guys at ZapThink are making this same claim that SOA is the way to decompose problems using these principles. I say that’s not enough to be useful!
Formalisms about loosely-coupled systems have been around since the 80s (just search for Communicating Sequential Processes, Calculus of Communicating Systems, π-calculus, and others…). So, if SOA only stands for these principles, then it brings nothing new to the table and thus is redundant (i.e. devoid of information in Shannon-speak), imo.
Here is why: all known programming idioms can be mapped to process calculi. Process calculus is modular, distributable, shareable, and loosely coupled by design. Hence process calculus is SOA. Since object-oriented programming is a programming idiom that can be mapped to a process calculus and process calculus is SOA, then it goes that object-oriented programming is also a form of SOA… How does that help anybody?
The reason there is value in REST is specifically because it defines constraints. It is what makes it a useful concept to talk about and debate. REST puts resources in the center and with limited verbs/methods to interact with the resources. Doing resource-oriented design is pretty darn hard when you start, because it requires you to shift your point-of-view.
WOA, in my opinion, is about following the principles that have worked on the web while minimizing new concepts that are not needed. HTTP is a fantastic protocol for many use cases, but for pub-sub XMPP is a better choice. Regardless if you use HTTP or XMPP, you still need to make a decision if you want to use REST or RPC. Roy Fielding makes a good case for using the REST architectural style for loosely coupled systems (which are by definition modular, shareable, and distributable; so these terms seem to be superfluous as well). Then you have the question of using JSON or XML. You may pick one or pick XML and have an on-demand mapping to JSON (my preference is for XML because of XML namespaces; they may be tedious, but they are absolutely necessary). Another useful tool in the WOA toolbox is ATOM/RSS which is a great format for packaging entities or lists of entities into known structures with a pre-defined mechanism for extensibility. And the list goes on about specific concepts that make WOA interesting and useful.
If SOA were about contracts between endpoints, enveloped messages, repositories for service discovery, and service buses for message delivery, I would see value in it. I may not agree with it, but I see value because it contains information (see Shannon). If it’s just a “concept” that’s almost as old as computing itself, I really don’t see the point…
Maybe I’ve been an engineer for too long! It wouldn’t be the first time that someone accuses me of that!
August 27th, 2008 at 1:51 pm
You’re absolutely right that SOA is completely derivative. It is indeed an amalgam of techniques and principles from the past. Unfortunately Gall’s quicky description of WOA and SOA left out the key parts of SOA: coarse-grained capability by a provider; accessed via a separately standing interface(s) by consumers.
Even those points aren’t new. Integration practitioners have long understood the value of separating the interface from the underlying implementation. SOA just synthesizes the well-known practices–and WOA refines it even further by saying thou shalt be RESTful.
“If you strip SOAP/ESB/repositories/etc. from SOA, how is it different from deamon processes on Linux?”
A daemon process might very well be a “proper” SOA service. To the extent that a single process has an architecture, then that architecture could rightly be considered SO. As long as that process has an explicit, separately standing interface that is independent of the implementation, then it fits within the SOA principles. SOA isn’t about technologies nor about how a service is implemented. It is about architecture.
Most OO components would not qualify as SOA services because the interface is not independent of the implementation. The relative failure of CORBA was due at least in part because the interface and the implementation were intertwined, at least in common practice.
“The reason there is value in REST is specifically because it defines constraints.”
As does SOA. One problem we face is there isn’t a widely agreed upon set of constraints for SOA. And that’s where the arguments arise. Plus people have incorrectly tagged SOA as a technology, associated with SOAP and ESBs.
There aren’t (many) arguments about the REST constraints because a seminal paper exists defining them. Well there are undoubtedly different interpretations and there are arguments about specific intent but I’ve not seen anyone say “Fielding is wrong, REST means this.”
SOA is ambiguous because of misunderstanding, misuse and misappropriation, having been co-opted by various entities to suit their own needs. WOA as a term may be heading that way too as I’ve seen many articles defining WOA in ways that are different from the original definition by Gall/Gartner (like material from MindTouch!).
“If SOA were about contracts between endpoints, enveloped messages, repositories for service discovery, and service buses for message delivery,”
SOA is about the contract between provider and consumer. As is WOA. SOAP has one style of contract. WOA/REST, another. SOA does not prescribe the nature of the contract–only that one should explicitly exist.
Enveloping messages is an implementation decision. POX. CSVs. EDI. All are valid as messages–as long as the provider and consumer agree to the format. From an SO perspective, the format of the data, and how it is exchanged between consumer and provider, is utterly unimportant. From an info architecture or MDM viewpoint, the format is very important.
Repositories can be useful in WOA too, correct?
A service bus is never required by SOA. The use of an intermediary (which can be useful in WOA too, correct?) is driven by principles/constraints other than SO principles/constraints. Point-to-point interaction is just as valid as intermediated interaction.
Much like many of the discussions about SOA, WOA discussions drill down quickly to the technologies that can be used. HTTP vs. XMPP. XML vs. JSON. ATOM vs. RSS. Important things to consider to be sure, but these aren’t the things that make WOA WOA. Too much focus on the potential implementation technologies can lead to errant conclusions about SOA and WOA.
August 28th, 2008 at 4:07 pm
“Too much focus on the potential implementation technologies can lead to errant conclusions about SOA and WOA.” That might be true, but unless someone gives a concrete shape to something–like Fielding did with REST–it’s hard to objectively compare approaches. If we can’t compare them, then we get stuck in weak arguments which benefit nobody. That said, I’ve found this exchange most interesting and hope so have others. Thanks Rob for so patiently sharing your position!
To clarify the OO comment, you can implement an OOPS using a service that accepts as request a URI to a resource, an operation name, and optional parameters to vary the operation. The service then either acts upon the request or delegates it to another service–it’s parent. This would be a simplistic mapping of behavioral inheritance to SOA. Polymorphism is achieved by first asking the resource that is being acted upon for a service that can accept operational requests. All very tedious and time consuming, but perfectly legit, and the end result would an OOPS that’s SOA…
August 29th, 2008 at 7:40 am
REST is definitely more prescriptive in its constraints. SOA principles are more abstract, which can, as you point out, lead to confusion. To beat a dead horse, an SOA can be RESTful. Not all SOA systems are RESTful and not all RESTful systems are SOA, but
Good clarification on OO. That’s exactly what my intended meaning was–OO components can fit into an SOA world. It’s just that most, in their current form, would not due to interface/implementation intertwining.
Interesting thought on the inheritance.
“The service then either acts upon the request or delegates it to another service–it’s parent. This would be a simplistic mapping of behavioral inheritance to SOA.”
It would seem that this could be approached in two ways: as an explicit part of the service contract or as an implementation detail. In the former, consumers would be alerted to the relationship of one service to another (e.g. subclass of class X). In the latter, how the service gets its work done–all by itself or with the help of friends and family–would be a behind the scenes detail. Pros and cons to each approach I suppose. Interesting idea though!
August 29th, 2008 at 8:36 am
[...] require an ESB, registry, and XML applicance, or any other tool…. SOA is not SOAP.” Steve Bjorg elaborated on his quotes in the original article and also predicts that SOA will very much be a legacy [...]
August 30th, 2008 at 8:56 am
One last thought:
“but unless someone gives a concrete shape to something–like Fielding did with REST–it’s hard to objectively compare approaches.”
The architect is the one that is supposed to give concrete shape to any approach. SOA was never intended to hand you an architecture. Fielding doesn’t hand us one either. As architectural styles, they simply provide guiding principles. WOA is a bit more prescriptive but there is still work to be done by the architect. In either case, the architect is responsible for defining the components and their relationships. It is the “A” in SOA and WOA that we cannot lose sight of, along with being business driven, not technology driven.
August 31st, 2008 at 6:33 am
There are “architectures” and “architectural styles.” I don’t think they are the same, but let’s not split hairs.
in the case of SOA, there is way too much rope for an architect to hang himself with, because it is so little prescriptive. If all it is meant to do define is “loosely coupled systems” then it doesn’t deserve the term “architecture” in its name; or we need to introduce “abstraction oriented architecture” as a replacement for encapsulation and “indirect execution oriented architecture” for polymorphism.
To me, it feels like clinging onto the term SOA after all its meat has been scooped out and discarded. Just say “loosely coupled systems.” It’s not new.. it’s not sexy… but it’s accurate and doesn’t strut with a veil of self-importance.
August 31st, 2008 at 11:06 am
“There are “architectures” and “architectural styles.” I don’t think they are the same, ”
We agree. They are not the same. SOA is not an architecture, IMO. It is a style that is used when defining a BA, an EA, an AA, whatever. REST is a style too.
” SOA, there is way too much rope for an architect to hang himself with..”
This would seem to assume that only SO principles are needed to define a real/practical architecture. IMO, a real-world archictecture will incorporate principles from multiple sources.
IMO, SOA is not a new level of archictecture and does not stand alone. SO principles are to be applied to a business architecture, an enterprise architecture, an integration architecture, an application architecture, etc. Those architectures will/should incorporate more than just SO principles.
“If all it is meant to do define is “loosely coupled systems””
You’ve missed some of the constraints/principles. Loosely coupled is not the only characteristic. Have you had an opportunity to read through the papers on SOA from Gartner? “Introduction to Service-Oriented Architecture” and “Advanced SOA for Advanced Enterprise Projects” are a couple of the titles. They are available on the web.
Another definition of SOA is available from Steve Jones, which is SO applied at the business architecture level. His book “Enterprise SOA Adoption Strategies” is available free on the web at InfoQ.
Even so, your point is well taken. SO principles are pretty spartan. There is no guidance on what is the proper level of service granularity. No guidance on how consumers and producers interact (they just do, somehow, and in a loosely coupled way). No guidance on service discovery, just that it “should be addressed.” No guidance on how many different service interfaces is a reasonable number.
In this manner, SO principles are somewhat like wood-working tools. In the hands of skilled wood-worker, some awesome stuff can result. In the wrong hands, or in the hands of a person more comfortable working with metals, yikes. (Possilbly a very poor analogy on my part!)
September 4th, 2008 at 7:49 pm
[...] Bjorg elaborated on his quotes in the original article and also predicts that SOA will very much be a legacy [...]
October 6th, 2008 at 6:34 am
Steve,
This is an interesting subject which I’ve been following for a while now and I’d like to add my .02. First SOA is overused and overloaded however I agree with Rob Earnon on what it really is, not just loose coupling but not an ESB and a Registry. I quote you:
“If it’s just a “concept” that’s almost as old as computing itself, I really don’t see the point…”
What the term SOA does is it brings to the forefront that concept that is as old as computing which everyone does so poorly which is why it is so deserving of center stage.
Your viewpoints and the viewpoints of others (http://www.infoq.com/articles/separation-of-concerns) on REST I believe are perfectly valid and a good thing for the web but only for the web and they have little or no business within the walls of an enterprise, let me explain:
Here is a quote from your interview with DDJ on WOA:
“Even internally, Deki Wiki delegates parts of its functionality to REST web-services. This enables these parts to be later moved to other machines or shared across multiple instances of the platform without requiring a single line of code to be changed.”
The argument for REST from you and others seems to be that it has a loose coupling with the physical implementation (machine interface) by genericizing the set of verbs and I quote you again:
“REST puts resources in the center and with limited verbs/methods to interact with the resources”
I do not disagree the simpler the set of verbs the easier it is to move that implementation from point A to point B; however, a more generic interface forces the semantics from the verb to the data (resources). This means that each implementation must be aware of the meaning of each message and the more you genericize the interface the more you couple implementations together via the data. So all you’ve done is traded one form of coupling for another.
So I think the REST and WOA argument confuse the argument of loose coupling of interfaces with loose coupling of content and semantics. The first is in my opinion a programmers problem (i.e. I don’t want to affect any clients connecting by having to change the (verb) calling syntax) whilst the second is an enterprise problem (combining functionality in an implementation forces coupling between two disparate concerns which in turn may limit flexibility). I work in one of the worlds largest enterprises and I can tell you without a doubt the more difficult and complex problem is the one about semantic coupling.
I believe advocating REST and WOA in an enterprise environment is tantamount to advocating monolithic implementations with comingled concerns (this is a bit drastic and can be tempered with good software engineering practice; however the best intentions …. you know the rest).
The argument has two sides and I believe REST and WOA focus largely on the technology side and woefully ignore the business and semantic side. I may be wrong due to a limited understanding of REST; however I am well versed in RDF and OWL so I am familiar with Resource orientation. Either way I am interested in reading your viewpoint.
October 6th, 2008 at 6:38 am
Correction:
” I work in one of the worlds largest enterprises and I can tell you without a doubt the more difficult and complex problem is the one about semantic coupling.”
Should be:
I work in one of the worlds largest enterprises and I can tell you without a doubt the more difficult and complex problem is the one about coupling concerns.
October 8th, 2008 at 4:48 pm
Manny,
Thanks for your comment. You raise good points, let me share my perspective on them.
You’re correct with your criticism about simpler verbs, but it seems you got something twisted around concerning the REST verbs: REST has *MORE* verbs than SOAP. The reason SOAP is so awful, is because it relies on a single verb: POST, which is the weakest of the HTTP verbs as it has no semantic constraints. Hence, in SOAP, the semantics of the operation must be embedded into the message. Thus, intermediaries are unable to assist unless you invest into an expensive XML appliance. It’s simply a bad design and, like you pointed out, it’s because the interface is too generic.
REST has a more precise/stronger interface and it is this property that allows the web to scale. GET/PUT/DELETE verbs have well defined semantics that can be relied upon by intermediaries. These known semantics is what enables caching in proxies and thus leads to a more scalable architecture. Another key property is the lack of state between messages, that is a stateless protocol. Of course, this doesn’t mean that using REST makes your application scalable. It just means you didn’t paint yourself in a corner!
Now, concerning your statement of “a more generic interface forces the semantics from the verb to the data,” I’ll assume you meant this by mapping method names, which are very diverse, to few REST verbs, and by data, you meant the message itself. The important thing to realize is that end-points (i.e. resources) have globally unique names and their behavior can be equally as diverse as method names. Thus the expressive power didn’t shift from verbs to messages, but from method names to resources. The message itself does not require further entanglement. If anything, it is desirable to keep the message as simple and generic as possible. For instance, ATOM feeds come to mind, which are used for news consumption, as well as database queries.
Here is where the beauty of REST lies, an intermediary can make assumptions about the communication between the client and the server and short-circuit it if needed. An observer–for example a developer–can observe the contents of the communication and make assumptions about its intent (e.g. Atom entries being published), yet what really happens depends on the effective end-point (i.e. resource) that the client is interacting with. These kind of shared semantics are extremely powerful. With a small leap of the imagination, one can see similarities to the workings of DNA: simple building blocks (base pairs), many fragments (RNA), infinite end-points (receptors). This is of course just an illustrative example. I wouldn’t want to claim that REST is as beautiful and elegant as DNA! Roy is a really smart guy, but…
Finally, should REST over HTTP be used in the enterprise? Absolutely! It has all the desired properties:
1) It scales globally (i.e. lower cost scaling).
2) It allows local decision making (i.e. innovation).
3) It provides the “rules of engagement” for co-mingling and interop (i.e. content-negotiation)
It’s worth the effort to look at the world through the REST lens. You already have a leg up on most with your familiarity of OWL and RDF. These are representations, like ATOM, which carry their own semantics. Now, try to shift your perspective from functional end-points (SOAP) to resource end-points (REST). You may not get their in one step, just like many are struggling with object-orientation, but I sincerely belief it will broaden your mind and perception of how behavior and data can be better distributed and decoupled for very large systems.
October 16th, 2008 at 12:41 pm
Steve,
Thank you for your feedback. I will have to defer further commentary until I finish digesting Roy’s dissertation. I believe I am refering to verbs deifferently and perhaps incorrectly. To align my understanding when you say verbs you are speaking of the set of verbs defined by the SOAP and REST protocols correct?
If so then my misunderstanding may be due to a bad inference chain :). Let me read up on Roy and get back to you. Thanks again.
October 16th, 2008 at 2:30 pm
I have three more comments.
If as you state the expressive shifted from methods names to resources and resources are part of the service interface and not the service implementation then no negative coupling can be introduced into the REST Service as desired. This is a good thing.
A richer set of verbs in the protocol as you’ve pointed out allows a more robust understanding of the operation the protocol will carry out. Another good thing in my opinion.
It sounds like REST is a better protocol than SOAP. What confuses me is the discussion about SOA. From everything you’ve defined I would classify REST as a better protocol with which to achieve a SOA; however, SOA != SOAP and SOA != REST and SOA != TCP/IP and SOA != AMQP and SOA != MQ and SOA != RTMP or any protocol for that matter.
Given what you’ve stated I will look into REST more deeply; however I think I understand what you are telling me if the semantics shifted from the method names to the resources and the resources are not tightly coupled to the implementation then that is good. I will have to gain a better understanding what that buys me with respect to protocol. After all the protocol is about the way I connect to and make a call to a service. However if REST allows the Semantics of the Resources to be more machine discoverable (not human developers) i.e. a machine can more easily infer what a resource is, then again extra points for REST. If this is not the case then there is still hardwiring to be done by the developer, albeit REST might make it easier.
In summary I think REST may be a good protocol with which to achieve a Service Oriented Architecture. Recently I had a stakeholder ask me why are we implementing an SOA, WOA is a better alternative. This begs the question what is WOA? How did the acronym WOA come up? How is WOA different than SOA?
October 21st, 2008 at 4:19 pm
Manny,
Thank you for your follow-up questions. I really like the bit about [quote]however, SOA != SOAP and SOA != REST and SOA != TCP/IP and SOA != AMQP and SOA != MQ and SOA != RTMP or any protocol for that matter.[/quote]. Indeed, I would say “SOA = ?!?” and hence it’s != to anything else…
Concretely, though, it appears that SOA has lost most of broadly understood meaning (SOAP, ESB, …), even if that meaning was never correct, and has been reduced to loosely coupled design, which isn’t novel. Neither is separation of interface from implementation. All protocols begin their live as a specification, which is the interface, and only some have a reference implementation. Implementation that tried to hide this, such as CORBA and .NET Remoting, have generally failed, although, Erlang appears to be a notable exception for now.
I’d like to clarify two things. First, that in REST, resources are the service. In other words, there is no notion of a “service” in REST. Implementation-wise, one may use service-oriented building blocks, but that’s just an implementation choice. With the proper framework, COBOL would be just as good for doing WOA as would Java or C#. Second, REST is not a protocol: it’s an architectural style. Meaning it’s a way to decompose a problem along prescribed constraints. The end goal being that the finished system exhibits desirable properties such as scalability and ability to evolve.
Roy Fielding recently did a great post on the many misunderstandings of REST. I highly recommend it as read:
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Finally, with regard to WOA vs. REST: WOA is an application of REST principles using the HTTP protocol and web-formats, such as XML/HTML/JSON. So, I agree with WOA = REST + http://WWW. I just don’t agree with SOA is related to WOA, because REST is so different from SOA and is an integral part of WOA. (More to follow on this point in a future blog post!)
October 24th, 2008 at 9:41 am
Steve,
I agree, loosely coupled design nor separation of interface from implementation are novel concepts. Any software engineer worth the title has understood this for a long time. Herein lies the problem most so called SE merely use the buzzwords or do not even follow the concepts. If SOA does anything it is to reinforce the importance of these concepts perhaps in a new shiny way for all those who are sitting by their monoliths wondering why they take so long to produce new functionality and respond to their stakeholders.
I think you get too hung up on SOA == {ESB, SOAP, …}. I’m adjusting my upper SOA ontology and adding a new triple sameAs(SOA,WOA).
Thanks for the discussion and the links.
October 29th, 2008 at 2:15 pm
Urgh, this is giving me an ulcer. No, please stop creating a bisimulation relationship between SOA and WOA. Why bother defining terms if they have no meaning?!?