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

Current themes in the OSGi Enterprise Expert Group

After the OSGi Enterprise R5 release this summer, the OSGi Expert groups have started working on new items for the OSGi R6 releases.

At this point in time, the main themes in the Enterprise Expert Group are Cloud and JavaEE integration. In the EEG the following documents are currently being discussed:

• OSGi/CDI integration (RFC 193) - jointly led by Red Hat/JBoss, SERLI and Luminis. This RFC aims to define a standard for OSGi-CDI implementations. A number of different implementations currently exist such as weld-osgi, Pax CDI and in Glassfish and others. The aim is to bring the CDI programming model to OSGi with portability across compliant implementations.
• OSGi Cloud Ecosystems (RFC 183) - jointly led by Red Hat/JBoss and Paremus. A standard OSGi-based PaaS definition with a focus on creating a highly portable dynamic cloud environment. This work is still in the early stages of discussion but you can find some of the thinking in my EclipseCon Europe presentation: http://www.slideshare.net/bosschaert/osgi-cloud-ecosystems
• Complex Repository Requirements (RFC 187) - lead by Red Hat/JBoss. This is a small enhancement to the OSGi Repository specification which was released as part of the Enterprise R5 release and for which Thomas Diesler did the Reference Implementation at JBoss. The enhancements discussed in this RFC focus on more complex requirements for the Repository back end.
• Portable Java Contracts (RFC 180) - lead by IBM. Read more about this RFC in my previous blog post.
• Enhancements to the OSGi HTTP Service (RFC 189)* - lead by Adobe. The OSGi HTTP Service specification is highly popular because its such an easy way to get Servlets up and running. However the specification was long overdue an update. This is what this RFC is about. It is about modernising the Servlet API and also brings the white board pattern to this specification.
• REST management (RFC 182) - lead by IBM. This RFC focuses on being able to remotely manage an OSGi Framework through REST, for example for use in a Cloud environment. For more information see my previous post.
• OSGi/EJB integration (RFC 194) - lead by IBM. This RFC has just started and aims at addressing the requirements from RFP 152.
• Blueprint version 1.1 (RFC 184) - lead by IBM. Discusses a number of improvements to blueprint, which include configuration around service damping and the grace period.
• Declarative Services Enhancements (RFC 190)* - lead by Adobe. This document discusses a number of improvements to DS among which are an Administrative API and new annotations.

Note that the OSGi/JCA integration (RFC 146), lead by Jesper Pedersen from Red Hat/JBoss is likely to become active again soon.

Additionally, a group of people is proposing an OSGi standard for C/C++. They are working on a new RFP which should be available in the near future.

At this stage many documents are still at the early stages of the technical design. The target date for the OSGi Core and Enterprise R6 releases is currently Q1 2014.

Note - if you're interested in getting involved in the RFC discussions and you are working for an OSGi member company, contact me (or any of the other EG co-chairs). If you're interested but don't work for a member company, have a look at the OSGi membership page: http://www.osgi.org/Join

* These RFCs are crossover topics with the OSGi Core Expert Group CPEG.

New OSGi EEG Early Access Draft available

A new Early Access Draft has been published at OSGi that contains 3 RFCs that are currently being discussed in the Enterprise Expert Group.

Blueprint Transactions (RFC 164)
This RFC focuses on how to add declarative transaction support to the OSGi Blueprint standard.

Portable Java Contracts (RFC 180)
OSGi has always been very outspoken about versioning Java packages (for more info see the Semantic Versioning white paper: http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf) however, what version to use for APIs defined by JavaEE has been unclear. While many people have been talking about these APIs in terms of the JavaEE versions (e.g. Servlet 2.5, Servlet 3.0) these version numbers don't always match with the Semantic Versioning ideas that OSGi promotes. For example, with Semantic Versioning you would only increase the major version if you are breaking backward compatibility. When Servlet 3.0 came out of the JCP it did actually not break compatibility with 2.5, but still the major version was increased. In the end the various OSGi-enabled application server implementors used different versioning schemes for JavaEE packages, which made it unclear how to use these in a portable way from OSGi. This RFC aims at addressing this issue in a way that is both natural to people familiar with the JavaEE version numbers as well as being able to cope with the various package version numbers used in the OSGi capable Application Servers.

REST Management Interface (RFC 182)
In the context of Cloud Computing, REST is becoming the dominant way of accessing and controlling remote applications running in the cloud. This RFC defines a remote management interface for OSGi bundles over REST and defines both JSON as well as XML data bindings.

