In this interview, IDN’s Chief Editor, Detlef Reiß, interviewed Mirko Jahn, a software architect at ICW and got to talking about the use of OSGi in ICW.

According to the their website OSGi technology "is Universal Middleware. OSGi technology provides a service-oriented, component-based environment for developers and offers standardized ways to manage the software lifecycle. These capabilities greatly increase the value of a wide range of computers and devices that use the Java platform."

Open standards are a crucial part of our software development strategy. Of course, we are developing our own APIs to deal with domain specific problems, but as soon as we are facing common problems the benefits of standards outweigh the proprietary ones. By using open standards, we can speed-up our development process by using already existing solutions, which in many cases have proven their reliability and depending on the implementer might even provide enterprise ready support. At a later time, we of course can decide to implement our own version, but we are not forced to do so. On the other hand, our goal is also to open our software for third parties and for them being able to use open and well known standard is crucial. No one wants to be locked into some vendor specific solution, if there is a well known standard available. OSGi is the de facto standard in Java for componentization and addresses common drawbacks of plain Java that even JEE wasn’t able to solve. With JSR 291 OSGi became an open standard specified by the Java Community Process and will most likely be supported by JSR 277 for the next Java 7 release. We are working with OSGi for many years now and believe that it is the right way to go. In our current projects OSGi is the core building block for our software product line and boosted our development process significantly.

OSGi as a componentization standard is pretty lightweight. The only thing you have to do is to add some manifest entries to your JAR files, so you can pretty much use it wherever you would use Java. Having said that, to really benefit from its capabilities, you have to do more things like correct versioning of your bundles (JAR-Files) and more importantly packages, your software design needs to take certain specifics of OSGi into account. In some use cases this extra effort doesn’t make sense, like for prototyping or simple scripting. Here plain Java or even dynamic languages like Groovy or JRuby might make more sense. Here at eHI we use OSGi whenever we see potential for reuse und certainly for every artefact we intend to integrate in our software product line. In the build system of our product line, we check on several metrics to ensure code quality and help us to propel software reuse. The bundles with their enriched metadata provide us with information on their interoperability and as a result help us to maintain robust and maintainable software.

I am not an expert for all Product Houses but I know that several of them are already using OSGi as their componentization strategy, either in their product or in prototypes for their new software. At eHI we have based our Connector architecture for almost 4 years on OSGi and we are in the process of extracting a framework from this architecture called the Connector Composite Framework (CCF) that has OSGi as its foundation.

Our main two OSGi based applications are the Gematik and SureScripts Connector products. Those two products already share a common subset of functionality in the form of OSGi bundles. Our goal with the CCF is to formalize and version this foundation which provides all the infrastructure plumbing like security, web services, web UI framework, workflow, etc., so that application developers inside and outside of eHI can take this framework and use it to build their own value added applications.

As soon as we see potential for reuse of certain parts of the domain specific applications we push them down into the core framework so that every other application can benefit from them. So far we have more than 240 bundles that we are sharing among different applications.

With the foundation of an internal OSGi working group within ICW's Architecture Board we are trying to document, harmonize and leverage the usage of OSGi in ICW. One concrete effort is an OSGi Guidance and Positioning paper driven by eHI, with contributions from other Product Houses that is currently being prepared. ICW is also investigating the possibility of becoming an OSGi Supporter in order to make a visible commitment to the standard and to support the adoption of it as the de facto standard for Java componentization.

Because of our long history of using OSGi, we are currently working on topics that are becoming increasingly important in the context of software reuse and security. One of the topics I am involved with right now is a build verification tool that ensures the compatibility of components. OSGi allows us to specify versions of bundles and packages, but there are currently no tools that actually prevent us from miss-specifying them. As a result the manual versioning is error prone and requires a very deep knowledge on the part of the developer to get the versioning right. Tools can help us to get rid of the “human” factor and create artifacts that are really compliant with our versioning rules - the building block for any software reuse. A second project is application security in OSGi. Till now, we mainly focus on using software in a secure way, meaning we are trying to build software that can’t be misused by allowing a user to gain more rights than he is supposed to have on a single application basis. OSGi however allows us to run several applications in the same container side by side, like insurance and eHealth applications for instance – both sharing basic building blocks so that it is not obvious where one application ends and the other begins. Of course, the last thing you want to happen is to grant your insurance company access to your confidential e-health records. This kind of application security is pretty much undiscovered territory for open and non-deterministic component frameworks and needs further research in order to drive reuse on one hand and information security on the other.

OSGi is a specification and there are currently several implementers providing OSGi certified frameworks. Although the specification is very specific about the implementation to guarantee interoperability, it still leaves a great amount of freedom for each provider to distinguish themselves from others. For one, not every detail of the specification is mandatory, so from the number of provided features it may only mean that there is one feature to take into account, but there are more. In eHI, we rely on the ProSyst mBedded Server (mBS) a commercial product, which not only offers us enterprise grade support, it also provides an enterprise grade remote management system which is capable of managing thousands of framework instances in a convenient way. The advantage of using a standard like OSGi is that although we are using the mBS we are not bound to it. When our customers don’t need specific features offered by ProSyst or are not willing to pay for the added value, we can still provide an open solution based on one of the open source alternatives. In some scenarios, special features like the adapter-hooks or the extension mechanism Equinox offers might be crucial, in others the better performance of Felix might be the feature that drives the decision. With a standards-based solution we can adapt to the specific need quickly and without any hassle. Our core CCF framework strives to remain implementation agnostic, where special applications built upon it can utilize certain proprietary features. This is the kind of flexibility that makes OSGi so valuable to us.

In January Markus Gumbel and I are going to give a talk about our security solution in OSGi. Under the title “Application isolation – software reuse without misuse” we are going to share our experiences and strategies in the domain of application security. As mentioned before, this area is not yet covered widely and we at eHI believe it is important for the future of application development once componentization and software reuse becomes a matter of fact than just a humble goal. Actually the buzz about OSGi is just starting and many companies are right now discovering the potential of OSGi. By talking about our experiences we are trying to play our role and give something back to the community. Right now we are planning to talk about more and more things that we are doing for quite some time here internally at ICW. Watch out for conferences about OSGi. In 2009, we intend to provide more and more insights about our solutions. In the mean time, we are preparing more articles about common pitfalls and best practices working with the specification. As one of the first artifacts the previously mentioned OSGi Guidance and Positioning paper will be created to help people getting started with OSGi. This paper should significantly lower the barrier to entry when adopting this technology and hopefully jumpstart a lively community around the topic OSGi and software reuse here at ICW. I think you can expect interesting input in the near future from our team here at eHI.

Our thanks to Mirko for telling us about OSGi activities at ICW.

Mirko Jahn works as a Junior Software Architect at InterComponentWare AG in Walldorf. As an OSGi expert and componentization specialist, he mainly focuses on driving software reuse within ICW by guiding the architecture and build process of the software product line. As his second occupation he works on application security design and is responsible for providing a Common Criteria evaluated Gematik Konnektor. You can also stay current with Mirko's OSGi work on his personal blog: http://osgi.mjahn.net