Implementing the instance service is going to be very simple, since we can reuse both the WSDL file and practically all the Java implementation from the previous chapter (with only minor changes to the resource class).

	The implementation of the instance service is $EXAMPLES_DIR/org/globus/examples/services/core/factory/impl/MathService.java.

But let's not leave it at that: this is a good moment to ask ourselves: why exactly can we reuse both the WSDL file and the Java implementation of the service and the resource? Well, take into account that what we are doing in this chapter, in a sense, is a generalization of the singleton service. In the previous chapter, we were interested in having a service with operations add, subtract, and getValueRP that interacted with a single (or singleton) resource. Interacting with multiple resources doesn't fundamentally affect the implementation of the service that will be accessing the resources; it only affects those parts of our application that are in charge of managing the resource. We've added a new factory service and, as we shall see right now, we have to modify the resource home. But the instance service is unaffected because it doesn't really care whether it has access to one or a million resources.

Even so, this doesn't mean that there isn't more stuff happening in the 'background' in the instance service. For example, in the add operation:

public AddResponse add(int a) throws RemoteException {
	MathResource mathResource = getResource();
	mathResource.setValue(mathResource.getValue() + a);
	mathResource.setLastOp("ADDITION");

	return new AddResponse();
}

We are still calling the getResource, which is still implemented as in the previous chapter:

private MathResource getResource() throws RemoteException {
	Object resource = null;
	try {
		resource = ResourceContext.getResourceContext().getResource();
	} catch (Exception e) {
		throw new RemoteException("", e);
	}
		
	MathResource mathResource = (MathResource) resource;
	return mathResource;
}

However, the Globus-supplied ResourceContext will do more than simply look up a singleton resource. It will look inside the endpoint reference that is used to invoke add, extract the resource key, and lookup the corresponding resource through the resource home. One of the nice things about using endpoint references, instead of plain URIs, is that the resource key is passed to the service transparently, so our methods can be declared simply as add(int a), instead of something like add(int a, int resourceID).

	Now is a good moment to review Figure 5.4, “Sequence diagram for WS-Resource invocation”.