Geeks With Blogs
Chris Falter .NET Design and Best Practices

When the P & C insurance company I used to work for wanted to start obtaining geocode information for addresses, I was responsible for the architecture and design decisions related to consuming the vendor-supplied data.  The background for the task was nothing unusual: the vendor provided the data via a web service that used proprietary (and poorly documented) XML schemas for the input and output messages.  We had 2 point-of-sale web applications and an internal underwriting application that would consume the information, but generally needed only a few bits of data from the very large vendor output message.  Thus the component or service would need to transform the vendor's mega-document into a standardized format that all our applications could use.

The first and most important decision was whether to consume the data via a .NET component that would be linked directly into the various applications, or via a web service.  My evaluation went like this....

Similarities in the approaches

  • Both SOA and components could support abstraction (component via an interface, service via a contract), and thus loose coupling.  In other words, both approaches could provide a simplified facade to the complexities of the vendor's service.
  • Both approaches could support automated testing (unit tests).

Advantage(s) of component-based approach

  • The component approach would have a small edge in performance, because the service would introduce an extra network hop between the applications and the vendor service. 
    • However, this was a minor factor, because the major performance constraints (latency between our network and the vendor's service, and processing time at the vendor service) far outweighed the cost of the extra hop and HTML processing at a facade service.

Advantage(s) of the service-oriented approach

  • Autonomous service design would allow development, testing, and runtime environment to have no overlap with consuming applications.  In particular, interfacing with the vendor service imposed unique requirements with respect to logging, web service policy, security, tracing and error handling/reporting.  Satisfying these unique requirements would be much easier via an autonomous service than via a component embedded in many applications.
  • Could be used by other non-.NET applications in the future (i.e., greater integration capability).
  • Could easily be consumed by potential service composition applications in the future (i.e., greater re-use capability).

The advantages of the service strongly outweighed the advantages of the component-based approach, so I designed and built a facade service instead of a component.  You will not be surprised that the choice turned out well.  The service's autonomy made development, testing, deployment and management much easier than if it had been a component, due to the fact that any change only had to occur in one track (the service's development - testing - integration -  deployment environments) rather than many (the applications' various environments). 

This became particularly important one day when the vendor implemented a change that we thought we had prepared for correctly, but...unbelievable as this may seem....the new version of our facade service had a critical bug!  That morning all Hades was breaking lose at our office.  The advantages of the service approach became quite apparent in the midst of the storm:

  • Everything we needed for troubleshooting (tracing, error analysis, input vs. output message analysis, profiling) was available at a single location--independent of the runtime environments of all the other applications.
  • Once the fix strategy was coded, it could be tested and deployed quite readily (in the service's environments).  If we had been using a component, we would have had to compile and move the component through the test-integration-deployment environments of many applications.  This would have delayed the deployment of the fix by several critical hours.

Of course, I am not advocating that you convert every application component in your assorted software systems into an autonomous service ASAP.  There is an art to building a service inventory blueprint and modeling the services, and I refer interested readers to Thomas Erl's fine book, SOA: Principles of Service Design, for more information on the subject.  I am simply saying that, in the right situation, service-oriented architecture can be superior to component-based architecture. 

I invite my readers to leave comments about how SOA improved their IT capability (or perhaps adversely affected it?!). 





Posted on Sunday, September 5, 2010 11:57 PM Software Architecture , SOA | Back to top

Comments on this post: SOA vs. Component-Based Architecture

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

Copyright © Chris Falter | Powered by: