Developing modular Java applications Julien Dubois France Regional Director 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
Agenda Wrong ideas about modular applications What you wanted to do in the first place What you should want to do : real modularity Modularity in the cloud
Agenda Wrong ideas about modular applications What you wanted to do in the first place What you should want to do : real modularity Modularity in the cloud
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
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. Disclaimer : I also did that kind of errors between 1999 and 2002
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
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 Use the right tool for the job you want to achieve
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 Good enough for smaller projects
Agenda Wrong ideas about modular applications What you wanted to do in the first place What you should want to do : real modularity Modularity in the cloud
Modularity & layers Let s do this architecture with local Java objects Presentation layer Spring @MVC Service layer Spring beans Repository layer Hibernate, JPA, JDBC
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
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
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 Many other tools can check that your layers are well-separated
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)
Agenda Wrong ideas about modular applications What you wanted to do in the first place What you should want to do : real modularity Modularity in the cloud
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
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!
Groovy by example class HelloWorld { String name String greet() { Hello $name } } def helloworld = new HelloWorld(name: Groovy ) println helloworld.greet()
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 Hot deployment on the server, depending on the users needs
Groovy summary Groovy is great to dynamically update your application at runtime It s also a very interesting & productive language per se But we have just seen a dynamic language, not dynamic modules
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 + +
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
It's a module system Partition a system into a number of modules "bundles Strict visibility rules Resolution process satisfies dependencies of a module Understands versioning
It's dynamic Modules can be installed started stopped uninstalled updated...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 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>
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 As long as you have an application server that supports OSGi
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?
So, what does dm Server do? dm Server allows you to use OSGi-based applications, running in an application server :
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 not a requirement
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!
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 Wrong ideas about modular applications What you wanted to do in the first place What you should want to do : real modularity Modularity in the cloud
Clustering The idea is to separate the load on several identical nodes Apache Tomcat Apache Tomcat Apache httpd Apache Tomcat Apache Tomcat Apache Tomcat
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)
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
The big picture Node Node Node Node Node Module
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.
Questions? Julien Dubois julien.dubois@springsource.com http://www.springsource.com/fr