An Overview

What does OSGi stand for?

Well, explaining that it is the Open Service Gateway initiative is making some people upset that control the purse that pays me. So it is not related to a gateway, that is a thing of OSGi's past and the OSGi Alliance tries to forget this abbreviation. If you feel a pressing need for a logical abbreviation, please call it the Open Specifications Group Initiative, but officially it is just a trademark with no special meaning.

So what does it stand for then? The shortest description I know is Universal Middleware. Software that you write once and then can use in binary form universally: in many different platforms, many different industries, and for many different purposes.

Universal Middleware

The OSGi Alliance tries to establish a standard so that different software components can meet for the first time in a computer and collaborate in a friendly way. This is quite different from the way software is traditionally constructed where an application is carefully crafted and then tested before it is deployed. These steps are a necessesity with todays tools because too many software blocks blindly assume too many details. If these assumptions turn out not to be true, the application fails, usually in a miserable way. The only way to achieve reliability is to integrate to test the hell out of it.

Let us take a look at what would be needed to achieve a standard that would achieve the goal of universal middleware.

Portability

Portability between hardware platforms is a precondition. Looking at the market 8 years ago when the Alliance got started there was only one portable solution in the market: Java. Looking at the market today, that choice was validated because there is still no reasonable alternative. Only Java gives the unprecedented portability between hundreds of hardware/os platforms. I am claiming it is perfect, but nothing else gets even remotely close. Forget Python, forget Ruby, forget .NET, if you really look at the details they are a remote dot on the horizon.

Deployment format

For a component system, programmers need to deliver artifacts that can be processed by the repositories and deployment agents. This needs to be standardized because the whole idea is that developers can create middleware that can be deployed universally. Unfortunately, Java lacks such a format. The JAR file format gets close but lacks important metadata. The OSGi Alliance therfore built their specification on the JAR files, providing the required metadata. This format is called the bundle.

Sharing

Universal Middleware implies that the components will run in a shared environment. Sharing resources is painful and requires lots of rules. A significant part of the OSGi framework specification is the module layer, which concerns itself with sharing the Virtual Machine. Components can export code to the OSGi platform, to be used by other components, but they can also import code from the platform or other components. Managing this sharing is hellishly complex. Fortunately component developers do not have to concern themselves with this complexity; this has been taken care of by the specification and the framework implementations.

Collaboration

The next question is, how should components meet? If the environment is dynamic and unknown, how can a component find another component? To address this issue, we developed a service oriented architecture before web services put SOA on the map. Bundles can register services, they can find services, they can bind to services, they can unbind the services, and they can receive notifications when services are registered or unregistered. Services sound like a big thing but in the OSGi service registry they are not. They are plain old Java objects (POJOs) that are registered with a list of interfaces or classes they implement together with a set of properties. Due to security we carefully protect the providers and consumers from each other but in the end all you have to do is register a normal Java object.

Service objects should be registerd under their Java interfaces instead of their implementation classes. This separation of specification and implementation allows many different parties to compete for providing this service. For this reason, the OSGi has standardized many services for common tasks. However, any organization can standardize services.

The service registry therefore allows bundles to find other components by the interfaces they implement. Further refinement of the choice can use the service properties. In practice the selection process of what service should be used is quite straightforward.

Management

The last remaining item is the management of the environment. How do you install bundles, monitor them, and uninstall them? The OSGi Framework provides a complete API for the life cycle management. By standardizing this aspect, management applications can be standardized.

Security

Last, but absolutely not leats for the OSGi Alliance. Not all components are created equal, which immediately puts up the question of security. Can components be protected from one another? Well, yes. Security has been an intrinsic part of all the OSGi specifications. Security starts with proper authentication. The authentication of bundles uses signing with digital certificates, is bundle location based, or follows a custom pattern. Depending on the authentication, the bundle receives a set of authorizations, which we call permissions. Each specification of the OSGi Alliance contains a separate section which models the permissions for that subject. For example, there is a permission to export and import a Java package.

The OSGi security model is extremely fine grained. Fortunately, it is optional, implementations that do not require can ignore the security model. Further, bundles can contain their own permissions that are intersected with the permissions it receives based on its identity. This at first sight paradoxical model gives each signer fine grained control over its security domain without compromising the overall security. This model significantly reduces the number of required identities.

Conclusion

The OSGi Alliance has developed a comprehensive architecture for componentizing applications. Many aspects of the specifications were ahead of the industry at their creation time. However, the software industry is moving into a direction where the OSGi Alliance has threaded for some time.

• Read also OSGi Technical Overview