Developing modular Java applications

(1)

(2)

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

Agenda

•Wrong ideas about modular applications

•What you wanted to do in the first place

•What you should want to do : real modularity

(4)

Agenda

•Wrong ideas about modular applications

(5)

Modularity & layers

•Typical Java applications are separated in layers

Presentation

layer

Spring @MVC, Struts, JSF, AJAX…

Service layer

Spring beans, EJBs…

Repository

layer

Hibernate, JPA, JDBC…

(6)

Modularity & layers

•Many architects want those layers to be well-separated

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

• They choose Web Services as a remoting protocol – “performance is not an issue, we’ll just add more servers”

•As seen in the biggest French IT consulting firms, banks, telecom companies, healthcare companies, etc… during the last decade.

(7)

Can you spot the errors?

•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

•Web Services is an integration pattern, not a remoting pattern. Using Web Services for doing RPC inside an application you own is a non-sense

•DTOs are just a pain to code… they reduce developers’ productivity and motivation

(8)

So remote layers is always wrong?

•Remote layers is a good solution when you need it

• For example in the presentation layer : Swing, Adobe Flex, GWT all use RPC calls to your JEE application

• It works really well with Spring : making a Spring bean available remotely is just a matter of configuration (no code)

•Web Services are an excellent solution when you need integration of different systems

• Spring Web Services, Spring Integration, Mule (built on Spring) can definitely help

(9)

Modularity is more than layers

•Modules can be horizontal and vertical

• Modules per layer : as seen in the previous slides

• Modules per functionality : admin module, accounting module

•Modules per layer is the simplest solution

(10)

Agenda

•What you wanted to do in the first place

(11)

Modularity & layers

•Let’s do this architecture with local Java objects

Presentation

layer

Spring @MVC

Service layer

Spring beans

Repository

layer

Hibernate, JPA, JDBC…

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

A business service coded with Spring

package myapplication.service;

@Service

public 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

(14)

Separating layers with Spring

•Just add your beans to your classpath (in a JAR file, for example), and you’re done!

•Your layers are well-separated :

• They are in a specific Java package. Maybe even in a specific JAR file. • Spring beans have annotations that tell in which layer they are.

•If you really need to be sure :

• AspectJ can check that layers work as expected, and make mistakes appear as compilation errors in Eclipse

(15)

Separating layers with Spring

•The code we have seen is :

• Easy to code and test

• Very performant in production • Still well-separated in layers

•You do not need to physically separate your layers to have a layered application

•This is beyond this presentation’s scope, but we can go one step further by looking at Spring’s hierarchical application contexts (by default, the presentation layer is a child of the service+repository layers)

(16)

Agenda

•What you should want to do : real modularity

(17)

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)

•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

•Changing some Java code at runtime is not possible with a traditional Java application server

(18)

Enter Groovy

•Solution #1 : Groovy

•Groovy is a dynamic language, inspired by Python and Ruby

•But it runs inside the JVM

• It can access all your Java components • Spring beans can be coded in Groovy

•Spring & Groovy work very well together – Groovy development being led by SpringSource employees!

(19)

Groovy by example

class HelloWorld {

String name

String greet() { “Hello $name” }

}

def helloWorld =

new HelloWorld(name: “Groovy”)

println helloWorld.greet()

(20)

Using Groovy at runtime

•A Spring Bean can be coded in Groovy

• It benefits from all Spring features : AOP, security, transactions… • It benefits from all JEE features : JPA…

• This Bean is a script, and can be changed at runtime

•Many organizations use Groovy to write business rules that change during production time

(21)

Groovy summary

•Groovy is great to dynamically update your application at runtime

• It’s also a very interesting & productive language per se

(22)

Enter SpringSource dm Server

•Solution #2 : SpringSource dm Server

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

• Allows powerful and modular applications

+

(23)

What is 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

(24)

It's a module system

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

•Strict visibility rules

•Resolution process

• satisfies dependencies of a module

(25)

It's dynamic

•Modules can be • installed • started • stopped • uninstalled • updated •...at runtime

(26)

It's even service-oriented

•Bundles can publish services

• dynamically

•Service Registry allows other bundles to find services

• and to bind to them

(27)

Introducing Spring Dynamic Modules

•Spring Dynamic Modules is a Spring project, backed by SpringSource

•Helps using OSGi with Spring

• Makes it easy to export a Spring Bean to the OSGi registry • Makes it easy to inject a Spring Bean from another bundle

<beans ...> <osgi:service ref="customerDAO" interface="dao.ICustomerDAO" /> <osgi:reference id="dataSource" interface="javax.sql.DataSource" /> </beans>

(28)

Doing OSGi bundles

•Doing a module with Spring Dynamic Modules is easy

• Put your configuration files in /META-INF/spring

• They are automatically merged

• ..and a Spring ApplicationContext is created

•It is extremely easy to achieve our architectural goals with this solution

(29)

Why another application server?

•Most application server vendors base their systems on OSGi

•But none offers OSGi as a programming model for the customer

•Why shouldn't the customer be as empowered as the application server vendor?

(30)

So, what does dm Server do?

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

(31)

Features for developers

•For developers :

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

• Hot-deployment of modules during

development time : you only work on your module, not on the whole application

• The complexity of OSGi is hidden by dm Server : doing a modular

application is easy, knowledge of the OSGi APIs and specificities is

(32)

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

(33)

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

(34)

Agenda

(35)

Clustering

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

Apache httpd

Apache Tomcat

(36)

Cloud computing

•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 VMWare for this reason

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

(37)

Tomcat & dm Server in the cloud

•You can already run Tomcat and dm Server “on the cloud”

• Amazon EC2 & Gandi Flex just provide the hardware… This is called IaaS (Infrastructure As A Service) - you can run any Java program there!

• SpringSource provides tools to monitor and manage Spring, Tomcat and dm Server at runtime

• In the future, those tools will evolve to be able to do “provisionning” : dynamically adjust the number of running nodes depending on the load

•SpringSource is working with VMWare : virtualized instances of Tomcat and dm Server

(38)

The big picture

Node

(39)

Summary

•Web applications should be split into modules :

• Vertically : “module per layer”

• Horizontally : “module per functionality”

•If you want to split your application in 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

•If you want to split your applications in modules that can be updated at runtime, dm Server and Groovy offer two excellent solutions

•Be ready for the future : cloud computing offers un-beatable scalability and costs.

(40)

Questions?

Julien Dubois

[email protected] http://www.springsource.com/fr