Working with SOA

On Friday I discussed what SOA is and why your organization should be looking into it. Today, I will explore the real-world of SOA. Referring back to the "electrical outlet" example outlined in Friday's post, even 102 years since the 1904 invention of the "electrical plug and socket" by Harvey Hubbell, while standards exist, there are still 14 plug and socket types used across the globe. Anyone who has traveled to Europe with an electric razor, sans adapters, has learned this the hard way. Likewise, having a Services Oriented Architecture across line-of-business (LOB)applications does not mean perfect interoperability, but it is a significant improvement over the alternative - writing C-code, developing communication protocols, designing error handling etc.,

While SOA can be implemented using any service-oriented technology, Web Services is the most common. Example Web Services include SOAP and REST (to delve deeper into these services and related SOA technologies, select the hyperlinks in this post). Web services allow communication between software, based on a set of standards (e.g., XML, WSDL, UDDI, etc.). It is also important to note that with Web Services, software applications do not need to be based on the same platform (e.g., Windows vs. Linux) or same programming language in order to communicate. These issues have long been the achilles heel for enterprise systems.

Organizations that have adopted SOA are primarily focused on communications between systems within the company. However, Web Services ushers in a whole new set of capabilities by allowing for smooth interoperability with applications outside the enterprise. While potentially revolutionary, this is less common as significant security, accessibility, and performance issues remain.

Tomorrow I'll review a business scenario that leverages SOA to drive value to the bottom-line.