An Introduction to the SAT Runtime

The Service Activator Toolkit (SAT) enables the development of service oriented OSGi bundle activators by making the registration of services and the acquisition of services easy.

Before learning about SAT it is important to have an understanding of the functionality of the OSGi Service Platform. The OSGi Service Platform Specification is available at the OSGi Alliance website.

By taking care of many of the complex OSGi Service Platform plumbing issues, the SAT runtime allows a developer to focus on building the application domain logic and defining how the application bundles collaborate.

What is the SAT Runtime?

The SAT runtime is a 100% pure Java toolkit that is packaged as OSGi bundles. The SAT runtime consists of:

A bundle called org.eclipse.soda.sat.core that exports packages and services that other bundles import to assist with the development of service oriented OSGi bundle activators and related behavior.
An optional bundle called org.eclipse.soda.sat.log.writer that reads log events from the OSGi LogService and writes them to the system console. This bundle is intended primarily for use during the development and debugging of an OSGi application. Without this bundle it is easy to miss important log events that are written to the OSGi LogService.
An optional bundle called org.eclipse.soda.sat.dependency.servlet that registers a servlet with the OSGi HttpService that allows the bundle dependencies that exist in the OSGi framework to be queried. The bundle dependencies may be queried programmatically via HTTP, via a web browser, and via the Eclipse IDE-based Bundle Dependencies view that is contributed by the SAT tooling.

The Benefits of Using SAT

The OSGi Service Platform was built as a horizontal component framework that is intended for a wide variety of vertical applications. The flexibility of the OSGi Service Platform comes at the cost of complexity. An application built for the OSGi Service Platform and that employs service oriented bundles is typically comprised of a variety of bundles, including:

Exporter of a Service: Bundles that export a service are simple to implement using the OSGi framework since they do not have dependencies on other bundles. Bundles that export a service simply need to decide when the service should be registered and unregistered with the OSGi framework.
Importer of a Service: Bundles that import a service are more complex to implement using the OSGi framework since the relationship between the bundle and the imported service must be managed. Bundles that import a service must be able to handle the case where a service it imports is unavailable and when a service is dynamically registered, unregistered and modified.
Importer and Exporter of a Service: Bundles that import a service to allow them to export another service are the most complex of all. Not only does the relationship between the bundle and the imported service needs to be managed, but they also must decide when the service they export needs to be registered and unregistered with the OSGi framework.

Of course bundles that import or export multiple services are proportionally more complex. As the complexity increases, it becomes more difficult to create consistent, accurate and bug-free service oriented bundles.

Through a small number of assumptions, SAT greatly simplifies the creation of service oriented bundles as compared to using the OSGi framework's APIs directly. From an application perspective, it can be assumed that:

Exported Services: An exported service is registered with the OSGi framework when its bundle is started, and unregistered with the OSGi framework when its bundle is stopped.
Imported Services: An imported service is acquired from the OSGi framework when its bundle is started, and released back to the OSGi framework when its bundle is stopped.
Imported Services and Exported Services: A bundle registers its exported services with the OSGi framework when all its imported services have been acquired from the OSGi framework. A bundle will release its exported services back to the OSGi framework when one or more of its imported services have been unregistered with the OSGi framework.

These assumptions are the cornerstone of SAT and consequently are typically true for service oriented bundles built using SAT. These assumptions are supported by SAT through a simple API to the OSGi framework. By using SAT, a developer can focus on the domain model of the application and handling the availability of services in a domain specific way.

The main benefits of using SAT can be summarized as:

Simplified creation of OSGi bundle activators for service oriented bundles.
Automatic notification of service availability and modification changes that affect a bundle.
A service oriented bundle behaves in a well-defined way.
Reduced bundle footprint by using common abstractions.
Increased bundle reliability and predictability.
Reduced bundle development time.
Reduced training costs; not everyone need to be an OSGi expert.
Allows you to decouple your business logic from OSGi and the dependency injection in the bundle activator. This enables:
- Simplified business logic unit testing.
- Reuse of the business logic on other runtimes, including a statically bound Java applications.

Migrating to and from SAT

Since OSGi bundles and SAT bundles can co-exist, it is entirely possible to start using SAT on a project where OSGi bundles have already been built.

An application can be built entirely from OSGi bundles, a mixture of OSGi bundles and SAT bundles, or entirely of SAT bundles.
It is simple to migrate an OSGi bundle to be an SAT bundle, and possible, be it much more work, to migrate an SAT bundle to be an OSGi bundle.

| Next