Database Reference
In-Depth Information
those that do not require customer intervention for issues the customer does not need to be
made aware of.
Instead, the responsibility to ensure the funds are processed should be on the system rather
than on the customer. Of course, in order for a website to take on the responsibility of fir-
ing off the message to an SOA, there has to be an SOA in place to take on the responsibil-
ity of processing the message for the payment.
While developing an SOA or ServiceBus system, many software architects consider start-
ing it from scratch. However, they soon realize that there are many unstated requirements
that are expected to be incorporated. These requirements assume a specific behavior and
do not explicitly call them out. It is a given fact that a good design takes these non-busi-
ness functional requirements into account.
Some examples of these requirements include second-level retries for when a credit card
isn't processed the first time. When this happens, the system stores the messages along the
way; keeps track of the state of the services; and integrates into other company systems
network errors, the encryption of the credit card number, and the access control level that
different users and systems may need.
These requirements become complex quickly, as the following diagram implies. It may
take years to resolve some of the issues but most of the time, the business allocates
months rather than years to address them. In order to resolve these non-business function-
al requirements and to address the associated issues that may arise, it is best to study solu-
tions that other architects have provided for similar situations.
For instance, use a ServiceBus product such as NServiceBus as a guide to performance-
enhanced products with built-in message reliability and integrity.
