Seeing the Data Transfer Pattern in Practice

The Data Transfer Object pattern started coming into practice as users of distributed object systems tried to improve performance in their network-based applications. Using Remote Method Invocation (RMI), a typical benchmark observes a substantial increase in time for a method call to complete. This increase is typically from less than a millisecond per method call in a local scenario to around 10 milliseconds per method call in a remote scenario, with little or no network separation in the client and server. This increase of more than a factor of 10 is barely noticeable in an application with few remote calls. However, enterprise applications do millions of method calls in a day. Consider a small application doing 100,000 method calls. The time for a local application to complete would be around 100 seconds, which is one minute and 40 seconds. In the remote case, the time will be more than 1,000 seconds, which is more than 16 minutes. This is serious performance degradation.

With a little analysis, you will quickly find that the amount of data is not the cause of the performance impact; it is the variability inherent in remote connections combined with the mechanics of communicating across a network. By simply reducing the number of times you place data onto the network and the number of times you do the work to put the data on the network, you can improve the performance of your application. In fact, you can place more data on the network in each call to reduce the number of connections and still recover substantial performance gains.

The Data Transfer patterns work for both retrieving data and changing data on the server. The Data Transfer Object pattern works by having the server-side component developer define common attributes of a business object, or other base type, that clients typically access or change as a group . An example is customer summary information; clients usually want the first name, last name , and social security number of a customer. Rather than treating these as three separate method calls, the Data Transfer Object pattern advocates creating a transfer object containing all three pieces of data that the client requests with a single method call. The client can also change several pieces of this data and return it to the server for processing with a single method call.

The Data Transfer Collection pattern works by taking some data transfer objects and bundling them into a collection. So, rather than requesting customer summary information for individual customers, you can request customer summary information for all customers. This information gets returned to you in a collection of data transfer object instances.

Often, the Data Transfer patterns are discussed in terms of data retrieval, but they are equally important for updating information. Clients can create and populate the Data Transfer patterns and submit the objects to the server side for updates.

Virtually all distributed systems now use the Data Transfer Object pattern. My first encounter with the pattern was in the Jini environment, but I now see it throughout all business applications that base their environment on object- oriented technologies.