Although it is technically possible to use the same service code both connected and queued (with simple changes such as configuring operations as one-way, or adding another contract for the one-way operations), in reality it is unlikely that you will actually use the same service both ways. The reasons are similar to the arguments made in the context of asynchronous calls, discussed in Chapter 8. Synchronous calls and asynchronous calls addressing the same business scenario often have to use different workflows, and these differences will necessitate changes to the service code to adapt it for each case. The use of queued calls adds yet another barrier for using the same service code (both connected and disconnected): changes to the transactional semantics of the service.
Consider, for example, Figure 9-10, which depicts an online store application that uses connected calls only.
Figure 9-10. A connected application relies on a single transaction
Store service uses three well-factored helper
services to process the order:
Billing. In the
connected scenario, the
Store service calls the
Order service to place the order. Only if the
Order service succeeds in processing the order (that is, if the
item is available in the inventory) does the
service call the
Shipment service, and only if the
Shipment service succeeds does the