Leveraging Collections in the Case Study

The case study application uses collections modeled after the pattern identified in this chapter throughout the application design. Collections hold virtually all of the data in the application, from the products offered by the application to the inventory, customers, and sales orders. These collections all become first-class Web Services in your application. Interestingly, the use of collections as identified with this pattern brings some limitations to the scenario:

Collections that hold additional collections do not have a mechanism to return references to Web Services rather than an array of data: This mechanism would be useful to allow lazy retrieval of information rather than a forced copy of the entire class containment tree.

There is no mechanism in place to ensure that the client is aware of changes to the server-side collection: This guarantee is natural to the Java Iterator class as it throws an exception when another thread modifies the collection while you iterate across it. Loss of this mechanism could cause problems in the event that your application expects to have the current copy of data at all times.

Despite these limitations, you will heavily leverage collections in the application. An important part of creating collections and encouraging pragmatic usage of them is to identify simple query methods that will return the minimal amount of data required for the client to achieve their task with the data.

You will not see a list of all of the requirements that the combination of the Business Object and Business Object Collection patterns fulfill, but Table 7-1 lists some of them.

Table 7-1: Requirements Fulfilled by the Business Object and Business Object Collection Patterns

ID	DESCRIPTION
U1	The application shall have Web-based access to the customer profile for update directly by customers.
U2	The application shall allow customers to access the current order status through a programmatic mechanism and through a user interface.
U3	The application shall enable a customer to access product catalog and sales information through a user interface and programmatically.

The requirements in Table 7-1 show an interesting mix of business objects and collections. For example, U1 shows a user interested in a single customer profile. The customer profile is contained in a business object collection, whereas the profile itself is a business object. On the other hand, a product catalog could be considered a business object containing a business object collection, the latter being a collection of products with their associated prices.

The two concepts of a business object and a business object collection go hand in hand. There are cases where the business object lives without the business object collection, but those cases are few and far between.

Identifying Important Classes and Files in the Case Study

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

Table 7-2: Sample Location

FILE	LOCATION	DESCRIPTION
TestCustomerCollectionWebService.java	src\com\servicefoundry\books\ webservices \tests	A client-side program that uses the deployed Web Service interface to the customer collection.
CustomerCollectionImpl.java	src\com\servicefoundry\books\webservices\entities	The service implementation for the CustomerCollectionImpl class presented in Listing 7-1. This class relies heavily on JDO for storing and retrieving data.

Using Ant Targets to Run the Case Study

Table 7-3 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 Appendix A.

Table 7-3: Ant Targets

TARGET	DESCRIPTION
testcustomercollection	Runs the example code from Listing 7-3