The SOA with reach: Web-Oriented Architecture

The SOA with reach: Web-Oriented Architecture

Summary: I recently had the pleasure of watching Nick Garr give his take on something he describes as Web-Oriented Architecture or WOA. There are a lot of ways to view Service-Oriented Architecture (SOA) and this particular lightweight vision of SOA is well worth watching. This is because WOA is more of an emerging best practice from the battle-hardened folks in the field than it is from ivory tower architects or the analyst group notebook, which always lends an idea more credence in my book.

SHARE:
TOPICS: Tech Industry
14

I recently had the pleasure of watching Nick Gall give his take on something he describes as Web-Oriented Architecture or WOA.  There are a lot of ways to view Service-Oriented Architecture (SOA) and this particular lightweight version of SOA is well worth watching.  This is because WOA is more of an emerging best practice from the battle-hardened folks building software on the Web than it is from ivory tower architects or the analyst group notebook. This always lends an idea more credence in my book.

This is all making folks fall back to simpler and more straightforward methods that just work.Essentially, WOA describes a core set of Web protocols like HTTP and plain XML as the most dynamic, scalable, and interoperable Web service approach.  The only real difference between traditional SOA and the concept of WOA is that WOA advocates REST, an increasingly popular, powerful, and simple method of leveraging HTTP as a Web service in its own right (and carefully devised by the co-creator of HTTP, Roy Fielding.)

An important concept in Web 2.0 is that Web-based software should offers its functionality not only via the browser, but also as open Web services so that it can be mashed up in new and unintended ways.  This takes software from being a mere application and turns it into a true platform.  A great many new online software applications are actually doing this now, even if it's just one-way via RSS.  And it's not just online consumer applications, major players like Salesforce are encouraging API use of their products on the Web and are even creating public directories, like Salesforce's AppExchange or Yahoo!'s new application Gallery, to make sure folks are aware of, and can find, the resulting third-party mashups.

The theory of sharing your application's pieces as Web services is that it allows your functionality and data to be useful to others in innovative ways you won't be able to predict ahead of time. People can take your best features and combine them with others, allowing you to become part of a larger supply chain instead of being limited to your individual delivery channel.  It's an interesting value proposition that the growing mashosphere seems to be validating.  And we shouldn't forget that SOA encourages this exact same view by liberating the silos of data and software in an organization as Web services, making it possible to share and reuse them anywhere inside an organization in a loosely-coupled and interoperable way.

WOA itself is a reflection of the classic Reach vs. Rich argument, in that richness is an outcome of robustness and complexity but cuts down how much reach you have to others, particularly in heterogenous communities.  And the modern SOA technologies and architectures have indeed become a near-morass of complex standards, protocols, and products.  The result is that the present list of WS-* standards is now nearly incomprehensible by a mere mortal. 

SOAP, the most common "true" Web service standard also has mandatory dependency system that can be problematic.  This is something I refer to as the "tyranny of SOAP's mustUnderstand flag".  And it makes it so that if you don't have the exact same set of standards in your Web services stack, you can't even talk to a Web service at all.  This is actually terminal to interoperability, instead of being the intended enabler. 

This is all making people fall back to simpler and more straightforward methods that just work, and hide the protocol complexity in the application state.  As far as REST and WOA are concerned, you don't need anything more complex than HTTP, one of the most scalable, proven, and widespread protocols on the planet, along with HTTP's verbs: GET, POST, PUT, DELETE.  Add some plain old XML to hold your data and state to top it all off.

 

 Web-Oriented Architecture

WOA itself is a new term out of the Gartner acronymizer but it's an important aspect of something I usually call Enterprise Web 2.0, which on the technical side strongly prefers the simplest, most open, Web-scale approaches.  An important point however is that SOA is not necessarily about Web services at all, but is actually much more about service-orientation concepts like loose coupling and abstraction (see Thomas Erl's terrific eight principles of service-orientation for a complete list).  This means you can do a great SOA with CORBA or even classic sockets.  As long as you follow the basic rules of service-orientation.

