Functional Modularity - Building Better APIs for the OSGi Ecosystem

Introduction

One of the new RFCs (RFC 216) being discussed in the Enterprise Expert Group is called PushStreams and is all about stream processing. I’m leading the RFC and whilst a final specification is still a way off, the open processes at the OSGi Alliance mean that people (including me) have already been talking publicly about this RFC.

My talk about PushStreams at the OSGi Community Event was well attended, and feedback on it led me to write a blog post about why we need PushStreams. Since then there have been even more questions, including a few about the design of the API and the theory behind it. I thought therefore I should talk a little about the reasoning behind the APIs from some OSGi specifications that I've worked on in the last few years.

Functional Programming at the OSGi Alliance

The OSGi framework is a module system for Java, and Java is inherently Object Oriented in its approach. Given that this is the case why is OSGi starting to define APIs with a more functional usage pattern? In fact OSGi is far from alone here, Open Source Projects, and even Java itself, are building more functional concepts into the libraries that we all use.

The reasons for this change are varied, but in general functional concepts are introduced to solve problems in a simpler way than is possible using Object Oriented programming techniques. OO programming provides a lot of benefits, but as systems become more distributed, more highly parallel, and more asynchronous they become much harder to manage and to reason about.

OSGi as a technology is used across a huge range of sectors, and across many layers of the technology stack. OSGi is used in embedded software, such as car entertainment systems and home gateways; it is used in desktop applications, such as Eclipse RCP apps; and it is used in server runtimes, such as Java EE application servers and distributed cloud runtimes.

In order to support such a large ecosystem it is vital that OSGi continues to evolve to better match the areas it is used. To better support distributed server platforms the OSGi compendium release 6 included Promises and the Async Service. The addition of PushStreams will help to support new use cases from IoT, where event filtering, forwarding, and aggregation are vital parts of allowing systems to work in the real world.

For those of you already familiar with functional programming, you will notice that the PushEventSource and PushEventConsumer are an example of an Enumerator and an Iteratee. Once a basic implementation is available I’ll put together some examples showing just how much they can simplify processing a stream of events.