Database Reference
In-Depth Information
Continuing with the order system for a pizza establishment, the website would process the
order and hand off the message to ServiceBus to process the payment. Then, the system
takes the ownership of the payment message instead of relying on the customer.
The messages need to accommodate the partner's systems. However, the bus handles data
and queues internally and saves the state, messages, and objects if something goes wrong.
This is important since payments affect the bottom line, and the company has a business
need to keep track of its payments.
The hand-off of messaging allows a customer to continue to the next action or website
page. The payment response is later processed as the system takes on the responsibility for
the payment.
The messages are sent between services as autonomous tasks, and the messages need to be
made durable, scalable, reliable, secure, transactional, and capable of being distributed
among different systems. This backbone, the pieces as a whole, is by definition an
Enter-
prise Service Bus
(
ESB
). ESB is simply a common bus across the enterprise, with the
preceding characteristics (durable, scalable, reliable, secure, transactional, and distribut-
able).
A saga is a mechanism that evolved in ESBs to save the state of messages. A saga also
keeps track of the originating message's endpoints so that it can respond to the originator
with changes to the message.
Just as an accountant must keep track of receivable payments and orders in a company, so
must a company's systems—record keeping is of paramount concern. Once a user creates
an account, they become a customer; as a customer, they assume that the company pro-
tects their information, unless told otherwise.
Throughout history, many companies that are no longer in existence neither protected
users' data, nor adequately kept track of payments and orders. Security and sales are an
overall concern in the industry. A company's main goal is to make more money than it
spends, which includes keeping track of the company's data. Losing sales and data can be
expensive. Reporting where data is and its current state (be it a sale or customer's data) is
important. Therefore, of course, it is better to have a system that never has an issue.
Though, if a system has an issue (such as losing data or funds), it is best to know the mag-
nitude of the issue and as much information as possible. Therefore, when building pay-
ment engines, it is not uncommon to require daily reports of dollar totals, the number of
successes or failures, reasons for failures, root cause of failures, and more.
