This presentation shows the benefits of modularity and component/service based development in Java

1. Modular Java
(Component Oriented Programming with OSGi)
December 2009
Ilya Rybak

2. Agenda
 Modularization and Object-Oriented
 Modularization in Java
 Component-Oriented buzz
 Introduction to OSGi
 Java 7 „wanted‟ list
2

3. Modularization
 Recycling old ideas that were raised in the early 70s
o High Cohesion
o Low Coupling
 Manage growing complexity
o Modularization minimizes complexity by creating proper
boundaries between the parts that compose a system
 Support dynamic extensibility
o Properly modularized systems are easier to maintain
and extend
o Changes are more localized and affect less of the
overall system
3

4. Complexity vs. Productivity
4

5. Object-Oriented
One of the primary goals of object oriented programming (OOP) was, and still is,
Re-Use
It has mostly failed in that goal!
5

6. What went wrong?
 Focus in OO was on encapsulation of instance variables, which is
some form of modularization, but granularity is too small
 Coupling
o Classes can almost never be used in isolation, they depend on other classes
o Those classes depend on other packages, which depend on other JARs/DLLs…
o OO systems become tangled webs quickly
6

7. A Solution?
Re-use of classes outside their original context is hard, so. . .
Leave them where they are,
Give up and hide by a façade and call it
duplicate "SOA"
Patterns like SOA, Factories, Dependency Injection,
Inversion of Control are trying to minimize the
consequences of the OOP’s lack of modularization
7

8. Modularization in Java
8

9. What‟s a Module?
Beyond the simple means of packaging, a true module
should define:
 Identity and scope
 Unit of deployment
 Dependencies
 What it provides to other modules
It is up to a module system to see if a module‟s requirements
can be satisfied and make sure consumers are „wired‟ to providers
9

10. JARs
Packaging
o Classes encapsulate data
o Packages contain classes
o Jars contain packages
Visibility Access
o private
o package-private
o protected
o public
Jars have no module characteristics
10

11. Java application
11

12. “Jar Hell”
12

13. Class Loading
13

14. Modularization in Java - Issues
 Classes are too fine grained, packages are too simplistic, class
loaders are too low level
 Jars provide packaging, but…
o Have no runtime representation (no identity and scope)
o Have no explicit dependencies
o Can not be used to restrict access - public class is globally visible
o Are not true deployment units
 Severe problems like split packages
o Multiple jars have classes with the same name in the same package
 No versioning support
o Order on CLASSPATH define chosen version
o Single version of a class in the VM
 Has no proper extension/collaboration model
In fact, Java never planned introducing module concept, yet…
14

15. Assembly
Assemblies are the building blocks of .NET applications.
An assembly is a collection of types and resources that are built to
work together and form a logical unit of functionality
 .NET has the built-in module system
o Early attempts were made already in Windows 2000
 It defines
o security boundary
o type boundary
o reference scope boundary
o version boundary
o deployment unit
15

16. What‟s a component?
The most common analogy -
Lego?
 Lego is a poor analogy
o Dead lump of plastic – no life cycle
o Not really replaceable - try replacing a block in already built model
o Not really reusable - try using a „Duplo‟ block in a „Lego‟ model
 Has characteristics closer to that of an object in OO
16

17. What‟s a component?
A better analogy –
Bees!
 Active participants in the system
 Aware of and adapt to their environment
 May provide services to other components and use services from
other components
 Have a life cycle
17

18. Environment
Ecosystem in which a component lives, e.g.:
beehive, Java VM
 When the environment is good, the component flourishes.
 When the environment is harsh, the component survives.
 When very harsh, the component dies.
18

19. Introduction to OSGi
 OSGi™ - The Dynamic Module System for Java
o Formerly Open Services Gateway Initiative
 Driven by OSGi Alliance - consortium of vendors
o Non-profit corporation founded in 1999
 Mission: Build ecosystem to support
component based development
in Java
Alcatel-Lucent ProSyst Software GmbH
Aplix Corporation Qualcomm
Deutsche Telekom Red Hat
Ericsson Mobile Platforms SAP AG
AB Siemens AG
Hitachi, Ltd. Siemens Enterprise
IBM Corporation Communications
LinkedIn Software AG
Makewave Sonatype Inc.
Mitsubishi Electric SpringSource (a Division of
Corporation VMware)
NEC Corporation Sun Microsystems, Inc.
NTT Telcordia Technologies, Inc.
Oracle Corporation TIBCO Software Inc.
Paremus, Ltd. Westell Inc.
Progress Software
19

