Consequences

The pattern has the following benefits:

1.

It provides an Abstract machine view of the server. When using BATCHING, clients no longer perceive servers as a separate set of entry points. Servers are now perceived as abstract machines. Their instruction set is made of the set of server entry points, together with some general-purpose control language. Therefore, it is feasible for users to reuse programs for different BATCHING calls. Programs that interact with the server can be built, and reused later.

2.

It reduces protection-domain crossings, as the cat program did above. If this is the main motivation to use the pattern, domain crossing (client/server invocation) time must be carefully measured. Whenever complex control structures are mixed with calls to the server, or when client computations need to be done between successive calls, the pattern might not pay. In any case, the time used to build the program must be lower than the time saved in domain crossing. The latter is approximated by the difference between the time to perform a cross-domain call and the time to interpret and dispatch a server call.

3.

It reduces the number of messages between clients and servers; provided that the Program issues repeated calls to the server and the control structure is simple enough. Again, the improvement due to the reduced number of messages can be lower than the overhead due to program construction and interpretation. Therefore, careful measurement must be done prior to pattern adoption.

4.

It decouples client/server interaction from the call mechanism. BATCHING provides a level of indirection between the client and the server. The client can perform a call by adding commands to a Program; while the Program can be transmitted to the server by a means unknown to the client.

5.

It decouples client calls from server method invocations. As said before, a client can perform calls by adding commands to a Program. The resulting Program can be sent to the server at a different time. Therefore, there is no need for the client and the server to synchronize in order for the call to be made.

6.

It allows dynamic extension of servers. Servers can be extended by accepting Programs from clients. Those programs could be kept within the server and used as additional entry points into the server. Should it be the main motivation to use the pattern, the concrete command set should be powerful enough.

The pattern has the following drawbacks:

1.

Client requests might take arbitrary time to complete. A batched program might lead to a nonterminating program. If server correctness depends on bounded client requests, it may fail. As an example, a server can use a single thread of control to service all client requests. Should a Program not terminate, the whole server would be effectively switched off by a single client. In such case, either avoid using BATCHING, or handle multithreading issues as a side-effect (i.e., arrange for each Program to use its own thread, using a giant lock⁷ to protect non MT-safe servers⁸.)

2.

Security can be compromised. The more complex the command set, the more likely the server integrity can be compromised due to bugs in the command interpreter. If high security is an issue, either avoid BATCHING or reduce the complexity of the command set to the bare minimum.

3.

It might slow down the application. When cheap domain crossing is available and efficiency is the primary objective, using BATCHING might slowdown the application if the time saved on domain crossings is not enough to compensate the overhead introduced by BATCHING.