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.

Liberate your components with OSGi services - Alasdair Nottingham

352 views

Published on

OSGi DevCon 2012

Converting any large application to be OSGi based is a difficult and complex process. Many projects find the fences that OSGi put in place puts insurmountable barriers in the way of success. Many projects get a short way through to embrace the concept of modules, but frequently they get no further and as a result they do not see the many benefits of OSGi.

In this talk the speaker will discuss the trails and tribulations of moving a large software product (WebSphere Application Server) to being based on OSGi and how the new liberty profile embraces OSGi services to produce a more lightweight and flexible server runtime.

For those aware of the Modularity Maturity Model the liberty project aims to move WebSphere Application Server from Level 2 to Level 6.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Liberate your components with OSGi services - Alasdair Nottingham

  1. 1. © 2012 IBM Corporation Liberate your components with OSGi services One products journey through the Modularity Maturity Model Alasdair Nottingham (not@uk.ibm.com) WebSphere Application Server V8.5 Liberty Profile Development Lead Tuesday, 10 April 12
  2. 2. © 2011 IBM Corporation Modularity Maturity Model Summary Level Name Summary 1 Ad Hoc Nothing 2 Modules Formal identity, decoupled from artifact 3 Modularity Formal module contracts, decoupled from identity 4 Loose-Coupling Services, semantic versioning, decoupled from implementation 5 Devolution Modularity-aware repositories, collaboration, governance, decoupled from ownership 6 Dynamism Life-cycle awareness and independence, decoupled from time Tuesday, 10 April 12
  3. 3. WebSphere Application Server WAS V8 WAS V8.5 Liberty profile (Alpha) WAS V7 Feature Pack for OSGi Applications © 2012 IBM Corporation 4 2005 2006 2007 2008 2009 2011 2010 2012 WAS V6 WAS V6.1 OSGi R4 WAS V7 OSGi R4 + OSGi R4.2 OSGi R4.3 level 2 level 3 level 4/6 OSGi R4.2 Server runtime used R4 Applications used R4.2 Tuesday, 10 April 12
  4. 4.  Componentized build  Components have identity and version  Components produce a jar © 2012 IBM Corporation Starting point - build 4 interfaces implinterfaces impl depends on interfaces at build time Factory in interfaces uses Class.forName to load impl at runtime Tuesday, 10 April 12
  5. 5. © 2012 IBM Corporation Component based runtime  A Java Bean  Implements a specific interface  Init/start/stop/destroy phases  Started in a specified order  Makes use of: –Class.getResources() –Class.forName() 5 D C B A init/start stop/destroy Tuesday, 10 April 12
  6. 6. © 2012 IBM Corporation Move to “OSGi” 6 Jar A Jar B Jar C Jar D Jar A Jar B Jar C Jar D Content of Jar A-D Option 1 Option 2 Tuesday, 10 April 12
  7. 7. © 2012 IBM Corporation Moving Forward Five Years  More bundles  Smaller bundles  Packages split across bundles a real issue  Limits on how much processing can be deferred  To much centralisation of control  Remove some non-standard eclipse technology –EMF –Update Provisioner 7 Tuesday, 10 April 12
  8. 8. © 2012 IBM Corporation Issues with Approach  All bundles are singletons  Support outside OSGi framework required  No notification support  Too many inefficient APIs  Data read up front during initialization  Many different extension patterns 8 Tuesday, 10 April 12
  9. 9. © 2012 IBM Corporation Liberty Profile  New server kernel  Mostly the same code  Exploit standards where possible  Be dynamic, lightweight, lazy 9 equinox framework 3.7.2 equinox metatype 1.2.0felix scr 1.6.1 Config Admin R4.2 Backed by simple XML. “schema defined in metatype Feature Manager Tuesday, 10 April 12
  10. 10. © 2012 IBM Corporation Why services?  OSGi Primitive  Peer to peer  Lifecycle  Deferred Initialization  Metadata driven service frameworks 10 Tuesday, 10 April 12
  11. 11. © 2012 IBM Corporation Declarative Services  XML Service Registration/Injection Framework  Defines components  Components are services.  Config Admin integration  Setup synchronously with bundle activation  Annotations/bnd/xml 11 Tuesday, 10 April 12
  12. 12. © 2012 IBM Corporation Blueprint  XML Component Injection Framework  Based on Spring  Defines components –Beans –Services –References  Allows non-service components  Extensible  Asynchronous to bundle activation  Service Damping  5 minutes to die 12 Tuesday, 10 April 12
  13. 13. © 2012 IBM Corporation When is optional truly optional? 13 Web Container transactions naming security Optional, multiple, dynamic Tuesday, 10 April 12
  14. 14. © 2012 IBM Corporation Intermediaries 14 Archive Web Metadata Ear Metadata OSGi Metadata Optional, multiple, dynamic Web Container Doesn’t know about specific convertersNeeds an ArchiveManager, know the converters it cares about Tuesday, 10 April 12
  15. 15. © 2012 IBM Corporation Mixing Services and Static API calls 15 Static Class Service A Service B Service C Client Tuesday, 10 April 12
  16. 16. © 2012 IBM Corporation When is a Bundle ACTIVE?  Services come and go  Dynamically  So what does ACTIVE really mean?  Are we ready for the ready service? 16 Tuesday, 10 April 12
  17. 17. © 2012 IBM Corporation Shutdown  Synchronous for mandatory services  Asynchronous for optional services 17 Service BService A Service C Tuesday, 10 April 12
  18. 18. © 2012 IBM Corporation Service versioning 18 Bundle A version 1.0.1 Service Client Bundle A version 1.0.0 Service interface Bundle ? which service to use? Tuesday, 10 April 12
  19. 19. © 2012 IBM Corporation Conclusion  Services are –Powerful –Flexible –Lightweight –Lazy –Peer to Peer  Complicated  Totally worth it 19 Tuesday, 10 April 12
  20. 20. © 2012 IBM Corporation Questions? 20 Tuesday, 10 April 12

×