Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OSGi in Action - How we use OSGi to build Open Liberty - Alasdair Nottingham (IBM)

20 views

Published on

OSGi Community Event 2018 Presentation by Alasdair Nottingham (IBM).

Abstract: 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.

Open Liberty was designed from the ground up to use OSGi as it’s core modularity framework, making extensive use of declarative services, metatype, and subsystems. We did a lot right, we made mistakes, some we fixed some not so much, we fixed a lot of bugs including a number in Felix SCR. Come along to hear a lessons learned about how we used OSGi to build the most flexible application runtime for building web and cloud applications.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

OSGi in Action - How we use OSGi to build Open Liberty - Alasdair Nottingham (IBM)

  1. 1. 1 How we use OSGi to build Open Liberty Alasdair Nottingham - IBM
  2. 2. 2 Project goals • Implement Java EE • Small Footprint • Start fast • Composible • Dynamic • Easy to use
  3. 3. 3 Fit-for-purpose server • You control which features are loaded into each server instance Kernel <feature>servlet-3.1</feature> servlet-3.1 http-1.1 appmgr <feature>jsf-2.2</feature> jsp-2.3 jsf-2.2 Java EE
  4. 4. 4 Server configuration <server> <featureManager> <feature>javaee-8.0</feature> </featureManager> <httpEndpoint id=“defaultHttpEndpoint” httpPort=“8080”/> <webApplication location=“myWeb.war” contextRoot=“/”/> </server>
  5. 5. 5 Modularity - OSGi vs Java EE Bundle A Bundle B Bundle c ear jar jar war jar jar ?
  6. 6. 6 Java EE -> OSGi ear jar jar war jar jar war jar jar
  7. 7. 7 custom classloaders Java EE on OSGi Bundle A Bundle B Bundle c ear jar jar war jar jar region Gateway
  8. 8. 8 Key OSGi Technologies • Equinox (duh) • Metatype • Declarative Services • Config Admin • Subsystem Features • Regions
  9. 9. 9 Things we learned • Shutdown is not as simple as stopping the framework • Statics and service do not mix & match • Use the build tools • Very powerful for large complex software • DS and ConfigAdmin together are brilliant • High learning curve • Java SE classloading assumptions don’t mix well in OSGi

×