SOA Adopting WOA?

Posted by Mark Little on Sep 10, 2008

Sections

Architecture & Design,

Enterprise Architecture

Topics

SOA Platforms ,

REST ,

SOA Appliance ,

Web Services ,

SOA

Dion Hinchcliffe, one of the first people to coin the term WOA,  contributes further to the debate with a discussion on whether WOA is actually not that far from what current SOA implementations are doing, or considering doing, anyway. As he says:

I'm not personally caught up on what we call this next generation of lightweight, Web-aligned SOA either, but WOA is the best name I've seen so far.

In Dion's definition, WOA is more than trying to reconcile SOAP and REST based approaches. In fact WOA is not synonymous with REST.

WOA encompasses all the architectural issues that are drive by the design of the World-Wide Web, an architecture, I will point out that has continued to refine itself including the rise of open Web APIs), prepackaged service consumption mini-applications (aka widgets or gadgets in the Web world, the advent of JSON, browser-based mashups, the recent resurgence of the Semantic Web, and much more.

He believes that a lot of the anti-WOA discussions are being driven by the SOA community being protectionist and afraid of something that could change the SOA business fundamentally.

I think there is actually little threat here; most of the top-down activities that SOA initiatives have been putting in place, such as governance and cross-functional business architecture alignment, are just as appropriate -- if not more so -- when it comes to making WOA successful.

According to Dion, WOA is an architectural style that is complimentary to SOA and he's not alone. David Linthicum had this to say on the subject:

... enterprises are finding that the path of least resistance is in essence to build their SOAs on the Web, using Web resources, including content, internet delivered APIs, and Web services. Once there is success with WOA you'll see the same patterns emerging behind the firewall, or SOA. This is similar to the rise of intranet applications after the success of Internet/Web systems.

If you look at traditional SOA today, Dion states that WOA offers a number of advantages, including improved service consumption models that "are less expensive and time consuming to use as well as unleashing the tremendous power of link architecture to drive information discovery, leverage, and analysis." It offers a lower barrier to entry than some other techniques for implementing SOA. As Roger Smith mentions:

A growing number of companies are finding that lower-visibility Web-oriented architecture (WOA) developments, spawned through grassroots movements, are a better route to the service-oriented architecture.

Dion goes on to state that distributed SOA has been neglected, especially when compared to WOA which is inherently distributed and offers techniques such as syndication and "low-impedance Web services." Plus popular development infrastructures, such as JEE and .NET, are embracing WOA (or at least REST) through approaches such as JSR 311 and WCF. It is still unclear whether this is due to a failure of other SOA approaches (such as Web Services), or simply because rarely does one size fit all. However, it's not all a bed of roses for WOA. As Dion points out there are some fundamental differences in the way businesses could exploit WOA that will make it more difficult for them to adopt, at least initially, which include the inherent searchability of information on the Web (PR people have learned that the Google cache will get you every time) as well as the fact that the APIs are inherently open for  partners to exploit directly making it easier to expose the right data securely and reliably:

The shift in control, the increase in openness, the different way of thinking about architecture, the countless security issues and governance concerns will likely prevent movement to WOA at a rapid pace for many businesses.

But it is clear that Dion and others believe strongly that the future of SOA is WOA. Whether it will happen this year or two years from now, WOA is building momentum and existing SOA incumbents need to embrace it or get out of the way.

1. Back to top

   Can we all get along?

   by Faisal Waris

   Just as there are sports car guys (light and flickable) and muscle car guys (ground pounding torque); just as there are dynamic language die-hards (Ruby, Python) and statically typed language die-hards (Java, C#) there will be SOA and WOA - for a long time to come.
   
   
   
   East is East and West is West, and never the twain shall meet (Kipling). In other words, somethings are burried deep in the psyche that no amount of rationalizaion can resolve.

   Reply

2. Back to top

   Re: Can we all get along?

   by Bob Boothby

   I think we can I've worked successfully with specialists of all forms to produce better systems.
   
   
   
   
   If you look at the rest of the Kipling quote it says:
   

   OH, East is East, and West is West, and never the twain shall meet,
   
   Till Earth and Sky stand presently at God’s great Judgment Seat;
   
   But there is neither East nor West, Border, nor Breed, nor Birth,
   
   When two strong men stand face to face, tho’ they come from the ends of the earth!

   Reply

3. Back to top

   Re: Can we all get along?

   by Lior Harel

   The endless debate about WOA and SOA just got reopened again in my organization ( I was already start thinking we left it behind us)
   
   Actually, it was partially reopened since finally we all agreed we should provide RESTful WS API for third parties and integrations, but the debate is in full power regarding the communication between our rich client application and the server.
   
   Anyways, I am looking for examples of enterprise applications that are using RESTful web-services to communicate between their proprietary rich client and the server.
   
   Can you assist?

   Reply

4. Back to top

   Re: Can we all get along?

   by Faisal Waris

   Most of our RIA's use web services. If your RIA tool supports WSDL then Web Services is much easier than REST. if not then REST would be easier.
   
   
   
   The RIA clients we have are Excel and XAML Smart Clients (.Net). Silverlight is another client that we are considering because it supports WSDL well.
   
   
   
   Recently I created a demo 'mashup' application in Silverlight combining Facebook API (REST) with the Amazon S3 storage service (WSDL).
   
   
   
   At that time a Silverlight2 SDK was not available for Facebook so I had to create a simple one on my own. It took me a few days to understand the Facebook API and build all of the client side tooling for the functionality I needed.
   
   
   
   With Amazon S3 I was basically done in 5 minutes because I could use the WSDL.
   
   
   
   Here I think is a key point and lesson. For REST interfaces of moderate complexity, developers typically wait till they have a client SDK in their hands for their favorite language/platform. The need for a client SDK is greatly reduced if you have a WSDL based service.
   
   
   
   Client SDKs are a reasonable option if you have a few, stable, widely reused services (such as for many public internet sites). I don't believe that this works in the enterprise. Firstly, you have many more services with limited reuse potential. Secondly,the services are likely to change often at least during development. And thirdly, it is not feasible to build client SDKs for all of the language/platforms that are in use in the enterprise.
   
   
   
   Newer tooling - .Net 3.5 and JAX-WS - give you the option of exposing WSDL and REST-style interfaces from basically the same code base. My recommendation would be use such toolsets on the service side. Both REST-full and WS* RIA clients will be served equally well.
   
   
   
   Here what I think is a good RIA development experience - Silverlight with WSDL-base services. In this case, use a 'bottom-up' approach - just develop the service layer in code and expose that as a Web Service via tooling (easliy done with Java / .Net). Let the tooling generate the WSDL. In Silverlight create a service proxy from the auto-generated WSDL. As you change the service interface simply refresh the proxy in Silverlight to update the generated interface objects. Painless.

   Reply

5. Back to top

   Re: Can we all get along?

   by Faisal Waris

   Quite. However not everyone may be as 'strong' as Kipling's men.

   Reply

• Older >