Communications of the ACM
Viewpoints
From the Front Lines: DOA with SOA
Photograph by Roy L. Angeles
It looks like today is finally the day that we all knew was coming, it was only a matter of time. An ambulance has just pulled up to haul away Marty the Software Manager after having been pummeled by his boss for failing to deliver on promises of cost savings, improved software reuse, and reduced time to market that had been virtually guaranteed by merely adopting service-oriented architecture (SOA). Everything was supposed to be so different. As opposed to the currently unfolding scenario involving an ambulance, Marty's mental vision of the future had been one of a Brinks truck speeding to the scene to relieve his coffers from buckling under the strain of overflowing cash.
Should anyone really be surprised? After all, Marty is probably still sporting the hook in his mouth from having been reeled in by Victor the Vendor's SOA fishing pole. The hype and propaganda sprinkled onto the bait that Marty swallowed must have caused a mind-numbing sense of euphoria that resulted in business and technical justification for his decisions to be ignored. Marty had been successfully convinced that his project was the only one not cashing in on the booming SOA silver-bullet bonanza.
Despite Marty's headlong charge into the SOA arena, he would have had difficulty describing it the same way three times. In his defense, however, many others have different ideas about what SOA is and is not. Thankfully, I have the benefit of a teenage daughter in the household so there is no shortage of expert opinion on any topic. Out of curiosity, I asked her what she thought was meant by service-oriented architecture. She told me that this was an approach used to construct the shops where she buys her fashionable apparel. There are certainly different opinions about what SOA might be, but this one might be a bit extreme.
Some might say they are doing the SOA tango by merely using XML, WSDL, SOAP, and UDDI technologies. Others may believe they are reverently saluting the SOA flagpole if they are using workflow and their classes are stateless. In actuality, SOA describes an architectural style that is independent of using a particular technology. This architectural style involves advertisement of services in some form of a registry that users can discover, introspect, hook up to, and invoke at their discretion. Sure, SOA is enabled by technologies such as those mentioned here, but others such as CORBA and DCOM have been enabling it for years.
For some software organizations, the primary dilemma is not so much about deciding whether or not adoption of SOA would help realize their development objectives, but instead, determining which technologies and design tactics should be used to do so. Not all SOA users or prospective users even realize they have options when it comes to how they should use SOA to develop their software. Unfortunately, the SOA lemmings who fail to consider these options have the potential for actually causing negative impacts to their software architectures as opposed to capitalizing on some of the benefits that SOA truly does offer.
I wonder which straw finally broke Marty's SOA back. In an effort to be good SOA practitioners, did Marty's software staff generalize some services to such an extent that they were not able to meet even their own product's needs? The idea of developing distributed infix services sounded good, but the performance impacts of remote process invocations to simply add and subtract numbers might have been a bit of an SOA stretch. Even though these infix services were written with the hallmark SOA qualities of being discoverable, stateless, composable, and not dependent on any other services, Marty fell into a trap that many projects seem to be falling into these days. He did not align his architectural and design decisions to the beacons characterizing his project's objectives: Quality Attributes.a Instead, he let rampant SOA hype and propaganda blind him. As a result, he couldn't see that the relentless pursuit of flexibility had trumped the importance of performance and usability in his product.
Perhaps Marty's misfortune was an aftereffect of firing all of his systems engineers due to a belief that adoption of SOA transformed the traditional software lifecycle into one where the only relevant activities are ones of development and integration? There is a great deal of money to be saved by assuming that jack-in-the-box architectures will just pop up amidst a haphazard collection of services without having to invest time and effort associated with traditional software engineering approaches.
There might still be yet another possibility at the root of Marty's looming ambulance ride: did he choose the wrong level of abstraction with which to implement SOA? As opposed to service users hooking into them directly at the "stub" level, there are often circumstances where a service layer encapsulating such stubs has the potential of improving important properties that include performance, availability, and survivability. Specifically, performance can be improved by short-circuiting remote method invocations in the event that requested information has been previously fetched. Availability can be improved by the service layer hooking up to alternate service providers in the case of failures or SLA violations. Survivability can be improved by providing service users with some fidelity of response even if connectivity to the actual service provider is temporarily unavailable.
Not all SOA users or prospective users even realize they have options when it comes to how they should use SOA to develop their software.
As just suggested, the benefits of encapsulation should not be ignored when selecting the tactics with which to best implement SOA. In fact, even in the context of my daughter's rather interesting definition of SOA, she recognizes the value of encapsulation, "Dad, I can enjoy my clothes without having to know any of the details of how they were made." Perhaps your SOA usage tactics should heed such wise words and similarly hide applicable implementation details from service users? Why should a user of an extremely simple service be bothered with having to know about UDDI, for example, when a resulting side effect might be to write more code to connect to the service than required to implement the service itself? A preferred implementation from a Quality Attribute realization perspective might be to hide UDDI from clients beneath a thin service layer.
Adoption of SOA is not about throwing a switch where roll-up-the-sleeves engineering can suddenly be avoided or where time and money unexpectedly become available with which to properly identify services using business process analyses. Sure, some development activities might be shortened as the result of reusing certain components or purchasing others, but, how often is one able to actually purchase preexisting services that provide a product's core "business logic"? How many software managers are actually willing to add risk to their development schedules to find out how a particular service imminently required can be generalized to meet the needs of unknown or future users? In order to realize SOA's benefits, engineering and planning are still required as opposed to just hoping that a bunch of random services glued together by a workflow engine will get the job done.
Sadly, Marty did not make it to the hospital. Whichever combination of misguided business decisions and implementation tactics may have finally led to his demise, Marty was DOAdead on arrivaljust like his SOA project. It did not have to be this way. Adoption of SOA did not constitute authorization for Marty to ignore best practices or to show contempt for common sense. Yes, Marty's architecture was flexible, but of what value is flexibility when other critical architectural properties have been ignored or trumped?
How is your SOA health? Do you presume that SOA can only be enabled by Web services? Do you believe that the benefit of properties such as performance and abstraction are only important in "old-fashioned" architectures? Have you aligned your usage of SOA to your Quality Attributes? Pay close attention to how you answer, you will not want to miss the warning signs of a possible DOA with SOA in your future.
Footnotes
a. Non-functional properties that drive software architecture (L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 2nd edition, Addison Wesley, 2003).
DOI: http://doi.acm.org/10.1145/1400181.1400191
©2008 ACM 0001-0782/08/1000 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2008 ACM, Inc.
No entries found