In this article, some basic EMB Switch usage examples are discussed. For the purpose to understand what EMB Switch can do for you and avoid to go too further details, only basic routes are shown in each example. Obviously each of them can be basic a part of your final switch. - Quentin Sherman Xue - CEO.

EMB Switch can be easily configured to realize different kind of integrations for your business. The following are some simplified examples:

Example 1: Bill Payment Query Route

This example shows you that EMB Switch allows you to build easily a "Bill Payment Query" system which will return a electronic "Inpayment" of specific user (payer) of a specific service on one or several specific period(s). The Message and ContentBasedRouter EIP element are used here:

Message: As a request message, a Bill Payment Query message query typically contains these information: Subscriber's ID, Service Company Id (Water supply company's ID for example), and a period indication.

Content Based Router: By using this router, the query request will be routed according its content. In this example, the request will be routed to different service company.

With Message and ContentBasedRouter EIP patterns, EMB Switch allows you to build the "Bill Payment Query" system very easily:

In this example, the EMB Switch can be used to route queries generated by an auto-service terminal in a bank branch office to generate a Inpayment coupon (voucher) with which the client of the bank can pay his/her bills at bank's tellers. With support of Content Based Router, the system can route the bill payment query to its corresponding services company.

Example 2: Bill Payment Notification Route

This example, as a continuation of previous example, shows you that EMB Switch allows you to build easily a "Bill Payment Notification" system which will enqueue payment realized notification request, return a confirmation as soon as the notification is enqueued, and then deliver the notification to its corresponding company and return "Notification Delivered" response to caller. The Message, ContentBasedRouter and Guaranteed Delivery EIP elements are used here:

Message: When a bill payment of a service provider company is received at a teller of client's bank, bank's system will send a "Bill Payment Received" notification to that service provider company. By using EMB Switch, a notification delivery system can be built easily and with high flexibility and performance. In this example, the notification will be enqueued into a "Guaranteed Delivery" queue and a confirmation of reception will be delivered back to the caller. Then, as soon as the notification is delivered physically to the service provider company, a "Notification Delivered" response will sent back.

Guaranteed Delivery: By using Guaranteed Delivery messaging, the message (request) is guaranteed to be delivered to its destination (service company). So, a reception response can be used as soon as the message is enqueued. So, the caller can continue to its next task.

Content Based Router: Just like previous example, when a notification is dequeued from the Guaranteed Delivery queue, it will be routed to its corresponding service company to process the notification. When the notification is processed, a "Notification Delivered" response will be generated and sent back to caller.

With Message and ContentBasedRouter EIP patterns, EMB Switch allows you to build the "Bill Payment Notification" system very easily:

In this example, the EMB Switch can be used to route notification of bill payment generated by bank's information system as soon as the client of bank has realized the bill payment with the voucher generated in previous example. As you can see from the diagram, different from a common a "Stop and Wait" switch, the EMB Switch can be configured with two different response messages: Notification Received Response, and, Notification Delivered Response. So, the caller can receive as soon as the notification is received and stored in the "Guaranteed Deliver". This feature will reduce delayed time of caller's system.

Example 3: Best Quote Route

This example shows you that EMB Switch allows you to build easily a "Best Quote" system which will return best quote of several vendors. Two EIP elements are used here:

Message: This quote message which will ask different vendors an estimated price about a specific good, like price of a specific model of a specific car, then the result will be compared and the best one will be returned to the caller.

Aggregator: With aggregator, the results of individual can be combined and so they can be processed as a whole. In this example, the different quote returned from different vendor can be compared and then the best one will be returned.

With these two EIP patterns, EMB Switch allows you to build the "Best Quote" system very easily:

As you can see, the switch receives a quote request, then it broadcasts to three vendors to quote some product, like a specific new car, then the quote results (different prices) will be returned and then the best one will be returned to the caller.

Example 4: ATM Cash Withdraw Request/Response with Frauds Detection Example

This "almost real" example shows you that EMB Switch allows you to build easily an "ATM Cash Withdraw Operation" which will register the transaction to audit log, feed fraud Business Intelligent Database, realize fraud check online, realize security zone exchange if necessary, route request to "On Us" or "Not On Us" banks, realize security zone exchange again on the response message and then send response to audit database and also feed BI database. Several EIP elements are used here:

Message: There are several messages used in this example, the first and most important one is the "Cash Withdraw Request" which typically is an ISO 8583 which contains client Id, account number, bank's Id, PIN (password) and withdraw amount etc. Typically 3DES encryption will be used to protect the PIN and other data and also MAC will also be used.

Content Based Router (CBR): There are two CBRs used in this example. One is used to determine if the TX is required to realize "Security Zone Exchange" which means the encryption and MAC will be changed to another security zone with proper HSM cryptogram and then, for the response another CBR will be used to do reversed security zone exchange.

Guaranteed Delivery: By using Guaranteed Delivery messaging in this example, the request and also response messages will be delivered to the audit database and also Frauds Detection BI Database.

Message Filter: With application of message filter, those requests considered as suspected can be rejected. To take correct decision about if a request is suspected or not, the request must be validated with FDS.

Request-Reply: In this example, the request-reply pattern is used to make calls to make validation with FDS (Fraud Detection System) and also HSM to change security zone.

Message Translator: In this example, the Message Translator is used to make to change security zone.

Durable Subscriber: In this example, a Durable Subscriber and Guaranteed Deliver are used to feed Audit Database and also Fraud Detection Database.

With these EIP patterns, EMB Switch allows you to build the "ATM Cash Withdraw with Fraud Detection" system very easily:

As you can see, when a cash withdraw operation is realized, the ATM will send an ISO 8583 message to the switch, first of all, EMB Switch will enqueue the request to a "Guaranteed Delivery" queue to feed audit database (ADB) and also Frauds Detection Database (FDDB).

Optionally, a Frauds Detections System (FDS) could be applied to check if the request is a suspected request, by using EIP's Request/Reply pattern, the request will be routed to FDS and check if the operation is suspected or not. If the operation is considered not secure (suspected), it will be rejected and a rejected response message will be sent back. Just as mentioned before, this response message will also feed back to ADB and also FDDB.

If the FDS does not detect any problem with the operation, then a content based router will be used to route the request to different path, if the client belongs to same bank of the ATM, it means the request is an On Us transaction, in this case, the request will be delivered directly to the On Us bank.

If the client is not belong to the same bank of the ATM, so the request is considered as a "Not On Us" operation, then the encryptions of the request must be transformed from our security zone to destination's security zone by using a HSM. As you understand, to realize this operation, each destination bank or network will have a specific key called "Cryptogram" associated with the applied HSM for each specific operation, In this case, the CBR will be used to determine which Cryptogram will be used to call HSM (HP Atalla for example). When the security zone exchange operation is done, the transformed request will be routed to its corresponding bank or network. To call HSM, a Request/Reply EIP pattern will be used.

When the destination bank or network send a response message back and if the client is not belong to the bank of the ATM, a reversed security zone exchange must be applied to change the security zone from destination security zone to our security zone. This is the same process of previous one but in reverse order.

Before the response message is sent back to the ATM, it will be copied to the same "Guaranteed Delivery" queue to allow the ADB and FDDB to be fed.

To here, the process is completed.

Questions, feedback, suggestions? We would love to hear from you!