Slides for the "Université du SI 2009", hosted by Octo Technologies.

1. Julien Dubois
Developing modular Java France Regional Director
applications SpringSource

2. Julien Dubois
• France Regional Director, SpringSource
• Book author :« Spring par la pratique » (Eyrolles, 2006) – new
edition coming soon!
• 10 years of experience in Java development
• Member of OSSGTP

3. Why do we want modular
applications in the first place?
• Dividing a complex problem into simpler, more manageable
problems is a well-known technique since 400 years
(Descartes)
• Improved quality
• Lower complexity
• Modules are easy to reuse across an application or even
several applications
• Improved time-to-market
• Lower costs
• Only true for “enterprise-grade” applications

4. Agenda
• Modules, layers and errors
• Doing a layered Spring application the easy way
• Modular Java with Spring and OSGi
• Modularity in the cloud

5. Agenda
• Modules, layers and errors
• Doing a layered Spring application the easy way
• Modular Java with Spring and OSGi
• Modularity in the cloud

6. Modularity & layers
• Typical Java applications are separated in layers
Presentation Service Repository
Layer Layer Layer
Object Object Object
Object Object Object
Object Object Object

7. Modularity is more than layers
• 1 module = 1 layer is the simplest solution
• Good enough for smaller projects
• Modules can be horizontal and vertical
• Modules per layer : as seen in the previous slide
• Modules per functionality : admin module, accounting module
Service Repository
Admin module
Layer Layer
Accounting module

8. Errors
• Many architects want those layers to be well-separated
• They separate those layers physically – “let’s do EJB 1 again!”
Server A Server B
Remoting
• As seen in the biggest French IT consulting firms, banks,
telecom companies, healthcare companies, etc… during the last
decade.
• This essentially comes from poorly-designed specs (EJBs)
written by hardware vendors…

9. What is the problem?
• Adding more servers will never make your application more
scalable
• Remoting is slow and inefficient
• A remoting call is several orders of magnitude slower than a
local one
• Remoting also affects your GC time : all those remote objects are
being garbage collected…
• Adding more servers will just add more network issues
• You do not need to physically separate your modules to have a
modular application

10. Agenda
• Modules, layers and errors
• Doing a layered Spring application the easy way
• Modular Java with Spring and OSGi
• Modularity in the cloud

11. Spring & Layers
• Let’s do this architecture with local Spring beans
Presentation Service Repository
Layer Layer Layer
Object Object Object
Object Object Object
Object Object Object

12. Separating layers with Spring
• The good news : with Spring, it works out of the box!
• Spring even has some specific Java annotations for this :
• @Controller for a Spring MVC controller (presentation layer)
• @Service for a Spring business bean (service layer)
• @Repository for a Spring repository bean (repository layer)
• There are many other ways to do this with Spring
• Using naming conventions with component scanning
• Using Spring’s XML configuration file

13. Layered Spring application
• A layered Spring application
Presentation Service Repository
Layer Layer Layer
@Controller @Service @Repository
@Controller @Service @Repository
@Controller @Service @Repository

14. Show me the code!
package myapplication.service; This Spring Bean belongs
to the Service layer
@Service
public class AccountServiceImpl implements
AccountService {
Injecting a Spring bean
from the Repository layer
@Autowired
private AccountRepository accountRepo;
@Transactional
@Secured("ROLE_MANAGER")
public void addAccount(String login) {
Account account = new Account(login);
account.setPassword(“changeme”);
accountRepo.save(account);
}
}

15. Spring’s hierarchical application contexts
• Spring also provides a hierarchy of application contexts out of
the box. By default (no specific configuration to do) :
• There is a “root” application context, which contains the
repository and service layers
• The presentation layer (Spring @MVC) is a child of this root
context :
• @Controller beans see @Service beans, but not the opposite
• Web Services written with Spring WS also have their own child
application context

16. Default Spring configuration
@MVC Application Root Application Context
Context
@Repository
@Controller @Service
@Repository
WS Application
@Service
Context
@Repository
@Endpoint

17. Separating layers with Spring
• The code we have seen is :
• Easy to code and test
• Very performant in production
• Still well-separated in layers
• This is Spring default’s configuration
• Works out of the box
• This can be customized in many, many different ways
• You do not need to physically separate your layers to
have a layered application

18. Agenda
• Modules, layers and errors
• Doing a layered Spring application the easy way
• Modular Java with Spring and OSGi
• Modularity in the cloud

19. The problem with the previous slides
• However, what we have just done is a monolithic application
• Everything is put into a single deployment unit (a WAR file)
• Memory is shared between all modules : not secured
• What you want as a developer is :
• Updating your application at runtime, and not redeploy your WAR
file all the time
• What your users want is :
• New functionalities hot deployed at runtime
• High availability
• But how can we change modules at runtime??

20. Introducing OSGi
• OSGi is a specification
• Used since many years in the telecom industry
• With several implementations in Java : for instance Equinox,
which is the basis of the Eclipse IDE

21. It's a module system
• Partition a system into a number of modules – "bundles"
• Each bundle has its own memory space Presentation module
Version 1.0
@Controller
• Strict visibility rules
Service module
Version 1.0
• Resolution process @Service
• satisfies dependencies of a module
Repository module
Version 2.0
@Repository
• Understands versioning

22. It's dynamic
• Modules can be
• installed
Service module
Version 1.0
• started
@Service
• stopped
• uninstalled
• updated
Service module
Version 2.0
@Service
• ...at runtime

