Modularity is the art of breaking a large system into parts that are easier to understand than the ‘monolithic’ whole.
Failing to achieve the right degree of modularity may lead to development of code that is hard to reuse and to maintain, and when you are working in a team this has a bigger impact on the costs.
The complexity of dealing successfully with modularity is mostly addressed during design, when understanding and planning the dependencies and the behavior of a module, but a good application framework can influence positively toward the right direction by providing a natural environment where to apply good architecture modularity patterns. And OSGi, with its service oriented philosophy and the ecosystem of related tools, where the modules have clear boundaries which coincide with those of ‘Bundles’, it provides such inspiring environment.
During the talk we will illustrate a concrete example of an OSGi project, built with Maven and M2E and running into Apache Karaf. Rather than focusing on the details of technologies, we will put emphasis on the experience of Java modularity so to give a feel of how this platform can help, and allow you to evaluate if this platform can be helpful for your next project and ambitions.
What does “module” means?
“A software module is a deployable,
manageable, natively reusable, composable,
stateless unit of software that provides a
concise interface to consumers”
Deployable: modules are unit of deployment.
Manageable: modules are unit of management.
Natively Reusable: modules are a unit of intraprocess reuse.
Composable: modules are a unit of composition.
Stateless: modules are stateless (*running software from a module has a state).
Testability: modules are a unit of testability.
uhm… the JAR file!
Where to find modularity?
There are two facets of Modularity
“Modularity is the best hope to
reduce the costs of changes due to
“to tame complexity”
Base patterns advise to
design and manage
modules, that you have
reusability at software
module level, and that
modules shall be
cohesive and have a
behavior that serves a
teach you that there must
be no cycles between
modules, that should be
organized in levels and
in physical layers. And
that a module should be
independent from the
runtime container and
Dependency Patterns: NO CYCLES!
Usability, Extensibility, Utility Patterns
The modules shall have a
public interface that is well
Modules are conﬁgured
For improving usability,
create a façade serving as a
coarse-grained entry point
to another ﬁne-grained
Restricted dependency to theabstract elements of the moduleso to improve extensibility andreduce the number of
Rely heavily on the use of
implementation factories anddependencies injection
Separate abstractions from theclasses that implement them inseparate modules, so to helpeliminate module relationships.
Perform a levelized build,
repeatable build of the
modules. This has positive
effect on the lifecycle of
software development as a
levelized build integrate
testing that require to
integrate early and often,
which guarantees a system
health always in a good
Modules should have a test
Let’s open pack 1:
Karaf: an OSGi container
Karaf is a small OSGi based runtime which provides a
lightweight container onto which various components and
applications can be deployed.
Apache Karaf can trace it's origins back to the Apache
ServiceMix project's Kernel.
Karaf: what is it in detail?
Karaf is a platform that
allow you to deploy your
You can install/uninstall/
start/stop your application
in several easy way.
You can replace/update it
and you can change its
conﬁguration on the ﬂy.
Karaf: what is an application?
An application is a
Each module can
depend from other
application or from
other module of the
Karaf: what is a module?
A module is a bundle
Bundle is a Jar with a
Manifest richer than that one
We can develop a bundle
using Eclipse and Maven
Karaf: how a bundle interact?
Each bundle can registers one or more service.
Each service can be retrieved by other bundle.
Each service can obtain the reference of other services.
Karaf: What is a service?
We can deﬁne a service using the SOA deﬁnition.
“A Service is a self-contained unit of
Caution: service in OSGi is NOT a WebService but it is an
Don’t worry: using Camel you can extend an OSGi service
with a WebService and more (as we’ll see later).
Karaf & Spring
Karaf has its own Dependency Injection API: Blueprint
Blueprint is a standard deﬁned in OSGi that allow bean
deﬁnition, service deﬁnition and dependency injection
Using Spring Dynamic Module we can also use Spring in
SpringDM explores bundles and load Spring xml ﬁles
Spring DM allows you to interact with the world without using
OSGi API in our code: in this way the code is cleaner and
classes that we write (our modules) can be reused on other
Karaf & Web
Pax Web allows Karaf to support web. Using integrated Web
Server Jetty, it implements:
-HTTP Service API deﬁned in OSGi
-Web Application API deﬁned in OSGi Enterprise
Like Spring DM, Pax Web explores Bundles installed in Karaf
to ﬁnd web.xml ﬁles.
When it ﬁnds ithe ﬁlet, Pax Web starts application by creating
servlets,ﬁlters and initializing servlet context deﬁned in web
An example of a Java Modular Application
• “Java Application Architecture: Modularity Patterns with
Examples Using OSGi”, Kirk Knoernschild - Prentice Hall
• “Spring DM in Action”, A. Cogoluègnes, T. Templier, A.
Piper - Manning
• “OSGi in Action”, R. S. Hall, K. Pauls, S. McCulloch, D.
Savage - Manning
• “OSGi In depth”, Alexandre de Castro Alves - Manning
• “Enterprise Integration Patterns”, G. Hohpe, B. Woolf -
• “Camel in Action”, C. Ibsen, J. Anstey - Manning
Modularity is good
Follow Modular Patterns
Build modular java software with Maven
Run modular java software with Karaf
Check SensorMix for an example