A software component is a re-useable, related, self-contained "chunk" of an application. A component can be installed, started, stopped, uninstalled and updated independently of other components in an application or system. Thus, components are intended to make a system easier to maintain. New or updated components can easily be switched for existing components - to introduce bug fixes or enhanced functionality.
In Oxygen a component is simply all the Java classes and resources in a JAR file. Oxygen attempts to search for a human readable name for the component in the JAR manifest under the Component-Name attribute. If no name (or manifest) is found Oxygen will name the component after the JAR filename. This name only appears in debug and user interfaces and makes debugging easier.
There are two types of component that can be written that are slightly different.
Library components - normally supply re-useable chunks of code (class libraries). They do not share instances of classes (objects). This is just a plain JAR file, nothing special is required.
Dynamic components - share software services (see below), that is dynamic components provide and consume object instances with each other. Dynamic components need a class that is used by the Oxygen framework to control the dynamic behaviour of the component. Such components need to declare a class that implementsComponentActivator, and has a no-argument constructor (allowing an instance to be created by the java.lang.Class instance() method). The class that activates the component is declared in the Component-Activator manifest entry of the JAR file.
By default all classes in a component (JAR) are made available to all other components operating in Oxygen - as if they were on the regular Java class path. However components can stop certain named packages from being made available to other components by supplying a Package-Excludes manifest attribute listing the packages that the JAR is NOT to share. Wildcards such ascom.acme.secrets.* are acceptable as well as individual class names.
A software service is a interface driven contract between two parties describing some runtime functionality one will provide that the other will consumer.
A service is normally defined by some abstract Java interface - providers implement this interface and register their service implementation with some central registry under the service name (normally the fully qualified name of the service interface). For example imagine a service that is used to generate random numbers, defined by the following interface:
A component can be written that contains a class that implements that interface, as follows:
Service consumers are built against the service interface, never knowing (or caring) which component provides an implementation of the service. Service consumers acquire a reference to the service implementation at runtime by registering an interest with the Oxygen framework (a ServiceManager) for any implementations registered under the service name. This provides strong de-coupling between service providers and consumers and allows the two to be "switched" without the other caring.