23. It's even service-oriented
• Bundles can publish services
• dynamically
• Service Registry allows other bundles to find services
• and to bind to them
• Services come and go at runtime, all taken care of for you

24. Introducing Spring Dynamic Modules
• Doing OSGi directly is complex
• It also makes your code dependant on the OSGi APIs
• Spring Dynamic Modules is a Spring project, backed by
SpringSource
• No OSGi in your code
• Your Spring beans are just configured to be OSGi services
• It’s easy to move a project to/from OSGi
• Moving from Spring to Spring+OSGi is easy
• Going back from Spring+OSGi to Spring is also easy

25. Introducing Spring Dynamic Modules
• Configuring Spring beans
• Just put your Spring configuration Best Practice
files in /META-INF/spring
Separate your
• It’s easy to export a Spring Bean to business code
the OSGi registry from your
infrastructure
• It’s easy to inject a Spring Bean from code!
another bundle
<beans ...>
<bean id="customerDAO" class="dao.CustomerDAO"/>
<osgi:service ref="customerDAO" interface="dao.ICustomerDAO"/>
<osgi:reference id="dataSource" interface="javax.sql.DataSource"/>
</beans>

26. Who supports OSGi?
• Most application server vendors base their systems on OSGi
• Validates the usage of OSGi as a solution for modular
applications
• But none offers OSGi as a programming model for the customer
• Why shouldn't the customer be as empowered as the
application server vendor?

27. Enter SpringSource dm Server
• The short version : it’s Spring, Tomcat and OSGi working all
together
• Allows powerful and modular applications
+ +

28. dm Server empowers you to use OSGi
• dm Server allows you to use OSGi-based applications, running
in an application server :
Spring MVC Spring Framework Database Connection
Pool
Service Repository
Admin module
module module
Accounting module

29. Features for developers
• For developers :
• A truly modular architecture : secured modules, with a well-
defined lifecycle
• More productivity Spring Framework
Database
thanks to the Spring MVC Connection Pool
hot-deployment of
modules during
development time :
you only work on your Admin module
module, not on the Service Repository
module
whole application module
Accounting module

30. Features for production
• For the production team :
• Hot deployment of modules of the application at runtime :
lower downtime
Spring Framework
• Several versions of Database
Connection Pool
the same module
can be deployed in
parallel
Service
module
• Better usage of the Version 1.0
Repository
server resources : Service
module
dm Server only loads module
modules that are Version 2.0
actually needed!

31. dm Server summary
• dm Server is the only application
server that gives the power of
OSGi to development and
production teams
• dm Server is built on standard,
widely used, Open Source
components : Spring, Tomcat,
Equinox
• Of course, dm Server is free
software (GPL v3), so why don’t
you start writing applications with
it?

32. Agenda
• Modules, layers and errors
• Doing a layered Spring application the easy way
• Modular Java with Spring and OSGi
• Modularity in the cloud

33. Clustering
• The idea is to separate the load on several identical nodes
Apache httpd
dm Server dm Server dm Server
Module

34. Cloud computing & virtualization
• Experience shows that
clusters are often widely
under-utilized… Because
you don’t need all the nodes
all the time.
• Cloud computing allows renting computing power on demand
• You can rent servers per hour with : Amazon EC2, Google
AppEngine, Gandi Flex (in France)…
• Companies datacenters are moving to virtualization for this
same reason

35. dm Server in the cloud
• Virtualization solution : SpringSource
works with VMWare to provide new tools
and support for dm Server in a
virtualized environment
• IaaS (Infrastructure As A Service)
solution : Amazon EC2 & Gandi Flex just
provide the hardware… dm Server
already runs on those systems
• PaaS (Platform As A Service) solution :
No OSGi support on those solutions, but
there is Groovy and Grails support on
Google AppEngine (in cooperation with
Google)

36. Cost reduction is king
• This can be far less expensive
than a traditional cluster as long
as :
• You can monitor your load
properly
• You can estimate your needs in
advance (launching a new EC2
instance can take a few minutes)
• But with the current global economic climate, there is a very
strong move towards those solutions

37. Hyperic
• SpringSource has just bought Hyperic (May 2009)
• Hyperic is a leader
in management
and montoring
• Hyperic already
proposes
CloudStatus, that
monitors Amazon
EC2 and Google
AppEngine

38. Dynamic provisionning
• Currently our monitoring & management tools are able to :
• Manage a group of servers : for example, deploying an
application on 100 dm Server nodes with one click
• Monitor a large group of nodes, including on the cloud or in a
virtualized environment
• In the future, those tools will evolve to be able
to do “provisionning”: dynamically adjust the
number of running nodes depending on the load

39. Summary
• Complex applications should be split into modules : reduced
cost, improved time-to-market
• If you want to split your application into modules at build
time, Spring provides an excellent solution out of the box:
there’s no need to go for more complex (and inferior) solutions
Use tc Server (= enterprise version of Tomcat) and Spring
• If you want secured, well-defined modules that can be
dynamically updated at runtime, Spring and OSGi offer a
perfect solution
Use dm Server (Tomcat + OSGi) and Spring
• Be ready for the future : cloud computing offers un-beatable
scalability and costs. Both tc Server and dm Server are ready!

40. Questions?
Julien Dubois
julien.dubois@springsource.com
http://www.springsource.com/fr