Geeks With Blogs
Chris Falter .NET Design and Best Practices

Robin Harris just posted a near-heresy on his ZDNet blog: he thinks that SOA (Service-Oriented Architecture) is overhyped, and will die a painful death as businesses discover the difficulties in monetizing it and making it reliable.  Come on now--hype, in our industry?  Please!

Actually...I agree that we are indeed well into a hype cycle regarding web services, and we would do well to make sure that SOA doesn't become the next "Golden Hammer."  This is a term coined by Brown, Malveau et al. in their terrific book, Anti-Patterns, and it refers to the idea that, to a little boy with a hammer, everything is a nail.  And likewise, to an organization that has drunk deeply of the SOA hype, every new software initiative can be an opportunity to create a web service.

Yet certain types of problems are best solved with web services, provided that you recognize the opportunities and take advantage of them.  Implementing services as the right opportunities arise is what I call "Opportunistic SOA." 

Whenever one of our lines of business asks for some new functionality, we ask ourselves, "Will any other lines of business want this functionality as well?"  If the answer is "yes" or "most likely," we typically invest the 25% extra effort needed to implement the functionality as a service.  Then when the next LOB asks for the functionality, we get to reap the reward of a vastly simpler and faster implementation.  And when a third LOB wants it, we're laughing our way to the bank.

Obviously, there are some situations where only a web service will do.  If you want to access some functionality across the internet, you're going to use a web service, period, end of story.  Also, if systems on disparate platforms require the same functionality, you will probably write a web service, because the alternative is to write the same functionality multiple times in multiple languages for multiple platforms.

When systems on the same platform on the corporate network need the same functionality, though, there are tried-and-true approaches that compete with web services.  In this situation, how do you distinguish a good SOA opportunity from an opportunity to make your users' lives harder while playing with a new technology? 

* A good web service hides the complexity of interacting with another system.  This is why our shop does not use web services to make database calls, even though it involves inter-process communication.  A database has so many possible interfaces (stored procs, table structures, etc.) that inserting an additional web service layer between the client and the server usually does not simplify anything.  The only time a web service interface might make sense for a data layer is when the data has to be transported over HTTP due to network considerations.  If you're inside the firewall, in other words, it's hard to justify writing a web service data layer.

* A good web service simplifies the management of inter-process interactions by allowing all updates to occur in a single place--namely, the web service.  Remember, you can simplify an interface to a complex system with the facade design pattern, which relies on a facade class to handle the complexity of interacting with some other system.  If it does not make sense to manage the interaction via a single system at a single point in your network, you should not write a web service; you should write a facade class library instead and compile it into your codebase.

Our shop has used web services to provide interfaces to services from outside vendors.  For example, some of our homeowners insurance lines acquire outside data regarding fire protection class, building code effectiveness grading scale, and distance to shore before underwriting a particular home.  The vendor's XML interface is quite complex, so we use an internal web service to simplify the interface.  Using a web service (instead of a facade class) also allows us to manage all the vendor updates and the configuration elements in a single place.

Another situation that was ripe for a web service was our need to convert PCL-formatted documents from our legacy system into PDF format for a web application.  We got a server license for a conversion component, wrapped it in a web service interface, and were able to perform the necessary conversion from any system on any platform.  And recently, when we discovered that the vendor component was not as reliable as we had hoped, we rejoiced that we did not have to re-write and re-compile code in a dozen different places to use a new vendor's (server-licensed) component.  We have only one system whose source needs to change--the web service.  We are planning to change the web service implementation in the near future, and all the client systems will get the benefit of the improved reliability without blinking an eyelash.

As is often the case with a new architecture, there is a sweet spot between the extremes of SOA hype (on the one hand) and total rejection of change (on the other).  I hope this article will help you find it.

Posted on Tuesday, April 10, 2007 8:55 PM Coding Practices and Design Patterns , SOA | Back to top

Comments on this post: Opportunistic SOA (or How to Make Your Cool New Code Survive the Hype Cycle)

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Chris Falter | Powered by: