Liberate your components with OSGi services

Transcription

1 Liberate your components with OSGi services One products journey through the Modularity Maturity Model Alasdair Nottingham WebSphere Application Server V8.5 Liberty Profile Development Lead

2 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 2011 IBM Corporation

3 WebSphere Application Server WAS V8.5 Liberty profile (Alpha) level 4/6 WAS V8 level 2 WAS V6 WAS V6.1 level 3 WAS V7 WAS V7 Feature Pack for OSGi Applications OSGi R4 + OSGi R4.2 OSGi R4.2 OSGi R4.3 Server runtime used R4 Applications used R OSGi R4 4

4 Starting point - build Componentized build Components have identity and version Components produce a jar impl depends on interfaces at build time interfaces impl Factory in interfaces uses Class.forName to load impl at runtime 4

5 Component based runtime init/start stop/destroy A Java Bean Implements a specific interface Init/start/stop/destroy phases Started in a specified order Makes use of: Class.getResources() Class.forName() A B C D 5

6 Move to OSGi Option 1 Jar A Jar C Jar A Jar C Jar B Jar D Jar B Jar D Option 2 Content of Jar A-D 6

7 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

8 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

9 Liberty Profile New server kernel Mostly the same code Exploit standards where possible Be dynamic, lightweight, lazy Backed by simple XML. schema defined in metatype Feature Manager felix scr equinox metatype Config Admin R4.2 equinox framework

10 Why services? OSGi Primitive Peer to peer Lifecycle Deferred Initialization Metadata driven service frameworks 10

11 Declarative Services XML Service Registration/Injection Framework Defines components Components are services. Config Admin integration Setup synchronously with bundle activation Annotations/bnd/xml 11

12 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

13 When is optional truly optional? transactions Web Container naming security Optional, multiple, dynamic 13

14 Intermediaries Needs an ArchiveManager, know the converters it cares about Doesn t know about specific converters Web Metadata Web Container Archive Ear Metadata OSGi Metadata Optional, multiple, dynamic 14

15 Mixing Services and Static API calls Service A Client Static Class Service B Service C 15

16 When is a Bundle ACTIVE? Services come and go Dynamically So what does ACTIVE really mean? Are we ready for the ready service? 16

17 Shutdown Synchronous for mandatory services Asynchronous for optional services Service A Service B Service C 17

18 Service versioning Service interface Bundle Service Client? which service to use? Bundle A version Bundle A version

19 Conclusion Services are Powerful Flexible Lightweight Lazy Peer to Peer Complicated Totally worth it 19

20 Questions? 20