`OSGi Enabled` – This is not a statement, this is an ongoing commitment to you…

A Product or Service bearing the “OSGi Enabled” ingredient mark signifies an ongoing commitment: a commitment to maintainability, flexibility, evolvability; a commitment to longevity.


The US DARPA agency states that the longevity of modern software systems is orders of magnitude less than other human built artefacts. In this, DARPA rightly recognise the need for software systems to be adaptive to unforeseen changes in their runtime environments. Via the BRASS initiative, DARPA hope to encourage the IT industry to think about bigger picture.

If you accept DARPA’s concerns; then the following conclusion is logically inescapable.

Adaptive, Evolvable Systems need to be Modular Systems. By modular – we mean internal structural modularity. An opaque software BLOB deployed as a static Virtual Machine or Container Image is not modular; and does not qualify. Also, to allow for interoperability and interchangeability, the approach to modularity must be based on open industry standards: standards that themselves must have demonstrable longevity.

DARPA – the answer to BRASS is OSGi™.

Since its introduction in the late 1990’s, OSGi – “the modularity system for Java” has slowly diffused into just about every corner of the IT industry. Originally create to address the resource and maintainability requirements for the Smart Home and IoT (circa 2000),  OSGi has evolved and adapted and is today, in 2016, still uniquely positioned to address the issues and challenges that exist for the IoT,  M2M, Smart Home, Smart Cities, Smart Agriculture markets.

Yes; an industry standard conceived in the late 1990’s is today directly addressing the commercial issues slowly being uncovered by the latest wave of IoT, including but not limited to: Analytics and Behaviour everywhere (Edge, Fog, Mist, whatever); the management of multitudes of heterogeneous and continuously changing Edge devices; secure software deployment to those devices; deploying only what is necessary and knowing the pedigree / providence of each atomic unit of software deployed.

This week the OSGi Alliance launched the OSGi™ Enabled ingredient mark. Probably long overdue; but in a decade’s time this may well be one of the most recognised ingredient marks powering the Adaptive / Pervasive Internet of Things. It will need to be if DARPA’s challenge is to be addressed.

So what does “OSGi Enabled” signify?

The Product or Service bearing the “OSGi Enabled” ingredient mark has been engineered with maintainability, adaptability and evolvability as design priorities.

The “OSGi Enabled” mark also indicates that the solution provider realises that open industry standards are both required, and that they do not just spontaneous appear. Effort and resources are required to create such standards; and the vendor, by supporting the OSGi Alliance, is actively playing their part in that process.





Paremus have been an OSGi Alliance Strategic Member for many years, and we have contributed in many areas across the organisation: President (2011-2013), Treasurer (2014-current), VP Marketing (2015-current), IoT co Chair (2015-current). Paremus have also driven or contributed to many OSGi Specifications.

The Paremus Service Fabric – a highly modular orchestration platform for Enterprise or IoT environment – has been built from the ground up leveraging OSGi. In addition Paremus extend OSGi principles beyond Java with Packager (see https://docs.paremus.com/display/SF113) – to support Microservices or traditional software components written in an language.






Hence I’m delighted that Paremus Service Fabric is eligible to use the “OSGi Enabled” ingredient mark and all that this signifies.

Dr Richard Nicholson. Paremus founder & CEO, OSGi Board Member.

Share This:

Java 9, OSGi and the Future of Modularity

InfoQ today published the first part of a two part article written by Neil Bartlett from Paremus and Kai Hackbath from Bosch / ProSyst.


Its definitely worth a read. The article was written some time ago so is in advance of the latest delay to JPMS / Jigsaw (and consequently Java 9) that was proposed last week on the mail list and at JavaOne this week.  This is just the latest in a series of delays over many years and we suspect won’t be the last.

As a very quick synopsis the conclusions are: (more…)

Share This:

Using Let’s Encrypt Certificates with OSGi HTTP Service

Rather than one of my usual polemics, this is a quickly-written practical post. I hope the information here is useful to somebody.

Currently I am setting up effectiveosgi.com, the website for my upcoming book “Effective OSGi”. The site is a web app that will allow users to download preview PDFs, order print copies, and so on. Naturally I am developing it in Java and OSGi (in fact, many of the code samples in the book are based on (more…)

Share This:

Vertical Components

Combining Web and OSGi Components

I consider myself a latecomer to Microservices; I only really started to understand and use them in 2005. Nobody called them “Microservices” at the time – as far as I can tell, the term was coined in 2006 by BEA for their microService Architecture (mSA). Regardless, with this history it was a little surprising to hear the term reinvented in 2014 and suddenly gain a great deal of traction. While implementation details vary, the fundamental (more…)

Share This:

Functional Transaction Management – old dog, new tricks! 3 comments

This blog post is all about the new Transaction Control service which is proposed to be part of the next release of the OSGi Enterprise Specification. Paremus has been leading this specification work, which arose from a collaboration with one of our customers, McCarthys. The current state of the RFC is available on GitHub, and there’s even an implementation available in Apache Aries.

Before we delve into the cool features of the Transaction Control service, it’s probably worth remembering why we need yet another transaction abstraction… (more…)

Share This: