Application

Fusing enterprise architecture

Service Oriented Architecture holds the promise of interoperability between diverse enterprise applications, says Venkatesh Ganesh

Perhaps, Darwin’s theory of evolution can be extended to software design. That worthy had stated that only the fittest survive. Fittest, as in the ‘best fit’ for a given environment. Considering that the enterprise application environment is an unwieldy tangle of legacy and modern applications, it isn’t surprising that the latest concept doing the rounds called ‘Service Oriented Architecture’ or SOA promises to let applications natter away like old friends on a vacation. Increasingly, enterprise application vendors are taking the SOA route because it promises interoperability. A SOA architecture is significant for enterprise application vendors as it lets customers lower their TCO without spending a bomb on integrating third-party applications with their enterprise systems.

As a SOA-enabled application is based upon open standards such as XML, integrating third-party applications stops being cumbersome and expensive. For example, SAP has changed its proprietary R/3 architecture to NetWeaver, a service-oriented architecture. With the latter, users can integrate their enterprise applications using standard components. Like SAP, almost all enterprise software majors, be it Oracle, Microsoft or even Indian vendors like Ramco, have moved their product architecture towards SOA. SAP, IBM, Microsoft and Oracle support BPEL (Business Process Execution Language) which helps organisations specify the way applications will interact with different systems. BPEL is a step towards SOA.

Software as a service

The need for a SOA architecture came about because of the increasing complexity and difficulty in integrating enterprise applications. Making a company’s traditional architecture talk to different entities (suppliers, partners) became a daunting task. For example, SAP adopted NetWeaver because of the changing landscape of ERP. In the 1990s, ERP packages, such as SAP were restricted to a company’s internal processes. As organisations started interacting outside their traditional boundaries, they faced integration issues with systems, which did not run on SAP. A SOA-enabled architecture allows an organisation to reduce the cost of integration and helps it respond faster to absorb and integrate new business partners. It is designed from a service perspective and implemented as a set of loosely coupled systems.

Says Ramkumar Kothandaraman, architect advisor, Developer Platform, Evangelism Team, Microsoft India, “This is natural evolution at work. Software architecture has progressed from modules to objects to components and now services.” The most attractive feature of a SOA is that it holds the promise of creating applications using models.

Explains Raghuram Devalla, GM Platform Technology, Ramco, “SOA will have big implications on the way we manage the software life cycle—right from the specification of requirements, to the design and, finally, the asset management of services.”

Integration blues

Web Services provide the communication, but SOA can be a base for designing any application R Ramakrishnan Director, Solutions Architect Team SAP India	SOA will have implications on the way we manage the software life cycle—right from the specification of requirements and design to service management Raghuram Devalla GM Platform Technology Ramco

One of the key issues that organisations face is integrating enterprise applications. Most spend huge amounts of money integrating diverse applications. There is a need for a standard that lets enterprise applications exchange information seamlessly without needing to use third-party EAI tools.

Avers Kothandraman of Microsoft, “There were a number of third-party vendors who made a killing as there was no other option other than buying an off-the-shelf EAI solution. SOA was born from this need.” Independence from the underlying technology is perhaps the biggest driver for SOA.

Explains Arunava Dutta, director–Technology Sales, Oracle India, “The attractive part of SOA, when compared with previous attempts at components-based architectures is that SOA relies heavily on common standards which do not place any requirements on the underlying technologies.”

Arunava furnishes his thoughts with an example. Let’s say a customer walks into a auto dealer’s showroom to trade in an old car for a new one and wants financing for the net value and insurance for the gross value of the new car. Currently, the dealer has access to a DMS (dealer management system) that is hosted by the vehicle manufacturer. He has to get a delivery date from the system and promise the same to the customer. This request has to be linked to the financing company for its approval. Lastly, the insurance company has to be informed about the premium to be paid. Finally, a sub-dealer who deals in second-hand vehicles will survey the traded car and assess its value. Each of these systems may be based upon different technology platforms and located at different centres. How is a deal to be made? Obviously the task of integrating these various systems is tedious and time consuming because there are too many systems.

With SOA-enabled applications, real-time data can be exchanged between diverse systems with no problems of integration. With SOA, one can even define a ‘service’ in the model itself. A service can be defined as a function that is independent of the context or state of other services. In the SOA model, the way these services should interact with different systems using varied technologies and protocols would be defined in the model itself. For example, our hypothetical DMS can automatically pull data from the OEM’s system while simultaneously interfacing with the system of the vendor dealing in second hand vehicles. After these two activities, the ‘service’ will pass on the information to the vendor who is financing the deal.

A SOA helps change

business processes without impacting application performance. For instance, Ramco’s VirtualWorks platform automatically generates code once a business process is defined by the customer. If you change the business process, the application changes to accommodate the new process. Customers can integrate the changed system architectures of external entities such as partners and suppliers without encountering any problems.

Solving the Web services puzzle

SOA differs from Web services that are a collection of technologies (XML, SOAP, WSDL and UDDI) used in building programming solutions for specific messaging and integration problems. You can define different Web services in the SOA model. So in a way, SOA can be considered as a collection of Web services.

Adds R Ramakrishnan, director, Solutions Architect Team, SAP India, “Web Services provide the communication, but SOA can be a base for designing any application.” The SOA architecture allows Web services to communicate with each other to pass data.

Web services have accentuated the need for SOA. Ultimately, the adoption of SOA will follow a pattern similar to that of XML or Object Oriented Programming. While it may take some time to evolve, the technology has got off to a promising start.

venkatesh@expresscomputeronline.com