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.
Community comments
Can we all get along?
by Faisal Waris,
Re: Can we all get along?
by Bob Boothby,
Re: Can we all get along?
by Lior Harel,
Re: Can we all get along?
by Faisal Waris,
Re: Can we all get along?
by Faisal Waris,
Can we all get along?
by Faisal Waris,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Can we all get along?
by Bob Boothby,
Your message is awaiting moderation. Thank you for participating in the discussion.
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:
Re: Can we all get along?
by Lior Harel,
Your message is awaiting moderation. Thank you for participating in the discussion.
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?
Re: Can we all get along?
by Faisal Waris,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Can we all get along?
by Faisal Waris,
Your message is awaiting moderation. Thank you for participating in the discussion.
Quite. However not everyone may be as 'strong' as Kipling's men.