20. OSGi is about…
 Module system for the Java platform
o Building systems from smaller components
o Includes visibility, security rules, dependency management and
versioning control
 Dynamic
o Installing, starting, stopping, updating modules, all dynamically at
runtime
 No downtime or 24 7 are the terms customers like to hear
 Service-oriented collaborative model
o POJOs can be registered as services, consumed and managed
inside a VM, again, all dynamically at runtime
20

21. Work Groups
 Multiple groups define the specifications
o Core Platform Expert Group (CPEG) – Core framework
o Mobile Expert Group (MEG) – Mobile
o Vehicle Expert Group (VEG) – Automotive
o Enterprise Expert Group (EEG) – Enterprise
o Residential Expert Group (REG) – Home Automation
 No more „All in One‟ solution – each group has its
own purpose and objectives
21

22. Evolution path
 Original use case (Home Automation) faltered around
2000
 OSGi used in niche areas (automotive, mobile) for a
decade now
 Eclipse 3.0 released June 2004 - First Eclipse platform
built on OSGi
 Gradual adoption and recognition for OSGi after Eclipse
 Currently undergoing widespread adoption in the
enterprise market
22

23. OSGi Architecture and Layers
 The OSGi Platform specifies
a modular architecture for dynamic
component based systems
o Execution Environment
o Module Layer
o Life Cycle Layer
o Service Layer
o Security
 Introduces Bundles as modules
L0 - JRE Level a publish/find/bind in-VM service model
L3 – Manages the life cycle modules
L2 Provides
L1 - Creates the concept of of a bundle
Security
•OSGi Minimum Execution Environment instances
• Standard methods for registering service
• Fine grained use classes from
(bundles) thatJava security modeland
• Discoveron events for application
Based
•CDC/Foundation to services from other components
• component lifecycle, e.g.: installing,
each other and bindA only way to use the XYZ
• Example: in a controlled wants
•J2SE-1.3 Vendor
according stopping, updating B (could be multiple other
starting,provided byand bundle
service to system Vendor
…
• implementations of XYZ)
constraints.API for with packaging,
Standard Deals registering, listening,
•J2SE-1.5
• and acting on events
versioning and dependencies using certificates
•JavaSE-6 can be expressed
Constraints
• from signed jars or attributes for bundle, service, etc.
No VM restarts
23

24. Bundle
Bundle is a module in OSGi terminology
o Simply a JAR file plus module metadata stored in jar manifest
• Bundle Identity
• Dependencies
• Versioning
What does a bundle JAR contain?
o Java classes (i.e., standard JAR file content)
o Resources (e.g., configuration files, images, etc.)
o Native code
o Embedded JAR files
• Bundles can have their own class path
A bundle JAR file can be both a standard JAR file
and a bundle at the same time
24

25. Bundle Manifest
META-INF/manifest.mf
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.apache.servicemix.kernel.filemonitor
Bundle-Version: 2.0.0.0
Bundle-Name: Apache File Monitor
Bundle-Vendor: Apache Foundation
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Bundle-Classpath: ., libmonitor.jar, libtest.jar, libreport.jar
Bundle-Activator: org.apache.servicemix.filemonitor.FileMonitorActivator
Bundle-Description: This bundle monitors the deploy directory for new deployments
Import-Package: org.apache.commons.logging,
org.apache.commons.io;version="1.4“,
javax.servlet;version=“[2.4,2.5]" ,
org.osgi.service.packageadmin
Export-Package: org.apache.jmx.facade,
org.apache.servicemix.kernel.filemonitor; version="1.0.0.0“
25

26. Bundle Life Cycle
26

27. Lazy Bundles
Bundles can be activated on demand
o Defer the creation of the bundle class loader and
activation of the bundle until the bundle is first used
o Can save resources and initialization time on startup
o Triggered by classloading event
META-INF/manifest.mf
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.apache.servicemix.kernel.filemonitor
Bundle-Version: 2.0.0.0
Bundle-Activator: org.apache.servicemix.filemonitor.FileMonitorActivator
Bundle-ActivationPolicy: lazy
27

