The development of the standard, reusable Windchill services caused the need for a general mechanism to manage the behavior of and interaction between these services. This service management mechanism specifies a protocol for startup, shutdown, and communication between Windchill services.

The wt.properties configuration file includes entries that specify which services should be started automatically when the Windchill server is launched. In addition, each entry specifies a pairing between the service interface and which implementation of the service should be constructed. That is, if other implementations are supplied in addition to the standard implementation of the service, one of the other implementations can be declared to execute in these entries. On the other hand, multiple service interfaces can also be implemented by a single class. For example, the PersistenceManager and PersistenceManagerSvr are both implemented by StandardPersistenceManager. The following is an example of several entries for the standard Windchill services:

The service number dictates the startup order of the service. Services are started from lowest to highest number. If a service depends on other services, those services must be started first.

There are no reserved ranges or values for Windchill services or customized services. At each new release, any out-of-the-box Windchill service may be renumbered, and any new number may be assigned. The maximum value for a service number is 231-1 (=2147483647).

When defining customized services, you should choose a minimum service number that is significantly higher than the highest number used by any Windchill service. The numbers for the Windchill services can be determined by inspecting the wt.services.service.#### entries in <Windchill>/codebase/wt.properties in your installation. Each time you install a new release of Windchill, you need to check the entries in wt.properties to ensure that all of your customized services still have numbers higher than the highest Windchill service number.

For each customized service, you must ensure that its number does not duplicate any number for an existing Windchill service or customized service.

There are entries that are termed either a service or a manager. During the initial stages of Windchill development, the use of the terms manager versus service was unclear. It has been agreed that service represents the more general concept and manager represents those services that are characterized more as managing groups of objects. Currently the terms manager and service appear interchangeably.

In order for services to be managed, they must implement the wt.services.Manager interface. This interface specifies methods for starting and stopping services.

A reference implementation of wt.services.Manager, named wt.services.StandardManager, provides most of the base functionality required for service management. If a new type of service does not require any special startup or shutdown processing, it can extend the base class wt.services.StandardManager without overriding any of its methods.

Two methods in class wt.services.StandardManager are intended to be overridden to specialize startup and shutdown processing. These methods are performStartupProcess and performShutdownProcess. Examples of startup processing include subscribing to service events and establishing queues for use in background processing.

ManagerService is a manager which is used to startup and provide access to a pre- defined list of managers. This list includes different managers for services. In addition to managing managers, the ManagerService provides a synchronous event dispatch service. This service can dispatch a vetoable or non-vetoable event to all listeners for the event key. Each listener may or may not object to the event. The service performs a synchronous "in thread/transaction" notification of each event listener for the event branch identified by the event key. It calls the notifyEvent operation on each subscriber.