Discussions

News: Impala dynamic modules for Spring-based apps, 1.0 M6 released

  1. I am pleased to announce the release of Impala 1.0M6. The 1.0M6 is an important release for Impala, as it is the last pre-1.0 final release to include major enhancements and API changes. Impala is a dynamic module framework for Java enterprise application development, building on the Spring framework. Impala is the simplest and most TDD-friendly way to bring dynamic modularity into Java applications, making it possible to build large, complex applications which are simple to test and productive to develop. With a focus on simplicity and productivity, Impala radically transforms application development using Spring and related technologies, doing so without requiring any additional third party tooling or runtime environments. Impala 1.0M6 release includes a full reworking of the Impala service registry implementation, as well as the mechanisms for exporting services to and importing services from the service registry. The headline improvements include the following.
    • Configuration of Impala services is now much simpler, as a new Spring 'service' namespace has been provided for easily exporting and importing services.
    • Service export and import can now be done not only by name but also by type or by custom attributes, the latter using a model similar to that used in OSGi.
    • Impala's mechanism for proxying services obtained from the service registry has improved, and is now more easily configurable.
    • It is now possible to export and import Impala services without having to specify an interface - proxying of the service implementation class is now also supported.
    • Impala now supports exporting and importing services based on Spring beans which are not singletons or not created using non-singleton Factory beans. It does this in a way that is totally transparent to users of the services, effectively allowing clients to treat all beans as singletons.
    • Impala now provides implementations of java.util.List and java.util.Map, dynamically backed by beans imported from the service registry.
    The 1.0M6 release also introduces a number of improvements to make dynamic module reloading more robust, particularly when using the module auto-reload feature, as well as other minor enhancements and bug fixes. For more information on this release see: http://code.google.com/p/impala/wiki/Release1_0M6Announcement Phil Zoio Impala Home: http://impala.googlecode.com Blog: http://impalablog.blogspot.com
  2. How does thsi differ from OSGi?[ Go to top ]

    Go on then how does this differ from OSGi?
  3. I posted a reply a little while ago, but seems to have got lost, so hopefully this doesn't appear twice. First of all, OSGi on it's own is a lower level technology than Impala. Raw OSGi offers lifecycle, modules class loading and a service registry, but you still have to manage the dynamics aspects of services yourself. So from a programming experience it is completely different. A better yardstick for comparison is between Impala and dm Server, which offer a much more similar programming model, as well as tools to facilitate module management. There is obvious overlap in objectives - fundamentally its about trying to get the benefits of modularity to build scalable systems. On to the differences: Impala has a heavy emphasis on productivity. I am not saying that OSGi is unproductive, but there are things you need to do when writing OSGi apps which will slow you down a bit. Impala has no such obstacles. The Impala model for modularity is much simpler, because it only deals with application modules, not third party libraries. Within the application itself, the model is still powerful, capable and very extensible. With Impala you don't need to worry about whether your jars have the correct OSGi bundle manifests. You don't need to get your JAR files from any special repository - the standard public maven repository will do. You don't need to install any third party runtime environments to run your application, nor do you need to run yor application on a container. You don't need to limit yourself to only specific environments (e.g frameworks, app servers, etc.) to run your application successfully - some OSGi frameworks do impose such limitations. You don't need to have any third party tools in place to help you write your applications, because its easy enough without (I just use the basic Eclipse distribution). Impala lets you build multi-module web applications running on standard containers (Tomcat, Jetty, JBoss, Websphere, etc.) using the standard packaging conventions. The biggest one for me - integration testing with Impala is a breeze - much easier than with vanilla Spring, while integration testing with OSGi can be difficult because it requires running your application on a container. Impala's management of modules is self-contained. You don't have to worry about what's happening in the OSGi lifecycle, set up asynchronous listeners, etc. because the module management environment is contained within the application, rather than external to it. With Impala you can't concurrently run multiple versions of particular third party libraries as you can with OSGi. How important this is important depends on your perspective. And obviously Impala is not a standard. Whether this is important depends on your perspective.
  4. Hi Phil, congrats on getting Impala a step closer to 1.0! Just wanted to clarify a couple of points... [disclaimer for those who don't know : I'm co-writing a book on OSGi and work on a number of OSGi related open-source projects]
    The Impala model for modularity is much simpler, because it only deals with application modules, not third party libraries.
    You can do something similar in OSGi by putting third-party libraries on the main classpath and listing the packages in "org.osgi.framework.bootdelegation" (you can use wildcards to avoid long lists of packages). While this means you can't use multiple versions of these third-party libraries it does mean they behave just as they would in a "classic" Java application, which can help when you're migrating to OSGi. Then you just need to sort out OSGi metadata for your own business modules, which hopefully are much simpler ;)
    You don't need to get your JAR files from any special repository - the standard public maven repository will do.
    OSGi doesn't restrict you either - the OPS4J community has tools to pull in JARs, WARs, etc. from all sorts of repositories and (if necessary) auto-wrap them for OSGi.
    The biggest one for me - integration testing with Impala is a breeze - much easier than with vanilla Spring, while integration testing with OSGi can be difficult because it requires running your application on a container.
    Yes, testing OSGi has been a bit of a slog - but thankfully, that is changing :D
    You don't have to worry about what's happening in the OSGi lifecycle, set up asynchronous listeners, etc. because the module management environment is contained within the application, rather than external to it.
    IMHO most OSGi business applications should not need to use async listeners either, they should be using an abstraction on top of OSGi like Spring-DM or Declarative Services - as you say, these provide a better comparison with Impala than raw OSGi.
  5. Hi Stuart, Thanks for this. Look forward to checking out your book. I am sure that over time there will be more and more well established solutions to the some of the issues that I've identified. I should point out that Impala does not conflict with OSGi. Indeed I have Impala running on OSGi. See http://code.google.com/p/impala/wiki/SamplesOSGi. However, there would still be a lot of work to do to get the same level of usability with Impala in an OSGi environment as there would be with the traditional environment, so I've parked it for now. In the end, its all about the right tool for the job. If your application really will benefit from the unique features OSGi offers - notably the ability to handle multiple versions of third party libraries - then OSGi is the right tool. For many applications, this feature can be overkill, especially if it entails a lot of extra work keeping managing these dependencies and/or a more complex environment/tool set to do this for you. On the other hand, IMO any non-trivial enterprise application does benefit from the type of modularity Impala provides - the ability to structure your application classes in a modular way and dynamically reload parts of your application. Cheers, Phil
  6. Can I run multiple versions of my own modules (i.e. not third party libraries) at the same time?
  7. No, you can't do this.
  8. Thanks for the Clarification[ Go to top ]

    Phil, Thanks for the Clarification much appreciated. We opted for the ServiceMix OSGI Kernel over Spring DM server (favourable license and more lightweight, in our option), but as we are a Spring Shop we will take a look at Impala. Thanks and good luck
  9. Hi Michael.
    We opted for the ServiceMix OSGI Kernel over Spring DM server (favourable license and more lightweight, in our option)
    The SpringSource dm Kernel (dm Server configured to omit the web support) is probably the right thing to compare with the ServiceMix Kernel. The dm Kernel has fewer dependencies and consumes less heap space than ServiceMix Kernel, so I'm intrigued to understand what you mean by "more lighweight". Thanks, Glyn Normington SpringSource dm Server team
  10. I am not saying that OSGi is unproductive, but there are things you need to do when writing OSGi apps which will slow you down a bit.
    Of course, using raw OSGi may slow you down. We'd recommend using tools like BND or Bundlor to manage your manifests, driven by some simple configuration. Also, we'd recommend using Spring DM, or the OSGi-standed BluePrint service which it inspired, to manage your application, and its services. You simply place a standard application context file in META-INF/spring.
    Impala's management of modules is self-contained. You don't have to worry about what's happening in the OSGi lifecycle, set up asynchronous listeners, etc. because the module management environment is contained within the application, rather than external to it.
    You don't have to worry about OSGi lifecycle if you use the BluePrint service or Spring DM: application contexts are started and stopped automatically and services are published and retracted automatically. The consumption of services is also automatic, with in-built damping to seamlessly cope with services coming and going. Andy Wilkinson SpringSource dm Server team
  11. Impala's management of modules is self-contained. You don't have to worry about what's happening in the OSGi lifecycle, set up asynchronous listeners, etc. because the module management environment is contained within the application, rather than external to it.

    You don't have to worry about OSGi lifecycle if you use the BluePrint service or Spring DM: application contexts are started and stopped automatically and services are published and retracted automatically. The consumption of services is also automatic, with in-built damping to seamlessly cope with services coming and going.

    Andy Wilkinson
    SpringSource dm Server team
    Andy, Yes, I made the point that you can't compare Impala with raw OSGi, rather Spring DM or dm Server. Just to clarify my point - with Spring DM you have less control over the life cycle of modules because that's handled through the OSGi container (and the administrative interface this exposes). You don't for example get control over which modules are loaded in which order. This is why in Spring DM application contexts are set up asynchronously - they need to wait until their dependencies are satisfied. Also, because the dependency relationship between modules is normally implied in OSGi, rather than explicit, the job of figuring out which modules need to reload if a change is made to a particular module is quite a lot harder. Not sure if how Spring DM handles this - Impala certainly handles this easily and seemlessly. The explicit relationship is between packages - direct module to module dependencies are slightly frowned upon in OSGi, but I think it is much less of an issue when you are dealing with modules in the application space (as opposed to third party modules). This is a valuable distinction for practical purposes. Impala has a well defined set of metadata for expressing relationships between modules - just as Spring has such metadata for expressing relationships between beans. This metadata (I believe deliberately) isn't present in OSGi - but it does make it easier to visualise and administer your application modules, and I believe is also adds greatly to the usability of Impala. Phil
  12. Just to clarify my point - with Spring DM you have less control over the life cycle of modules because that's handled through the OSGi container (and the administrative interface this exposes). You don't for example get control over which modules are loaded in which order. This is why in Spring DM application contexts are set up asynchronously - they need to wait until their dependencies are satisfied.

    Also, because the dependency relationship between modules is normally implied in OSGi, rather than explicit, the job of figuring out which modules need to reload if a change is made to a particular module is quite a lot harder. Not sure if how Spring DM handles this - Impala certainly handles this easily and seemlessly.

    The explicit relationship is between packages - direct module to module dependencies are slightly frowned upon in OSGi, but I think it is much less of an issue when you are dealing with modules in the application space (as opposed to third party modules). This is a valuable distinction for practical purposes
    In terms of dependency relationships, OSGi gives you the best of both worlds. During development it gives you the flexibility of defining your dependencies at the package level. The advantage of this over module-level dependencies is that a consumer of a dependency is not coupled to the module supplying the dependency. For example, if a module is refactored and split into two modules, this change rarely impacts the consumers with package-level dependencies. Another advantage is that it's easy to drop in another supplier of a dependency and not have to change the consumer. At runtime, following dependency resolution, module-level dependencies are created, i.e. OSGi knows from which module a package is being consumed. A standard API (PackageAdmin) is provided to navigate this wiring, and inspect your module- (and package-) level dependencies. dm Server builds upon this to seamlessly handle updates to modules, propagating those updates to other modules and refreshing them as necessary based on the dependencies. This is also of great benefit at development time. Using the dm Server tools, as a developer makes changes, the affected modules are refreshed and updated on-the-fly, with no need to reload the entire application.
  13. Look very interesting. How do you handle the reloadability without the dreaded OutOfMemoryException due to the perm-gen-space being flooded with "un-gc-able" Classloaders? Did you consider offering a Mavenized Version?
  14. Daniel,
    Look very interesting.

    How do you handle the reloadability without the dreaded OutOfMemoryException due to the perm-gen-space being flooded with "un-gc-able" Classloaders?
    I'm no expert in this area, but memory management does not seem to be a problem, not least because Impala does not reload third party libraries (even if reloading all your application modules). The amount of perm gen space used by your application classes is miniscule compared to that used by third party libraries. I don't have precise figures, but if you have a relatively large app with say 2000 classes, that is still very small compared to the space taken by classes that are loaded from 3rd party libs if you have 50 jars in your classpath. For example, if I run the HibernateClinicTest as a main application from the Petclinic sample (see http://code.google.com/p/impala/wiki/SamplesPetclinic), I can type reload pretty much forever without memory usage going much above 3MB.
    Did you consider offering a Mavenized Version?
    Yes - but I'm not a Maven user so haven't done anything that will work out the box, yet. However, the default project structure conventions are not that far off those of the Maven defaults, and you can vary these both at the Impala and Maven ends. The only obvious thing that's different about the standard Impala build is that when building a war file it puts module jars into WEB-INF/modules rather than WEB-INF/lib. A tweaked Maven build would need to do that. Some out of the box support for Maven will definitely happen - not sure whether this will take place before 1.0 though.