Skip to content

Lotus Symphony based on Eclipse RCP

I installed the latest Office Productivity Pack announced by IBM and called Lotus Symphony. It contains a word processor, a spreadsheet and a presentation program.

I was very impressed by the fact that it has been implemented on Eclipse RCP. In other words its architecture is based on OSGi and Java. Probably it is not 100% Java because a few OSGi bundles reference native dll libraries (IBM proprietary and/or Openoffice components).

It is an interesting proof of the sounding architecture of OSGi and Eclipse RCP for large and complex desktop applications.

Informal comparison of Java Component Models (Javabeans, EJB 2.x, OSGi)

I made an informal comparison table of three Java component models: JavaBeans, EJB 2.x and OSGi. I considered several point of views without being rigorous on terminology. My goal was to show fundamental features of these component models.

Personally I think that previously used component models (in particular EJB) lack many fundamental features that can help developers keeping their applications mainteneable and easy to develop.

An interesting technology that contains these important characteristics is OSGi which is an interesting enabling technology for designing new systems and applications.

Continue reading ›

OSGi and Open Source ecosystem

Update 17 Nov 07

  • Added Newton Project
  • Added Osxa Project

As InfoQ reported this summer, there is an increasing interest in OSGi and its related projects. I have created a table summarizing the status of OSGi in the field of Open Source community. Starting from available open source container, I searched about projects exploiting OSGi and their level of adoption of this technology

There are several levels for OSGi adoption. At the minimum level a project’s team can package its artifacts as OSGi bundles with the goal of deploying them across an OSGi compatible container. At the maximum level a project’s team can strategically adopt OSGi as the component architecture using programming model and services offered by the platform.

A project starting from scratch could exploit OSGi at its maximum level while an existing project could start adopting its features incrementally. In both cases benefits are evident: dependency tracking between components, version tracking, standard deployment format and many more. If your code is monolithic and bad modularized you have to fight against a lot of large refactoring before OSGi-enabling it.

OSGi standard is quite aged (first version was release on 1999) but it seems that only in the last months it is becoming a consolidated platform to build systems. As you can see from the following table several projects have adopted a whole OSGi architecture while many other successfully projects are starting experimenting and/or discussing about it.

I divided table in four categories:

  • OSGi open source containers
  • Projects exploiting an OSGi-based Architecture
  • Projects supporting OSGi deployment
  • Projects experimenting OSGi

Continue reading ›

Adopting OSGi as architectural asset for internal development

n this article I’ll explain how many benefits can be obtained using a component oriented approach for software development adopting the OSGi model as the enabling component model.

A lot of team practices from the software engineering community can be used to reduce and to ease software development. There is another set of practices that lies at the architectural level and can be also adopted successfully for daily software development. One of these practices is the adoption of a modular component-oriented approach to software development relying on a formal component model.

One interesting, complete and innovative component model is the OSGi (Open Service Gateway Initiative) service platform. It is lightweight in contrast with EJB, it supports the full software lifecycle: from development to deployment and it can be used as the basis component model for Java Development. There are several advantages that can be obtained through the adoption of OSGi

Enable truly component development. Building componentized software is a bizarre thing. It’s conceptually very simple, but in practice it is usually quite difficult. It requires forethought, discipline and consistency. This is certainly something that is more difficult to achieve in large systems. OSGi offers a component model that solves most of the basics problems related to components: dependency tracking, version tracking, service binding, …

Continue reading ›