+1 Although I think a modification that SOA is finally _beginning_ to be understood in terms of what it means.
Steve 2008/5/17 Michael Poulin <[EMAIL PROTECTED]>: > 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. > > > > > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
