| A service is an API provided by a plugin. A plugin can provide zero or
more services. If a plugin provides many methods which can be called, they
should be logically grouped as services. If a service is requested, and
the plugin providing that service has not already been started, it will be
automatically started. When the service is no longer in use (ie. the
service instance is garbage collected), the plugin may be stopped. (This
is tracked using a
Resource , so the plugin will only be stopped if
there are no other resources causing the plugin to be active.
The service instance should be lightweight (ie. not have state), because
it is possible that multiple instances of the service exist at any time.
If a service implementation provided by a plugin (written in either java
or script) is to be used by code written in java, there must be an abstract
class that subclasses this class to define the API provided by that service.
The implementer of that service must then subclass that service class and
implement the abstract methods defined it defines. It is recommended
that all well defined "core" services provide an interface (abstract
class) that can be implemented by the provider of that service.
NOTE: There is a reason for implementing this as an abstract class,
rather than an interface. It is to prevent the service implementer from
being lazy and just making an existing object implement an interface, which
could pollute the service with other methods which are not part of the
well defined service interface. Script code could inadvertantly call one
of these methods. If the service were to be overridden by another
implementation which did not define those method(s), it could cause run-
time errors. Service implementations should be inner-classes which provide
only those public methods defined by the service.
author:
Rob Clark
version:
0.1 |
