Services
A service is a collection of modules that combine to provide the full functionality defined by the service. A service is defined by three pieces of information:
- A fully qualified java class name that identifies the functionality or API that the service must provide. Typically this class represents a java interface. This class name is termed the factory interface.
- The identifier of the service. Services are identified by a String, this may be hard-coded, come from a UUID or any other source.
- An optional java.util.Properties set.
The running functionality of the service is provided by a module that implements the factory interface. The identifier of the this module is not (need not be) the same as the identifier of the service. The identifier of the service is held by the monitor in its service tables.
Each module in a service is keyed by at least one factory interface, identifier} pair. This pair is guaranteed to be unique within the service.
The lifetime of a module in a service is no longer than the lifetime of the service. Thus shutting down a service shuts down all the modules within a service.
Optionally - an individual module within a service may be shutdown, this will in turn shutdown any modules it started if those module are not in use by other modules within the service. This would be handled by the monitor, not the module itself.
A service may be persistent, it goes through a boot in create mode, and subsequently boot in non-create mode, or a non-peristent service, it always boots in non-create mode. Persistent services can store their re-start parameters in their properties set, the monitor provides the persistent storage of the properties set. Non-persistent services do not have a properties set.
Booting Services
Services can be booted a number of ways
- A non-persistent service can be booted by having a property in the application properties or the system (JVM) set.
derby.service.service name=class name e.g. # Added to the properties automatically by the class org.apache.derby.jdbc.EmbeddedDriver derby.service.jdbc=java.sql.Driver
- A persistent service can be booted by having a property in the application properties or the system (JVM) set.
derby.service.service name=persistent storage type e.g. derby.service.mydatabase=serviceDirectory
serviceDirectory is a type understood by the monitor which means that there is a directory named mydatabase within the system directory and within it is a properties file service.properties. This properties set is the set for the service and must contain a property derby.protocol=class name
This is then the factory interface for the service. Other storage types could be added in the future. - The monitor at start time looks for all persistent services that it can find and starts them. E.g. all directories in the system directory that have a file service.properties are started as services.
- Services are started on demand, e.g. a findService attempts to boot a service if it cannot be found.
Any or all of these three latter methods can be implemented. A first release may just implement the look for all services and boot them. .
System Service
A special service exists, the System Service. This service has no factory interface, no identifier and no Properties set. It allows modules to be started that are required by another service (or the monitor itself) but are not fundamentally part of the service. Modules within this service are unidentified. Typically these modules are system wide types of functionality like streams, uuid creation etc.
The lifetime of a system module is the lifetime of the monitor. Optionally - this could be changed to reference count on individual modules, requires some minor api changes.
Modules
A module is found or booted using four pieces of information:
- The service the module lives in or will live in.
- A fully qualified java class name that identifies the functionality or API that the module must provide. Typically this class represents a java interface. This class name is termed the factory interface.
- The identifier of the module. Modules are identified by a String, this may be null, be hard-coded, come from a UUID or any other source. If the identifier is null then the module is described as unidentified.
- Boot time only - A java.util.Properties set. This Properties set is service wide and typically contains parameters used to determine module implementation or runtime behaviour.
The service is identified by explicitly identifiying the System Service or by providing a reference to a module that already exists with the required service.
The factory interface is provided by a String constant of the form class.MODULE from the required interface.
The module identifier is provided in a fashion determined by the code, in most cases a unidentified module will suffice.
The Properties set is also determined in a fashion determined by the code at create or add service time.
Module Implementations
When creating an instance of a module, an implementation is found through lists of potential implementations.
A list of potential implementations is obtained from a Properties set. Any property within this set that is of the form
derby.module.tag=java class name
is seen by the monitor as a possible implementation.
tag has no meaning within the monitor, it is only there to provide uniqueness within the properties file. Typically the tag is to provide some description for human readers of the properties file, e.g. derby.module.lockManager for an implementation of a lock manager.
The monitor looks through four properties sets for lists of potential implementations in this order.
- The properties set of the service (i.e. that passed into Monitor.createPersistentService() or Monitor.startService()).
- The System (JVM) properties set (i.e. java.lang.System.getProperties()).
- The application properties set (i.e. obtained from the derby.properties file).
- The default implementation properties set (i.e. obtained from the /org/apache/derby/modules.properties resource).
Any one of the properties can be missing or not have any implementations listed within it.
Every request to create an instance of a module searches the four implementation lists in the order above. Which list the current running code or the passed in service module came from is not relevant.
Within each list of potential implementations the search is conducted as follows:
- Attempt to load the class, if the class cannot be loaded skip to the next potential implementation.
- See if the factory interface is assignable from the class (isAssignableFrom() method of java.lang.Class), if not skip to the next potential implementation.
- See if an instance of the class can be created without any exceptions (newInstance() method of java.lang.Class), if not skip to the next potential implementation.
- [boot time only] See if the canSupport() method of ModuleControl returns true when called with the Properties set of the service, if not skip to the next potential implementation.
If all these checks pass then the instance is a valid implementation and its boot() method of ModuleControl is called to activate it. Note that the search order within the list obtained from a Properties set is not guaranteed.
Module Searching
When searching for a module the search space is always restricted to a single service. This service is usually the system service or the service of the module making the search request. It would be very rare (wrong?) to search for a module in a service that was not the current service and not the system service.
Within the list of modules in the service the search is conducted as follows:
- See if the instance of the module an instance of the factory interface (isInstance() method of java.lang.Class), if not skip to the next module.
- See if the identifier of the module matches the required identifier, if not skip to the next module.
- See if the canSupport() method of ModuleControl returns true when called with the Properties set of the service, if not skip to the next module.
Note that no search order of the modules is guaranteed.
Also note that a module may be found by a different factory interface to the one it was created under. Thus a class may implement multiple factory interfaces, its boot method has no knowledge of which factory interface it was requested by.
Service Properties
Within the service's Properties a module may search for its parameters. It identifies its parameters using a unqiue parameter name and its identifier.
Unique parameter names are made unique through the 'dot' convention of Properties files. A module protocol picks some unique key portion to start, e.g. RawStore for the RawStoreFactory and then extends that for specific parameters, e.g. RawStore.PageSize. Thus parameters that are typically understood by all implementations of that protocol would start with that key portion. Parameters for specific implementations add another key portion onto the protocol key portion, e.g. RawStore.FileSystem for an file system implementation of the raw store, with a specific parameter being RawStore.FileSystem.SectorSize.
These are general guidelines, UUID's could be used as the properties keys but would make the parameters hard to read.
When a module is unidentified it should look for a parameter using just the property key for that parameter, e.g. getProperty("RawStore.PageSize").
When a module has an identifier is should look for a property using the key with a dot and the identifier appended, e.g. getProperty("RawStore.PageSize" + "." + identifier).
In addition to searching for parameters in the service properties set, the system and application set may be searched using the getProperty() method of ModuleFactory.
Should any order be defined for this, should it be automatic?