Queued Versus Connected Calls
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
The Store service uses three
well-factored helper services to process the order: Order, Shipment, and 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 succeeds does the ...