Loraine Lawson asked Gartner Vice President Nick Gall, who is credited with first describing Web-oriented architecture (WOA), to give business and IT leaders the bottom line about the WOA versus SOA debate.
Lawson: I read that you coined the term Web-oriented architecture in 2006. Is that correct?
Gall: Actually, I coined it a little earlier. The earliest entry I can find is back in fall of 2005. I presented at a conference to use the term and Whit Andrew - another one of our vice presidents - blogged about my use of the term WOA. So far as the acronym is concerned, I think I'm the first one to start using it, sure, but with Web use these days, you never know.
Lawson: What did it mean to you then and how has the meaning changed?
Gall: I saw there was already a distinct style for Web services emerging at certain Web sites. They were doing Web services very, very differently from how Gartner's clients - semi-large corporations - were doing Web services internally.
SOA was this overall umbrella concept for how you do Web services, and it typically meant one style of Web service, you know, the WS* style, with SOAP and WSDL. I could see already this alternative style, which didn't have one single name. Probably the closest name was REST. I could have, maybe should have, gone with REST, but I already saw from my own research in the area and my presence on the Web that REST raised a lot of hackles and there was a lot of misunderstanding about what REST really meant and so on. I didn't want to really get into that directly.
So, long story short, what WOA meant to me was a more Web-centric style of doing Web services: Simpler, less complex, less vendor-driven, just a catch-all for this different style that was emerging.
That's what it originally meant and, since 2005, what we at Gartner have been doing is trying to add some precision to the term. Okay, great, WOA is this nice fuzzy concept for a way of doing Web services, what does that really mean, get a little more specific, a little more concrete. We came up with a variety of ways of describing WOA that tried to pin it down a bit more. Probably the first thing that people like is a shorthand equation that we use to describe it:
WOA = SOA + REST + WWW
There's a lot of talk about WOA or RESTful style as incompatible with SOA as a concept. We don't take that position. We're very clear at Gartner that WOA is a sub-style of the overall SOA style. Beyond that, it doesn't rate all of the REST constraints, and those are enumerated all over the place. Roy T. Fielding wrote a PhD thesis piece in 2000, which is probably now arguably the most widely read thesis piece in history, since nobody usually reads reviews for those things. He's got it posted on the Web, and it's the founding document defining the REST style of architecture.
So, clearly a Web service that would count as a WOA should aspire to adhere to all the constraints of REST. But it doesn't have to be 100 percent RESTful. That's why we didn't call it REST because already people are saying, "Well, the REST principles, the REST constraints, are really great but we're mere mortals and some of them are pretty hard to achieve now given the current tooling so let's do a relaxed version or simper version of REST or whatever name you want to call it." What we try to get across is, while REST principles and REST constraints are aspirational, and you should try to use them, they're not mandatory to be Web-oriented.
Lawson: I think I can see maybe some of the confusion because REST, you described it as an architecture, correct?
Gall: No, an architectural style.
Lawson: Okay, just wanted to clarify that. Then you have SOA, which is supposed to be an architecture.
Gall: This is all very confusing, so let me tell you how we've addressed the confusion - I'm not saying it's the right way, but it works for us. We described SOA as an architectural style. We did that at about same time, around 2005-2006, we published a note, clarifying Gartner's definition of SOA. That's when we adopted the definition that SOA is an architectural style with essentially five constraints.
There can be many different architectures that qualify as SOA - it's a style, remember - just like many houses can qualify as a Colonial. They can be very different, but as long as they have certain key characteristics, they're a Colonial-style house.
For an architecture to be counted as adhering to the SOA style, it has to be modular, distributable, describable ... we've used lots of words for the third constraint, that is, it must have a written description as well as metadata description of its interface ... and then the two most important ones, the two most difficult to achieve, are sharable, aka reusable, and then last but not least, loosely coupled.
If your architecture has all five of those characteristics - it's modular, distributable, describable, sharable and loosely coupled - you get the SOA stamp of approval. And if it's not-and this is the hard part for some of our clients and others to deal with - if it's missing any one of those constraints in a major way, then you can call it SOA if you want, but it's not. And there are a lot of SOA initiatives out there, unfortunately, in the enterprise realm that use Web services, that use XML, that use SOAP and WDSL, but they're tightly coupled and there's actually no real sharing going on. And yet, they're still called SOA initiatives. And that's fine because we understand clients have to get around a bandwagon, but if you're asking us for our critique of whether you've used the SOA style, we'd have to say, "Well, that particular initiative in your enterprise, while labeled SOA, really isn't."
That's the style for SOA. So we just said, "Look, WOA adds a few more constraints." Any sub-style adds more constraints to an existing architecture, right? So, beyond the five major constraints of SOA, WOA goes a little bit further and says adhere to the constraints of REST as well, and those are perfectly compatible. Every one of the constraints of REST, in essence, gives you guidance for how to do the big five of SOA.
Lawson: When people say that WOA is going to be so much easier and simpler than SOA, as Gartner defines it, then wouldn't you have to say, "No, not really."
Gall: (Agreeing) Not really, no. I don't know what to do about this. The major confusion about this is nine times out of ten SOA is being used really as a code name or shorthand for WS*. It really is. We have a whole presentation on WS* versus WOA.
Now even that's not perfect because - and here's the real rub - this is why there's so much confusion: There is no name for the de facto standard style by which most WS* implementations are done. There really is one (de facto standard style). You can look around and say, "Yeah, the typical way in which WS*, SOAP, WSLD and related technology (is deployed) is roughly this way. You really can put your finger on it - it's not perfect, but you can describe it. But there's no name for it. You can't call it WS* because in theory you can use WS* any way you want. To be hyper-accurate, you can do WS* standard in a RESTful way. Nobody's done it that I know of, but, in theory, it's possible.
I'll give you some hints as to what we're thinking of to call it, and none of these is perfect. Some people claim that it's really good old distributed objects, that the way in which we thought about designing distributed systems under CORBA has carried over and even though we're not using CORBA technologies, the CORBA mindset for how to define service interfaces is pretty much still being used to define interfaces. Some people call it an IDL approach, that if you're using a complex interface description language and it generates code like WSDL does, then it's an IDL style of design. So there's no great name for it.
Look, SOA is this umbrella term with the big constraints. So far there have been two major sub styles. One is this Style X, which we don't have the name for yet but is this distributed object like, IDL-like, style. And the other major style for SOA is WOA style. Of all the approaches to SOA, WOA has demonstrated the high degrees of sharability and loose coupling.
And those really are two competing styles. We could do a comparison about the strengths and weaknesses of the WOA style of SOA and this X Style. We're working on that research right now.
Lawson: As you were talking about it earlier, I thought the X style actually did not conform to SOA?
Gall: Well, you know, that's where things get interesting and religious. There are some who claim that the use of an IDL and the use of more traditional styles of distributable application architecture that evolved from CORBA and PCE and Java, that there is a way to get large sharability and loose coupling from that.
I don't happen to be in that camp. I would claim that you're right - if we really nail down Style X, we'll have to say that the major sweet spot of Style X hampers sharability and loose coupling. Now that's my personal opinion, that's not a Gartner position at all.
There are those in Gartner and outside of Gartner who are well-respected, insightful analysts and practitioners who strongly believe that a traditional IDL distributed object style of architecture can lead to sharability and loose coupling. I haven't seen the evidence for it, I haven't seen anybody present a compelling case of that or any kind of compelling description of how that would work, so I'm skeptical.
Every one that I've seen is brittle and tightly coupled, but the claim is well, they didn't do it right so, I'm still waiting for the other side to put forward its best case for a different non-WOA style of SOA that nonetheless qualifies with the big five SOA constraints.
And the big five, the trivial ones anybody can do and I would claim even half-baked WS* does, is you can make it distributable, you can make it describable - just using WSDL does that - and you can even make it modular to some degree, chunked in some way. Those three have always been doable. It's those last two.
What we're looking for is Style X that can prove it leads to a high degree of sharing/reuse and it also leads to loose coupling, that is, I can make changes to interfaces without breaking existing uses. Show me an intensive WS*, WSDL SOAP-based version of that, that can be changed rapidly without breaking existing interfaces and has high degrees of sharing achieved, and I'm all over it.
Lawson: Is there a bottom line here for CIOs? How can they tell if they should focus on SOA or WOA which, as we have discussed, are kind of the same thing? Or this Style X, if you want. How are they to make sense of all this debate?
Gall: It's pretty straightforward. Focus in on the two key criteria: sharing and loose coupling.
Look at your business and say, "I'm getting into this new approach to services." Everybody kind of agrees services is a good name for this approach and service is all about having the right kind of interface for the services.
There's a lot of religious disagreement about what the best style of interface is - put that aside, that's for the techies to determine. What I, as a CIO or CEO, want to make sure of is whoever is going to be architecting my new systems for me, they better show me, persuade me and have a plausible approach to deploying services that are highly shared. I'm going to look back in a year's time - or whatever your time frame is - and if I haven't seen a large degree of sharing, I would deem that project a failure.
I also want to make sure that I get agility out of it. What agility means is I have business processes and service interfaces and information flows across the interfaces to keep needing new information. I'm going to augment and enrich the data model, add new attributes and capabilities all the time. I don't want to hear back from the IT organization that I have to do a lot of rip and replace with every new interface change because I was promised loosely coupled interfaces, which means I could make changes on one end with little or no ripple effect any place else.
So if my IT organization, my CIO or my CTO, can deliver me a project, an initiative, an approach, that lets me change my IT-based applications and processes more rapidly, with lower costs, and I can have high degrees of shared service, then I win. And you figure out in IT the best way to do that.
So the advice is basically, if a CIO focuses relentlessly on delivering high degrees of this shared service and agile, very changeable and flexible and customizable services, they will get that. Don't assume the technology stack, an ESB, a registry/repository - don't assume that by buying the right technology, you will somehow be any closer to those two goals - loose coupling and sharability. If they simply focus on the technology towards doing that, they will get nothing. It's all about focusing on the architecture required for sharing and the architecture required for flexibility and different ways of filling that gap.