OSGi thoughts

OSGi Cloud Workshop at EclipseCon/OSGiDevCon 2012

2012-02-07T08:06:00.000Z

Many people are seeing how well OSGi fits conceptually with Cloud Computing. Its modularity is frugal on memory, and provides isolation. Additionally it focuses components on a particular task, which makes them better maintainable too. Furthermore, OSGi dynamicity makes it possible to create Cloud components that react to changes in the cloud environment in a natural way. They can be dynamically configured, reconfigured and an OSGi Framework can be dynamically provisioned and re-provisioned as well!

Over the past while the OSGi Cloud Working Group has been looking at how OSGi can be enhanced to provide additional support for Cloud Computing. This has resulted in a requirements document called RFP 133.

At this point in time we need to discuss which of these requirements should be tackled first? Is it Discovery in the Cloud? Or Metadata? Or Management or maybe something else?
At the same time we should embrace any existing standards in this area and certainly not attempt to reinvent the wheel!

This discussion is the topic of the Second OSGi Cloud Workshop which is held this year at the EclipsCon/OSGiDevCon venue on Thursday March 29 at 9am.

It is set to be a morning with some presentations (the lineup currently is: Paremus, JClouds, eBay and RedHat/JBoss), a demo, and a lot of time for discussion. Entrance is free - you don't need an EclipseCon pass, but you do need to register as numbers are limited (see here also for details on the location of the venue): http://osgi-cloudworkshop-2012.eventbrite.co.uk

Oh, and just to be sure: EclipseCon/OSGiDevCon 2012 has moved and is in Washington/Reston this year!

JavaSE 8 Modularity, Project Jigsaw and OSGi

2012-01-06T08:55:00.000Z

One of the requirements for the JavaSE 8 module system is to provide support for and be able to integrate with OSGi. I am therefore very happy to see that a new OpenJDK project is being proposed to focus on precisely this: Project Penrose. Tim Ellison posted the proposal here: http://mail.openjdk.java.net/pipermail/discuss/2012-January/002320.html

They're still looking for initial supporters, authors and committers, so if you're interested in helping out just sign up!

BTW I posted before on this topic, see here: http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html

New OSGi Alliance membership stucture

2011-11-10T10:37:00.000Z

The OSGi Alliance is where all the OSGi specs are developed as a collaboration effort of a number of companies (and sometimes invited researchers). To be able to contribute to specs you need to be a member. There are a number of reasons for this but probably the most important one is proper handling of IP flow.

In the past a number of people have told me that they would be interested in taking part in the specification work at OSGi but they simply could not afford the membership. Well for those people there is good news today. The OSGi Alliance has moved to a new membership structure where much cheaper options to become a member are available. Also the size of a company is taken into account at certain levels where smaller companies (under 250 employees) pay less.

