The factory/instance patterns is a well-known design pattern in software design, and specially in object-oriented languages. In this pattern, we are not allowed to create instances of objects directly, but must do so through a factory that will provide a create operation.

When dealing with multiple resources, the WSRF specs recommend that we follow this pattern, having one service in charge of creating the resources ("the factory service") and another one to actually access the information contained in the resources ("the instance service").

Figure 5.1. The WS-Resource factory pattern

Figure 5.1, “The WS-Resource factory pattern” summarizes the relationship between these two services, the resources, and the client. Whenever the client wants to create a new resource, it will contact the factory service, who will take care of creating and initializing a new resource. It is important to see that, in this case, the resource is also assigned a unique key. Since we are no longer dealing with a single resource, we need some way of telling each resource apart. The factory service will return an endpoint reference to a WS-Resource composed of the instance service and the recently created resource.

Remember from Section 1.3.2, “The resource approach to statefulness” that endpoint references are a part of the WS-Addressing specification. Endpoint references (or EPR's for short) allow us to uniquely address a single WS-Resource. Also, remember that a WS-Resource is the pairing of a service with a particular resource. In our first example client, our EPR included only the service's URI (because we had a single resource). In this chapter, our EPR's will have both the service's URI and the resource's key.

Using the EPR returned by the factory, the client can now invoke the service's operations through the instance service. This service, in turn, will perform the operations using the recently created resource.