Developing modular Java applications


Published on

Slides for the "Université du SI 2009", hosted by Octo Technologies.

Published in: Technology, Education
  • Sorry : I have just copy/pasted the marketing stuff from Oracle, they say they do OSGi internally, but maybe they don't! You know it better than me, you're the one who will soon work there!!

    Concerning the OSGi bug on Weblogic, I was talking about this one :

    This was for a major client using Weblogic and Spring together...

    By the way, the good thing about Open Source is that our bug tracking tool is public :-)
    Are you sure you want to  Yes  No
    Your message goes here
  • I don't think there is any OSGi-related bug in WebLogic. OC4j doesn't build on OSGi either. Do you run SpringDM on top of them? But then if the crust of the presentation was in the animations that doesn't really matter I suppose ;)
    Are you sure you want to  Yes  No
    Your message goes here
  • Com'on, you know it : OC4J and Weblogic! At least they claim to (I recently had some funny Weblogic bug related to this!)... Anyway you're missing all the fun with this slideshare version of the presentation : there was in fact an animation showing Bea and Sun being replaced by Oracle...
    Are you sure you want to  Yes  No
    Your message goes here
  • I couldn't attend your presentation.
    Can you say which app servers Oracle and BEA are based on OSGi?
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Developing modular Java applications

  1. 1. Julien Dubois Developing modular Java France Regional Director applications SpringSource
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. Layered Spring application • A layered Spring application Presentation Service Repository Layer Layer Layer @Controller @Service @Repository @Controller @Service @Repository @Controller @Service @Repository
  14. 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”);; } }
  15. 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. 16. Default Spring configuration @MVC Application Root Application Context Context @Repository @Controller @Service @Repository WS Application @Service Context @Repository @Endpoint
  17. 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. 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. 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. 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. 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. 22. It's dynamic • Modules can be • installed Service module Version 1.0 • started @Service • stopped • uninstalled • updated Service module Version 2.0 @Service • runtime
  23. 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. 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. 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. 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. 27. Enter SpringSource dm Server • The short version : it’s Spring, Tomcat and OSGi working all together • Allows powerful and modular applications + +
  28. 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. 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. 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. 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. 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. 33. Clustering • The idea is to separate the load on several identical nodes Apache httpd dm Server dm Server dm Server Module
  34. 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. 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. 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. 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. 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. 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!
  40. 40. Questions? Julien Dubois