If you are following the progress of Java 8, then you will be aware that Jigsaw may – yet again – fail to make the release train. There again, it might: ‘they’ seem just a little uncertain.
In stark contrast, since the appearance of JSR277 in 2005 (yes 2005!), the OSGi Alliance position has remained consistent and coherent. This position was restated yet again this week here. For those interested, several excellent supporting background articles may be found here, here and with Neil Bartlett’s usual humourous perspective here.
Paremus’ view is quite simple. For the record…
Java modularity should be based upon OSGi. Failure to do so will fracture the Java community and market and so damage to the future of the Java language.
However, this isn’t the main focus of this post: Just an interesting aside. 😉
And now for something completely different…
Paremus have been dynamically deploying OSGi based applications into ‘Cloud‘ environments for 7 years! Why would one use static virtual machine images, when your applications can be automatically assembled from re-usable components and automatically configured with respect to their runtime topology and the specifics of the runtime environment?
Surprisingly, this message has taken a while to seed; but seed it has: Paremus is nothing if not persistent. So 7 years on, and the Paremus Service Fabric represents the state-of-the-art ‘Cloud’ platform for those organisations that require something a little bit special: an adaptive, self-managing solution for their next generation of low maintenance modular OSGi based Java or Scala composite applications.
- Some popular Java software projects remain monolithic and are unlikely to embrace OSGi anytime soon: e.g. Hadoop, ZooKeeper etc.
- Many Service Fabric customers have a large portfolio of monolithic applications.
- Some applications are not even Java / JVM based.
So if you want Service Fabric capabilities, but have one or more of the above challenges what are we to do?
OSGi > Java
OSGi provides a set of Modularity, Life-cycle and Service capabilities that transcend any particular language.
The journey starts with the realisation that OSGi specifications encapsulate a number of remarkably useful language neutral concepts:
- Metadata for describing software artefacts; including flexible declaration of the artefact’s Capabilities and Requirements [environmental resources, Services and module dependencies], and a powerful semantic versioning scheme for module dependencies.
- Leveraging this metadata; powerful and extremely flexible dynamic dependency resolution capabilities.
- A consistent approach to life-cycle: installing, starting, configuring, stopping and uninstalling software artefacts.
- A flexible configuration service for configuring installed artefacts.
- A powerful Service model, including pluggable RPC implementations for remote services that enable the decoupling of the service interactions from the underlying implementation language. For example, the Paremus Remote Service Administration implementation provides an Avro distribution provider.
So, pulling these concepts together, Paremus created Packager: Packager allows traditional software artefact to be installed, deployed and dynamically configured just like OSGi bundles.
Neil Ellis, our lead developer on the Packager project, will post a series of articles over the next few weeks that will:
- Introduce Packager concepts with a series of examples.
- Investigate scenarios in which Packager may be of interest in non OSGi environments.
- Contrast Packager against some of the other software deployment approaches that are available today.
If you are pursuing a modular cloud platform strategy and see the value in a consistent approach to runtime deployment and management: from the smallest of bundles to the LARGEST OF APPLICATIONS. If you understand the pitfalls and complexities caused by reliance on static bloated virtual machine images, and if you value open industry standards; then we think you will be interested in Packager.
So Stay Tuned … 😉