There is also an entirely new type of 'low-fee' membership: Contributing Associate (which replaces the old Adopter Associate). Being an Contributing Associate is much more useful than Adopter Associate was as Contributing Associates can send up to 2 delegates to Expert Group meetings (such as the Enterprise Expert Group) where they can fully participate in the development of RFPs and RFCs, which ultimately can become OSGi specifications.
Any existing Adopter Associates are automatically moved to Contributing Associate, so they can start contributing right now! (well, you need to sign some docs, but that's all).

Ideally you want stuff like this to be free, but as any Standards Development Organization, the OSGi Alliance (which is a non-profit organization) has operating costs and the membership fees are used for that. As a representative on the Board of Directors I will always make sure that any money in the organization is used appropriately.

I'm personally very happy to see the OSGi restructuring finally taking place. I expect that it will open the door to more participation, especially from the large number of smaller companies who are successfully using OSGi in the field. The OSGi technology is great, but great things can always be improved. Doing this in the OSGi Alliance means that those improvements will be embodied in specifications and specifications ultimately lead to choice as multiple implementations can co-exist so that users will be free from vendor lock-in.

For all the details of the new membership structure see here: http://www.osgi.org/About/Join and here: http://www.osgi.org/About/Benefits#compare
Alternatively, feel free to contact me at david.bosschaert@gmail.com if you have questions, I may not be able to answer all of them but I can always point you at the person who does.

For a list of current OSGi specifications and their implementations see here: en.wikipedia.org/wiki/OSGi_Specification_Implementations

OSGi Enterprise Specification Early Access Draft

2011-10-11T20:11:00.000+01:00

A new Early Access Draft containing RFCs aimed at the upcoming OSGi Enterprise Specifications has been made public. The following RFCs are expected to be part of the OSGi Enterprise Release next year:

RFC 112 OBR
RFC 152 Subsystems
RFC 167 java.util.ServiceLoader support
RFC 169 JMX updates

In addition, the EA draft contains a number of RFCs related to the Core and Compendium specifications.
You can find this draft on the OSGi website here: http://www.osgi.org/download/osgi-early-draft-2011-09.pdf

JBoss Application Server 7 is out - with OSGi support!

2011-07-12T21:44:00.001+01:00

JBoss AS7 has been released today - an amazingly fast and lightweight Application Server with built-in OSGi support. Just deploy your OSGi bundles and go!

For more information see the main AS7 page: http://www.jboss.org/as7.html
Or have a look at the quickstarts page!

The OSGi support in AS7 implements the OSGi 4.2 core specification. Thomas Diesler has contributed most of the code, and I have implemented some bits and pieces in there too... Lets us know what you think or if you find an issue. The forums are here: http://community.jboss.org/en/jbossosgi and more details on the project can be found here: http://www.jboss.org/jbossas/osgi

The need for Modularity

2011-06-28T08:54:00.002+01:00

The title of this blog is not new - it has been used by many other blogs and articles in the past, but Rod Johnson seems to think that Modularity not really needed any more so I decided to reuse the title and take a look at why we really need Modularity.

In this age of Cloud Computing where hardware utilization and energy consumption are being highly optimized you will find that more and more service providers are moving towards a multi-tenancy model where multiple deployments are co-located on a single platform. Whether these deployments are from different providers or from the same provider is the choice of the deployer, but the end-result is a situation where multiple deployments share a single platform. In such cases modularity is an absolute must as without it there is a reasonably big chance that the system won't work. This is because deployables might depend on incompatible versions of the same library, which means that in order to work, they need to be isolated from each other. Or, a deployable might depend on a library that also happens to be used by the platform provider, this is an even harder case which requires the platform itself to be developed in a modular fashion so that it's details don't bleed into the user-space.
Scenarios like this require modularity and in the case of Java this modularity is provided through OSGi and/or many application servers. Additionally, modularity can also be found in many non-appserver systems that allow plugins to be installed.

Further benefits of modularity relate to memory footprint and performance. A modular system can make intelligent decisions about its memory usage, where only modules that the end user actually needs are loaded. This makes it possible for a fully featured server to have a tiny runtime footprint if only a small portion of it is actually used. And all of these benefits have performance benefits too: you'll save a lot of time if you're only loading the modules you actually need rather than pre-loading the entire system as a single entity.

But even if you don't need modularity for side-by-side versioning, isolation or performance just yet, there are additional benefits associated with using a modular approach in your development. I think that even for small projects it's not a bad idea to start out by using Modularity. It's true - getting a modular project off the ground takes a larger initial effort compared to the 'traditional' approach. But that cost is quickly earned back once the project grows a little bigger. Once your project is structured to support modularity, it becomes much more maintainable, easier to understand and to extend while 'traditional' approaches tend to become much harder to maintain as they grow in size.
See the following diagram, adapted from a blog by Hal Hildebrand:

Cost of Software Maintenance

The investment in a Modular Architecture earns itself back quicker than you think.

Using a modular approach together with a service oriented architecture*) gives your system highly cohesive entities with a clear responsibility. This makes it easier to identify what parts are affected when a system needs to be enhanced or changed. Changes for a particular feature are often more localized to a specific set of modules, which enables better parallelization of development and will ultimately make your developers more productive.

So Modularity is highly desirable for a number of reasons and the best place to get modularity today is by taking an OSGi Framework, as OSGi has been providing Modularity as well as an excellent Services Framework to Java for over 12 years and is standardized in the OSGi specifications.

Part of the choice for a particular development architecture is always the consideration regarding tooling support. With OSGi the following tools are popular:

Additionally, Netbeans and IntelliJ have OSGi Support. While tools can always be improved the above toolsets are quite usable. Especially the Maven Bundle Plugin is very popular in the Open-Source world and many, many examples can be found that show its use.

To conclude, Rod Johnson says that especially on the server side, using a non-modular system is better for customers. This seems like a highly incorrect statement to me. Modularity is needed especially on the server side, as without it your deployments become fragile, especially if you have more than one deployment on that server...

*) Note that by saying 'service oriented architecture' I'm not implying a distributed SOA. Using services within a single process is highly valuable and works great in combination with modularity to avoid tight coupling. Yes, services open the door to distributing parts of your application, but that's really a different topic...

OSGi Enterprise Specification Early Access Draft available!

2011-06-07T19:59:00.000+01:00

An early access draft for the upcoming OSGi Enterprise Specifications has just been made available. This is really interesting stuff and it shows what we've been working on in the Enterprise Expert Group over the last year or so. Although still work in progress, some of these specifications will be included in the next OSGi Enterprise Release which is currently planned to be released during the first half of 2012.

The main theme for the Enterprise Release is around Subsystem/Application support and OBR (the OSGi Bundle Repository). These are covered in RFC's 152 and 112. Together they greatly improve the way you can define and distribute, assemble and install OSGi applications and I'm really looking forward to the moment that these specs are finished and broadly implemented.

Additionally you can find in the draft: RFC 146 JCA support, two new Blueprint specifications and an update to the JMX specification (chapter 124 in the Enterprise Release 4.2).

