Implementing the Data Transfer Object with Web Services
The P.T. Monday Coffee Company application primarily uses the data transfer object and data transfer collection as simplification mechanisms and secondarily uses them as ways to reduce the amount of data traversing the Web Service architecture. In the first case, the P.T. Monday Coffee Company Web Services expose simple objects made up of common groups of data that clients often access. You allow these simple objects to be manipulated and returned to you in lieu of an entire business object. In the latter case, large applications with high transaction rates can use as much help as they can get to reduce the amount of data conversions. By transferring small, flat objects instead of complete business objects on operation calls, you can diminish the need for your Web Service environment to serialize complex objects.
In the current case study example, the CustomerCollectionImpl class in the P.T. Monday Coffee Company application returns instances of the CustomerImpl class. The CustomerImpl class is a business object that contains several complex types, as shown in Figure 16-5. Also in the class diagram is a new data transfer object, the CustomerSummaryInformation class. This class is created on demand in the CustomerCollectionImpl class when someone requests customer summary information via the getCustomerSummaryInformation() operation. To compare Figure 16-5 to the original class diagram, refer to Figure 4-5.
Figure 16-5: Customer business object collection Web Service
In this application, the CustomerImpl object is not a service implementation. The CustomerCollectionImpl object is actually the service implementation that your CustomerCollection Web Service uses. The CustomerCollectionImpl object enhances its implementation to allow clients to retrieve collections (in this case, arrays) of CustomerSummaryInformation class instances; this is the Data Transfer Collection pattern.
In the following sections, you will look briefly at the CustomerSummaryInformation class, followed by the modifications to the CustomerCollectionImpl for the data retrieval path . You then look at a client that uses your enhanced CustomerCollection Web Service and see some details of the Web Service environment.
Implementing the Data Transfer Object
The CustomerSummaryInformation data transfer object contains a few instance variables and optional get and set methods for each of the instance variables. Clients typically use the Data Transfer Object pattern by accessing instance variables directly rather than through methods. Unfortunately, the Apache Axis environment creates private instance variables on the client side for all JavaBeans. Consequently, clients must use the accessor methods rather than access the instance variables directly. Listing 16-1 shows the CustomerSummaryInformation class.
 |
public class CustomerSummaryInformation { public String lastName; public String firstName; public String id; // bean get/set methods conforming to JavaBeans specification } | |
Enhancing the Customer Collection to Surface a Data Transfer Collection
In this example, you only use the Data Transfer patterns between the client and the CustomerCollectionImpl class. You could extend the Data Transfer Object pattern to work between the CustomerCollectionImpl and CustomerImpl classes, but the payoff would not be as great. The CustomerCollectionImpl object is both a service implementation accessible to clients in a remote scenario, through Web Services, and it can serve up a lot of data in a short time. These are both good reasons to implement the Data Transfer patterns on the collection.
Listing 16-2 shows a retrieval method from the CustomerCollectionImpl object that builds data transfer objects and inserts them into a collection ”an array in this case. In this implementation, you retrieve all of the customers; then you take only the data you want to transfer across the network and insert this data into the transfer objects. In reality, an expert in Java Data Objects (JDO) could substantially improve the performance of this operation. Rather than retrieving all of the customers and all of the data from the database, you can tune JDO to retrieve only the data you need. This technique saves in performance on the host side; add this save to the network performance savings and you could find that the Data Transfer Object pattern gives you a large bang for the buck.
| |
public CustomerSummaryInformation[] getCustomerSummaryInformations() { CustomerImpl[] customers = getCustomers(); CustomerSummaryInformation[] infos = new CustomerSummaryInformation[customers.length]; for (int i = 0; i <> customers.length; i++) { infos[i] = new CustomerSummaryInformation(); infos[i].firstName = customers[i].getFirstName(); infos[i].lastName = customers[i].getLastName(); infos[i].id = customers[i].getCustomerId(); } return infos; } | |
Beyond the performance gains you can get from the Data Transfer Object and Data Transfer Collection patterns, consider the simplified API you can have for your classes. Instead of retrieving a large, complex business object, the client receives a simple array of objects with the exact data they need.
Using the Data Transfer Collection and Data Transfer Object from a Web Service Client
Using the data transfer object from the client is, basically, the same as if you were to use a business object passed to you from a business object collection. The client receives the array of data and retrieves information from the individual data transfer objects in the array, as shown in Listing 16-3.
| |
public static void main(String[] args) { try { CustomerCollectionImplService service = new CustomerCollectionImplServiceLocator(); CustomerCollectionImpl port = service.getCustomerCollection(); CustomerSummaryInformation[] infos = port.getCustomerSummaryInformations(); System.out.println("Printing Customer Summaries"); for(int i=0 ; i<>infos.length ; i++){ System.out.println(infos[i].getId()+"\t" +infos[i].getLastName() +"," +infos[i].getFirstName()); } } catch (Exception e){ e.printStackTrace(); } } | |
The only mildly interesting twist in Listing 16-3 is when the client retrieves the last name and first name from the data transfer object. Recall from Listing 16-2 that the host side was able to use direct access to the instance variables to store data in the transfer object. Using Apache Axis to create client-side architecture adapters, you lose the direct access to instance variables and, instead, must access the data through accessor methods.
| |
Starting with Chapter 6, "Exploring the Business Object Pattern," you reduced the operations present directly on business objects. In fact, you will not find complex logic on any of the business object implementations in the P.T. Monday Coffee Company application.
Consider the difference between a business object implementation that is also a service implementation and a business object contained in a collection, where the collection is the service implementation for a Web Service. In the first case, each method on the business object that is also a service implementation will be a remote operation that traverses the Web Service architecture. On the other hand, the business object collection that is a service implementation returns copies of the contained business objects, as discussed in Chapter 7, "Exploring the Business Object Collection Pattern." This behavior is exactly like the Data Transfer Collection pattern.
The Business Object pattern yields the most direct benefit from the Data Transfer Object pattern. The data that returns from the Business Object Collection pattern is a degeneration of the data transfer collection variation of the Data Transfer Object pattern. The business objects that return from the Business Object Collection pattern are a copy of all of the data residing in the Web Service, rather than a focused group of attributes.
| |
EAN: 2147483647
Pages: 190