Cloud Services focuses on creating innovative solutions by enabling technologies we believe in to work in the cloud environments. Today we would like to present OSGi – the dynamic module system for Java™.
The article by Peter Kriens, Director of Technology for OSGi Alliance, is addressing many questions a newcomer might have on the benefits of developing with OSGi:
Well, these problems are not intrinsic and OSGi technology solves many of them. This article tries to explain why OSGi technology is relevant and why software developers, as well as strategic people, should pay attention. Some people say OSGi technology is the best kept secret of the computing industry. Let us try to change this.
So, what benefits does OSGi’s component system provide you? Well, quite a list:
• Reduced Complexity – Developing with OSGi technology means developing bundles: the OSGi components. Bundles are modules. They hide their internals from other bundles and communicate through well defined services. Hiding internals means more freedom to change later. This not only reduces the number of bugs, it also makes bundles simpler to develop because correctly sized bundles implement a piece of functionality through well defined interfaces. There is an interesting blog that describes what OSGi technology did for their development process.
• Reuse – The OSGi component model makes it very easy to use many third party components in an application. An increasing number of open source projects provide their JARs ready made for OSGi. However, commercial libraries are also becoming available as ready made bundles.
• Real World – The OSGi framework is dynamic. It can update bundles on the fly and services can come and go. Developers used to more traditional Java see this as a very problematic feature and fail to see the advantage. However, it turns out that the real world is highly dynamic and having dynamic services that can come and go makes the services a perfect match for many real world scenarios. For example, a service could model a device in the network. If the device is detected, the service is registered. If the device goes away, the service is unregistered. There are a surprising number of real world scenarios that match this dynamic service model. Applications can therefore reuse the powerful primitives of the service registry (register, get, list with an expressive filter language, and waiting for services to appear and disappear) in their own domain. This not only saves writing code, it also provides global visibility, debugging tools, and more functionality than would have implemented for a dedicated solution. Writing code in such a dynamic environment sounds like a nightmare, but fortunately, there are support classes and frameworks that take most, if not all, of the pain out of it.
We strongly encourage you to read the entire article and see how this technology might benefit you. If you would like a more detailed introduction to OSGi, this is where you could start:
– Getting Started with OSGi by Neil Bartlett.
Cloud Services makes it possible to deploy server side OSGi applications in Amazon EC2 instances. With several mouse clicks exported bundles can be uploaded to remote storage (S3) and added to profile (Launch Configuration). That is all it takes to start virtual servers (EC2 instances) containing OSGi framework provisioned with selected bundles.
