by Pavel Cheshmedjiev
In the last 10 years the Java world welcomed many different technologies, frameworks and initiatives. It is getting harder and harder to keep track of all innovations or at least what Ivko does 
Nevertheless there are technologies that are almost impossible to be missed or neglected. Such technology is the OSGi – Open Services Gateway initiative. For more information visit http://www.osgi.org
While the original focus was on embedded systems OSGi appeared to be too attractive for all in the scope of Java technology. There are a number of papers and much documentation on the OSGi topic so I’ll try to give my point of view and what I think is the real value of OSGi for a typical software developer.
Briefly the OSGi introduces a framework that brings the following main features:
- Modularity
- Life cycle management
- Service orientation
- Execution environment
So why OSGi ? We have the Object Oriented Java language , we can use design patterns and different component models.
The first and most important reason for me is that thinking in the context of OSGi makes a developer think in the direction of best design principles such as service reusability, separation of concerns and loose coupling on any application level. This is very important especially when we design core application layers because usually these layers aim to provide such functionality rather than get use of it. All of these can be achieved with pure language techniques and good practices but not in such lean and standard way. It is also possible that some of the design issues will be left for later refactoring.
Secondly we have all the infrastructure to achieve this – the execution, module, life cycle, service and bundle layers, providing the needed functionality for registering services, life cycle and dependency management etc. We can concentrate on defining the granularity and logic of the modules of our application , what services it will provide, what are the dependencies and how services interact with each other. Respectively we don’t bother with issues related to the class loading, application life cycle, service registry etc. Application bundles can be developed and tested in the most agile way – separately, service oriented and with clear dependencies. Once again – we enhance our application design together with all added values from the OSGi specification.
Currently the OSGi Service Platform, Enterprise specification is available at http://www.osgi.org . Now why Enterprise OSGi ? This time it is a bit more confusing – we have the OSGi core, we have all the JEE world – CORBA, EJB, Spring etc and many JEE frameworks are even based on OSGi implementations – from JBoss micro container to Spring DM. Sounds very complicated but the idea is exactly the opposite. We already have the service platform and management. It is well accepted and adopted. So it is most naturally to think how this platform can be enhanced for the Enterprise world. And what do we need to face the Enterprise world – we need component model, distributed services, life cycle, session, transaction, persistence management and a set of standard services. So that’s exactly what the OSGi Enterprise specification introduces:
- Component model
- Distributed service
- Web applications and http servlets
- Event models
- Management and configuration services
- Naming and directory services
- Database access
- Transaction support
- Miscellaneous Supporting Services
So on the question why Enterprise OSGi – we have the EJB, CORBA and other component models, JPA specification, DI frameworks and many products that provide similar set of functionalities. So what is new and is it alternative to the JEE world. The new approach that OSGi brings is that it keeps the modular and service oriented nature of the application – we are still thinking in bundles and service, but now a bundle can define a set of components, a component might expose a service and live in distributed environment. We may think of the OSGi enterprise profile to OSGi core as RMI model to the Java object – it brings many important features, it is transparent, and the main idea is the same. And Enterprise OSGi integrates the JEE concepts very nicely – it does not define alternative of the EJB containers, neither it specifies own persistence APIs – Enterprise OSGi just introduces EJB and JPA service specifications. Existing implementations can be migrated as standard services and keep all the advantages of the specification and their own realization.
So OSGi, Enterprise or both ? Let’s try both with accent on the proven JEE specifications.
Thanks for your time.