The core API is only one package and less than 30 classes/interfaces.
Simple - The OSGi API is surprisingly simple. Though it is not advised to design systems with this versioning issue, it can be a life saver in some cases. This allows both bundle A and C to function with their own library. In the OSGi environment, all bundles are carefully versioned and only bundles that can collaborate are wired together in the same class space. JAR hell is the problem that library A works with library B version=2, but library C can only work with B version=3. Versioning - OSGi technology solves JAR hell. Instead of staring at millions of lines of logging output and long reboot times, OSGi applications can often be debugged with a live command shell. Parts of the applications can be stopped to debug a certain problem, or diagnostic bundles can be brought in. For example, most frameworks provide a command shell that shows this internal state. The management API provides access to the internal state of a bundle as well as how it is connected to other bundles. Transparency - Bundles and services are first class citizens in the OSGi environment.
#Projectlibre osgi code
This makes code more flexible and resilient to changes. This dynamic service model allows bundles to find out what capabilities are available on the system and adapt the functionality they can provide. The OSGi service registry is a dynamic registry where bundles can register, get, and listen to services. This requires that the dependencies of components need to be specified and it requires components to live in an environment where their optional dependencies are not always available. However, after using this in development for some time, most start to realize that it actually works and significantly reduces deployment times.Īdaptive - The OSGi component model is designed from the ground up to allow the mixing and matching of components. Many Java developers do not believe this can be done reliably and therefore initially do not use this in production. Bundles can be installed, started, stopped, updated, and uninstalled without bringing down the whole system. The standardized management API makes it very easy to integrate OSGi technology in existing and future systems.ĭynamic Updates - The OSGi component model is a dynamic model. This management agent can be as simple as a command shell, a TR-69 management protocol driver, OMA DM protocol driver, a cloud computing interface for Amazon's EC2, or an IBM Tivoli management system. This API has been used by many bundles to provide a management agent. It also specifies how components are installed and managed. 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.Įasy Deployment - The OSGi technology is not just a standard for components. This not only saves writing code, it also provides global visibility, debugging tools, and more functionality than would have implemented for a dedicated solution. 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. There are a surprising number of real world scenarios that match this dynamic service model. If the device goes away, the service is unregistered. If the device is detected, the service is registered. For example, a service could model a device in the network. 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. Developers used to more traditional Java see this as a very problematic feature and fail to see the advantage.
#Projectlibre osgi update
It can update bundles on the fly and services can come and go. Real World - The OSGi framework is dynamic. However, commercial libraries are also becoming available as ready made bundles.
An increasing number of open source projects provide their JARs ready made for OSGi. Reuse - The OSGi component model makes it very easy to use many third party components in an application. There is an interesting blog that describes what OSGi technology did for their development process. 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. Hiding internals means more freedom to change later. They hide their internals from other bundles and communicate through well defined services. Reduced Complexity - Developing with OSGi technology means developing bundles: the OSGi components. What benefits does OSGi's component system provide you?
0 kommentar(er)
