Developing modular Java applications

Developing modular Java applications - Presentation Transcript

Julien Dubois Developing modular Java France Regional Director applications SpringSource

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

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 Presentation Service Repository Layer Layer Layer Object Object Object Object Object Object 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 Service Repository Admin module Layer Layer Accounting module

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…

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

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

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 Presentation Service Repository Layer Layer Layer @Controller @Service @Repository @Controller @Service @Repository @Controller @Service @Repository

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

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 @MVC Application Root Application Context Context @Repository @Controller @Service @Repository WS Application @Service Context @Repository @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

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

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

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

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

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 : Spring MVC Spring Framework Database Connection Pool Service Repository Admin module module module Accounting module

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

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!

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?

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

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 leader in 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 Dubois julien.dubois@springsource.com http://www.springsource.com/fr