Database Reference
In-Depth Information
A real-life saga
NServiceBus simplifies the implementation of the concepts in the previous section; the fol-
lowing is a real-life scenario to illustrate them and multiple services that communicate with
each other.
Recall the pizza-ordering example we discussed earlier where the
Please do not refresh
the page and wait for the order to complete
message is displayed when a user places an
order. We discussed the concern that the user may have doubts about whether the order is
completed, and there is the implication that a browser refresh could cause order issues. Ob-
viously, an ASP or JSP web page waits for some web service to go out and charge my card
as it waits for the result. To avoid this behavior, a better solution is needed. One such solu-
tion is a workflow for passing messages around so that the system fires off a transaction to
process the payments, allowing user interaction to continue; eventually, the system is to re-
ceive an update once the payment is processed.
There are a few possible solutions for the preceding example, and all of them have one
thing in common: combining a workflow with a middle layer simplifies the solution.
One possible solution is to have several services that are responsible for different actions.
We need to save data entered by a user to a database; this can be accomplished via some
backend services. These services handle all the transactions needed. A service, say Ser-
vice1, can pick up the data and pass it into a MSMQ for processing. This provides the sep-
aration of knowing which messages are in the state of processing. Another service, say Ser-
vice2, can be responsible for the interaction with a payment engine.
Continuing with the pizza-ordering example, Service1 is responsible for getting the data
entered by the customer and Service2 is responsible for processing the credit card payment.
If there are errors with the payment engine, Service2 and the ServiceBus have the logic to
retry again. However, Service1 remains unaware that there are errors with the payment.
Service2 is atomic and does not provide notifications and feedback to the user. The pay-
ment service may place the error in an error queue, but some information, such as why the
payment was not processed, will remain missing.
