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.

A connected application relies on a single transaction

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

Get Programming WCF Services, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.