The Foundation of an OSGi-Based Application: Design and Bundles
Open Service Gateway Initiative (OSGi) is a popular standard that begun in embedded systems, expanded to mobile platforms, and is now actively adopted in the Java world. OSGi characteristics such as modularity, service orientation, reuse, dynamic updates and component versioning allow it to overcome the factors that limit the scope of the Java platform. For its part, Java is working towards OSGi-style functionality by including JSRs like JSR 294, 291, and 277 the upcoming Java 7 release.
OSGi has already made waves in the software industry with many established products such as Spring dm server, Oracle (formerly known as BEA) WebLogic, IBM WebShere, JBoss, and Eclipse IDE adopting the OSGi architecture for its modularity and flexibility. Even now, efforts are under way to develop distributed OSGi solutions (at the Apache CXF Distributed OSGi subproject, for example), which will enable efficient communication between multiple OSGi containers.
An OSGi Overview
The core of the OSGi specification is a framework that defines:
- An application lifecycle management model
- A service registry
- An execution environment
- An atomic part of the application that is composed of modules or components
These definitions standardize how you define modules or components and how you manage the lifecycle of these components.
The non-proprietary OSGi platform spans:
- Mobile phones
- Embedded systems
- Desktop software
- High-end servers
The beauty of the OSGi runtime is that you can install, update, or remove components on the flywithout interrupting existing operations. This feature makes OSGi ideal for domains where component/module provisioning must occur without interruptions to the existing operations (e.g., grid and cloud computing).
Largely because it allows multiple components to interact efficiently and securely in a Java Virtual Machine (JVM), OSGi claims the title: "The Dynamic Module System for Java." With its rich security model, OSGi allows each component to run in its own secured environment. However, by setting the proper permissions, you can enable OSGi components to reuse other components, a capability that differentiates OSGi from other containers. This is what makes the OSGi framework lightweight and reusable.
OSGi also can expose Plain Old Java Object (POJO) services at each component level, a service-oriented way for components to communicate with each other. While binding occurs at the interface level, this feature will not bind components at the implementation level. So, at any time a service provider can change the implementation without changing and interrupting the service consumer. Designers utilize this SOA aspect of the OSGi framework to build loosely coupled applications. In fact, OSGi brings SOA to core Java-based applications without complexity.
OSGi in the Real World (Hypothetically): A Case Study
The demo application is a user login component centered on implementing user authentication for access to back-end resources. This example will allow us to explore reusability and size reduction of individual bundles, as well as how features such as OSGi services and Eclipse plug-in extension points like Splash Handler and preference pages fit perfectly for the application's requirements.
Here are the use case details:
- Tim, an architect for StarTrek Company, leads a software team who need to build a Java-based, thick-client application.
- The application must provide users with a rich user interface (UI) and experience.
- The application must interact with many back-end applications, some of which expose web services, some are database storage, and others could be socket servers.
- These back-end applications are intranet based and located inside the company's network. They give access only to valid StarTrek Company users.
- For security purposes, before allowing users to access the back-end applications, a login component will verify their credentials against the company's LDAP or database.
So, this StarTrek project calls for Tim's team to validate against LDAP and ensure that henceforth intranet-based applications are integrated using NTLM authentication, in the same way that all the database- and socket-based systems are authenticated using the same LDAP system.
First, Tim evaluated the available technologies for building the thick-client application. He finally chose the Eclipse Equinox implementation of OSGi because of this open source framework's maturity and features. He also liked the active support from the open source community. The other open source OSGi implementations, Apache Felix and knopflerfish, weren't as popular as Equinox largely because the Eclipse IDE itself uses the Equinox container.
Page 1 of 2