Although it is technically possible (with simple changes such as configuring operations as one way, or adding another contract with the one way operations) to use the same service code both connected and queued, 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, the application in 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
Store service call the
Shipment service, and only if the
Shipment service ...