And, before anyone gets hot under the collar and writes about how REST doesn't handle enterprise issues like two-phase commit, messaging, asynchronicity, etc, I'll also go on record to state that WOA is definitely not the hammer for every job.  Certain applications, particularly in the high-end of the enterprise, just flat-out require the more sophisticated portions of the SOA stack (and don't forget, WOA is a subset of SOA and is not disjoint, as long as you follow the principles of SO).  For the vast majority of uses, I'll argue that WOA is the most interoperable, easiest to implement, and most highly scalable technique for building great, open Web services that anyone can use.

Forget the acronym for the moment, what would you prefer to use a Web services with?

Topic: Tech Industry

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

14 comments
Log in or register to join the discussion
  • SOAP vs. REST; not just about the protocol.

    The choice whether to use REST or SOAP is not just about the protocol, it's also about development tools.

    REST is simpler than SOAP, but in many development environments creating or consuming SOAP web services is just a matter of a few mouse clicks, while if you want to use REST, you have to write much of the code yourself.

    Personally I prefer SOAP because the tools make it easy.
    If I had to write all the SOAP code myself, I'd use REST.
    Gert Van Waelvelde
    • Actually, REST tool support is getting quite good.

      Hi Gert,

      Thanks for replying but I'm happy to report that REST tool support is getting very good and will probably equal and might even exceed SOAP support in the next year or two.

      Consider sqlREST (http://sqlrest.sourceforge.net/) alone, which turns a relational database into a full RESTfully navigable Web service. Even Microsoft's WFC (aka Indigo), which represents the future of Microsoft's Web service strategy, includes explicit support for REST (http://tinyurl.com/eb7jy).

      So, while I agree that things like Visual Studio's WS Wizards and Next, Next, Next, Done abilities to create Web services are very convenient, they will almost certainly have a hard time competing even in the near future with the large scale community interest and active support of REST.

      Best,

      Dion
      dhinchcliffe
    • I suspect ...

      I suspect that by "had to write all the SOAP code myself" you're referring to building your app the same way you'd build it with SOAP. REST is about building your app differently, and in doing so, learning to appreciate how that code you're talking about isn't necessary.
      distobj
  • WOA = REST = AoWWW: A very different approach to SOA

    Dion, Thanks for plugging Web-Oriented Architecture. You did a great job summarizing it. Let me add two clarifications.

    First, speaking for myself (not Gartner), WOA is nothing more than a term for describing the Web's essential architectural principles. These are roughly the same principles that Roy refers to as REST and the W3C refers to as "The Architecture of the WWW Vol 1" (AoWWW). The only reason for coining a new term, instead of just using REST or AoWWW, is that REST has too much baggage and AoWWW makes people think that you are ONLY talking about interactions between users and systems, not system to system.

    Second, while I wholeheartedly agree that WOA is a subset of SOA, the problem is that most explications of SOA principles are either wrong or very misleading. Take for example Thomas Erl's common principles of service-orientation, which you cite. His "Services Are Composable" principle is the motherhood-and-apple-pie of SOA. Yet, his illustration of composability is to begin with resource-specific operations (UpdateAccount, UpdateHistory, and UpdateLogs) and then "compose them" into UpdateEverything. It is precisely such resource-specific operations that lead to the "impedance mismatches" you discuss elsewhere in your blog. This is the exact opposite of Web, REST, and WOA best practice, which is to begin with as generic an operation as possible (say UpdateAnything <grin>) and then apply it to as many diverse resources as possible.

    So, yes, SOA and WOA are completely consistent at the "conceptual principles" level (ie the names of the principles and their value). But when it comes to the next level of detail, most "traditional" SOA practice follows in the failed footsteps of common "distributed object" approaches (eg object-specific methods), while WOA follows in the successful footsteps of the Web.
    nickgall
  • Enterprise RSS as an enabler for WOA?

    Dion - With the Enterprise RSS Day of Action just around the corner (24th April - see http://enterpriserssdayofaction.wikispaces.com/) I would be really interested to hear more about how RSS and ATOM will play a part in WOA, particulary what is needed to enable it within organizations.
    chieftech
  • RE: The SOA with reach: Web-Oriented Architecture

    Since WOA is all about REST, the real question is: to REST or not to REST?

    So far, REST is not very much attuned to real business operations support. Therefor, for real business applications (i.e. where the money is)we continue to need SOA(P).
    See also: http://www.iks.inf.ethz.ch/education/ss07/ws_soa/slides/SOAPvsREST_ETH.pdf for a nice comparison between SOAP and REST.
    Zeeprest
  • RE: The SOA with reach: Web-Oriented Architecture

    Hi Dion,

    just to let you know that you are in my presentation used in this blog (just opened):

    http://blogs.oracle.com/woa

    I added an important element (imho) to your vision: a datagrid at the server side in order to scale the unpredictable "network effects".

    I'm following you on twitter. Thanks again for sharing your knowledge on this important topic.
    EmilianoPecis
  • RE: The SOA with reach: Web-Oriented Architecture

    <a href="http://www.itouchcopy.net">itouch Copy</a> can de divided into three conditions: first, transfer itouch to computer to backup files from iTouch
    jojohoho2321332
  • RE: The SOA with reach: Web-Oriented Architecture

    its great but annoying in a way that doesnt help me at all and wtf if the wos thing anyway i never know its annoyin but good for ur brain EAT MOR CHIKIN!
    what a wall!~!!~!
  • RE: The SOA with reach: Web-Oriented Architecture

    <a href= "http://www.evdekorasyon.biz/" title="ev dekorasyonu, mobilya dekorasyonu, mutfak dekorasyon, fiyatlar?, " target="_blank">ev dekorasyon</a> <a href= "http://www.filmizlesene.org/" title="film izle, film izlesene,online film,full film " target="_blank">film izle</a>
    delta0x
  • RE: The SOA with reach: Web-Oriented Architecture

    Although the discussion on Service-Oriented Architecture given by the author is not so extensive, I was able to pick up some important pointers to add to my knowledge on <a href="http://www.webbizdesigns.com/web-architecture">web application architecture</a> and <a href="http://www.webbizdesigns.com/web-architecture">website architecture</a>. Additionally, I will always remember that Service-Oriented Architecture itself is a reflection of the classic reach vs. rich argument, in that richness is an outcome of robustness and complexity but cuts down how much reach you have to others, particularly in heterogeneous communities.
    marcusdane
  • RE: The SOA with reach: Web-Oriented Architecture

    Although the discussion on Service-Oriented Architecture given by the author is not so extensive, I was able to pick up some important pointers to add to my knowledge on <a href="http://www.webbizdesigns.com/web-architecture">web application architecture</a> and <a href="http://www.webbizdesigns.com/web-architecture">website architecture</a>. Additionally, I will always remember that Service-Oriented Architecture itself is a reflection of the classic reach vs. rich argument, in that richness is an outcome of robustness and complexity but cuts down how much reach you have to others, particularly in heterogeneous communities.
    marcusdane
  • RE: The SOA with reach: Web-Oriented Architecture

    thanks <a href="http://www.ucanhoroz.com">film izle</a></div>
    direk film izle
  • RE: The SOA with reach: Web-Oriented Architecture

    http://www.google.com
    free man