It all started as the REST movement a few years back and then a flurry of open APIs and Web widgets that began to generate impressive results for their developers. Today, Web-Oriented Architecture (WOA), a trend that describes the widespread use of the newer developments in Worldwide Web architecture to drive integration, composition, and web development has become the standard in the consumer space. To capture the story so far, enterprise architect Dion Hinchcliffe explores the latest developments in WOA with a look at the opportunities and advantages it can confer to developers and architects. "The SOA world begins considering Web-Oriented Architecture (WOA) in earnest" as well as a companion piece on ZDNet discuss the current trends. Yes, WOA is something many Web developers do today, but formalizing its adoption in the enterprise is an entirely different prospect.

As an acronym or acro-buzz or buzz-onym, WOA sucks. It will further contribute to the general confusion about SOA rampant in the IT and business communities. WOA is SOA, it's only different if you think that SOA is SOAP or requires and RPC style. It does not and it never has. (SOAP document/literal is still defined in terms of operations being invoked. The WSDL just associates a message format with a particular operation of a particular end point.) Why do we need a term like WOA anyway? "REST services" says it all to me, because that is what it really means. Being REST versus RPC (as in SOAP) does not change the architectural style - it's still service oriented. It changes how the interfaces are designed. Before any one who is confused weighs in with an objection or gotcha - there is an RPC style that is not SOA, i.e. the traditional sort of interface commonly used in many distributed architectures before SOA. A service interface is one where the operations are defined in terms of the use cases they realize where an RPC (non-service) interface is defined in terms of a particular component or object's capabilities. It’s like the difference between ordering your meal and getting it served to you or going into the kitchen to make it yourself. You can implement a service style interface using RPC technologies (the procedures are service operations) or not which is why SOA can be implemented in CORBA, Java EE using EJBs, Tuxedo, CICS and many other technologies. So what does "WOA" contribute as a new buzz-onym?

Being REST versus RPC (as in SOAP) does not change the architectural style - it's still service oriented. It changes how the interfaces are designed.

It is hugely different as you are exchanging representations of data rather than making a remote function call. At least with REST+HTTP, you can negotiate with the server on the data format you are exchanging. HTTP caching can come into play to help scale your app. Composition becomes easier as you have a simple way to compose disparate remote data (URIs) and knowledge on how to invoke on these URIs (the HTTP uniform interface). I wrote an Intro to REST article a few weeks ago that explains this in more detail. Also, better articles are available on http://infoq.com, specifically: http://www.infoq.com/articles/rest-introduction http://www.infoq.com/articles/rest-anti-patterns http://www.infoq.com/articles/tilkov-rest-doubts -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com http://resteasy.sf.net

Being REST versus RPC (as in SOAP) does not change the architectural style - it's still service oriented. It changes how the interfaces are designed.

It is hugely different as you are exchanging representations of data rather than making a remote function call. At least with REST+HTTP, you can negotiate with the server on the data format you are exchanging. HTTP caching can come into play to help scale your app. Composition becomes easier as you have a simple way to compose disparate remote data (URIs) and knowledge on how to invoke on these URIs (the HTTP uniform interface

They are different, but what you are describing are engineering and design differences, not architectural ones. SOA refers to the architectural style of what it is you are building, which in this context means applications. SOA is reflected in the granularity and the orientation (internal versus external) of the interfaces you expose to your actors. It has nothing to do with the technologies you use. So, I repeat, WOA is an unnecessary buzzonym. “REST services” basically covers it and REST is an alternative to RPC.

Being REST versus RPC (as in SOAP) does not change the architectural style - it's still service oriented. It changes how the interfaces are designed.

It is hugely different as you are exchanging representations of data rather than making a remote function call. At least with REST+HTTP, you can negotiate with the server on the data format you are exchanging. HTTP caching can come into play to help scale your app. Composition becomes easier as you have a simple way to compose disparate remote data (URIs) and knowledge on how to invoke on these URIs (the HTTP uniform interface

They are different, but what you are describing are engineering and design differences, not architectural ones. SOA refers to the architectural style of what it is you are building, which in this context means applications. SOA is reflected in the granularity and the orientation (internal versus external) of the interfaces you expose to your actors. It has nothing to do with the technologies you use. So, I repeat, WOA is an unnecessary buzzonym. “REST services” basically covers it and REST is an alternative to RPC.

Sure, REST/SOA same architecturally, but RPC/REST are not the same architecturally, which is what you originally stated. IMO, REST is really a messaging architecture, while RPC tries to make a remote call look like a local one. I agree though. RESTFul Web Services belong under the SOA acronym, not as a replacement.

Web != REST. In fact if anyone bothered to read the original REST paper, there is a section about all the parts of the web and the specific things about them that are not RESTful.

The fool looks at the finger, not at the moon. The main point is building the architecture of your business, not choosing the protocol(s). One can use EJB, Web services , Corba, REST, DCOM, JMS ... It's the same. Perhaps less or more complex or effective. And a good architecture can mix protocols, a good application can switch to another protocol without changing every thing.