Package de.danet.an.workflow.spis.rms

This package defines the interface to a resource management service (RMS) as used in the de.danet.an.workflow.spis.ras sample implementation.

See:
Description

Interface Summary

ResourceAssignmentContext	This interface defines the callbacks that are needed by DefaultResource to obtain information from the server.
ResourceManagementService	This interface defines the workflow resource management service used in the workflow package.

Class Summary

DefaultGroupResource	This class provides a GroupResource implementation based on the BasicResource.
DefaultResource	This class provides a default implementation of the WfResource's methods workItems, isMemberOfWorkItems and release.
DefaultRoleResource	This class provides a RoleResource implementation based on the BasicResource.
DefaultUserResource	This class provides a UserResource implementation based on the BasicResource.
ResourceManagementServiceFactory	Defines a factory API that enables a workflow component to obtain a workflow resource management service.

Exception Summary

ResourceNotFoundException

This exception is thrown by the resource service implementation if no resource for a given key can be found.

Error Summary

FactoryConfigurationError

This exception is thrown by the newInstance method of ResourceManagementServiceFactory.

Package de.danet.an.workflow.spis.rms Description

This package defines the interface to a resource management service (RMS) as used in the de.danet.an.workflow.spis.ras sample implementation. Note that the implementation of the workflow core does not require a resource management service. However, the sample resource assignment service (RAS) needs a resource management service. We have based the sample RAS on this interface to allow a deployer to use the sample RAS with any resource management service by simply writing an adapter.

The service interface follows the standard conventions for a service interface, i.e. it defines an abstract factory class and a service interface.

Implementing this interface implies a particular problem. The RMS must provide objects that implement WfResource. This interface has, as specified by OMG, methods workItems isMemberOfWorkItems and release. While it is obvious (from an OO point of view) that those methods are defined as methods of WfResource the RMS cannot really implement them. They can only be implemented by an RAS, as it is its task to track assignments. Thus the objects defined and returned by an RMS can only implement the methods by delegating to the RAS.

There may, however, be several instances of RASs in an environment that request resources from the RMS. How can the RMS know, where to delegate to? One way to solve this problem would be to have every RAS "register" itself with the RMS if it assigns a resource from that RMS. This approach has a major drawback. In order to be able to recover from an application restart, the RMS would have to implement such a registry for RASs in persistent store. Depending on the implementation of an RAS, this may be from difficult to impossible.

A much more simple solution is to have a central runtime registry of all available RASs and use the RASs registered there to implement the above mentioned WfResource methods⁽¹⁾. This approach is even more charming as something very close to such a registry exists anyway. While not designed to fulfill this function in the first place, the ResourceAssignmentServiceFactory actually implements a kind of registry, as it must know about all RASs in the system (else there is no way that the workflow core uses it for resource assignment anyway).

The ResourceAssignmentServiceFactory therefore provides the methods needed to implement workItems isMemberOfWorkItems and release. As a convenience this package provides a class ResourceSupport that uses the methods provided by the ResourceAssignmentServiceFactory and can be directly used by an RMS as base class for providing its implementation of WfResource.

(1)Few things in life are free. There is a small performance penalty to pay for this approach. As the RMS doesn't keep track of the RASs that have requested a particular resource, the central registry has to query all known RASs. However, tracking RAS information (e.g. with identifiers usable as hints for the central registry) in the RMS would impose an overhead as well.

Since:

1.0