28. Bundle Activator
 Bundle-Activator: Like main() for your bundle
 Bundles can hook into their life cycle by implementing
a bundle activator interface
o Notifies them when they are started/stopped
o Gives them access to their bundle context
• Which is how they access framework capabilities, e.g.:
 Bundle life cycle management
 Publishing or looking up services
 Simple Java interface
public interface BundleActivator
{
public void start(BundleContext context) throws Exception;
public void stop(BundleContext context) throws Exception;
}
28

29. Resolving a Bundle
exported package
install package dependency
resolve existing
bundle
bundle
resolution
bundle
OSGi Framework
 Resolution of dependencies at deployment
 If resolution fails, bundle is not available for use
 No runtime CNFE unless you‟re still relying on Class.forName(…)
 Services and lifecycle methods not called until AFTER resolution
29

30. Multi-version support
Export-Package: foo; Import-Package: foo; Export-Package: foo;
version="1.3.0“ version=“[1.3.0, 2.0.0)“ version="1.0.0"
foo foo
foo
 Same package can be installed with different versions
 Bundles explicitly expose internal packages (i.e., export)
o Exporters export precise package versions
 Export-Package: bar; version="1.0.0“
 Bundles explicitly declare dependencies on external packages (i.e., import)
o Importers may specify an open or closed version range
 Import-Package:; foo version="[1.0.0,1.5.0)"
 Allows staged migration of multiple components
30

31. Controlling Dependencies
Export-Package: foo; Import-Package: foo; Export-Package: foo;
version="1.0.0“; version=“1.0.0” ; version="1.0.0"
provider=“Pooh” provider=“Pooh”
foo foo
foo
 Arbitrary export/import attributes for more control
o Exporters may attach arbitrary attributes to their exports
o Importers can match against arbitrary attributes
o Exporters may declare attributes as mandatory
 Mandatory attributes provide simple means to limit package visibility
o Importers influence package selection using arbitrary attribute matching
31

32. Class space consistency
Import-Package: foo
Export-Package: foo Export-Package: bar; uses:="foo" Import-Package: foo, bar Export-Package: foo
 Exporters may declare package “uses” dependencies
 Exported packages express dependencies on imported or other exported
packages, which constrain the resolve process
 The framework must ensure that importers do not violate constraints implied
by “uses” dependencies
32

33. Class Filtering
Exporters may declare that certain classes are included/excluded
from the exported package
o Ideal solution for building facades around existing jars
Export-Package: foo; exclude:="*Impl", Import-Package: foo;
Import-Package: foo foo; friend="yes“; mandatory:="friend" friend=“yes”
foo foo
exclude:=”*Impl” friend=”yes”
include:=”*”
33

34. Bundle-to-Bundle dependency
Bundle-SymbolicName: A Require-Bundle: A
Export-Package: bar, foo Export-Package: bar
 Allows for tight coupling of bundles when required
 Import everything that another, specific bundle exports
34

35. Bundle Fragments
Fragment-Host: B Bundle-SymbolicName: B
Export-Package: foo Export-Package: bar foo
bar,
Import-Package: baz Import-Package: woz baz
woz,
 Allows bundle content to be extended
 A special bundle that attaches to a host bundle and uses
the same class loader
o Conceptually becomes part of the host bundle, allowing
a logical bundle to be delivered in multiple physical bundles
35

36. Bundles - Summary
 Package level dependencies i.e.: Export/Import-Package:
• Can be mandatory(default) or optional
 Support for versioning
 Support arbitrary attributes and filters
 Control dependency graph with uses attribute
 Bundle-to-Bundle relationship with Require-Bundle:
 Fragments as bundles extender model
META-INF/manifest.mf
…
Import-Package: org.apache.commons.logging; resolution:=optional,
org.osgi.service.cm; version=“[1.3,1.5.0]" ,
org.osgi.service.packageadmin
Export-Package: org.apache.jmx.facade; role=“admin“; mandatory:=“role"
org.apache.servicemix.kernel.filemonitor; uses:=“org.apache.commons.logging”;
exclude:= “*Impl,*Helper*”
Require-Bundle: org.apache.felix.http; bundle-version="[1.0.0.0,2.0.0.0)“
36