Finally there is RFC 167. This is a new RFC that I've been working on. It intends to fix a small but quite annoying issue: the fact that java.util.ServiceLoader() and META-INF/services use generally don't work in OSGi. You can work around it, as I've blogged about in 2008, but it's ugly. Using RFC 167 this issue can be addressed so that any non-OSGi code that uses this pattern can work in OSGi without too much hassle. I've been working on an implementation of this in Apache Aries, if you're interested in trying it out.

Note that the specifications are not yet final so significant changes might still occur. Also, feedback is welcomed! You can leave comments here on my blog or write an email to the osgi-dev mailing list.

You can find the EA draft here: http://www.osgi.org/download/osgi-early-draft-2011-05.pdf

Java SE 8 Modularity Requirements

2011-05-25T22:14:00.000+01:00

Mark Reinhold posted the requirements for the Module System in JavaSE 8 here today: http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12 . And, I won't deny it, I was part of the group that worked on getting these requirements formulated, although I don't fully agree with all of them, but more on that below.

There are many, many good requirements in this document and Java will certainly gain from having these realized - if this is done in an open and inclusive manner.

So what does this mean for OSGi? OSGi is a widely used, mature, modularity standard today, existing for 10+ years.
Well, the good news is that the new requirements are not incompatible with OSGi. There is actually a specific requirement around the necessity for OSGi to be able to interact with the JavaSE modules.

Many of the requirements mentioned in the document are already supported by OSGi today. The file format that defines the modules will most likely not be the MANIFEST.MF file that is used by OSGi today, but another file of some sort. OSGi will support this new mechanism to declare the module as well in the future; the semantics are the same, the format will be slightly different.

Another good thing is that once modularization is part of Java SE 8, moving to OSGi will be easier than it is today. The biggest stumbling block for migrating an existing system to OSGi today is often the modularization of a system that wasn't created in a modular way in the first place. It's not an issue with OSGi per se, but with modularity as a concept. If you have existing code that is non-modular, it can be difficult to modularize it. With JavaSE 8 this problem will appear earlier in the development cycle which should help people design their systems in a modular way from early on. If you need more than the basic JVM module system then you can move to OSGi taking your existing JavaSE 8 modules and they will just work as-is - so migration will be a breeze. Then you can enhance the modules to take advantage of the OSGi benefits (see below).

Why not take OSGi as-is?
Well, this would be nice. And it should be quite possible to take a (possibly reduced) OSGi framework and make that the module system for Java SE 8. But to a certain degree it's an implementation detail. The important thing is that the Java SE 8 Module System is a well-defined standard. Whether JRE implementations take OSGi as the basis for their module system or write their own from scratch is up to them.

Does OSGi still add value? Absolutely! Here are some points:

