Setting up an OSGi project and running the application with bnd and Bndtools is quite easy as it provides the basics to get a developer started. Unfortunately, the default templates only get you settled with the basics. Companies have certain requirements on their code and often require builds to match the requirements of their company processes. Thus, something extra is required to help new developers get ready to roll and this tutorial will explain how this can be achieved. Attendees will understand how they can setup new projects and workspaces accordingly.
The OSGi Alliance Community Event is co-located with EclipseCon Europe, and offers a full OSGi specific program that is open to all attendees. Talks related to OSGi technology and the OSGi ecosystem, including use cases and new initiatives around OSGi IoT, Cloud, and OSGi enRoute, should be submitted here. OSGi provides a vendor-independent, standards-based approach to modularizing Java software applications and infrastructure. Its proven services model enables app and infrastructure modules to communicate locally and distributed across the network, providing a coherent architecture for IoT services. OSGi specifications are tested and ready now to provide highly scalable remote management and effective maintenance over the long term.
OSGi was originally designed for Smart Homes and Residential Gateways almost 20 years ago.
This talk will present how the OSGi specifications have evolved over the years, and how you today, in 2018, design an OSGi based Smart Home System.
A real world use case of a Swedish Smart Home start-up company will be used to illustrate different design principles and how OSGi remains as relevant today as it was when it started.
- Small fit-for-purpose executables
- Put the micro in Microservices
- Minimal Docker images
- Does Java have what it needs?
The OSGi framework, and the service specifications, is a powerful and simple way to build modular software. However writing modular software is hard and even a simple framework doesn't necessarily make things easy, especially when you are writing an application server consisting of over 100 discrete features. When that application server needs to dynamically respond to configuration changes, provisioning (or deprovisioning) features as required. Even worse when it has to support Java EE applications which are written with a totally different modularity (cough-cough) model.
Every so often we need to introduce a new developer into our team who might not have experience with OSGi nor any other modular system. Have you ever thought how we can make adoption of new comers into your ecosystem easier?
Most of OSGi projects require some kind of tooling during both - build and development time. While we might live without second reliability of first one is a key of stable builds. As new hire you probably went over some introduction showing how to use properly tooling and surrounding infrastructure in order to become productive. Lets see together how much we can simplify.
OSGi Compendium R7 provides a major update to the OSGi LogService specification. A new logging API is added which supports logging levels and dynamic logging administration. A new Push Stream-based means of receiving log entries is also added. But it is quite often the case you need to use other code such as open source projects which are using slf4j for their logging API. This session will explore the new OSGi LogService changes and how you can integrate code using both slf4j logging and OSGi LogService logging.
Java 9 introduced the Java Platform Module System (JPMS) as a way to modularize the Java platform and it can be also be used by developers to modularize their own applications, although JPMS lack a number of important features for software running on the Java platform.
As people look to support the latest versions of the Java platform, changes introduced in Java 9 related to JPMS led to the needs for some features in the OSGi Core specification. OSGi framework implementations like Eclipse Equinox and Apache Felix and tools like Bnd were updated to support these new features.
Turtles all the Way Up - From OSGi bundles to Fog Computing.
The model of centralised cloud compute is changing. As large-scale IoT deployments have started to become real organisations are realising that a single central cloud can’t cope with the data security, data volumes, latency or robustness that they need for their businesses. Centralising in a single cloud also offers a huge operational risk - if the cloud fails, their business must continue!
With the proliferation of cloud computing and more recently mobile and edge computing, there is a increasing demand to build flexible and robust distributed applications. The OSGi service and module technology is a key enabler for such deployment. Recent additions to the OSGi standards provide a set of services that provide interfaces for managing distributed instances of OSGi frameworks.
OSGi offers an excellent service discovery mechanism, it is limited to services inside the JVM. That limits us in two ways: It limits us to Java services, and it limits us to one single machine, and neither are acceptable in this day and age. Can we connect our OSGi runtime to a cluster orchestration manager like Kubernetes so our runtime can interact with the cluster and allow us to respond to changes in the cluster as dynamically as we are used to in OSGi itself. I think we can.