KNB Software Development Guide: Metacat Service Based Architecture
	KNB Home	Data	People	Informatics	Biocomplexity	Education	Software

There is a goal to migrate Metacat to a service based architecture. This provides several advantages:

• Cached values can be refreshed via the configuration utility without requiring a restart of Metacat.
• Services can be gracefully shut down when Metacat is stopped. For instance, the database service can make sure all db requests have completed before continuing with shutdown.
• Services can have a common interface to expose MBeans for JMX monitoring (see the Java Management Extensions page).

From a

There are a few basic questions that can be asked when you are creating a class to decide if it should be a service.

• Does this class perform some action repeatedly throughout the lifetime of the Metacat application?
• Does it make sense for this class to cache certain information? This is typically information that is accessed often and seldom changes. For example, system properties rarely change and are constantly being accessed. (Thus the PropertyService class.)
• Would it make sense for the information in the class to be refreshable? Note that this is not a strict requirement, since, as we will discuss, a class can declare itself to be non-refreshable. A good example of a non-refreshable class might be a database service. If core database information changes, that usually requires a system restart, and not a service refresh.

Any of these could signify the need for a service. Note that another option is to create a utility class. Utility classes are singletons that have static methods and less state requirements. See the Utilities Classes page for more information.

All Services extend the BaseService class except the ServiceService class (discussed next).

Currently, BaseService defines three methods:

• refreshable() - a package level abstract method that reports whether the class can be refreshed. This has package level access because we only want ServiceService to be able to access this information. You will need to decide at implementation time whether it makes sense to refresh your service and return the appropriate boolean from this method.
• doRefresh() - a protected abstract method that performs the service refresh. It is protected because it should only be called by the refresh() method (see next). Typically, an implementation of the doRefresh() method updates any cached values in the service and performs any appropriate state-specific service updates.
• refresh() - a package level method that calls refreshable() and doRefresh(). It has package level access because we only want the ServiceService to be able to refresh the service.
• stop() - Gracefully shut down the service, releasing any resources.

The ServiceService class is a exception to the BaseService extension rule. This service controls all other services. It maintains a registry of available services.

Some of the methods available via ServiceService are:

• registerService() - register a service by sending the service name and an instance of the service.
• refreshService() - refresh a service by name.