I disagree that SOA "concept is finally understood and gaining traction". Here are a lot of things to gain, especially, in the business and enterprise areas.
Setting WOA or Web Services as a "substyle of SOA" has two troubling aspects: 1) SOA is still taken as a technology (otherwise Nick Gall mixes apples and oranges), we it is not 2) communication models - Web Services/WS*-, REST, MOM/Event-Driven - cannot be architectural principles, its are just communication models; depending on the task one of them might be more preferable than others. I agree with ZapThink in that SOA and WOA are abstractions of different levels. However, I disagree with using expressions such as Web-Oriented SOA, Event-Driven SOA, Model-Driven SOA, Process-Driven SOA, etc. I think it would be a mistake to limit SOA even in one enterprise to only one communication mechanism ( unless it is very a simple business where enterprise operates). I feel it would be more appropriate saying something like "a SOA subsystem with Web-Oriented communication model (WOCM)" - Michael ----- Original Message ---- From: Gervas Douglas <[EMAIL PROTECTED]> To: [email protected] Sent: Saturday, May 17, 2008 1:38:25 PM Subject: [service-orientated-architecture] [ZapFlash] WOA is Me - Another Acronym? WOA and SOA WOA is Me - Another Acronym? WOA and SOA Document ID: ZAPFLASH-2008516 | Document Type: ZapFlash By: Ronald Schmelzer Posted: May. 16, 2008 The problem with IT: Attention Deficit Disorder (ADD). Just when one concept is finally understood and gaining traction, the pundits, marketers, and industry standards-bearers come up with a new and confusing phrase to confound us all. In this iteration of IT’s fascination with new TLAs (three-letter acronyms for the acronym-challenged) , bloggers and hypesters galore are talking up the concept of Web Oriented Architecture (WOA). Given ZapThink’s distaste for old wine in new bottles, we have to ask: is there anything new in the WOA concept? And if there are new ideas, do they have any substance? More importantly, if there are indeed new ideas in the WOA concept, how do these compare and contrast to the SOA concept? What is WOA? At the time of writing this ZapFlash, there’s no Wikipedia entry page on Web Oriented Architecture, which is both a sign that there isn’t sufficient interest to create one (although perhaps the simple act of writing this might spur an entry), as well as a reflection that the term is too new to have garnered any sort of consensus definition. However, over the past year or so there has been a flurry of impassioned blog writing and research work yielded a number of detailed definitions. Nick Gall was and early proponent of WOA and defines it as “an architectural style that is a substyle of SOA based on the architecture of the WWW with the following additional constraints: globally linked, decentralized, and uniform intermediary processing of application state via self-describing messages.” In his short-hand, he defines it as the combination of SOA, Web, and REST architectural and technology implementation styles. Dion Hinchcliffe further clarifies WOA as “a core set of Web protocols like HTTP and plan XML” to provide a simpler, and in his view, more scalable, approach to Web Services. He further states, “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”. The first question to ask is whether WOA is just the concept of Representational State Transfer (REST) rebranded. Indeed, Dion Hinchcliffe makes little distinction between the fundamental concepts of REST, which we explored ad nauseum in earlier ZapFlashes, and the concepts of WOA. In his words, “as far as REST and WOA are concerned, you don’t need anything more complex than HTTP” along with “some plain old XML to hold your data and state to top it all off.” We’ve explored in the ZapFlash referenced above how REST and SOA are indeed quite complimentary and thus this would apply to Hinchcliffe’s treatment of SOA and WOA. Hinchcliffe would seem to agree with us: “don’t forget, WOA is a subset of SOA and is not disjoint, as long as you follow the principles of [Service Orientation] .” The question about the REST-WOA overlap can best be answered by stating that while not all REST applications are WOA, all WOA implementations are necessarily RESTful. Nick Gall, who coined the term, provides further key insights in a blog posting in which he said, “I felt REST was too caught up in religious debates, and Web Architecture would confuse people, since it was originally oriented toward user-to-system interaction, not system-to-system interaction.” Therefore, we can gather that WOA is REST dusted off and applied specifically to SOA. None of the proponents of WOA seem to advocate it as a replacement for SOA concepts, and indeed indicate that it is a subset or style of SOA implementation. Nick Gall once stated, “[WOA] describes a subset of SOA that fits the architecture of the Web”. ZapThink would tend to agree. Service-Oriented Architecture is an enterprise architecture approach that is fundamentally agnostic to the method for implementing a Service. Use of RESTful styles for Service implementation as well as following specific REST-oriented styles of Service design would be helpful for those that seek a Web-oriented approach to SOA. Given that, why bother calling this new concept WOA at all? How about just Web-Oriented SOA? Users can implement Web-Oriented SOA by following a set of conventions for defining Services and coordinating their interaction: * Follow all the precepts of SOA defined by ZapThink as well as others in the space – make sure your Services are properly abstracted, loosely coupled, composable, and contracted * Every Web-Oriented Service should have an unambiguous and unique URI to locate the Service on the network * Use the URI as a means to locate as well as taxonomically define the Service in relation to other Services. * Use well-established Web methods (POST, GET, etc.) for interacting with Services * Lessen the dependence on proprietary middleware to coordinate Service interaction and shift to common Web infrastructure to handle SOA infrastructure needs WOA and SOA: Different Levels of Abstraction Right now, we’re seeing a lot of breathless adoration of the WOA concepts, with some stating that it will replace SOA or be the next evolution of SOA. Neither of these statements are anywhere near correct. The first glaring problem we see in those statements is that WOA and SOA define concepts at different levels of abstraction. If we can toss out the WOA acronym here for a minute and simply talk about Web-Oriented SOA, I think it all becomes clear. Rather than advocating a replacement for the ideas of SOA, Web-Oriented SOA simply provides clarity in how to define and create infrastructure for Services. Just like our earlier conversations about REST, the need for Web-Oriented SOA arises from the disappointment in Web Services and current vendor approaches to SOA more so than it arises from a need for a new architectural form to replace SOA at the enterprise architecture level of abstraction. With this in mind, it should be noted that the key requirement for WOA is a dependence on the Web as a protocol and means for both Service definition and Service interaction. SOA is necessarily and completely agnostic with regards to how to define and interact with a Service, but WOA is necessarily more specific. WOA cannot exist without the Web protocols, but SOA can. Does this mean that WOA and SOA conflict? No, it simply means that WOA is more specific than SOA. In other words, WOA is a more concrete than the SOA abstraction. Hence, we are talking about different layers of abstraction. In this way, WOA is really an alternative to Web Services and perhaps other approaches to Service design, such as emerging mainframe-oriented, message-oriented, and event-driven approaches that all might mandate different styles of Service definition and associated infrastructure. The ZapThink Take A while back, we thoroughly debunked the idea of Event-Driven Architecture (EDA) as a separate architectural concept. We also took the ill-fated idea of SOA 2.0 behind the barn and put it out of its misery. Introducing new TLAs are only helpful when they provide clarity and distinguish concepts so as to make them easier to understand and implement. Introducing new TLAs for the sake of shining up a blogger’s ego or helping analysts create new markets to peddle their research or events isn’t particularly helpful when we’re talking about the billions of dollars in IT invested in new innovations and trends. It’s for this reason that ZapThink takes a particularly wary eye on concepts that try to rebrand existing, well-worn ideas or split hairs in concepts that would be better off standing as a single idea. While the WOA concept does indeed provide deeper insights into how to best implement a Service and create an infrastructural approach for scaling Services, we simply don’t see a need to identify this as a truly separate architectural approach. As mentioned earlier, WOA would be better represented as Web-Oriented SOA in much the same way that we derided EDA and indicated that those who wish to take an event-driven perspective of the world should simply think of Event-Driven SOA. One could even combine the two and think about Web-Oriented, Event-Driven SOA as perhaps a counterweight to the Web Services-Oriented, Synchronous SOA that is all-too-prevalent in today’s so-called SOA implementations. ZapThink believes that the term Web-Oriented SOA represents greater clarity than WOA, since it disambiguates the desire to position WOA as an alternative to SOA as well as more accurately positions the concept at a lower level of abstraction than the SOA concept. Going forward, hence, we will prefer the term Web-Oriented SOA over WOA, since it provides greater clarity. And clarity is exactly what companies today need to make SOA a reality.
