Impala A dynamic module framework for Java web development Phil Zoio Realsolve Solutions Devoxx 12 December, 2008 Today's talk Introduce you to Impala Explain its background and benefits Show how it works in practice Explain where it fits in with OSGi 4 Speakers qualifications Java developer, architect and consultant Active open source developer. Creator of Strecks (Java 5 extensions for Struts) Impala (today's talk) Regular speaker at user groups and conferences 5 What is Impala? Source: 6 What is Impala? Source: 7 What is Impala? Impala is a dynamic module framework for Java-based web applications, based on Spring. Focus on simplicity and productivity. 8 Project goals Provide the most productive, lightweight, test-friendly environment for creating and running Java web-based applications Provide the most effective Java environment for reducing complexity as applications grow 9 The importance of modules Static modularity allows parts of system to be decoupled less complexity easier to deploy, test and configure Dynamic modularity allows partial updates developer productivity operational benefits (e.g. live updates) Module topologies: hierarchy Modules arranged in tree A BD CE Module topologies: graph Modules can have multiple direct dependencies A BD CE F Fast project startup, out-of-the-box experience Dynamic load, update and removal of modules Dramatically reduced develop/deploy/test cycle Allow all development in IDE, no special tooling required Reusable build system, based on ANT Good web support Impala features DEMO Impala Quick Start Create a new project Import into Eclipse Demonstrate Impala in action Build and run on Tomcat How can you update your application without having to restart the JVM? How can you add functionality without having to change any existing code or configuration? How can you make integration tests easy to write and quick to run? How can you make your application easy for operations to deploy and administer? How can you support multiple configurations of software without builds and with minimum admin? Problems Impala solves How do you avoid XML hell? Problems Impala solves String[] locations = { "applicationContext-hsqldb.xml", "applicationContext-domain.xml", "applicationContext-content-repository-mock.xml", "applicationContext-service.xml", "applicationContext-push-service-mock.xml", "applicationContext-billing.xml", "applicationContext-security.xml", "applicationContext-messaging-mock.xml", "applicationContext-jms-common.xml", "applicationContext-jms-producer.xml", "applicationContext-jms-consumer.xml", "applicationContext-subscription-client.xml", "applicationContext-subscription-server.xml", "applicationContext-subscription-jms.xml", "applicationContext-guid.xml", "applicationContext-scheduler-hsqldb.xml", "applicationContext-notification.xml", "applicationContext-notification-test.xml", "applicationContext-velocity.xml" "applicationContext-tag-synchroniser-null.xml", }; ApplicationContext context = new ClassPathXmlApplicationContext(locations); A code or crud generator A new API or programming model A replacement for any existing framework A module system for third party libraries What Impala isn't Instead, it provides a productive and dynamic environment for applications DEMO Spring Petclinic, Impala-style Created new 'surgery' entity Add new methods to Clinic, with tests Update the GUI Class loaders limit visibility of classes between modules allow reloading by replacing class loaders Service registry decouples service providers from users Proxies allow static references to dynamic services Dependency injection provides transparent programming model How does it work? main root Architecture Impala Service Registry App/web class loader hibernate application services application web servlet Module class loader Imported from service registry Exported to service registry 1. Impala bootstrapped as Spring context 2. Impala loads module definitions 3.Corresponding module graph loaded, each with class loader and Spring context 4. Modules export beans to service registry 5. Client modules consume these via proxies 6. Communication via shared classes and interfaces Module marked as stale, i.e. eligible for reload Required reload operations determined based on module's position in graph/hierarchy Old modules shut down in correct order. e.g. ApplicationContext.close() called, services removed from registry New modules loaded in correct order. Involves creation of new class loader and ApplicationContext Registry entries added, new client proxy references supplied Module reload Runs directly in IDE using embedded Jetty Build war, or zip file with embedded Jetty Supports multi-web module applications Reduced reliance on web.xml as configuration source Supports dynamic reloading of web apps built not only using Spring MVC, but other Java web frameworks Web support DEMO Web framework integration Multi-web framework application Allows separate, dynamic reloading of Struts, Wicket and Tapestry modules mature specification adopted by most application server vendors sophisticated class loader model comprehensive model for dynamic services considerable vendor backing (e.g. SpringSource) Impala and OSGi OSGi is increasingly the leading Java module system Impala and OSGi Background: Impala brings modularity to Spring, not Spring to OSGi Occam's razor principle: most valuable features of Impala don't require OSGi Significant practical barriers requires active 3 rd party library management popular libraries not always OSGi compliant relatively slow adoption by typical enterprise developer Runs in container, therefore harder to integration test Why is OSGi not the default model for Impala? Testing in OSGi Not a trivial problem Impala and OSGi Natural evolution for Impala Fits in fairly comfortably into OSGi world Preliminary support in current snapshot. Web integration and better testing support required Impala modules are now also OSGi bundles (wrapped using BND) As OSGi moves forward, Impala will not be left behind! Impala support is now being built into Impala OSGi benefits Impala offers potential benefits even when using OSGi Impala's productivity brought to OSGi Impala's abstractions are still valuable (application vs library modules) seamless transition to (and from) OSGi decision to use OSGi can be deferred or made on per-project basis DEMO Impala OSGi support Hello world example Integration test running on Equinox container What's next 1.0 M4 December 2008 module graphs preliminary OSGi support 1.0 early to mid 2009 Spring namespace support administration GUI better OSGi support other enhancements Summary abstractions for building genuinely modular Spring apps greatly enhanced developer productivity a strong focus on simplicity and testability minimal reliance on IDE and build tools a works out of the box experience an open source licence (Apache 2.0) Impala offers a simple, practical modularity solution, with Try it out. Help would be very welcome and appreciated! References Impala Project home:Impala Blog:Realsolve Solutions: Q&A Thanks for your attention!