Your SlideShare is downloading. ×
Developing modular Java applications
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Developing modular Java applications

11,080

Published on

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

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

Published in: Technology, Education
4 Comments
9 Likes
Statistics
Notes
  • 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 :
    http://jira.springframework.org/browse/SPR-4990

    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 :-)
       Reply 
    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 ;)
       Reply 
    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...
       Reply 
    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?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
11,080
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
307
Comments
4
Likes
9
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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!
  • 40. Questions? Julien Dubois julien.dubois@springsource.com http://www.springsource.com/fr

×