A decade ago Paremus fused Java’s dynamic service framework (Jini) with OSGi to create a modular, distributed, Microservces platform (known as Infiniflow); thereby creating the ancestor of the current Paremus Service Fabric. Seeing the importance of OSGi (strong modularity / isolation, dynamic dependency resolution, semantic versioning, a nascent but potentially powerful service architecture, all of which defined by open industry standards ) Paremus joined the OSGi Alliance as ‘Adopter Associate’ – a small step, a minimal commitment.
As Service Fabric concepts evolved, became centre stage. Hence in September 2009 I took the decision to upgrade Paremus to a full Alliance member – the equivalent of today’s OSGi Alliance Strategic Member. Paremus also decided to stand for election to the OSGi Alliance Board.
This was then, as today, a significant commitment for a small UK software company. And each year this decision is re-assessed.
Do Paremus stay as Strategic Members, perhaps downgrade to a lower level, or even follow the example of some in the software industry and consume the benefits of OSGi without being an OSGi Alliance member?
Of course, the financial commitment is only one consideration. If participating in an OSGi Alliance Expert Group (EG), your engineer/s will want to physically attend at least some of the EG meetings each year. As a member of the OSGi Alliance Board you will attend one or more face to face Board meetings each year.
There is also the effort required to actually move an initiative forwards. The OSGi Alliance is not just a talking shop: one or more companies need to contribute intellectual property and commit engineering resource so that a new specification may first be first created, and then life breathed into it via a corresponding reference implementation and conformance tests.
Looking back at 2015 Paremus contributed to the OSGi Alliance in the following ways …
- We organised the OSGi Developer Certification events – see https://www.osgi.org/osgi-certification/developer-certification/.
- Building upon the success of the Asynchronous RPC specification in 2014 (see – asynchronous-osgi-promises-for-the-masses-osgi-devcon-2014 & osgi-promises), which in-turn trigger the Promises specification led by our IBM colleagues, Paremus started follow-on specification work in the areas of Push-Streams (Reactive Java – see asynchronous-event-streams) & Distributed Eventing – see rfc-0214-DistributedEventing.pdf.
- We contributed to the JAX-RS specification work with our Liferay and Adobe colleagues – see rfc-217-JAX-RS-Services.pdf.
- Paremus were also heavily involved in the OSGi Alliance’s new IoT efforts including: the initial workshops (Europe & US), the IoT demonstrators at the European OSGi Community events (2014 & 2015), and chairing the new formed IoT EG.
- Finally, Paremus continued to man the position of OSGi Treasurer and contributed to general OSGi Alliance’s Marketing activities.
Then there is bndtools.
A high quality development tool chain is critically import to the ongoing success of OSGi. For this reason Paremus continued to invest throughout 2015 in bndtools with Neil Bartlett (bndtools project founder), Tim Ward and Gustavo Morozowski delivering improved Maven support and a new template system. At this point I should also mention the sterling efforts by Peter Kriens (OSGi Alliance) & BJ Hargrave (IBM) in enabling bndtool’s support for the OSGi Alliance’s new Enroute initiative.
But why bother? Isn’t OSGi a niche play – one of a number of alternate modular approaches for Java only environments?
OSGi is perhaps the most valuable treasure to have emerge from the entire Java EcoSystem. Modularity and dynamic dependency management are fundamental to driving down maintenance costs, removing technical debt and increasing business agility (see – Design Rules, Volume 1) and OSGi squarely addresses these concerns.
But what about the threatened arrive (sometime during this millennium) of JigSaw? Well the Paremus’ analysis of JigSaw can be found in Neil Bartlett’s post – jigsaw-is-a-shibboleth. To summarise Neil’s conclusions – JVM modularity is required and JigSaw addresses this requirement. Oracle should get on and deliver it. However JigSaw should not attempt to compete with OSGi at the application layer; here JigSaw is simply not fit for purpose.
But ultimately who cares? In this age of Polygot systems Java is just one of many languages! Surely Paremus efforts would be better spent chasing the current industry fashions: i.e. Docker and REST based Microservices?
True the world isn’t just Java, but Enterprises are predominately Java centric. Also many OSGi modularity concepts are quite generic in nature…
Leveraging OSGi principles, the Paremus Service Fabric does support the deployment of native none Java artefacts to Containers. However, our perspective is different from others in the industry.
‘Cloud Platforms‘ tend to fixate on resource optimisation. For Cloud Service providers this is understandable as this is where profits are created; i.e. via the simple arbitrage opportunity on compute resources. However this mindset has skewed the software industry’s perceptive of the issues faced by large organisations. Hence, unlike potential Platform competitors (e.g. Docker, Mesosphere, CloudFoundry/Pivotal, Google and others) Paremus does not consider the ability to maximally pack static opaque software artefacts into an unchanging data centre environment as THE fundamental issue. For large organisations this is only a line item in a much larger wish list.
Organisations require robust, secure, low maintenance platforms and hosted applications, that are simple to install, and simple to maintain and adapt. The platform must allow for architectural flexibility and business agility, while at the same time enforcing governance, re-use and scalability. The ideal platform solution would allow business units the freedom and flexibility to merge into, or detach away from, central IT services as changing business imperatives dictate. Within this spectrum of concerns – optimising resource utilisation is desirable – but much much less important than maximising operational simplicity, platform robustness and enforcing effective corporate governance.
All of these concerns ultimate reduce to the problem of operational management of an increasingly complex set of dynamic runtime dependencies; and OSGi remains the only industry standard that effectively addresses this issue. In contrast ‘Containers‘ do not address the issue – indeed Container Images effectively sidestep the problem. A neat conjuring trick – but a trick none the less. On a positive note – the current Container trend is an incremental step forwards from what proceeded it! Namely the extremely bad idea of deploying ‘applications & operating system‘ combinations as shrink wrapped opaque virtual machine images (VMI’s).
So today, at the start of 2016, OSGi seems to be as fundamentally important to Paremus as when we initially joined the OSGi Alliance in 2006. Paremus will be renewing our OSGi Alliance Strategic Member this year.
Not yet an OSGi Alliance member? Why not join the OSGi Alliance this year and help us deliver the modular & reactive foundations necessary for the next generation of federated Cloud & IoT!
Wishing you both Peace & Enlightenment in 2016