Archief voor categorie OSGi
OSGi Configuration Admin command line client restored
It has been lost for a long time, but i finally restored the Luminis OSGi Config Admin command line client!
I can here you think. “Restored? Lost? What was this guy doing?”
It’s a long story, and I don’t even know all the ugly details myself, but we (Luminis) used to host our open source projects on a separate server, with all that nice Atlassian collaboration tools like Confluence and Jira. It was a hosted environment, so we didn’t have to manage anything. Well, that’s what we thought.
One of my favorite oneliners is: “the fact that the chances are low, doesn’t means it’s never happening”. How true. The server crashed and it turned out there was no backup. Oops, that hurts.
Of course, i’m lazy, so the latest source was still on my laptop. But only the latest. Not a big deal, but I hate losing history. Worse: i never checked-in the documentation, because I’d written it right into Confluence; after all, that’s what a wiki is for, right? You know the feeling when your word processor crashes and makes you lose work: yes, you can recreate it, but you always end up with the nasty feeling that the original version was better written. I hate that too.
It took me a few hours of digging the internet, but finally i found some traces of my docs in Google’s cache; enough to restore it quite easily. The source history is lost forever, but well, what the hack.
I swore this will never happen again, so i made two promises.
One: i’ll never use subversion again. I was already using Git now and then, but I never realized that having the whole repository on each system has more advantages than just speed and being able to work offline.
Two: i’d better keep the documentation with the source.
You can find the source and the renewed docs on bitbucket. All in one git repository. Please clone it, so I’ll have one more backup when something terrible happens.
Op 24 oktober 2011 vond een kennissessie plaats over services in gedistribueerde en/of embedded omgevingen. Deze sessie was georganiseerd door Luminis in samenwerking met Thales en leden van de Apache community, en ging in op de vraag hoe het toepassen van services kan helpen bij het verbeteren van de flexibiliteit van bestaande systemen.
De video presentaties van deze sessie zijn nu beschikbaar.
Innovatie, Services en Open Source
Rene van Hees, Technical Authority Software bij Thales
OSGi en Dynamische Services
Marcel Offermans, lid van de Apache Software Foundation
Apache Celix en Apache Foundation
Alexander Broekhuis, Software Engineer Luminis, committer Apache Celix
Last summer I started working on a project to see if it is possible to implement OSGi concepts in C. After a simple Proof of Concept the idea grew to see if it is possible to not only use the OSGi concepts, but actually implement the OSGi specification. Since the OSGi specification is written for Java, simply implementing it in C cannot be done. So an adaptation is needed.
With a series of posts I will detail how Celix implements the OSGi specification, where and why it deviates from the original specification. But for a start, why is it created and what will it deliver?
OSGi provides a dynamic, extensible and easily maintainable environment for complex and distributed architectures. But with one large restriction, it is written for Java based systems only. For embedded/realtime systems there is no alternative, and yet the need for a well defined and modular architecture is becoming more and more important. Besides the dynamics, such architecture also makes it possible to reuse parts of a system, which reduces the time needed to implement and maintain software.
Celix uses C functions (Dynamic Loading) that have been around for a long time, so why follow the OSGi specification, and create abstractions to be able to expose the dynamic concepts like OSGi does?
There are three reasons for this, the first being the fact that OSGi solves much more than existing C functions do. For example, dynamic loading only solves how a library can be added at runtime, but for a complete solution a registry is needed to keep track of available libraries and services provided by these libraries. The OSGi specification provides a good and proven specification for this.
This is also where the second reason emerges, since the OSGi specification is implemented by several vendors (commercial and open source), and being used by many organizations and people, it is a well known and proven API. Following this API makes it easier to understand and use Celix.
Finally, implementing the OSGi Compendium specifications for Remote Services also makes it possible to create a seamless, yet flexible, integration between Celix and OSGi implementations.
As mentioned before, Apache Celix is open sourced at the Apache Incubator. This is mainly for two reasons:
As a middleware project, we think Celix can benefit from a large community. Apache provides the means to support such a community.
Several parts of Celix are a direct port of Apache Felix, and with Felix being hosted at Apache, it is a logical choice to also open source Celix at Apache.
While Apache provides a great basis for Celix as an Open Source project, the community still has to grow. Celix is a new project, and user, committers as well as testers are still needed and always welcome. As with all Apache project, communication is done using mailing lists, to subscribe to the development list of Celix send an email to <firstname.lastname@example.org>.
What will it deliver?
Eventually, the goal is to have an implementation of the full OSGi Core, and part of the Compendium specification in C. But as with all good things, the OSGi specification was written over a longer period, and expecting Celix to implement everything at once, and still deliver a usable product in a reasonable time would be naive.
So for a first release the following goals are set:
Provide a basic implementation of the OSGi Framework API
Provide an implementation of Remote Services
For both Celix <-> Celix but also Celix <-> OSGi
While this is a short list, actually implementing the OSGi Framework API entails a lot of functionality. In the coming blog posts I will detail parts of the specification, and how they are implemented in Celix.
Call for help
Finally, I would like to invite everyone to join the Apache Celix community, and provide us with feedback, ideas, bugs, and maybe even bugfixes and additions to the current code base.