ESB is an SOA implementation. ESB stand for Enterprise Service Bus is a computer software architecture used for designing and implementing communication between software applications.

What is SOA? There is much description about SOA. IMO, SOA (Service Oriented Architecture) is an architectural pattern in computer software design which application components provide services to other components (usually enterprise software) via communications protocol, typically over a network.

In this post, I want to share about ESB implementation on Bank.

In Bank usually there is ESB implementation for communicating many enterprise software applications such as Internet Banking Server, EDC/POS Server, Mobile Banking Server, SMS Banking Server, ATM Server, Core Banking Server, or even HSM (Hardware Security Module). All mentioned server can be developed by different programming-languages, or even can deployed on different operating-systems. ESB should do communicate all of internal server in Bank.

Wait what? Internal Server? Are there external server? Yeah. There will be Payment Gateway server for multipurpose transactional such as Bill Electricity, Phone Bill, TV Cable, and any other payment. ESB may communicate with more than one Payment Gateway. Note that Payment Gateway is external server, not in the Bank; they may have different communication protocol.

In my experience (well I’m not the expert anyway), ESB may have capabilities as below:

1. Messages Identification and Validation

ESB must identification each incoming message, whether it’s request or response, etc. And also validate it whether it’s valid nor not

2. Routing

After knowing the incoming message, ESB must know where to route this message. Usually, ESB use parameter to route the messages. It can be deterministic routing, ruled-based routing, or policy-based routing.

3. Messaging Transformation or Translation

Beside of routing, ESB also can transform message info other format message. For example, incoming iso8583 message from IB Server [1], transformed into http get for bill inquiry to Payment Gateway [2]. Iso8583 and Http GET was just example, it can be any other format message. In Bank, iso8583 used for card based transaction.

Example of Inquiry Bill

Example of Inquiry Bill

4. Process Choreography

This part little bit complex. Process choreography means routing capabilities for business process in financial or non financial transaction.

a. Example non financial transaction: bill inquiry flow (yeah, usually… bill inquiry doesn’t have fee). You can see example on picture above. After ESB receive request message from IB Server [1], ESB will forward this request to Payment Gateway [2]. Payment Gateway will send response to ESB [3], and then ESB will forward this response to IB Server [4].Example non financial transaction: bill inquiry flow (yeah, usually… bill inquiry doesn’t have fee). You can see example on picture above. After ESB receive request message from IB Server [1], ESB will forward this request to Payment Gateway [2]. Payment Gateway will send response to ESB [3], and then ESB will forward this response to IB Server [4].Example non financial transaction: bill inquiry flow (yeah, usually… bill inquiry doesn’t have fee). You can see example on picture above. After ESB receive request message from IB Server [1], ESB will forward this request to Payment Gateway [2]. Payment Gateway will send response to ESB [3], and then ESB will forward this response to IB Server [4].

b. Example financial transaction: bill payment flow. After you see detailed bill, you choose to pay the bill. The IB Server will send payment message to the ESB [1]. ESB will check your limit transaction first (Transaction limit maybe checked on IB Server, depend on Bank IT Policy). Then ESB request to debit account to Core Banking [2]. If the balance is sufficient to make this payment, the balance will be debited by Core Banking. The Core Banking will send success response to ESB. After that ESB will send Payment Message to Payment Gateway. Payment Gateway will mark this Customer ID’s bill as “paid” and then send success message response to ESB. Finally ESB will send success message response to IB Server. As a user, we will just wait and then get the message from IB that our bill paid successfully.

Example Bill Payment

Example Bill Payment

c. What if the balance account is insufficient? The process choreography, will slight different with option (b) above. After receive negative response from Core Banking[3], ESB will not send Payment Message to the Payment Gateway, it would send a negative response to the IB Server[4].

Example Negative 1

Example Negative 1

d. What if (after ESB send payment message) Payment Gateway send negative message response to ESB? ESB must credit the account balance to the Core Banking. On this example, ESB may have to wait response from Core Banking then send negative message response to IB Server. On other case, response from Core Banking may have not necessary for ESB.

Example Negatie 2

Example Negatie 2

Those scenario above, are just example. There are much-much other scenarios such as what if transaction limit is reach? What if ESB didn’t receive response message from Payment Gateway? ESB must have capabilities to face all possibilities scenario on this payment. Well, note that this is just on feature on IB Server. Do you know how much feature on IB? How about other features on other channel such EDC or ATM? I think a little bit complex doesn’t fit for ESB. It’s really complex, isn’t it?:mrgreen:

5. Management

ESB is also must have capabilities for Management: monitoring (transaction, failure, etc), audit log (who accessed it, what menu it’s accessed, when it’s accessed), logging (incoming request, incoming response, etc) and reporting. One of the important features of ESB is reporting. ESB must generate report daily, or even monthly, or yearly depend of bank policy. Daily report usually use for reconcile.

6. Support Various MEPS

MEPS stand for Message Exchange Patterns, such as synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe. ESB may have connected to more than one Payment Gateway. All those Payment Gateway may have different format message, and event different protocol

7. General Agnosticism

Yes there is no doubt about it. IB Server may be deployed on Windows operating-systems; ATM Server may be implemented using IBM AS/400 operating-systems; Payment gateway may be developed on various programming-languages. ESB must act like a bridge, connecting all kind of server

8. Other Quality of Service

Other Quality of Service is also important. One of the most important is TPS (Transactions per Second). In banking transaction, there is much-much transaction. Imagine a bank may have hundreds of millions of customers. How many transactions per second ESB must have to carry? What method to measure ESB TPS?

And let’s think about security breach. What if someone sniffing our packet through computers network? We must encrypt the message with randomized key (example: Triple Des). These parts are really critical since bank transactions (between enterprise software) are highly private.