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.

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. © 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. 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.  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. © 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. © 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. © 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. © 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. © 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. © 2012 IBM Corporation
Why services?
 OSGi Primitive
 Peer to peer
 Lifecycle
 Deferred Initialization
 Metadata driven service frameworks
10
Tuesday, 10 April 12

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. © 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. © 2012 IBM Corporation
When is optional truly optional?
13
Web
Container
transactions
naming
security
Optional,
multiple,
dynamic
Tuesday, 10 April 12

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. © 2012 IBM Corporation
Mixing Services and Static API calls
15
Static
Class
Service A
Service B
Service C
Client
Tuesday, 10 April 12

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. © 2012 IBM Corporation
Shutdown
 Synchronous for mandatory services
 Asynchronous for optional services
17
Service BService A Service C
Tuesday, 10 April 12

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. © 2012 IBM Corporation
Conclusion
 Services are
–Powerful
–Flexible
–Lightweight
–Lazy
–Peer to Peer
 Complicated
 Totally worth it
19
Tuesday, 10 April 12

20. © 2012 IBM Corporation
Questions?
20
Tuesday, 10 April 12