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.
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.