Johannesburg, 18 Mar 2009
The modern systems architect has a plethora of software technologies, methodologies and tools available, to the extent that it is becoming almost impossible to keep up to date, let alone use all of them. We have SOA, REST, SOAP, JASON, Rails, Seam, EJB3, .Net and J2EE, to name just a few.
One of the technologies that has enjoyed a lot of attention is SOA, or service-oriented architecture. It seems most of the hype has died down, and technologists have realised that SOA is not a silver bullet, but that it is, nevertheless, a valuable architecture to be used when designing enterprise systems. Modularising system components into concrete service entities that are easier to manage and support separately makes perfect sense.
However, most medium to large enterprises have a number of legacy systems that were not developed using the latest technologies. These systems are usually very close to the core of the business, which is exactly why they are still in active use. Because of their nature, these applications become silos of information and business rules that are difficult to access. To replace these systems is prohibitively expensive, but failing to switch to newer technologies may restrict the agility of the business.
As an example, a hypothetical enterprise system may comprise a Web application; say an HR employee portal developed with Seam, using EJB3 and Hibernate for persistence, running on a J2EE application server. We have an application that manages employees' leave, developed in C#, running on a .Net platform. This application exposes a Web services interface using SOAP. A payroll system runs on a mainframe and was developed in Cobol. We also have a time and attendance system developed in C++ and Corba.
We would like to use SOA principles to integrate these systems in order to provide a unified Web-based interface, for management and employees to access the human resource data.
ESB solution
The enterprise service bus (ESB) is one solution to this problem. ESB is an architecture that provides a method of communication between disparate systems through a messaging and routing system (the bus) and translation facilities (adapters).
In the above scenario, an ESB could be deployed and adapters configured for each legacy system to translate messages or requests into a format that is compatible with that particular system. For example, the ESB will communicate with the time and attendance system through a CORBA adapter, while a SOAP adapter will provide communication facilities to access the SOAP interface of the leave application. Once connected to the ESB, each application has the ability to exchange information with any other application on the bus.
The ESB can also translate data into different formats, such as postal codes to city names. Most ESB implementations have a number of standard adapters that could be used, and an API that allows developers to implement their own adapters to communicate with systems not catered for out of the box.
An ESB implementation may also provide service orchestration (the combination of multiple services into one), process choreography (process flow) and security and management (authentication, monitoring, auditing and logging).
The ESB concept is certainly not new, and a number of mature and stable implementations exist, both open source and commercial. Some commercial implementations are Microsoft BizTalk, Oracle ESB, Progress Sonic, Pervasive Data Integrator and WebSphere ESB. Examples of open source implementations are Apache ServiceMix, ChainBuilder ESB, JBoss ESB, Mule ESB and OpenESB.
There are some disadvantages of using this solution, as it does add an additional layer of complexity to the system, and will require additional effort to maintain. The process of message routing and translation increases latency, and an ESB is, therefore, not suitable for high throughput applications such as telecommunications and other real-time messaging systems.
Applied correctly, this technology has the ability to leverage SOA principles, while extending the return on investment of legacy applications, with the added benefit of flexibility, allowing the application of new technology that may become available in the future.
Share