The focus of this article is to use a combination of online research and hands-on experience to explain the practicality of SOA as the foundation of application enterprise architectures. The rest of this article will cover three aspects of SOA:
The Good: In this section, I have used what I believe to be the most obvious immediate return on investment items for any enterprise. The upside on these items is substantial and in most cases immediate.
The Bad: All of the items in this section will create some minor headaches when attempting to deliver services that can be reused and remain long lived. The cost is most likely higher than a typical non-SOA approach, but with strong guidelines much of the cost will be a one-time-only issue.
The Ugly: These items are the ones that will likely make any project manager uneasy about the timelines and costs associated with an enterprise SOA. Many of these issues don’t have good answers for them yet and will likely continue to evolve as the technologies being used to deliver services evolve.
Service-oriented Architecture vs. Web Services
Too often discussions about service-oriented architectures inadvertently progress into a best practices discussion on web services development. This article will use many of the existing limitations of web service development to explain the costs associated with delivering service-oriented architectures. Web services are by no means the only technological mechanism for delivering an enterprise SOA. There are code libraries, shared components, and EAI solutions. With that said, web services are the most popular approach and are seen used much more often due to their implicitly interoperable transport mechanisms.
Other Reuse Strategies
It is worth taking a moment to walk the SOA timeline. At the root of SOA is code reuse and there have been a number of mechanisms used over the past 30 years for reusing code. It all began with cumbersome error-prone cut and paste techniques. This eventually progressed into code libraries and code includes. These techniques were foundational for many different development platforms until the introduction of object orientation.
Object orientation soon progressed into an underlying design concept and the packaging and deployment mechanism that followed was dubbed component oriented. These components were used to package and deploy reusable code. However, that still required multiple versions of the code and the next step was to use proprietary channels for remotely invoking those components from a single location.
What seems to be the final obstacle in the evolution of code reuse emerges. We now have a standards-based approach for remote invocation of reusable code. This, above all other reasons, is why web services over HTTP are the most common technologies found enabling service orientation in today’s enterprises.
