Developing modular Java applications
Download as PPT, PDF18 likes11,879 views
Julien Dubois discusses the benefits of developing modular Java applications. Modularity improves quality, lowers complexity, and makes applications easier to reuse and maintain. Spring provides tools for creating layered applications with clear separation of concerns between presentation, service, and repository layers using annotations like @Controller, @Service, and @Repository. For true modularity with hot-deployable modules, OSGi is introduced, which Spring Dynamic Modules builds upon. dm Server leverages Spring, Tomcat, and OSGi to allow deployment of modular applications to virtualized and cloud environments at runtime for improved scalability and reduced costs.
Ad
More Related Content
What's hot (19)
Viewers also liked (20)
Ad
Similar to Developing modular Java applications (20)
Ad
More from Julien Dubois (20)
Recently uploaded (20)
Developing modular Java applications
- 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!