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
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
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
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
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
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
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
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