37. Classloading
The standard Java classloading hierarchy
37

38. Classloading – Java EE
38

39. Classloading - OSGi
Tree is simply the wrong shape!
What we really need is a graph
39

40. Class Search Order
 Classloading in OSGi is fast compared to the conventional CL tree model
o Classloaders wiring happens at the bundle‟s resolution time
o No walking up and down the parent tree when looking up classes
 Classloading event is directly delegated to the owning classloader
40

41. OSGi Module System - Summary
 OSGi technology bridges the gap in the area that Java has not
addressed
 Promotes a better structuring of your application code by defining
clear boundaries
 Robust classloading model that overcomes the deficiencies
of the conventional Java
 Control over versioning
 Lifecycle
 Modularization is rewarded when creating new systems and
modifying existing ones
 No silver bullet, bad code and bad ideas are still bad
41

42. What else is missing?
42

43. Service-Oriented-Architecture for the JVM
 OSGi introduces service layer as primary means of collaboration
between bundles
 Lightweight implementation
o No protocols, no stubs - direct Java method calls
o Cross-VM communication is out of scope (addressed by EE group)
 Service Registry is where decoupling between provider and
consumer happens
offer
Registry query
43

44. Services
 Services are POJOs
o Services are identified with components
o Registered and looked up using their interface name
 Follow publish/find/bind model
o Used as bundle‟s input/output ports
o Allow loose coupling between modules – modules can be substituted
 Allow lazy instantiation and late binding
 Meta-data is decoupled from implementation
o Service properties can be queried without the need for creating
service instance
44

45. Services
 But most importantly, services are dynamic
o Static dependencies are handled by the module layer,
runtime dynamics are realized through services
o Services can be enabled/disabled/substituted dynamically at runtime
service dependency (dynamic)
package dependency (static)
OSGi Framework
 However, there is a challenge
o Fully dynamic systems require a different way of thinking
 Services may come and go at any moment in time
• Java programming not for faint hearted
 Multiplicity of service providers
45

46. OSGi Compendium Services
 OSGi uses services to extend its functionality
o One or more service components „bundled‟ together implementing
a specific functionality
o Provided separately from the OSGi core
o Many services are defined as mandatory for OSGi framework providers
 Application architecture can be defined by a set of deployed services
o Create your own profile – VM + OSGi core + required services
Log Service Initial Provisioning
Event Admin UPnP
Http Service Declarative Services
User Admin Auto Configuration
Configuration Admin Application Admin
Deployment Admin DMT Admin
Metatype Service Monitor Admin
Preferences Service Device Access
Wire Admin IO Connector
46

47. Bundling existing code
... legacy code is a challenge. Many developers say
things like: “My code is very modular”, or “My code
doesn’t depend on very much”, or “No one uses any of
my classes except from the Foo package”
Unless they are already using osgi, they are wrong.
Until modularity is enforced, it is not there.
John Wells, BEA
 Analyze what you have
o What are the dependencies between the JARs that make up your
application
 OSGi bundles need manifest headers
o Exported/Imported packages
o Versions
 Good chances are your favorite open source is already „OSGfied‟
o Check with the online repository, e.g.: http://www.springsource.com/repository/app/
47

48. Bundling existing code
48

49. Bundling existing code
 Start with your existing application
and all its dependent jars
 Create a bundle activator (i.e.: the
existing startup class or main) if
needed
 Put all libraries into one bundle
• Super sized!
• Don‟t worry, it‟ll get better
 Having a working bundle (whatever
the size) is a good baseline and
allows for gradually replacing the
dependent jars with bundles
 Keep it working!
49

50. To Include or to Refer?
 When to refer to a library?
o External API
o Implementations can differ,
e.g.: javax.naming, javax.transaction
o Very large library
o Sharing
 When to include a library in the
bundle?
o High Cohesion
o Localized library version
o Reduces number of dependencies
50

51. OSGi Best Practices
 Raw OSGi APIs are powerful but create coupling
o Isolate the use of the OSGi APIs to a minimal number of classes
 Best practices is to write POJOs that are not coupled to
a framework
o There are many such application models for OSGi
 OSGi Declarative Services (xml descriptors)
 Apache iPOJO (annotations)
 Spring-DM (formerly Spring-OSGi)
 Service Application Toolkit
 Pick one of these application models after you got your
