Just recently in some meeting with clients in Budapest several questions were raised about what is truly different about SOA than previous approaches to improve IT agility? The history of COBOL (Common Business Oriented Language) being touted as a means to improve business and IT linkage was raised along with innovations in object-oriented development and component based development.
Rather than discuss the merits or pros and cons of each of these technology innovations I chose instead to focus on what is actually different with SOA. I described five differences:
(1) The ubiquitous presence of standards is actually different. The use of XML and WSDL or derivatives is a major difference. In addition, the way in which vendors author standards has also improved.
(2) A focus on interoperability versus integration is a key difference between SOA and prior approaches. Using the metaphor of applications as islands, integration is about creating bridges between these lands masses; interoperability is more like being teleported as in Second Life.
(3) The linkage between business and IT is different in that SOA makes the assertion that all businesses have a business design which describes how the business operates such as its business processes, the services rendered and consumed, business goals and objectives, business rules and policies. The business design ought to be a tool to communicate requirements between business and IT. Hence the use of business process models and BPM, where both process models and services have a distinct and clear relationship is different than previous approaches. Promoting the best practice of documenting as much as possible of the business design with tooling rather than the more common approach of using word processing or drawing tools is also different.
(4) The focus on reuse is also different in that with SOA we are focused on improving the organizational productivity versus a focus on developers and programmer productivity.
(5) Software design is also different. See Don Ferguson's blog (http://www-03.ibm.com/developerworks/blogs/page/donferguson) which I have included herein: Web services are more language independent than previous approaches. For example, CORBA was very C-like and was awkward in Smalltalk. EJBs and Java are, by definition, focused on the Java type space. XML renders more naturally into multiple languages like C, Java, COBOL, etc. XML and Web services are less fragile and better accommodate change. For example, it is possible to add or reorder elements in an XML business object without necessarily breaking code using older versions. The same applies to WSDL. Most previous approaches like RPC or CORBA were often a distributed version of a runtime model with offsets into data structures or function tables. So, additions and reordering broke code. Previous approaches really had three data models and type spaces. For example, a CORBA application had: 1) IDL, 2) IIOP for inflight messages, 3) SQL if the application was accessing a database. Distributed Java has a similar approach with serialized objects, the Java language and JDBC/SQL. Web services have one type space (XML) for interfaces, data applications are manipulating, XML databases and in-flight messages. It may not be obvious why one type space is better than three. The primary reasons are simplicity and flexibility. In Web services, there could be one basic approach for converting a data structure/business object from one format to another, instead of potentially three different type models and tools. This could enable a simpler development tool suite and API set. Moreover, having a consistent model enables flexible and more dynamic placement of business logic. The transformation code could run in an application, in an active database or in network intermediaries (proxies). We designed Web services to support both asynchronous messaging and remote procedure call. Previous approaches started with one or the other, and then grafted the other model later on. For example, implementing a layer on top of MQ for simple RPC is common. CORBA was originally RPC centric, but then added support for asynchronous messages. In most cases, the after the fact grafting of one technique on another was awkward and error-prone.
So when you add these all five things together you see there is something different. This is not a case of a shell game. In fact the only thing that is the same is the use of SOA as an architectural style, where we have the notions of consumer, provider, service description, broker, and a registry are similar to previous approaches. Of course many technical people see SOA as solely an architectural style and this misses the point entirely of service orientation.