Berichten met label apache
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.
With Apachecon NA 2010 about a month behind us, I’d like to share some of the trends I picked up there.
Big Data, the cloud
One of the main trends I noticed is the interest in Big Data (mainly Apache Cassandra) and Big Data processing in various shapes and forms (e.g. Apache Lucene, Apache Hadoop). In relation to many of these, we find a ring of ‘cloudness’: the products tend to allow distribution and replication of data and functionality.
But it doesn’t stop there. It’s no surprise to find cloud-references in talks about Apache Tuscany (including a talk on Building cloud native software, which I regrettably missed), but for instance Tomcat is making its move into cloud territory with Stratos.
OSGi all around
Of course I have a vested interest in OSGi, and my talk during the OSGi track on friday shows this. However, apart from in its own track, OSGi and OSGi-based technologies popped up in a number of other tracks. To name a few,
- Apache Sling is an OSGi based web application platform, and showed up in the Content Technologies track,
- Apache Geronimo 3.0 (in the Content Technologies track) is now based on OSGi, and
- in the Enterprise Track, a number of sessions were decidated to Apache Aries, which focuses on the OSGi Enterprise specification.
It is an interesting development that OSGi is now mainly being referenced in the web- and enterprise spaces, whereas it started out as a specification for embedded devices.
Does this mean that OSGi is really getting traction in the software community? Yes and no. I believe the thing that is really getting traction is the notions of modularity on the one hand, and µServices on the other. OSGi is currently the main technology that marries those two notions.
Business is not a dirty word
I noticed there were roughly three kinds of talks,
- Community talks are all about how Apache works, and how open source software fits into the world around it,
- Technology talks focus on some Apache project, or a combination of projects, and go into the technical details, and
- Industry talks that show how the projects are used in industry.
The last kind of talk shows how industry, the ‘people with the problem’ use open source technology to run their business. No, I probably don’t really care about the products and services you deliver, but I am very interested in your case studies in using open source in your daily life.
A few days ago, Slashdot ran a story Paid Developers Power the Linux Kernel. In the light of sessions on open source in industry (I counted about half a dozen on this year’s schedule), this is not that surprising: if you’re a good enough developer to become a committer in an open source project, it’s very unlikely you’re working as a janitor during the daytime. All of us work for a corporation in some way, and many of us work on open source project during our paid time. I believe this is a good thing!
The Apache Software Foundation celebrated its 10th anniversary last week at the ApacheCon US in Oakland, California. The event, which lasted from November 2nd to 6th, consisted of many different types of events, ranging from full-day trainings to lightning talks, from a hackathon to technical and marketing sessions. On friday, the event featured a full-day track about OSGi, where all OSGi related Apache projects like Felix, ACE, Sling and Tuscany where present. The big announcement of the conference was the fact that Subversion wanted to join Apache. In fact, during the event, just like with any other project, there was a vote to accept Subversion into the incubator. As with many projects, this triggered some discussion, debating the merits of doing a release during incubation, even though this is a project with many seasoned Apache committers on board.
A conference like no other
Apache probably is the strongest brand in the open source space, but the conference itself focusses strongly on content. Here you will see no sponsored talks by commercial vendors, no sales people trying to sell you anything, it’s all about the code, the community and collaborating with each other. In that sense it’s quite different from most other conferences and if you like meeting and discussing fellow developers, this is a great place to visit. Many events facilitate discussion, and power and internet connectivity are available everywhere.
What open source is all about
Brian Behlendorf summarized the three main cultural elements of Apache quite well:
- write good code and debate it to the bone
- be humble
In essence, Apache is a meritocracy, of which only individuals can become a member. It’s sometimes also described as a do-ocracy as projects are driven by contributions: if you want something done, just do it. Another important aspect is that everything that is done on the Apache projects is discussed and archived on the mailing list. All discussions, code diffs and decisions must be recorded there.
Presenting Apache ACE
Tuesday evenings “birds of a feather” session featured a discussion about Apache ACE, where questions mostly centered around the use cases for ACE and possible integrations with other OSGi components. One of the conclusions is that there are probably three different phases of deployment:
- Using Apache Felix File Installer, which allows you to drop components in a local folder to have them installed.
- Using Apache Felix Karaf’s provisioning components, which allow you to define features which basically group components and allow you to define dependencies on other features.
- Using Apache ACE, which allows you to group components and automatically deploy them to many remote systems.
Friday’s OSGi track started with an introduction to OSGi and moved into more advanced topics during the day. The Apache ACE talk was received well, with several people expressing an interest in wanting to use it and contribute to it.
Summarizing the week, Floris and I had a great time talking to many interesting people and learning about various projects. ApacheCon is a great conference, and I’m already looking forward to the next one.