This website and its associated repositories, are deprecated and no longer supported by the OSGi Alliance. Please visit https://enroute.osgi.org for the latest supported version of OSGi enRoute.
This enRoute v2 archive site is kept for those who do not intend to use the latest version of OSGi enRoute. If you are new to OSGi enRoute, then please start with the latest OSGi enRoute.
The OSGi programming model is based on the collaboration of standard and custom components. In such a model there is no central authority that has global knowledge of the complete application. Though this lack of authority can significantly increase reusability (and robustness) there are times when the activities of the collaborating bundles must be coordinated. For example, a service that is repeatedly called in a task could optimize performance by caching intermediate results until it knew the task was actually ended.
To know when a task involving multiple collaborators has ended is the primary purpose of the Coordinator service specification. The Coordinator service provides a rendezvous for a requestor to create a Coordination that is then associated with the current thread. When the request finished, the Coordination is terminated. Through the Coordinator service anybody being called on the thread can find the current Coordination, similar to how transactions are governed.
For example let’s assume a service is called that sets some information for the current user. Since the API is designed to take element by element, it is generally called a number of times in a web request. Going to the database for each request can be expensive. The service can therefore delay the processing until all requests have been received. To implement this, the service checks