Asynchronous Token

Consider an enterprise application in which a user can place purchase orders for some parts and request price quotes from various suppliers. In this case, the user may click several buttons, resulting in server-side calls to one or more destinations. On each click event of the button, a RemoteObject sends a new request to the server.

The user hits this button several times to place several orders, which in turn initiates the same number of remote calls. The user can also click different buttons, initiating calls to different destinations. Because of the asynchronous nature of remote calls in Flex, the results from each call can arrive at random times.

When each result arrives to the client, it triggers a result event, which obediently calls the result handler function written by an application programmer. So far, so good. Here’s the million-dollar question: how can the application code map arriving result objects back to the initial requesters if they can come back to the client in an arbitrary order? The fact that you place an order to purchase a Sony TV first and a DVD player 10 seconds afterward doesn’t guarantee that results will arrive to your Flex application in the same order.

The goal of the Asynchronous Token pattern is to properly route the processing on the client in response to the data arriving asynchronously from the server.

Because AsyncToken is a dynamic class, you can add any properties to this class during runtime, as is done with orderNumber in ...

Get Agile Enterprise Application Development with Flex 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.