Chapter 16: Implementing the Data Transfer Object Pattern

Overview

The previous two chapters discussed mechanisms for optimizing a client's use of a Web Service. You will find that, in practice, Web Service operations are relatively expensive when compared to a local method call between objects in the same process. Consider Figure 16-1 (previously shown as Figure 4-2). A communication path between two components , ArchitectureAComponent and ArchitectureBComponent , contains at least two transformations in a single direction and an intermediate format. Then, consider that each call must return from the one-way trip with a new value.

Figure 16-1: Web Service architecture participants

The first leg of a trip in a call from the ArchitectureAComponent component to the ClientAdapterA component typically traverses the A architecture's communication mechanism. The ClientAdapterA component transforms the call to the Simple Object Access Protocol (SOAP) format and traverses a Hypertext Transfer Protocol (HTTP) path to the ClientAdapterB component. There, ClientAdapterB transforms the call from SOAP to the ArchitectureBComponent 's format and communication mechanism. After receiving a response from the target component, the return trip duplicates the path through SOAP and HTTP. You can probably see how this path is a little more expensive than a local method call.

Now, consider a target object with five different values you would like to retrieve, each with a get operation. This is five separate Web Service calls: 10 trips through SOAP, 20 communication mechanism conversions, and 10 traversals through the HTTP protocol ”all for five values. If the Web Service developer knows that clients retrieve a particular group of values in a series of Web Service operations, you can drastically improve performance by allowing clients to retrieve all of the values in a single operation. This performance gain occurs simply by minimizing the number of operations the client must conduct. From 10 traversals through SOAP and HTTP, you reduce this to two. Imagine the secondary savings on garbage collectors and raw processing power.

This value proposition is the motivation for the Data Transfer Object and Data Transfer Collection patterns. The Data Transfer Object pattern became a heavily used pattern over the past five years as remote object manipulation became a reality. It is now used in Java 2 Enterprise Edition (J2EE) applications, Jini applications, and virtually all enterprise object-based systems. This chapter explores the basics of the Data Transfer Object pattern and then discusses how you apply it using Web Services. You will also see a slight variation of the Data Transfer Collection pattern, which is a simple extension to the Data Transfer Object pattern that applies to collections of objects rather than single objects.

Note  

Often, information in this chapter applies to both the Data Transfer Object and the Data Transfer Collection patterns; in these cases, this text refers to the pair of patterns as simply the Data Transfer patterns.