Callback

Pattern Properties

Type: Processing (Behavioral)

Level: Architectural

Purpose

To allow a client to register with a server for extended operations. This enables the server to notify the client when the operation has been completed.

Introduction

A networked Personal Information Manager will periodically make expensive requests of a server. For example, the time required to retrieve an entire project stored on a server is very unpredictable—the project might have thousands of tasks and deliverables.

A networked Personal Information Manager will periodically make expensive requests of a server. If a client wants to retrieve an entire project— potentially hundreds or thousands of individual tasks with corresponding budgets, timelines, and so on—it might take a lot of time to retrieve that information. At best, the time to retrieve the project would be unpredictable.

In this situation, it would be limiting for the server to keep an open network connection. Although one open connection might actually improve the server’s efficiency, having an open connection for each client severely limits the number of client requests it can process concurrently.

Rather than requiring that the client and server remain connected, it would be better to enable the server to contact the client when it finishes the client's request. The Callback pattern uses this approach.

The client sends a request for a project to the server, providing its callback information along with the request.

The client then disconnects from the server and allows the server to spend time on retrieving the project.

When the server completes the task, it contacts the client and sends the requested project information.

The benefits include conserving bandwidth and allowing the server to more effectively use its processing time. This solution also gives the server freedom to perform tasks like request queuing and using task priority, to more effectively manage its workload and available resources.

Applicability

Use the Callback pattern for a client-server system with time-consuming client operations, and when one or both of the following are true:

You want to conserve server resources for active communication.

The client can and should continue work until the information becomes available. This can be accomplished with simple threading in the client.

Description

For some distributed systems, a server must perform longer-term processing to satisfy client requests. In these systems, synchronous communication is probably not the best option. If the server maintains contact with the client during processing, it uses resources that could be better applied to other tasks, such as communicating with another client. Imagine a system where a user wanted to perform a complex query on a moderately large database table; for instance, a table of customer information with more than 10,000 records. In a synchronous client-server system, the client process has to wait, possibly for a long time, for the server to finish. The server performs the query and handles any necessary tasks to organize, format, and package the data, until it finally returns the data to the client.

160