For a moderately complex application to manage complexity it needs to be broken up into smaller modules – which can be developed / tested independently. The modularization should be based on the domain rather than along layers (dao/service etc). This session will focus on some guidelines on how to breakup large applications into modules and how to realize that modularity in an application that uses Spring, Hibernate, Maven. The talk is based on the experience gained implementing (and refining) these techniques in 3-4 large product development that I have been involved in.

1. Building modular applications
Kamal Govindraj
TenXperts Technologies

2. About Me
 Programming for 13 Years
 Architect @ TenXperts Technologies
 Trainer / Consultant @ SpringPeople
Technologies
 Enteprise applications leveraging open source
frameworks (spring,hibernate, gwt,jbpm..)
 Key contributor to InfraRED & Grails jBPM
plugin (open source)

3. Agenda
 Importance of Moudlarity
 How to?
 Challenges
 Tools & best practices
 OSGI

4. Modularity
 Break application into smaller modules
 Interaction between module via interfaces
 Helps in dealing with complexity
 Break development into smaller teams
 Reuse
 Easier to maintain

5. Horizontal / Technology
Presentation
Catalog Inventory
Inventory Order
Service
/ Domain
Persistence

6. Vertical / Functional
Order
Presentation
Inventory
Catalog
Order
Application
Inventory
Catalog

7. Vertical is better
 Scales better
− Team size
− Feature
 Separate concerns along the lines of business
functionality
 Easier to maintain

8. Physical Vs Logical
 Logical separation provides most of the
benefits
 Phyiscal separation issues
− Performance overheads
− Reduces reliability
− Increased Complexity

9. Package guidelines
Visible to other
modules
Visible to other
modules
Private classes /
Not visible outside
this module

10. Challenges
 Builds become more complex
 Changes across module boundaries are
harder
 Integration issue
 Wiring the system together

11. Tools & Frameworks
 Maven
− Simplifies multi module builds
− Declarative dependency
− Transitive dependency handling
− Versioned

12. Maven in action

13. Dependency Injection
 Takes care of wiring together components
from different modules
 The modules are loosely coupled depending
only on the published interfaces
 Spring Framework / Google Guice / EJB 3.0 ..

14. Java module limitation
 Jar is the basic construct for defining modules
 Only a compile time construct
− Modules are not preserved at run time
 No way to enforce strict separation
 Difficult to have multiple versions of same
module in a vm
 Not easy to share modules across multiple
applications

15. Runtime modularity
 OSGI
− A mature specification & platform
− Eclipse is built on OSGI
− So are many of the application servers
− Multiple implementations (Equinox, Felxi,
Knopflerfish
 JSR 294 – Simple module system for Java

16. OSGI
 A module is a jar with metadata (MANIFEST
file)
− exported packages
− Imported packages with versions
− Other module dependecies with versions
 OSGI container
− Manages module lifecycle
− Resolve dependencies
− Enforces strict separation

17. OSGI != modular
 OSGI can make a existing modular
application work better
 Breaking up a system into well defined
modules and maintaining it that way is the
harder part
 Tools can help – but ...

18. Questions ?

19. Thank You.