You can find the Early Access Draft here: http://www.osgi.org/News/20121011
Remember that these drafts are not final - if you have any feedback, let us know either via bugzilla (http://www.osgi.org/bugzilla) or via the osgi-dev mailing list: http://www.osgi.org/MailLists

Disappointed by Jigsaw delay? Java Modularity is here today!

I recently heard that some people are expressing disappointment over the lack of a built-in module system in Java 8, now that Jigsaw is delayed. Some are apparently even looking at technologies other Java because of this. Well, I'd like to point out that There is No Need To Wait! All the modularity that your application needs is already available with OSGi! OSGi pretty much supports everything that Jigsaw was planning to support to allow modularization of applications. And OSGi has more features such as a dynamic lifecycle and a very useful services model. Still OSGi frameworks can be remarkably small. Of the popular implementations Apache Felix is probably the smallest with its implementation in under 500kilobytes. But Eclipse Equinox and our own JBoss OSGi Framework inside AS7 are also very good opensource implementations.

Want to learn how to use OSGi? Like many people I like learning stuff by reading a book. Recently a number of books have been published that provide really good explanations of how to use OSGi, notably OSGi in Action, OSGi in Depth and Kirk Knoernschilds Modular Architecture book, but probably my favorite book is Enterprise OSGi in Action. Besides containing a good description of a number of Enterprise OSGi specs, it also describes really well why certain things are done in OSGi they way they are, which give you a nice and deep understanding of the technology. Additionally it contains some great chapters on how to get your build, test and development environments to work smoothly with OSGi. Enterprise OSGi in Action will be in print later this year, but you can already get it in electronic form from here.

Besides the books, the OSGi Javadoc can be very useful and if you really want to know the details of it all, the OSGi specs are a great resource. Oh, and don't forget to check out the Wikipedia page that shows where you can get implementations of the various OSGi technology.

So in short - no need to wait or turn away from Java if you need Modularity. OSGi is here today and has been used in production by numerous users for many years, just get started by downloading one of the opensource implementations and try it out!

Presenting about Cloud Ecosystems at OSGi Community Event 2012

Over the past few months I've been piloting what I started to call an OSGi Cloud Ecosystem. You can see the details on my technical blog <coderthoughts/>. I am coming to the conclusion that OSGi can provide a really interesting basis for a Platform as a Service that can support the fluidity of the cloud, where services migrate from one VM to another and systems can scale up and down as needed, without having to worry about getting swamped by configuring what runs where etc. Your OSGi system is based on a Service Oriented Architecture where your services are implemented and consumed using the widely supported OSGi services programming model. Your system is comprised for multiple cloud VMs each of which may take different roles over time. As the need arises you add or remove cloud VMs that contain some of your OSGi services, migrating services across VMs as needed. However as a consumer you simply use the OSGi Service Registry to find and use your services.

The postings on <coderthoughts/> show a pilot that implements these ideas and I'll be talking more about them (and showing a demo) at the OSGi Community Event 2012 (which is part of EclipseCon Europe 2012) on October 23-25 in Ludwigsburg, Germany. See here for the programme: http://www.osgi.org/CommunityEvent2012/Agenda for general conference information go here: http://www.osgi.org/CommunityEvent2012

Hope to see you there!

Feedback requested for OSGi RFPs

Now that the summer holidays are drawing to a close for most, it would be a good time to look at some of the new work that is happening at OSGi.
In OSGi new specification efforts are kicked off by creating an RFP, a document that lists the uses-cases and requirements that the ultimate specification must implement. Once an RFP is agreed on the actual technical design and spec-work starts through the creation of a follow-up RFC.

Recently 4 new RFPs have been made public via OSGi bugzilla to see if people have further input or requirements, a process that has worked really well for the OSGi/CDI RFP and a little longer ago for the OSGi Cloud RFP.

RFP 143 OSGi Connect

The people at PojoSR have done some great work in showing how you can use OSGi Services in cases where you may not want to take on OSGi modularity (yet). RFP 143 captures requirements for creating a specification around this. The RFP can be found here: RFP 143.

RFP 150 HTTP Service Updates

The OSGi HTTP Service is widely used and it provides a very nice programming model for sevlets in an OSGi environment. However the specification is in need for an update to modernize it in relation to the Servlet spec itself. Additionally, the whiteboard pattern is introduced for servlet. You can find the RFP here: RFP 150.

RFP 151 Declarative Service Updates

A variety of updates are proposed to the Declarative Services specification. They can be found in RFP 151.

RFP 152 EJB Integration

EJB integration with OSGi has been done at Apache Aries, Glassfish and ObjectWeb (EasyBeans / JOnAS). Other appservers such as JBoss and others also provide some form of interaction between EJBs and OSGi. This RFP aims a writing a specification for this integration to make OSGi-enabled EJBs portable. You can find the RFP here: RFP 152.

So if you have any thoughts about these topics, do chime in and leave your comments or ideas on the associated bugs!

No Jigsaw for JavaSE 8

Yesterday Mark Reinhold announced that Oracle will not pursue modularity for JavaSE 8: http://mreinhold.org/blog/late-for-the-train. Following long delays for the Modularity JSR the decision was made not to postpone JavaSE 8 or rush through the JSR but rather postpone the Modularity part of Java 8 and push ahead with the rest of it.

So what does this mean for Modularity in Java? Well, I think its an appropriate decision to not rush things through. As modularity is such a fundamental piece of functionality you don't want to cut corners with the architecture. OSGi has been providing modularity to Java for over 12 years now and there are a lot of lessons to be learnt from it.

Project Jigsaw is a prototype of a modularity system that's part of the Java runtime, but at this stage it's just one approach to this. In Project Penrose work is ongoing around improving the extensibility of Jigsaw so that it can work better with other module systems such as OSGi.

While some work is definitely needed to modularize Java itself, as an application developer you don't need to wait for this. If you need modularity in your applications, then OSGi provides all that you need today and it has been proven for years by many in the field.

It's good that the Modularity JSR will get some proper time now. I hope the process will be democratic and that the result will provide the best technology possible that keeps extensibility in mind.