Presentation: The Benefits of OSGi in Practise

A little while ago I created a presentation around how I see the benefits of OSGi. It can serve as an introduction to those who like to learn more about OSGi and how it can solve real-world problems.

I've now put this presentation on slide share. You can find it here: http://www.slideshare.net/bosschaert/benefits-of-osgi-in-practise

Polyglot OSGi: new C/C++ and JavaScript RFPs!

OSGi has been a great Modularity and Services platform for Java for many years. If you look at the Core, Enterprise, Compendium and Residential specifications you will see that a broad spectrum of topics and technologies is covered by OSGi specs.

However, Java isn't the only language in town. And indeed OSGi is already being used by other JVM-based languages, such as Scala as you can see from the Scala Tool Chain page on the OSGi wiki.

Going forward, OSGi will go places where there is no JVM available! Recent work is looking at gathering requirements for OSGi frameworks for JavaScript and C/C++.

A new RFP around OSGi for JavaScript was started. This RFP currently mainly focuses on the OSGi Service Layer and bringing something like that to native JavaScript. You can already find an implementation of many of the concepts in Eclipse Orion. The JavaScript Microservices RFP 159 is in available in bugzilla here: http://www.osgi.org/bugzilla/show_bug.cgi?id=169

On the C/C++ side, there have been a number of projects that implemented an OSGi-like core framework either in C or in C++. These are use in a variety of contexts from embedded in hardware to image processing systems. The authors of all these projects have put their heads together and started an RFP on a Native OSGi Core Framework. You can find RFP 156 here: https://www.osgi.org/bugzilla/show_bug.cgi?id=165

I think this is pretty exciting! The concepts of OSGi apply to many environments and languages and its great to now see standardization work happening in these new areas too!

If you have any feedback on these RFPs, leave a comment on the bugs!

InfoQ interview about work in the EEG

A little while ago I did an interview with Alex Blewitt from InfoQ about current activities in the OSGi Enterprise Expert Group. The interview is now available from here: http://www.infoq.com/interviews/Bosschaert-changes-OSGi-Enterprise-Specification

OSGi Cloud Ecosystems RFC 183 in public draft

Recently the OSGi Alliance has made an Early Access Draft available of many of the RFCs that are currently being worked on in the Enterprise Expert Group (EEG) and the Core Platform Expert Group (CPEG).

One of these is RFC 183: OSGi Cloud Ecosystems.
OSGi Cloud Ecosystems is about having a many OSGi frameworks co-operating in a Cloud or Cloud-like environment. Its about having multiple cloud nodes work together to provide a coherent logical function. This includes the ability to reconfigure your deployments to scale up when needed or scale down when possible. It also includes providing the ability to react to volatility in your Cloud environment, as nodes might die unexpectedly or may become unresponsive for some reason.

A large portion of RFC 183 is about how you discover things. How do I discover what OSGi frameworks are available in my environment? And what are the characteristics of those frameworks? What cloud or other environment are they running on and where? For certain applications knowing the actual country or region of your deployment is vital, so this is one of the pieces of information available.

When a cloud node appears it often appears on a dynamically assigned node. RFC 183 is about letting the other OSGi frameworks in the environment know that there is a new Framework available so that they can communicate with it. Information passed to other frameworks includes things as the IP address of the node, which is obviously vital in order to be able to communicate. Additionally information about the type of infrastructure the node is running on is made available. Typically the process that reacts to changes in the topology involves some of the following:

• If a new framework appears, it needs to be provisioned, meaning that an entity in the system needs to decide what artifacts need to be deployed on it.
• Once provisioned it needs to become part of the overall function of the system. This means that other entities on the various participating nodes must be wired up to use the new node.
• Similarly, when a VM is taken out of the environment, the interested other nodes are informed so that they can adjust to the situation.
• Other conditions may also require a change in the way the system is provisioned can be:
• when the load on a particular node gets too high - we need to find some quiet nodes that can take over some of the load.
• when the functionality offered by the application changes, maybe the user has changed the application configuration.
• when the system is quiet - we can give some resources back for consumption by other components.

RFC 183 aims at making it really easy to use OSGi services across Cloud nodes. This means that as a developer you're just writing OSGi services (which are really just Java POJOs) and that you can make these available across your Cloud Ecosystem to all the frameworks available. The mechanics are based on the OSGi Remote Services specs. The nice thing is that the Discovery piece takes care of wiring these services up, so you don't need to know where the service is running, you can simply find it in your local Service Registry and use it. If the service migrates to another VM, or another copy of it becomes available, Discovery will update the Service Registry in your framework so that it's up to date with what services are available in the ecosystem. The OSGi service model is already very much geared towards dynamicity of services, so the potential volatility of a cloud deployment fits here very well. Existing service component such as Declarative Services, Blueprint and others can work well with these Distributed Services while providing a very simple programming model at the same time.

RFC 183 is really about providing a base layer for dynamic applications that run in the cloud. It's minimal in the sense that it provides some primitives that allow you to create a dynamic, service-based cloud system in a way that is very familiar if you are used to OSGi services. It gives you all you need to write a provisioner that is part of the system, but it does not define a cloud deployment descriptor format or anything like that. At this stage you need to write your own provisioner that knows how to provision your application, although a more generic provisioning system could be written using the primitives provided.
Or maybe someone wants to create a PaaS that can take direct deployment of Blueprint beans or Declarative Service components. These too could also be modeled atop of what RFC 183 attempts to provide.

At the moment RFC 183 does not attempt to provide a standard mechanism for creating or shutting down compute nodes. There are already a number of projects that abstract over this and I think it would be best to utilize those right now, although it might make sense to describe at some point how these are integrated with the OSGi Service Registry.

It's still early days, this is the first EA draft that contains RFC 183, but from speaking with people who are using OSGi in a cloud environment, many solutions are moving into a similar direction, so it looks like things are converging.

You can find RFC 183 in the draft here: http://www.osgi.org/Download/File?url=/download/osgi-early-draft-2013-03.pdf

If you have any thoughts about it, let us know what you think at the osgi-dev mailing list or to create a bug around the topic in OSGi buzilla.

Additionally, I'll be talking about this topic at EclipseCon: http://www.eclipsecon.org/2013/sessions/osgi-cloud-ecosystems