dynamicity and lifecycle: OSGi modules are dynamic; you can add, remove and update modules from a running framework. It allows patching applications without taking them down! (I have demo'ed this many times) This will probably not be possible in the JavaSE 8 modules.
advanced service registry: the OSGi Service Registry is much richer than the Java SE java.util.ServiceLoader class. It allows filtering for services on additional metadata (beyond the interface name), supports multiple instantiation modes and, again, is dynamic: services can come and go.
richer dependency metadata: OSGi has an extremely rich metadata model that supports specifying dependencies in many ways. It does support module-level dependencies (as is proposed in the Mark's requirements doc) through the Require-Bundle header. However, most people who have been working with OSGi for the last 10+ years have realized that pure module-level dependencies are inferior to declarative dependencies such as the ones provided by OSGi's Export-Package and Import-Package. Since OSGi 4.3 generic capabilities and requirements are also supported, which allows you to create your own dependency system.
many other OSGi specifications: there are many OSGi specifications that describe useful things which can be used on top of any OSGi framework. See the compendium and enterprise specifications for the details.

Where are the disagreements?
They're actually spelled out in the requirements document.

The form of the module definition. Having module metadata in a file different from MANIFEST.MF is fine, in my opinion. MANIFEST.MF is a near text-file format with some strange limitations. A proper DSL would be nice for module definitions. I don't see the value, however in compiling that information into some binary format. It has been invaluable to me many times in the past to be able to open an OSGi bundle, look at the manifest and see exactly from that information what the module definition is. Compiling the information into a binary format will make it harder to see the module definition and it might also make life harder for tools that work with the module system.
The file extension of the module definition. Some argued that the module source definition should be in a .java file and because it's in a .java file there should be a compiled .class file in the resulting Jar file. However, I think that the structure of a module definition screams for a specific DSL that might be quite different from ordinary Java. Especially the extensibility requirement makes a DSL much more natural than a traditional .java source file. I think the module definition should be in META-INF/module.jmod or something like that. Then it becomes natural to migrate that file as-is to the resulting jar. In a sense the existing MANIFEST.MF does cover most of the requirements. Sure, it has some issues (esp. the 76 chars-per-line limit) but it's clear, simple and extensible - and - it is readable by humans in the Jar file.

Conclusion
I congratulate Mark Reinhold and all others involved in this for providing the basic requirements and design proposal that will make OSGi work nicely with the JavaSE 8 module system. OSGi will extend the basic JavaSE 8 modules and both systems will work with each other to form a layered design.

Nice magazine about OSGi

2011-05-18T08:32:00.000+01:00

The people behind the Jax conferences have created a PDF magazine with a focus on OSGi. There's some good articles in there, so definitely worth a read!

Table of Contents:

Introduction to OSGi by Jerome Moliere
What's new in Core 4.3 by BJ Hargrave and Peter Kriens
Developing with BndTools by Marcel Offermans and Alexander Broekhuis
OSGi a la Carte by Valentin Mahrwald and Holly Cummins
OSGi and JPA by Dmytro Pishchukhin
Cure for Complexity (Business focus) by Richard Nicholson
Enterprise OSGi by Tim Diekmann and myself

Lots of topics, from Core to Enterprise to Business and also information about popular OSGi projects and developing for OSGi! The download process is a little involved, but it took me only a few seconds to get it. You can get the PDF here: http://jaxenter.com/java-tech-journal/JTJ-2011-04

Enterprise OSGi in JBoss AS7

2011-04-29T08:33:00.000+01:00

As many of you know, I have been working on OSGi support in the JBoss Application Server for the past year now. My colleagues at JBoss/Red Hat and I have built an OSGi Framework from the ground up with as focus the best possible integration with the Application Server.

AS7 has been OSGi-enabled since its Alpha1 release and over the past few weeks Beta's have been pushed out on a bi-weekly basis. It's starting to look really good!

Next week at Red Hat Summit/JBoss World in Boston I'll be presenting and demoing the current state of things w.r.t. to Core OSGi, Enterprise OSGi and OSGi/AS integration in AS7. My session is on Friday at 11am: http://www.redhat.com/summit/sessions/jboss.html#38 - hope to see you there!

OSGi 4.3 core proposed final draft now available

2011-03-25T03:02:00.001Z

The OSGi 4.3 core specification proposed final draft if now publicly available!

New and noteworthy:

Generified Framework API
Generic Requirements and Capabilities
New BundleWiring API
New Bundle and Resolver Hooks
New Weaving Hoooks

Get it here: http://www.osgi.org/Download/File?url=/download/osgi.core-4.3.0-pfd.pdf

Update - the final 4.3 Core spec is now public: http://www.osgi.org/Download/Release4V43

OSGi Cloud Computing RFP 133

2011-02-15T14:40:00.000Z

I'm quite excited by the work that is being done in the OSGi Cloud Working Group recently. In this working group we are looking at what role OSGi standards can play in a Cloud Computing environment. Currently we're focusing on the possible requirements in RFP 133. Both OSGi Alliance members as well as non-members are involved in defining this document.

If you're interested, have a look at the RFP. It's available as an attachment to this bug in the public OSGi Bugzilla system: https://www.osgi.org/bugzilla/show_bug.cgi?id=114. Feel free to comment!

If you're interested in becoming more involved, join the OSGi Cloud Working Group mailing list: https://mail.osgi.org/mailman/listinfo/cloud-workshop.

Cool! Planet OSGi aggregator!

2010-12-07T17:37:00.000Z

Just wanted to share that as of today there is a new OSGi-focused feed aggregator: Planet OSGi. You can find it here: http://www.osgi.org/Planet

So if you have a blog that is interesting to the OSGi community at large, get listed!

OSGi Community Wiki now open for contributions

2010-10-29T07:22:00.000+01:00

The OSGi Community Wiki is now open to everyone for contributions. Sign up here:

http://wiki.osgi.org/SiteLicensing/Contributor

OSGi DevCon 2011 Call for Participation now open

2010-10-21T07:06:00.000+01:00

OSGi DevCon 2011 will be held at EclipseCon in Santa Clara as it has been over the past few years. You can now submit talks and tutorials. For more information see: http://www.osgi.org/DevCon2011/HomePage

Public OSGi Wiki being set up

2010-10-06T21:20:00.000+01:00

During the OSGi Community Event last week in London the suggestion was made to create a public OSGi Wiki. BJ Hargrave has acted quickly and just set up a mailing list to discuss this further. This is an open mailing list so subscribe if you want to join the discussion: https://mail.osgi.org/mailman/listinfo/osgi-wiki

OSGi 4.3 core/compendium EA draft 2

2010-10-04T17:22:00.000+01:00

The OSGi Alliance has published the second Early Access draft of the upcoming OSGi 4.3 core/compendium specifications. The draft contains the following RFCs (in this order):

RFC 138 - Framework Hooks (this is the current approach to providing protected scopes for things like applications in the framework).
RFC 151 - Framework Update
RFC 154 - Generic Requirements and Capabilities
RFC 147 - Command Line Interface
RFC 157 - Event Admin Update
RFC 160 - Coordinator Service
RFC 165 - Combined Configuration Admin enhancements

You can find it here: http://www.osgi.org/Download/File?url=/download/osgi-4.3-early-draft2.pdf

OSGi 4.2 Enterprise Interfaces Jar now available in Maven Central

2010-09-07T16:56:00.000+01:00

I can only say: apologies that this took so long, but the OSGi Enterprise Jar is now available from maven central:

group ID: org.osgi
artifact ID: org.osgi.enterprise
version: 4.2.0

or directly here: http://repo1.maven.org/maven2/org/osgi/org.osgi.enterprise/4.2.0/

This should make using Enterprise OSGi from Maven builds a lot easier.

CXF Distributed OSGi 1.2 is out!

2010-07-26T23:56:00.001+01:00

I'm really excited to be able to say that the CXF Distributed OSGi subproject has done its 1.2 release.

With this release it now also provides the Reference Implementation of the Remote Service Admin specification (chapter 122 of the OSGi Enterprise Specification) in addition to being the Reference Implementation of the Remote Services specification (chapter 13 in the OSGi Enterprise Spec). Together with the Apache ZooKeeper-based discovery implementation it provides all you need to do Distributed OSGi.

A lot of work as gone into this release, which is a major refactoring from the previous code base. This was necessary to support the RSA specification which provides a standard API for the internal building blocks that constitute a Remote Services implementation. This provides a number of benefits:

You can mix & match components from various implementations, for instance you could use the Web-Services based OSGi Service Remoting provided by CXF together with a Discovery System from another project.
You could replace the default Topology Manager with a custom built one to control more explicitly which services should be exported or imported and how.
You could make some interesting mash-ups. I think that the Tuscany project provides a implementation of the Topology Manager for SCA, so in theory you could replace the default one with the Tuscany one and control you CXF-based Remote Services through SCA. I haven't tried this out yet, but it should be possible :)

Besides the real spec text (which is quite readable) you can find a some more information on the components described by the RSA spec on slides 6-8 of my Enterprise OSGi presentation.

You can find the CXF-DOSGi 1.2 release here: http://cxf.apache.org/distributed-osgi.html

Wikipedia page listing all available OSGi implementations

2010-06-02T11:19:00.001+01:00

With the release of the OSGi 4.2 Enterprise Specifications, the number of OSGi specs has improved dramatically. This is a good thing because many more use cases are now covered. Is it getting bloated? Not at all, as with OSGi you only take what you need. The basis is always something that implements the OSGi Core specification, and these implementations are often very small. Apache Felix is 383kb and Eclipse Equinox is only just over 1MB. If you need to use any of the other specifications you can add them to your framework runtime to just provide you what you need. Nothing more, nothing less.

To my surprise it was sometimes fairly hard to find where a certain OSGi spec implementation could be obtained. Most people know where to find a number of core frameworks, but where to I find a compliant OSGi Web Applications implementation? Or a Remote Services one? Or maybe you're not happy with a particular implementation, where do you find an alternative?

So I started putting together a list of OSGi spec implementations on Wikipedia, both for core frameworks as well as for other OSGi specifications such as the Enterprise ones.

The wikipedia page is here: http://en.wikipedia.org/wiki/OSGi_Specification_Implementations

I'm sure the list is not complete and there may be some mistakes in it, so I would invite anyone who has more information to add it in!

Presentation: What's new in OSGi 4.2 Enterprise

2010-05-07T07:54:00.001+01:00

Just as I was setting off to travel to the Jax OSGi day in Mainz earlier this week my plans got disrupted by another plume of volcanic ash. Only hitting Ireland and Scotland this time, but enough to close Irish airspace for the day. So I wasn't able to deliver my presentation about the new specifications in the OSGi 4.2 Enterprise Release. Lucky enough my friend Roman Roelofsen was at the conference. He has given the talk instead at short notice. Thanks Roman!
This is the presentation that I gave at Jax London and Tim Diekmann also used it at EclipseCon 2010. A number of people have asked to get access to it, so here it is!

What's new in the OSGi 4.2 Enterprise Release

View more presentations from David Bosschaert.

New OSGi spec drafts available!

2010-05-06T17:07:00.001+01:00

Recently the OSGi Alliance has published two new drafts that contain the RFC contents for a number of future specifications.

There is a new draft for the OSGi Core 4.3 release: http://www.osgi.org/download/osgi-core-4.3-early-draft1.pdf. This draft contains:

RFC 138 which describes running multiple frameworks in a single VM.
RFC 151 updates the core framework API to include Java 5 generics.
RFC 154 introduces generic capabilities and requirements to the OSGi resolver.

Also released was a new draft for the OSGi 4.2 Residential release: http://www.osgi.org/download/osgi-residential-4.2-early-draft3.pdf. This draft contains a number of highly specific specs for the residential area with the notable exception of RFC 144, which has a general impact on OSGi:

RFC 144 Configuration Admin Extension. The extensions described in the RFP are twofold. The Configuration Permissions are extended. Additionally, with RFC 144 it is now possible for multiple bundles to consume a single Configuration Object. So it means that with that it's possible to share a common Configuration Object across many bundles! This is one thing that I've been looking for a long time, and it will benefit many OSGi Core and Enterprise users as well...

As with previous early draft releases. These specs aren't finished yet, but this should give people a good idea of where things are going and also allow opensource projects to start implementing!

The OSGi 4.2 Enterprise Release is out!

2010-03-23T17:25:00.000Z

Today the OSGi EEG reached a very important milestone. The OSGi 4.2 Enterprise Release is finished and publicly available! You can download it from here: http://www.osgi.org/Download/Release4V42

The specifications in the release address a number of important Enterprise use-cases and greatly enhance the OSGi programming model. Besides bringing a number of JEE technologies to OSGi, there are also a number of specs that nicely enhance the OSGi programming model.

Here's a high-level overview of the specs developed by the EEG in this release:

The Blueprint specification is a standard based on Spring-DM. It provides an IOC container for OSGi and really makes developing with OSGi services very easy. Spring has many fans and the Spring-DM project has shown that integrating Spring with OSGi is a very elegant combination. The Blueprint standard helps developers by not binding their code to a single implementation. There are already a number of Blueprint implementations available.
Remote Services and Remote Services Admin. These specifications started out under the name Distributed OSGi and bring Distributed Computing to the OSGi Service model. The Remote Services spec is for bundle developers. It describes how the OSGi Services Programming model is enhanced with a number of properties that turn your services into Remote Services. It's a very simple spec with big possibilities.
Remote Service Admin standardizes on a high level the internal components that a typical Remote Services implementation consists of. It defines the API for the Distribution Provider (the thing that makes the remote invocation), a distributed Discovery System (that can make your OSGi framework aware of suitable remote services) and a component called a Topology Manager that provides the decision policy over what services to export and import. RSA provides users with the capability to mix and match these components from various implementations. A user might use the Distribution Provider from CXF while taking the SCA-enabled Topology Manager from Tuscany combining that with maybe a yet another implementation of Discovery that might use a UDDI server.
Web Applications - while deploying .war files in an OSGi Framework was already possible with technologies such as PAX-Web the Webapps spec describes a standard way to do this. Besides providing some new standard Manifest headers (like one to describe what context path your webapp lives on) it also describes a standard way for the Web Application to interact with the other bundles in the OSGi Framework. The Servlet Context will contain a new attribute 'osgi-bundlecontext' that gives your Servlet access to other OSGi Bundles and Services and allows the servlet to register OSGi Services of its own. Other OSGi bundles can interact with Servlets as the Servlet Context(s) of a successfully started Web Application is registered in OSGi Service Registry.
The JDBC specification nicely solves problems that database users previously had while using OSGi. Obtaining a database driver was typically ugly and most of the time required exporting and importing private database packages. With the new specification JDBC Database drivers simply register themselves under a standardized DataSourceFactory class in the OSGi Service Registry. It has APIs to create a DataSource (variants for Pooled and XA are also provided) or obtain the underlying java.sql.Driver object. No exposure of internal classes any more.
JPA is a highly popular Database Persistence framework and the OSGi-JPA specification describes how to use it from within OSGi. While there is a 'traditional' mode of using JPA in OSGi which is identical to using it in JSE, the recommendation is to obtain a JPA EntityManagerFactory from the OSGi Service Registry. This provides additional lifecycle support (you can update your JPA implementation without restarting the container) and it also allows the existence of multiple JPA providers in the system. OSGi-JPA implementations normally work well with the OSGi-JDBC providers described above.
The JNDI spec provides a bridge between JNDI and the OSGi service registry. It enables the lookup of an OSGi Service or BundleContext through JNDI. It also describes how you to obtain a JNDI Initial Context from the OSGi Service registry in case your bundle needs to do a JNDI lookup or bind.
Like the OSGi-JDBC spec, the OSGi-JTA spec provides access to JTA APIs such as javax.transaction.UserTransaction and javax.transaction.TransactionManager through the OSGi Service Registry. If you have a JTA implementation in your framework they will simply appear there.
Finally, the JMX specification provides JMX access to the OSGi Framework. It enables controlling the Bundle Lifecycle (like installing, uninstalling, starting, stopping a bundle) from JMX and also provides Bundle and Service information through JMX. Additionally JMX APIs are defined for a number of standard OSGi Services such as Package Admin and Configuration Admin.

Besides the new specs a number of existing OSGi specs are also included in the document. Specifications like Event Admin, Configuration Admin, Declarative Service and others are also included as they are also relevant to Enterprise use of OSGi.

Oh, and as a side node, I don't expect Enterprise OSGi Frameworks to deploy all of these specs at the same time. Take only what you need, keep your framework nice and lean :)

Implementations for all of the above are available. Good places to look for them are the Apache Aries and Eclipse Gemini projects. And, of course, Apache CXF provides Remote Services and Remote Services Admin implementations in the CXF Distributed OSGi project.

CXF-DOSGi 1.1 Implements the OSGi Remote Services spec

2009-12-07T10:20:00.000Z

Last week the Apache CXF implementation of the OSGi Remote Service specification, CXF-DOSGi version 1.1 was released.

The CXF-DOSGi code base has already been supporting the OSGi Remote Service spec (chapter 13 in the OSGi 4.2 Compendium Specification) for some time. Now it's in a released version as well.

Major new features since CXF-DOSGi 1.0:

Reference Implementation of the OSGi Remote Service spec.

A live Discovery System is now supported. CXF-DOSGi makes use of Apache Zookeeper as the Discovery Server and provides client-side bundles for transparent interaction with Zookeeper.

Besides SOAP/HTTP support, it now also provides REST support for JAX-RS-based Remoted Services and Consumers through the org.apache.cxf.rs configuration type.

For more information see: http://cxf.apache.org/distributed-osgi.html

In the mean time we're working on refactoring the code to also be compliant with the upcoming Remote Service Admin specification. The RSA spec defines standard interfaces between the Distribution Provider, Topology Manager and Discovery System in a Remote Service implementation. This means you can mix-n-match these from multiple implementations. So for example, you could take the CXF Distribution Provider to give you a Web-Services based remote service and combine that with something like a UDDI-based Discovery system from another project. Then you might want to provide your own Topology Manager since this is the entity that makes the decisions about what gets exported and what gets imported. The RSA spec makes all this possible. Read more about it in chapter 122 of http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf

OSGi 4.2 Enterprise Release Early Access Draft 4

2009-12-01T07:57:00.000Z

In the OSGi Enterprise Expert Group we're working hard to get the Enterprise Release ready some time in Q1 2010. But if you can't wait, we've just released an Early Access Draft of the new specs. As it says, these aren't finished specs yet. Some details are still bound to change, you will see open questions in certain sections and the formatting of the documents is certainly not final yet, but the overall direction of these specs is most likely not going to change.

The OSGi 4.2 Enterprise Release addresses a number of Enterprise use-cases and brings a collection of Enterprise-related Java specs into OSGi. You'll find the following chapters in the Early Access Draft:

Web Apps - turn your OSGi framework into a web container. This was already possible with components such as pax-web but now there is a standard for it. Besides being able to deploy your WARs as-is you can also make your Web Apps OSGi-aware and interact with the OSGi BundleContext from within a Servlet. Plus every web-application's Servlet Context gets registered in the OSGi Service Registry as a service, so you can interact with it from an OSGi Bundle too.

Transactions - brings JTA to OSGi. You get hold of a Transaction Manager or User Transaction through the OSGi Service Registry. You can also register a Transaction Synchronization callback object with the Transaction Synchronization Service.

Remote Service Admin - this specification adds an extra layer on top of the existing Remote Services spec (chapter 13 in the 4.2 Compendium). Remote Service Admin defines standard interfaces for the Distribution Provider, Discovery System and Topology Manager, making it possible to mix-n-match these from multiple implementations. The Distribution Provider registers a RemoteServiceAdmin service that exports and imports services when asked. The Discovery System API (called the EndpointListener) provides a standard view over any Discovery System, regardless of how it's realized or what protocol it uses. The Topology Manager provides a Policy over these things. It decides what services will be exported and for when to look for services in a Discovery System.

SCA Configuration Type for Remote Services - this chapter provides a standard mechanism to configure Remote Services and provide qualities of service or intents, through SCA configuration metadata and WS-Policy. Remote Service implementations that also implement the SCA config type provide a portable way to configuration.

Database Access (JDBC) - provides a standard way to look up JDBC Database Drivers through the OSGi Service Registry. Using JDBC in OSGi has been tricky before as it typically involved either using Class.forName() or the META-INF/services SPI model both of which are problematic in OSGi. The Database Access specification uses the OSGi Service Registry to provide you with your database drivers without having to expose any of the implementation classes to your client bundles.

JMX - provides a JMX API into the OSGi Framework. It can be used to control the lifecycle of bundles in the framework (including install, start & stop etc...) but also provides standardized JMX access to a number of OSGi Services such as Package Admin Service, Configuration Admin Service, User Admin Service.

JNDI - brings the JNDI and OSGi Service Registry closer together. It provides a way to look up OSGi Service through JNDI and also makes it possible to interact with JNDI through the OSGi Service Registry.

JPA - brings a proper Database Persistence API to OSGi. It allows you to use JPA from within your OSGi Bundles. Combined with the JDBC and JTA support from the other spec chapters JPA provides a nice way to add database support to your OSGi-based applications.

The Early Access Draft doesn't contain all of the specs that you'll find in the final Enteprise Release, it only contains the ones changed since the 4.2 Core & Compendium release. For example, you will also the Remote Service and Blueprint specifications in the final Enterprise release, but they are not included in the Early Access draft.

You can download the 4.2 Enterprise Early Access draft from this location: http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf

Submit your OSGi talks!

2009-11-05T14:31:00.000Z

Two OSGi Conferences are currently accepting presentation submissions, so if you have something interesting, cool or noteworthy to say about OSGi, make sure to submit your stuff!

They are:
OSGi DevCon London (Feb 23, 2010): http://www.osgi.org/DevConLondon2010
and
OSGi DevCon at EclipseCon 2010 (March 22-25, 2010): http://www.eclipsecon.org/2010/

So come out and show us all what you are using OSGi for!

Felix now fully supports OSGi Fragments

2009-09-29T14:53:00.000+01:00

A long awaited feature has finally been completed in Felix: Fragments!
I'm really happy to hear this because in the past it has been a pretty big gap in the support provided by Felix.

Here's the message from Richard Hall: http://www.nabble.com/Re%3A-Status-of-Fragments-in-Felix--p25663384.html

Aries: an Apache project for Enterprise OSGi

2009-09-28T11:50:00.000+01:00

Some of you may have noticed the Aries incubator project at Apache: http://incubator.apache.org/aries.

Aries is about building a community specifically around enterprise OSGi components and an enterprise OSGi application programming model. It provides a home for bundles and larger chunks of enterprise OSGi technology independent of the OSGi container, so anything found in Aries should work in a compliant OSGi runtime such as Felix or Equinox.

Part of the proposal focuses on the development of an OSGi Application model for assembling multiple bundles into a larger parts which you can think of as an application.

An application model is one of the things that the OSGi Enterprise Expert Group (EEG) is currently defining and working ahead on an implementation will help making this standard better as experience is always better gained by doing.

Initially the project will provide an implementation of the OSGi 4.2 Blueprint specification (RFC 124), an implementation of JPA support for OSGi and JNDI integration for OSGi.

Like with any Apache project, anyone interested in joining the fun is more than welcome to contribute! Many individuals and people working for a large variety of companies have already joined during the proposal stage and I would expect even more people to join once the project is under way.

Exciting stuff!

OSGi 4.2 Core and Compendium Specs Available

2009-09-17T09:39:00.000+01:00

The new OSGi 4.2 Core and Compendium Specifications are now publicly available.

The big new items are:
Remote Services - The Remote Services Specification (Chapter 13 in the Compendium Spec) defines how you can use the OSGi Services Programming model to distribute your services across machines. It brings Distributed Computing to OSGi in a very natural way. The Reference Implementation is provided by Apache CXF.

Blueprint Container - This standardizes the Spring Dynamic Modules development model and allows you to expose simple POJO's as OSGi Services. Additionally, OSGi Service References can be injected into your own POJO through simple setter calls. In a way it is similar to OSGi Declarative Services (and other OSGi Component Frameworks), the difference is that this one works very similar to the way Spring works. The good thing is that all OSGi Component Frameworks works seamlessly with each other. E.g. a Service created with DS can be consumed by Blueprint without any problems, and vice versa. The Blueprint Reference Implementation is worked on at the Spring-DM project.

Service Registry Hooks - This enhancement to the OSGi Core was initially triggered by the Remote Services (Distributed OSGi) work as it needs to know what Services active Bundles are looking for. This information allows the Remote Service implementation to look specifically for the requested service in any of its registries to see if there is a remote one available. Later it turned out that there are many more applications of Service Registry Hooks. They allow you to figure out what services are being looked for, but they also add the possibility to hide certain services for certain bundles making it a building block for Service Proxification. The Hooks (Chapter 12 in the Core Spec) are implemented by both Equinox 3.5 and Felix 1.8.0.

Additionally, many small updates have been made to other specs. You can find the specifications here: http://www.osgi.org/Specifications/HomePage

Meanwhile, the Enterprise Expert Group is working at full speed on the OSGi 4.2 Enterprise Release which contains many additional new Enterprise related specifications.

Co-chairing the Enterprise Expert Group

2009-08-05T09:36:00.000+01:00

Last week the OSGi Enterprise Expert group has elected me as their new co-chair after Eric Newcomer is moving on to greener pastures elsewhere. I have to say that I'm thankful for the confidence that the EEG has in me and would like to thank everyone for their support. Obviously I will be taking on the role together with my esteemed co-chair Tim Diekmann, who has been in this role since the EEG started.

Here's a little bit about me. I work for Progress Software in Dublin, Ireland and worked for IONA technologies for about 10 years before they were acquired by Progress. During my time I've worked on a number of products which include Orbix the IONA Corba product, a J2EE Appserver, Mobile Middleware and a Repository product. I've also been involved with the Apache and Eclipse open source projects where I am a committer on CXF and on the STP Policy component respectively. Before I joined IONA, I worked in the Netherlands for a Cap Gemini subsidiary called Bolesian. I've been active in the OSGi EEG since it started in January 2007, and have been one of the drivers behind Distributed OSGi, now called 'Remote Services' which is released in OSGi 4.2.

Looking forward, things will be busy. Within the EEG everybody is working really hard on the 'OSGi 4.2 Enterprise' release, which we're planning to get out at around the end of this year. We're hoping to get a bunch of JavaEE mappings in, things like Webapps, JPA, JTA, JMX, JDBC, JNDI. Being an army of volunteers, its hard to guarantee that they will all make it, but at least I know everyone is doing their very best to get there.

Last but not least, I would like to thank Eric Newcomer, which whom I have worked for many years for the excellent work he has done in OSGi and wishing him the very best for his new job that he is starting soon.