existing application running
 Convert the application part-by-part
51

52. OSGi Implementations
 Several independently implemented OSGi frameworks exist
today, including four that are available as open source software
o Equinox - the most widely deployed OSGi framework today owing to its
use in the core runtime of Eclipse. It is also the official RI (Reference
Implementation) of the OSGi spec.
o Knopflerfish - popular and mature implementation of both OSGi Release
3 and 4.1. It is developed and maintained by Makewave AB
o Apache Felix - a community implementation of the OSGi Release 4.x.
It is designed particularly for compactness and ease of embedding, and is
the smallest (JAR size ~360K) implementation
o Concierge - a very compact and highly optimized implementation of
OSGi Release 3. This makes it particularly suited to resource-constrained
platforms such as mobile phones.
52

53. Markets & Solutions
 Automotive: BMW, Volvo, Bombardier…
 Mobile: Nokia, Ericsson, Motorolla…
 Smart Home: Bosh, Siemens, Phillips…
 E-Health: Siemens Med…
 Enterprise
o Currently the OSGi framework is adopted by most
enterprise Java vendors for internal use as the underlying
infrastructure platform
o Base for the new application server generation architecture
o Oracle BEA mSA – micro-service architecture built on OSGi is the base for BEA products
o JBoss MicroContainer - replaces old JMX MicroKernel
o IBM WebSphere, Lotus as well as other ~200 products run on Equinox
o JOnAS, SpringSource DM server…
o Smaller vendors, such as SpringSource and Paremus, as well as open source projects such
as Apache ServiceMix and Apache Aries, are starting to promote the direct use of the OSGi
programming model in developing enterprise applications, and some early adopters such as
LinkedIn and VMware have started to do so
53

54. A bit of Java politics…
 JavaSE 7 (OpenJDK) long awaited features
o G1 garbage collector
o JSR 292: VM support for non-Java languages
o JSR 294: Language and VM support for modular programming
o Project „Jigsaw‟ – modularization of JDK(merged with JSR 294)
 Java 7 was expected at the end of 2009
 The release date was postponed to Oct. 2010
 Modularity and Jigsaw is in the center of continuous debates
54

55. Jigsaw - Motivation
 JDK is BIG
o JDK 1.1 = 3.5Mb
o JDK 6 = 65.2Mb (>1800% growth)
o Startup time is relatively long
• 306 classes to load for a simple “Hello World”
o Difficult to evolve APIs
• Deprecation has no meaning
o Depending on whole JDK version is no longer feasible
• Would like to depend on, e.g., Swing v2 and Concurrency v1.x
• Or Swing 1.x but NO higher - now v2 can break compatibility
o Doesn‟t scale down(for small devices)
o Doesn‟t scale up(ME cannot run on SE)
55

56. Module (the Jigsaw way)
org/company/services/ui/module-info.java
module org.company.services.ui @1.0 {
system jigsaw;
requires module java-core @7;
requires module java-swing @1.7.*;
requires optional module commons-lang @ [2.4,3.0);
requires private module org.company.services.kernel @1.0;
class org.company.services.ui.Main;
}
org/company/services/ui/Utils.java
public class Utils {
module boolean foo(); //new access level modifier –“module”
public boolean bar();
}
java –m org.company.services.ui
56

57. Jigsaw - Summary
 No support for package-level dependencies
 Not dynamic – requires VM restarts on installing, updating
and uninstalling a module
 No Lifecycle
 Does not offer collaboration model i.e.: services
 Questionable as primary development model for your
application, but…
 A big step forward in terms of affirmation (from Sun) that
modularity is important and currently missing from Java
 Probably the shortest path for modularizing JDK as a
product
57

58. Useful Links
 OSGi Alliance http://www.osgi.org
 Peter Kriens presentation
http://www.infoq.com/presentations/osgi-the-foundation
 Neil Bartlett‟s blog
http://njbartlett.name/osgibook.html
http://www.eclipsezone.com/eclipse/forums/t90365.html
 Equinox
http://www.eclipse.org/equinox/
 Apache Felix
http://felix.apache.org/site/index.html
 SpringSource repository
http://www.springsource.com/repository/app/
58