Here’s a little background for the uninitiated
The Challenge:
Let us take an example: Most retail banks in India deploy a number of core banking packages (serviced from various different vendors) to collectively constitute a complete end-to-end application (Universal bank). Think of the processes and systems that facilitate a loan lifecycle:
- Customer verification and KYC process [could be a CRM running on Linux and Oracle]
- Loan sanctioning and disbursement [could be a COBOL system running on z/OS mainframe]
- Repayments from payment gateways [could be a .CSV file that is inputted to a the system]
- Suggestions for bancassurance products [could be from PostgreSQL, Python and Java running on Linux and Solaris]
These individual packages (modules) need to liaise with each other for the bank to function smoothly. They can communicate with each other by exposing their data through interfaces like HTTP, JSON, AMQP, XML, SOAP, FTP, CSV, etc.
So far so good. But is facilitating communication between the systems that easy?? If we consider the loan lifecycle, the communication imbroglio might look something like this:
Mind you, we’ve not even considered the physical servers or components that are used in the actual setup, which will definitely increase the total number of message exchanges necessitated. More comprehensive the system, the more chaotic it will inevitably get. How can we get past this?
The Solution:
The fundamental basis of making sure such environments can scale above a handful of systems is – Don’t let them interface directly. Introduce a mediator that can arbitrate between them.
For this, we make use of an ESB [Enterprise Service Bus]. It now becomes the job of the ESB to expose and invoke services of the integrated systems. This way, only one access method and only one interface needs to be defined between each system and the ESB.
So if, like in the diagram above, you have 4 systems, there will be 8 interfaces (one in each direction) to create, maintain, manage and take care of. Without an ESB you’d have 12 interfaces to think of and deal with (assuming each systems system talks with each other). 8 interfaces less means less time wasted and more money saved.
Also, if a system undergoes a rewrite (due to change of ownership, logic change, etc), it will be a duty of the ESB to conform to the change. None of the other systems will be affected as their interface with ESB will be still intact.
The Footnote:
SOA is a valid approach to solve many of the architectural problems that enterprises face today.
With time the whole organization will begin to understand that it’s no more about database tables, files, batches, functions, routines or records. This will be about an architecture centered on interesting, reusable and atomic services applications offer to ESB.
No longer will people think that applications and system send things over one to another. They will see ESB as a universal access gate to interesting services their own systems can make use of. And they won’t even bother with checking who exactly provides what, their systems will only deal with ESB.
Recommended Reads:
