Leveraging the Data Transfer Object in the Case Study

This case study leverages the data transfer object heavily throughout the application. The most obvious place you will use the pattern is on all of the Business Object Collection pattern interfaces that contain complex business objects. You also use it on an asynchronous business process as a way to obtain the core data in a business process with a single method call. For example, you would typically make two successive remote calls against a business process to obtain its state and then obtain the results of the business process. You may also check its success flag and any other data that may give you information about the business process. Instead of making these individual Web Service operations, you will use a single Data Transfer Object pattern implementation to allow the client to retrieve all of the data.

Another side effect of the Data Transfer Object pattern is its ability to represent a single coherent state within one object. If you used separate Web Service operations to retrieve information, the state of the object you are querying may change between operations. By requesting a data transfer object, the server can assemble the data in a single transaction and give you a single view of the data instead of one that may be inconsistent across operations.

In summary, you use the Data Transfer Object pattern throughout the P.T. Monday Coffee Company application for three primary reasons:

• To simplify the Web Service interfaces: This creates a more natural interface for clients to obtain particular groups of data, such as the summary data for a client.

• To increase performance: You can increase performance by allowing users to call a single operation on your Web Service to retrieve groups of properties rather than individual operations for each property.

• To ensure the client gets a single, consistent view of the data: You do this by allowing the client to access a group of attributes guaranteed to be taken from the database within a single transaction. Without the Data Transfer patterns, clients may end up getting the summary data for a business process between data updates, giving an inconsistent view of the data.

The performance criterion is one of the nonfunctional requirements in the P.T. Monday Coffee Company application; simplification of the API was not listed as a primary or secondary goal, but it is always useful. One of the interesting side effects of using the Data Transfer Object pattern is the requirement that the creator of the Web Service must determine what groups of data that they expect the client will want. If you guess wrong, you will simply end up with a more complex interface to your services with no obvious benefit.

Identifying Important Classes and Files in the Case Study

Table 16-1 shows the primary code discussed in this chapter that you should browse in the downloaded source code.

Table 16-1: Sample Location

FILE	LOCATION	DESCRIPTION
CustomerSummaryInformation.java	src\com\servicefoundry\books\ webservices \entities	A data transfer object implementation, as shown in Listing 16-1
CustomerCollectionImpl.java	src\com\servicefoundry\books\webservices\entities	The modified collection implementation that adds the data transfer object to its interface, as shown in Listing 16-2

Using Ant Targets to Run the Case Study

Table 16-2 describes the targets to run for the Ant environment to see the programs and chapter samples in operation. Before running any samples, be sure you read and perform all of the install steps in the appendix.

Table 16-2: Ant Targets

TARGET	DESCRIPTION
testdatatransferobject	Data retrieval program from Listing 16-3 that uses the Data Transfer Object pattern from a client perspective