Devoxx 2012 University session "Modular Architecture Today" demonstrating how to apply some of the modularity patterns to build a system with a modular architecture.
3. Java Application Architecture
Modularity Patterns with Examples Using OSGi
Forewords by Robert C. Martin and Peter Kriens
I’m dancing! By god I’m dancing on the walls. I’m dancing on the ceiling. I’m
ecstatic. I’m overjoyed. I’m really, really pleased.”
- From the Foreword by Robert C. Martin (a.k.a. Uncle Bob)
Java Application Architecture will help you
‣Design modular software that is extensible, reusable, maintainable, and adaptable
‣Design modular software today, in anticipation of platform support for modularity
‣Break large software systems into a flexible composite of collaborating modules
‣Understand where to place your architectural focus
‣Migrate large-scale monolithic applications to applications with a modular architecture
‣Articulate the advantages of modular software to your team
Visit http://modularity.kirkk.com for more information.
3
5. Goals Today
2 Simple Goals Today
1.) Start designing modular software tomorrow!
2.) Don’t flip the bit on OSGi as too complex!
5
6. Modular Architecture Today
Introducing Modularity
The Modularity Patterns
Refactor to Modularity
Introducing OSGi
OSGi-ify the App
6
7. Agile Architecture
Introducing Modularity
What
ch
What Why i
s mo d us to d allenges fac
are th ula ay in e
e ben neces design
mo dul
arity? efits o sar y c rity a mo dul
ar sof ing
f ag ile o mpon tware
archit en ?
ecture t of
?
7
8. Modularity - Not New!
1972 (or a bit before)
On The Criteria To Be Used in Decomposing Systems into Modules
by David Parnas at http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
8
9. Defining Module
Hey, it’s a JAR file!
- unit
of reu
- unit se
of co m
- unit po
of dep sition
- unit loyme
of ma nt
nagem
ent
A module system provides a runtime environment for modules
9
10. The Facets
Runtime Development
Infras Progr Desig
tructu am ming n Para dThink about when
re Mo de igm
l
Runtim The fr The te you started using
e plat amew chniqu
suppo for m techn o r ks a
nd to i de esobjects! Using the
use d
rt hel olog ie ntify
enforc ps allow s that create an d language constructs
e mo d us to the ri
archit ular mo dul create o f mo ghtwere easy, but
ecture ar sof dules set
. tware
creating designs
was still really hard.
The Design Paradigm
- What’s the right granularity for a module?
- What the right weight for a module?
demo
10
11. Paradox
Increa
sing e
decre volvab
ases s ility
ur viva
bility
(Reuse,
Compose,
Extend,
Lightweight,
Fine-Grained, ...)
(Use, Maintain, Understand, ...)
... making everything easy to change makes the entire system very
complex...
- Ralph Johnson in “Who Needs an Architect”
11
12. Architectural Joints or Seams
Here?
Which Here?
system area of the
deman
ds mo
flexib re
ility?
Here? Here?
Here? Here?
Here?
12
13. Complexity and Knowledge
Source: http://www.tensegrity.hellblazer.com/ Source: http://adaptevolve.blogspot.com/
13
15. demo
Architectural Joints or Seams
Here?
Which Here?
system area of the
deman
ds mo
flexib re
ility?
Here? Here?
Modularizing software Here? Here?
affects our design in
interesting ways.
Here?
15
16. Benefits of Modularity
- reus
e Increases architectural agility!
- re du
ce co m
- ease ple
mainte xity
- incr nance
ease
exten
sibility
Umm...we can already do this with objects, aspects, methods, and services!
16
17. All the Way Down
?
Reuse Release Equivalence:
Unit of reuse is the unit of release!
17
18. Agile Architecture
The Modularity Patterns
What
are th
mo dul e
arity
patter
ns?
18
19. Base Patterns
• Manage Relationships – Design Module Relationships.
• Module Reuse – Emphasize reusability at the module level.
• Cohesive Modules – Module behavior should serve a singular
purpose.
19
20. Dependency Patterns
• Acyclic Relationships - Module relationships must be acyclic.
• Levelize Modules – Module relationships should be levelized.
• Physical Layers - Module relationships should not violate the
conceptual layers.
• Container Independence - Modules should be independent of
the runtime container.
• Independent Deployment - Modules should be independently
deployable units.
20
21. Usability Patterns
• Published Interface - Make a module’s published interface well
known.
• External Configuration – Modules should be externally
configurable.
• Default Implementation - Provide modules with a default
implementation.
• Module Facade – Create a facade serving as a coarse-grained
entry point to another fine-grained module’s underlying
implementation.
21
22. Extensibility Patterns
• Abstract Modules - Depend upon the abstract elements of a
module.
• Implementation Factory - Use factories to create a module’s
implementation classes.
• Separate Abstractions - Place abstractions and the classes that
implement them in separate modules.
22
23. Utility Patterns
• Colocate Exceptions: Exceptions should be close to the class or
interface that throws them.
• Levelize Build – Execute the build in accordance with module
levelization.
• Test Module – Each module should have a corresponding test
module.
23
24. Agile Architecture
Patterns Applied
Ho w c Ho w d This is the Design
an I u o they
mo dul
arity
se the acco m h
mo dat elp Paradigm
patter archit e
ns? ectura
l shift
s?
24
25. The System
Design a system to handle payment and auditing of
various types of bills. The system must integrate with
3rd party auditing software, and a legacy financials
system that must be fed payment information for
reconciliation.
25
26. The Class Model
Note t
he bi-
a sso ci direct
ations ional
!
26
27. demo
Initial Systems Modules
If I la
ye
but no r conceptua
t phys lly
then a ically,
m
the a d I realizing
vantag
layeri e
ng? W s of
layer ? hy do
I
27
28. Physical Layers
Module relationships should not violate the conceptual layers.
28
29. Abstract Modules
Depend upon the abstract elements of a module.
package client;
import service.*;
public class Client {
Service service;
}
package service;
public interface Service {
public void doService();
}
- “Inje
ct
implem ” the package service;
entati
Client. on int
o public class ServiceImpl implements
- “ Lo o
ku p Service {
implem ” the
entati public void doService() {
Client. on w it
hin ....
};
}
29
30. Abstract Modules
What
if
to use Bill must be
differ
system ent au able
s? diting
30
31. Abstract Modules
Au ditF
aca de
into B 1 is in
ill as jecte d
Au ditF an
aca de
type.
31
38. Separate Abtractions
Separate abstractions from the classes that realize them.
How d
o I in
with a tegra
te
nothe
auditi r
ng sy
stem?
Wher
e doe
s
Audit
Facad
e2 liv
e?
38
41. Colocate Exceptions
Exceptions should be close to the classes that throw them
Audit
Facad
e thro
the A ws
uditEx
ceptio
n.
Exception goes here.
41
42. Independent Deployment
Modules should be independently deployable units.
How d
o I re
bill.ja use
r wi t h
financ out
ial.ja
r? Lik
a bat e in
ch ap
plicat
ion?
42
51. A Bit of History
• JSR 8 - Open Services Gateway specification in 1999 (JSR 232
or JSR 291)
• Gateway for providing services to home devices
• lifecycle management, dependencies, installing, versioning, configuration
• OSGi Alliance formed in 1999 and delivered V1.0 in 2000
• Very popular on the desktop; driven by Eclipse 3.0 adoption in
2003
• Today, just about all Java middleware products use OSGi
• WAS, WebLogic, GlassFish, Paremus Service Fabric, JBoss, Geronimo, ...
51
52. Introducing OSGi
Dynamic Module System for Java
ClassLoaders
- Each bundle has it’s own classloader and it’s own
lifecycle
µServices
- Bundle exposes it’s
behavior via well-defined
interface
MODULE
Bundles
- Bundle is a JAR file with
manifest
52
54. The Basic Workings
Private packages Classloader restricts
are implementation visibility
Imported Exported
packages packages
Publishes the
JAR is a module interface, ideally as
Classloader gives µServices
each module its own
DYNAMICITY
lifecycle
54
55. Modules as First Class Citizens
INSTALLED STARTING
start Because bundles have their
own classloader, they can be
managed independently.
RESOLVED ACTIVE Hence, a very dynamic
environment.
stop
UNINSTALLED STOPPING
55
56. demo
The Runtime
- Dyn
ami
- Mult c deployme
ipl nt
- Enfo e versions
rce de
- Enca pen de
psulat ncies
ion
56
57. demo
Too Complex?
“OSGi provides little value and is too complex as demonstrated by our failed attempt to make
modularity invisible when porting our legacy system to it with over 150 third-party JARs.
-- http://blogs.mulesoft.org/osgi-no-thanks
“OSGi is a great solution for complex applications with stringent modularity requirements.”
-- http://www.theserverside.com/news/thread.tss?thread_id=62590
57
61. Type Visibility
Any public class in any JAR on the classpath can be seen by any
other class on the classpath!
With OSGi, you have control who sees what!
Cookie Jar images courtesy of Richard Hall
61
64. Modularity Today
Platforms discourage modularity! Why a
re
design n’t we
in
mo dul g more
ar sof
tware
?
64
65. demo
Modularity Tomorrow
This is the next generation application platform!
- Dyn
ami
- Mult c deployme
ipl nt
- Expl e versions
icit de
pen de
ncies
65
66. Modular Architecture Today
OSGi-ify the App
Ho w d
o I bu Is it i Is it r
applic ild nvasiv eally
ations e to m to o co
using y co de mplex
OSGi? ? ?
66
67. Java Application Architecture
Modularity Patterns with Examples Using OSGi
Forewords by Robert C. Martin and Peter Kriens
I’m dancing! By god I’m dancing on the walls. I’m dancing on the ceiling. I’m
ecstatic. I’m overjoyed. I’m really, really pleased.”
- From the Foreword by Robert C. Martin (a.k.a. Uncle Bob)
Java Application Architecture will help you
‣Design modular software that is extensible, reusable, maintainable, and adaptable
‣Design modular software today, in anticipation of platform support for modularity
‣Break large software systems into a flexible composite of collaborating modules
‣Understand where to place your architectural focus
‣Migrate large-scale monolithic applications to applications with a modular architecture
‣Articulate the advantages of modular software to your team
Visit http://modularity.kirkk.com for more information.
67
