On Sat, Jan 17, 2009 at 4:59 AM, Steve Jones <[email protected]> wrote: > 2009/1/16 Nick Gall <[email protected]>: > >> On Fri, Jan 16, 2009 at 2:05 PM, David Chappell >> >> <[email protected]> wrote: >>> [DC] - In my blog posting from Earth Day of last year, >>> >>> >>> http://blogs.oracle.com/davidchappell/2008/04/roi_by_the_ton_going_green_wit.html >>> >>> I highlighte a case study about Verizon Wireless going green by rewriting >>> their fraud detection application using SOA, EDA, and Web 2.0, and as a >>> result eliminating 6 tons of hardware from their datacenter. >>> >>> The old application, which was based on J2EE, replicated the entire data >>> warehouse of call detail records for use by the fraud detection >>> application. >>> It also had a lot of procedural custom code that was hand written by 5 >>> FTE >>> over 2 years, some stuff that was ported from Forte to J2EE, and 100s of >>> JSPs feeding (circa 1995) html 3.0 pages with data. >>> >>> The new implementation is 0.5% of its original size. They replaced 100's >>> of >>> JSPs and EJBs with 1 JSP and 1 SWF file for UI and BPEL processes which >>> access call detail records from the backend systems directly (via service >>> level interfaces). They also went from 5 FTE over the course of 2 years >>> down to 1 consultant who wrote several BPEL processes over the course of >>> 1 >>> year. >> >> Why is this an example of SOA? >> Is ANY use of BPEL and "service level interfaces" (as Dave calls them) >> an example of SOA? >> Is ANY use of BPEL and things called "services", which is deemed a >> success by its implementors, an example of SOA? >> >> The reason I ask these questions is that I see a LOT of "SOA" case >> studies that sound to me just like good old fashioned integration case >> studies or even good old fashioned EAI studies. So why isn't any >> "successful" integration project that throws the term "service" around >> an SOA project? Or perhaps it is to some people. >> >> Gartner's definition of SOA (modular, distributable, described, >> sharable, and loosely-coupled) requires more than just successful >> integration and the use of the label "service". The resulting system >> must deliver services that are both sharable and loosely-coupled (able >> sustain change with minimal impact on existing dependencies). >> >> I didn't see anything in Dave's description that indicated that the >> resulting fraud detection system was any more changeable or sharable >> than the old one. Sure it was smaller, cheaper, etc. But perhaps it >> was incredibly brittle and needlessly specialized (ie not sharable) as >> well. I can't tell from the description. >> >> And that's my problem with most "SOA" case studies. Almost all are >> reported immediately after they are deployed. So I have no reason to >> believe that they will generate more shared use down the road or that >> the service interfaces will be evolvable over the long run. And if >> they lack these qualities, they're not good examples of SOA -- at >> least according to some definitions -- they're merely good examples >> of integration using services. >> >> Unless good integration using services is all you mean by "SOA". > > Just a little point of order here. There are those (Mr Baker for > instance) who have regularly claimed that just using HTTP makes it Web > Oriented/REST.
I won't speak for Mark, but I never claimed that just using HTTP makes it WOA/REST. If that were true then every HTTP-based WS-* interface would be WOA/REST and I hope it is blindingly obvious that I don't believe that. > If this project thought about its services, modelled its services and > then co-ordinated them using BPEL then that to me can count as SOA, a > million times more realistically than quoting HTTP usage figures as > proof of REST. There's a critical gap between "Can count as SOA" and "does count as SOA". Sort of the necessary vs sufficient divide. I'm looking for those who consider themselves SOA experts to provide their opinions as to what is required to fill the gap. > The key phrase is "using services" at the highest level that is what > is important an architecture that is ORIENTED towards services. This > isn't old school EAI which was oriented towards either APIs or > messages. So to fill the gap between "could be SOA" and "is SOA" in a case study is merely the additional requirement that "we are using services at the highest level"? Even if those services are as poorly designed as imaginable, ie they are needlessly specific services and they are virtually impossible to change once deployed, we still have SOA? That seems a woefully low threshold to me. And a large factor in the current backlash again SOA. Every set of ancient EDI supply chain services (PO, Invoice, Shipping Notice) would qualify as SOA, even though organizations have bemoaned EDI's brittleness and fragmentation for years. IMO, if a so-called "SOA case study" doesn't substantially improve sustainable business flexibility (enabled by service sharability and adaptability) then its not worthy of the name. (That's how I fill the gap between "could be" and "is". And I hold WOA to the same requirement.) But virtually none of the case studies I've read (other than the WOA ones) demonstrates how the "SOA-based" system responded to changing business needs over time. -- Nick
