/ciol/media/agency_attachments/c0E28gS06GM3VmrXNw5G.png)
Follow UsSivaraj Doddannan, Enterprise Architect at Intelligroup
Introduction
The main underlying theme of SOA is the effort to bring open standards to the corporate world.
During early computerization initiatives, most organizations tried to implement their existing business practices directly. This led to varied processes, which often were not optimal.
Wide spread adoption of ERP was a direct offshoot of Business Process Reengineering1 concepts which started in early 90's. Organizations started implementing ERP to standardize on the processes across the company, and to bring their processes inline with the best practices followed in other organizations.
While ERP systems helped to standardize business processes, getting them to talk to other applications within and outside the organization was not a simple task. This has been the major pain point for organizations over the past decade. EAI systems started appearing in the late nineties, to reduce this pain significantly. However they were not able to address all the integration problems. Main problem was that there was no standard way of connecting between systems. Often, applications from the same vendor might use different mechanisms to connect to each other.
Such incompatibilities lead to nightmarish issues that haunt our IT manager. Let us leave her a bit longer with nightmare - we will rescue her soon.
Internet and its standards
Since its early days, internet was made possible by widespread adoption of standards. Various standard setting agencies like ISOC, ICANN & W3C2 emerged ensuring that all parts of internet work together seamlessly.
Custom networks slowly died down, and internet became the means of corporate data communication for majority of applications. As corporations started adopting internet for their wide area networking needs, they also started adopting the standards used in the internet. The change came first in the physical networking area. Many proprietary networking products died down rapidly, as they cannot cope with the technological advances in internet based standards, and reducing the cost of running these networks.
The next casualties were the proprietary communication and networks. Then leading networks like CompuServe bit the dust before mid-90s. Networks based on open standards based services proliferated. As there was minimal value addition between networks, and exit costs were very low, the networks fought mainly on cost - thus reducing the cost of service very low. Availability of internet at low cost also spun thousands of new opportunities which wouldn't otherwise be possible.
In each instance, standardization brought with it significant cost benefits along with increased flexibility.
The Front-End
In late nineties, with the widespread use of internet based standards in enterprise, certain other developments started happening. Most obvious was the way how applications are built, as browser became the preferred front end for most applications.
Advantages of embracing browser as common application front-end were multi-fold. It offered ultra-thin clients, improved mobility, platform independence, besides very low costs in development and maintenance.
Such conveniences lead users to demand more and more applications to be available on the browser, instead of custom front ends. Increased productivity and reduced training costs lead the managers to demand more applications on the browser. Web front-ends also made it convenient to make the internal applications available to partners.
Overcoming initial shabby looks, and with the development of technologies like AJAX, web front ends started offering glossy looks as well. However putting all these applications on the web is not an easy task. They are often from different vendors and were developed in totally different technologies. Job of trying to port them to web and getting a uniform look and feel sounds almost impossible. All these have started adding a migraine to our IT manager.
Among the thousands of technologies spawned by internet, there was a simple one that caught the imagination of visionaries, called "web service"3,4. Web services were used communicate between internet applications. The basic technology is extremely simple; hence I will talk about it briefly.
Web services were originally intended to retrieve or send small packets of information between web applications. For example, a website might be providing an application to get current stock prices. Corporate websites can use this application to retrieve the stock price and display on its pages. Both the applications involved would talk using some basic web standards. The communication would be carried out via the HTTP protocol. The data will be formatted as xml snippet, and wrapped around in additional xml codes call SOAP envelop. The data format will be defined using WSDL.
As we see, this simple communication uses four different standards. HTTP and XML are fundamental ones, and SOAP and WSDL are specialized standards related to web services. Use of such standards makes easy and fast to build applications using web services, as most internet applications understand how to use these standards.
Service Oriented Architecture
We were talking about visionaries earlier, who were admiring the "web services". These people thought web services are neat. "Neat" is such a big complement, coming from them. A neat technology will first and foremost be simple. It will also be flexible and easy to build upon. It will of course be based on open standards.
So the first thought was, why not make all "interfaces" to an application use "web services"? Yeah, that would be neat too.
The thought evolved a bit further. Hey, why not break our application in smaller chunks, and make each chunk communicate to others via "web services"? That would be very neat.
Thus has borne the idea of Service Oriented Architecture or SOA.
While building applications out-of-the-box using service oriented approach is one aspect of SOA, it is not always possible build applications from scratch. Most companies are already running various applications. Some of them are complex and huge business applications which they have spent many years to build or implement. It wouldn't be feasible to discard them and start afresh.
No fear. Most of the application vendors have started realizing the need to make their architectures service oriented. Instead of rebuilding their applications with SOA concepts they are exposing well defined services out of their applications. Such approach helps in mitigating the couple of problems we have explored above.
Integration nightmare revisited
Let us go back and wake up the IT manager from her nightmare now. It is impossible to make this bad dream go away with a single magic pill. But SOA offers a way to ease such pain in the long run.
That is another aspect of SOA5. Rather than a single application or chunks of an application, here it is about multiple applications communicating to each other. When they talk different languages, it is difficult to communicate (obviously!). When we make applications talk the same language, it would be easier to integrate them, isn't it?
SOA here means making applications using "standards" to communicate to each other rather than a single application. In other words, "architecture" would refer to the architecture of the landscape containing all applications, rather than a single application.
Outside a nutshell
Internal applications are only one part of the giant jig saw puzzle. Majority of enterprise integrations happen between partners. This precludes the possibility of "standardizing(?) on a single vendor" within an organization and emphasizes the need for open standards. With the advent of industry specific standards, we start looking at a much bigger picture than the architecture of internal landscape. We start seeing the architecture of the industry eco-system.
The IT manager also had the headache of exposing all enterprise applications to the web6. She understands the advantages of doing that, but still unable comprehend how she would go about it.
SOA lends a hand in this dilemma. It says that, she just has to expose all applications as web services, and use out of the box applications to string these web services together to make a full application. "Yeah, that sounds simple... how do you go about doing it anyway?"
As we saw earlier, most major enterprise application vendors have started exposing services out of existing applications. We would still be having many applications that do not have out-of-the-box web services though. In these cases there are middleware tools available that can communicate to the backend systems using proprietary tools and expose the functionality as web services on the other end.
This approach has an added advantage. Because she can string together web services from multiple applications and build a seamless application crisscrossing multiple backend applications.
Industry calls such applications as composites. Composites are in fact one of the major selling point for SOA. This is where we would start realizing the true potential of SOA.
Abbreviations
ERP - Enterprise Resource Planning
EAI - Enterprise Application Integration
ISOC - Internet Society
ICANN - Internet Consortium for Assigned Names and Numbers
W3C - World Wide Web Consortium
AJAX - Asynchronous Javascript and XML
HTTP - Hyper Text Transfer Protocol
WSDL - Web Services Definition Language
XML - Extensible Markup Language
SOAP - Simple Object Access Protocol
Brief about Author
Sivaraj Doddannan is an enterprise architect at Intelligroup. He has 14 years of IT experience and has worked extensively in implementing ERP systems. He is currently focused on guiding organizations in determining their technology platform strategy and building feasible roadmap towards adopting Service Oriented Architecture.