Skip to content

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 ›

2006 11 15 Articles Comments (0) Permalink

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 ›

2006 11 09 Articles Comments (1) Permalink

Recording streams with mplayer (real audio, asf, …)

Problem: I have a Unix server (BSD at the moment) always on and I want to record real audio streams daily, encoding them in mp3 to listen later in my ipod.

Solution: mplayer, lame, shell script and cron

1) I wrote a script called record.sh that get an output filename and an url representing the stream to record

#!/bin/sh
# Usage:
# record.sh <file> <url_to_record>
mplayer -quiet -cache 32 -vc dummy -vo null -ao pcm:file=$1.wav $2 > /dev/null
lame –quiet –preset radio $1.wav $1.mp3
rm $1.wav > /dev/null

2) I wrote a script that grabs my favourite program. Call it for example grab_xyz.sh

#!/bin/sh
RECORD=/home/pc/bin/record.sh
filename=/data/shared/P2PDownload/toListen/$(date+%y%m%d)_xyz
$RECORD $filename rtsp://url/xyz.rm

3) Finally I edited a cron job (cfr: crontab -e)

# Record ‘XYZ from Live Stream’ (from 13.30 to 14.30)
30 13 * * *     $HOME/bin/grab_xyz.sh
30 14 * * *     /bin/killall mplayer

4) At end I’ll find (in toListen directory)

060118_xyz.mp3
060117_xyz.mp3
060116_xyz.mp3
2006 10 09 Hack Comments (0) Permalink

Software design principles (mined from books)

In the last post I wrote that “Design principles are quite generic and abstract that rarely help concretely a developer during the process of software design”. In this post I report a list of Software Design principles that I have mined from several books, papers.

Source: [Gamma et all, “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley, 1995]

  • Program an Interface not an Implementation
  • Favor Composition Versus Inheritance
  • Find what varies and encapsulate it

Source: [R. Martin, “Agile Software Development, Principles, Patterns, and Practices”, Prentice-Hall, 2002]

Continue reading ›

2006 10 08 Articles Comments (0) Permalink

Why Software Patterns are important

There is a sounding question that I started investigating many years ago. The question is: “How to design software?“. The hard side of this question is that software design and in general software development is fundamentally hard.

As Fred Brooks suggests in his book is: “Complexity of software is an essential property, not an accidental one“. In other words software development is about managing complexity and the goal of a team is to build the illusion of simplicity.

I agree with Grady Booch when he writes in his paper that the:

“difficulty of design lies in disclosing which design and architectural decisions should be used to best balance the technical, economical, business, political and emotional that swirl around every software intensive system”.

To put in other terms as Booch continues:

“the problem of design is NP-complete“. An optimal solution that balances forces exists but it is not computable. “So we have to accept a compromise and selecting then a good enough solution for our design problem“.

Continue reading ›

2006 10 08 Articles Comments (0) Permalink