Synchronous Versus Asynchronous Processing

Although it’s technically possible to call the same component synchronously and asynchronously, the likelihood that a component will be accessed both ways is low.

The reason is that using a set of components asynchronously requires drastic changes to the workflow of the client program, and as a result the client can’t simply use the same execution sequence logic that it would for synchronous access. Consider, for example, an online store application. Let’s suppose the client (a server-side object executing a customer request) accesses a Store object, where it places the customer’s order details. The Store object uses three well-factored helper components to process the order: Order, Shipment, and Billing. In a synchronous scenario, the Store object calls the Order object to place the order. Only if the Order object succeeds in processing the order (i.e., if the item is available in the inventory) does the Store object call the Shipment object, and only if the Shipment object succeeds does the Store object access the Billing component to bill the customer. This sequence is shown in Figure 7-1.

Synchronous processing of a client order

Figure 7-1. Synchronous processing of a client order

The down side to the pattern shown in Figure 7-1 is that the store must process orders synchronously and serially. On the surface, it might seem that if the Store component invoked its helper objects ...

Get Programming .NET Components, 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.