1

Modular Architecture Today

Kirk Knoernschild@pragkirk

2

Java Application ArchitectureModularity Patterns with Examples Using OSGi

Forewords by Robert C. Martin and Peter Kriens

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.

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)

3

The Code

https://github.com/pragkirk/poma/network

or just Google pragkirk github

4

Goals Today

2 Simple Goals Today

1.) Start designing modular software tomorrow!

2.) Don’t flip the bit on OSGi as too complex!

5

Modular Architecture Today

Introducing Modularity

The Modularity Patterns

Refactor to Modularity

Introducing OSGi

OSGi-ify the App6

Agile Architecture

Introducing Modularity

What are the benefits of modularity?

Why is modularity a necessary component of agile architecture?

What challenges face us today in designing modular software?

7

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

Defining Module

- unit of reuse- unit of composition- unit of deployment- unit of management

A module system provides a runtime environment for modules

Hey, it’s a JAR file!

9

The Facets

Programming ModelThe frameworks and technologies that allow us to create modular software

Design ParadigmThe techniques used to identify and create the right set of modules

The Design Paradigm- What’s the right granularity for a module?

- What the right weight for a module?

InfrastructureRuntime platform support helps enforce modular architecture.

demo

DevelopmentRuntime

Think about when you started using objects! Using the language constructs were easy, but creating designs was still really hard.

10

Paradox

Increasing evolvability decreases survivability

... making everything easy to change makes the entire system very complex...

- Ralph Johnson in “Who Needs an Architect”

(Reuse, Compose,Extend,

Lightweight, Fine-Grained, ...)

(Use, Maintain, Understand, ...)

11

Architectural Joints or Seams

Which area of the system demands more flexibility?

Here?

Here?

Here?

Here? Here?

Here?

Here?

12

Complexity and Knowledge

Source: http://www.tensegrity.hellblazer.com/ Source: http://adaptevolve.blogspot.com/

13

Complexity, Knowledge, & Modularity

14

Architectural Joints or Seams

Which area of the system demands more flexibility?

Here?

Here?

Here?

Here? Here?

Here?

Here?

demo

Modularizing software affects our design in interesting ways.

15

Benefits of Modularity

- reuse- reduce complexity- ease maintenance- increase extensibility

Increases architectural agility!

Umm...we can already do this with objects, aspects, methods, and services!

16

All the Way Down

?

Reuse Release Equivalence: Unit of reuse is the unit of release!

17

Agile Architecture

The Modularity Patterns

What are the modularity patterns?

18

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

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

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

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

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

Agile Architecture

Patterns Applied

How can I use the modularity patterns?

How do they help accommodate architectural shifts?

This is the Design Paradigm

24

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

Note the bi-directional associations!

The Class Model

26

Initial Systems Modules

If I layer conceptually but not physically, then am I realizing the advantages of layering? Why do I layer?

demo

27

Physical LayersModule relationships should not violate the conceptual layers.

28

Abstract Modules

- “Inject” the implementation into Client.- “Lookup” the implementation within Client.

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();}

package service;

public class ServiceImpl implements Service { public void doService() { .... };}

29

Abstract Modules

What if Bill must be able to use different auditing systems?

30

Abstract Modules

AuditFacade1 is injected into Bill as an AuditFacade type.

31

Abstract Modules

32

Acyclic RelationshipsModule relationships must be acyclic

33

Recall - Abstract Modules

AuditFacade1 is injected into Bill as an AuditFacade type.

Same problem here

34

Recall - Abstract Modules

35

Uni-Directional

36

Acyclic Relationshipsdemo

37

Separate Abtractions

How do I integrate with another auditing system? Where does AuditFacade2 live?

Separate abstractions from the classes that realize them.

38

Separate Abstractions

Should I put AuditFacade2 in audit.jar?

39

Separate Abstractions

40

Colocate Exceptions

AuditFacade throws the AuditException.

Exceptions should be close to the classes that throw them

Exception goes here.

41

Independent Deployment

How do I reuse bill.jar without financial.jar? Like in a batch application?

Modules should be independently deployable units.

42

Independent Deployment

43

Independent Deployment

1.) PayAction invokes Bill.pay() and passes BillPayAdapter as a BillPayer.2.) Bill.pay() invokes BillPayer.generateDraft()3.)BillPayAdapeter.generateDraft() invokes Payment.generateDraft() passing itself as a Payable.4.) Payment.generateDraft() invokes Payable.getAmount()

44

Independent Deployment

45

Implementation FactoryUse factories to create a modules implementation classes.

46

The Final Structuredemo

47

Opportunities

48

Modular Architecture Today

Introducing OSGi?

What is OSGi?

Is OSGi new? Who is using OSGi?

This is the Infrastructure & Programming Model

49

Modularity is coming to the Java platform!

OpenJDK

50

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

Introducing OSGiDynamic Module System for Java

ClassLoaders- Each bundle has it’s own classloader and it’s own lifecycle

µServices- Bundle exposes it’sbehavior via well-defined interface

Bundles- Bundle is a JAR file with manifest

MODULE

52

JAR

A Valid BundleManifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: Scala CalculatorBundle-SymbolicName: scala calculatorBundle-Version: 1.0.0Import-Package: com.extensiblejava.loan,scala.annotation.unchecked;uses:="scala.reflect,scala" ;version="2.8.0.final"

+

myjar.jar Manifest.mf

<osgi:service id="LoanCalculator" ref="loanCalculator" interface="com.extensiblejava.loan.LoanCalculator"/><osgi:reference id="paymentFactory" interface="com.extensiblejava.loan.PaymentFactory"/>

Register µServices

µService Reference

53

The Basic Workings

JAR is a module

Private packages are implementation

Importedpackages

Exportedpackages

Classloader restricts visibility

Classloader gives each module its own

lifecycle

Publishes the interface, ideally as

µServices

DYNAMICITY

54

Modules as First Class Citizens

INSTALLED

RESOLVED

UNINSTALLED

ACTIVE

STOPPING

STARTING

start

stop

Because bundles have their own classloader, they can be

managed independently. Hence, a very dynamic

environment.

55

The Runtime

- Dynamic deployment- Multiple versions- Enforce dependencies- Encapsulation

demo

56

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

demo

57

A Modular System TODAY!

58

Standard Java Lack Encapsulation

Everything is still visible; no dynamics!

59

No Encapsulation

60

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

Not Visible

62

Encapsulation

Nothing can reach this class!

demo

63

Modularity Today

Why aren’t we designing more modular software?

Platforms discourage modularity!

64

Modularity TomorrowThis is the next generation application platform!

- Dynamic deployment- Multiple versions- Explicit dependencies

demo

65

Modular Architecture Today

OSGi-ify the App

How do I build applications using OSGi?

Is it invasive to my code?

Is it really too complex?

66

Java Application ArchitectureModularity Patterns with Examples Using OSGi

Forewords by Robert C. Martin and Peter Kriens

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.

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)

67

Q&A

68