developing modular java applications

Developing modular Java applications

Julien DuboisFrance Regional DirectorSpringSource

•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

Julien Dubois

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

Agenda

•Modules, layers and errors

•Doing a layered Spring application the easy way

•Modular Java with Spring and OSGi

•Modularity in the cloud

Modularity & layers

•Typical Java applications are separated in layers

RepositoryLayer

RepositoryLayer

Object

Object

Object

ServiceLayer

ServiceLayer

Object

Object

Object

PresentationLayer

PresentationLayer

Object

Object

Object

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

RepositoryLayer

RepositoryLayer

ServiceLayer

ServiceLayer

Admin moduleAdmin module

Accounting moduleAccounting module

Errors

•Many architects want those layers to be well-separated

• They separate those layers physically – “let’s do EJB 1 again!”

•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…

Server BServer BServer AServer A

Remoting

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

Agenda





Spring & Layers

•Let’s do this architecture with local Spring beans

RepositoryLayer

RepositoryLayer

Object

Object

Object

ServiceLayer

ServiceLayer

Object

Object

Object

PresentationLayer

PresentationLayer

Object

Object

Object

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

Layered Spring application

•A layered Spring application

RepositoryLayer

RepositoryLayer

@Repository

@Repository

@Repository

ServiceLayer

ServiceLayer

@Service

@Service

@Service

PresentationLayer

PresentationLayer

@Controller

@Controller

@Controller

Show me the code!

package myapplication.service;

@Servicepublic class AccountServiceImpl implements AccountService {

@Autowired private AccountRepository accountRepo;

@Transactional @Secured("ROLE_MANAGER") public void addAccount(String login) { Account account = new Account(login); account.setPassword(“changeme”); accountRepo.save(account); } }

This Spring Bean belongs to the Service layer

Injecting a Spring bean from the Repository layer

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

Default Spring configuration

Root Application ContextRoot Application Context

@Service

@Service

@Repository

@Repository

@Repository

@MVC Application Context

@MVC Application Context

@Controller

WS Application Context

WS Application Context

@Endpoint

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

Agenda





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??

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

•Partition a system into a number of modules – "bundles"

• Each bundle has its own memory space

•Strict visibility rules

•Resolution process

• satisfies dependencies of a module

•Understands versioning

Repository moduleRepository module

Service moduleService module

Presentation modulePresentation module

It's a module system

@Service

@Controller

@Repository

Version 1.0

Version 1.0

Version 2.0

It's dynamic

•Modules can be

• installed

• started

• stopped

• uninstalled

• updated

•...at runtime


@Service

Version 1.0


@Service

Version 2.0

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

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

Introducing Spring Dynamic Modules

•Configuring Spring beans

• Just put your Spring configuration files in /META-INF/spring

• It’s easy to export a Spring Bean to the OSGi registry

• It’s easy to inject a Spring Bean from 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>

Best PracticeSeparate your business code

from your infrastructure

code!

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?

Enter SpringSource dm Server

•The short version : it’s Spring, Tomcat and OSGi working all together

• Allows powerful and modular applications

++

dm Server empowers you to use OSGi

•dm Server allows you to use OSGi-based applications, running in an application server :

Repositorymodule

Repositorymodule

ServicemoduleServicemodule



Spring FrameworkSpring Framework Database Connection Pool

Database Connection Pool

Spring MVCSpring MVC

Features for developers

•For developers :

• A truly modular architecture : secured modules, with a well-defined lifecycle

• More productivity thanks to the hot-deployment of modules during development time : you only work on your module, not on the whole application

Repositorymodule

Repositorymodule

Servicemodule

Servicemodule



Spring FrameworkSpring FrameworkDatabase

Connection Pool

Database Connection PoolSpring MVCSpring MVC

Features for production

•For the production team :

• Hot deployment of modules of the application at runtime : lower downtime

• Several versions of the same module can be deployed in parallel

• Better usage of the server resources : dm Server only loads modules that are actually needed!

Repositorymodule

Repositorymodule

Servicemodule

Version 1.0

Servicemodule

Version 1.0

Spring FrameworkSpring FrameworkDatabase

Connection Pool

Database Connection Pool

Servicemodule

Version 2.0

Servicemodule

Version 2.0

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?

Agenda





Clustering

•The idea is to separate the load on several identical nodes

Module

dm Server

Apache httpd

dm Server dm Server

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

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)

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

Hyperic

•SpringSource has just bought Hyperic (May 2009)

• Hyperic is a leaderin management and montoring

• Hyperic already proposes CloudStatus, that monitors Amazon EC2 and Google AppEngine

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

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!

Questions?

Julien [email protected]

http://www.springsource.com/fr

developing modular java applications

Technology