Impala is a modular, dynamic productivity framework. The principal aim of Impala is to help developers extract every ounce of productivity out of the Spring development environment, while remaining true to the original Spring premise of simplicity and testability. The result is a much more productive Spring application development than you might think possible.
Here's how Impala lets you be more productive when working with Spring.
1. Virtually instantaneous build/deploy/test cycles
For typical Java applications, redeploying a change requires redeploying the whole application. Not with Impala. Only the affected parts of the application need to be deployed. This leads to virtually instantaneous build/deploy/test cycles, as the granularity of redeployment is typically very small relative to that of the application as a whole. You don't need to sit around for ages waiting for your whole application to load.
2. Automatic modification detection and redeployment
When you make a change to an Impala web application running in Eclipse, Impala can automatically pick up which parts of the application have changed, and redeploy those parts of your application without any user intervention. This removes the need for a manual step to perform this task. Impala gives you control over what resources are monitored for changes, how frequently resources are checked for modification, etc.
3. No explicit build step required
When writing typical Java web applications using Eclipse, in many projects there is an extra build step required to package your applications in order to deploy them. Not with Impala. Eclipse automatically compiles your classes for you incrementally in the background. The project structure conventions for Impala mean that this sufficient, and that no extra build steps are required during development.
Of course, you can do a regular WAR build when required for packaging for a production environment.
4. You can write your integration tests interactively
Writing Spring integration tests can be slow, particularly for monolithic single module applications. Impala allows you to write integration tests interactively. You can write and run integration tests using an interactive console within Eclipse. If making changes to your application between test runs, you simply redeploy the changed modules. If you're simply changing your test, you don't need to do anything special as changes to your test class will automatically be picked up on the fly. All of this leads to a much more rapid build/deploy/test cycle when writing integration tests than would be possible otherwise.
5. Suites including integration tests run super-efficiently
When running a suite of integration tests, modules needed by successive tests are loaded incrementally and remain available for subsequent tests run as part of the same suite. There is no need for continually starting and stop Spring application contexts, which can really slow down the execution of integration tests.
All of this makes test suite execution really fast, making Impala very friendly to use in environments where developers are expected (as they should be) to run the full project test suite before each commit to the version control system.
6. Setup is very simple
For a developer getting started on an existing project using Impala, it is really as simple as "check out and go" - simply check out the project files and starting writing and deploying the application within the IDE.
If you're starting a new project, this too is easy, as Impala provides a script which allows you to set up a simple, working application by executing a couple of commands.
7. Easy to use build and dependency management support if you need it
Impala works with Maven, but if you're not a fan of Maven, Impala also features a reusable build system which saves you having to write create your own build from scratch. Impala also gives you a simple way to pull third party library jars and source from Maven repositories, even if you aren't using Maven as your build system.
Monday, April 5, 2010
Friday, March 12, 2010
Impala 1.0 RC3 released
I am pleased to announce the release of Impala 1.0 RC3. Impala 1.0 RC3 is the final release candidate prior to the official 1.0 release. If no significant issues are raised against this released, it is envisaged that there will be virtually no changes in the subsequent 1.0 final release.
This release contains a number of enhancements:
For more information on this release see: http://code.google.com/p/impala/wiki/Release1_0RC3Announcement.
In the next couple of weeks, I plan to add more documentation on how to get Impala working nicely with Maven, and how to migrate an existing Spring-based project to use Impala.
Please don't hesitate to report any issues you may encounter, which you can do on the Impala issue tracker: http://code.google.com/p/impala/issues/list.
Phil Zoio
http://impala.googlecode.com
This release contains a number of enhancements:
- simplifications making it easier to migrate existing Spring-based projects to use Impala. It is now possible to run Impala as part of an existing virtually unchanged traditional Spring web application, which should significantly simplify the task of migrating an existing Spring application to use Impala.
- support for JSPs deployed within individual web modules. Prior to 1.0 RC3, JSPs need to be contained within the web application folder. With 1.0 RC3 it is now possible to completely modularise the web elements of a JSP-based web application.
- support load time weaving of aspects created using AspectJ.
- various other minor features and bug fixes.
For more information on this release see: http://code.google.com/p/impala/wiki/Release1_0RC3Announcement.
In the next couple of weeks, I plan to add more documentation on how to get Impala working nicely with Maven, and how to migrate an existing Spring-based project to use Impala.
Please don't hesitate to report any issues you may encounter, which you can do on the Impala issue tracker: http://code.google.com/p/impala/issues/list.
Phil Zoio
http://impala.googlecode.com
Wednesday, February 3, 2010
OSGi and Enterprise Java dynamic modularity after Spring dm Server
The key message to be taken from SpringSource's decision to hand last month their Spring OSGi projects (Spring DM and dm Server) to the Eclipse foundation is the following: that OSGi is not ready for adoption by the mainstream of enterprise Java. Reality has finally dawned!
According the announcement from Adrian Colyer, CTO of SpringSource:
This is a good thing. Firstly, the obsession with OSGi has distracted the community away from practical efforts which could work more comfortably within the existing enterprise Java model. Hopefully that obsession will go away, or at least be limited to those already converted to the OSGi way. Secondly, from a purely selfish, egotistical point of view, I feel vindicated. For years, I have been saying that OSGi is too complex for the Java mainstream. For years, I have been beaten over the head by a small group of hardcore OSGi evangelists who have persistently used the argument that if SpringSource is betting on OSGi, then it must be a good thing for everyone else, and that any alternative approach does not warrant any consideration. The bet has failed, and this argument has now fallen rather flat. If SpringSource, with all the credibility it has generated through the Spring Framework, all its intellectual and marketing muscle, and all the effort and expense it has incurred, cannot make work OSGi for mainstream enterprise Java, then no one else can.
But all of this is also points to a real missed opportunity. The fact remains that Spring users still need a modularity solution. They need a way of being able to take advantage of the best of what dynamic modularity has to offer - dynamically composable software with genuine decoupling between parts of the application, and rapid build/deploy/test cycles during development - without having to take on all the complexity of the full-blown OSGi approach. This need still exists, and will not go away. As Adrian suggests, this need will not be served by OSGi without some fundamental simplifications, something I could not imagine happening any time soon.
In the meantime, I have invited SpringSource to engage more with Impala. While they have flirted with the idea in the last few months, perhaps even seriously, they have backed away from it for now. In view of recent history, it is not that surprising. Imagine the uproar that would ensue among the OSGi zealots if SpringSource were to go down that route. It doesn't bear thinking about.
According the announcement from Adrian Colyer, CTO of SpringSource:
For a mainstream development team though, who just want to build an enterprise application as quickly as possible, and with as little hassle as possible, the costs currently associated with adopting enterprise OSGi can outweigh the short-term benefits. This situation needs to be addressed before enterprise OSGi can become the de-facto approach for mainstream enterprise application development.While SpringSource will no doubt continue to support OSGi, the extent to which it will continue to provide resources to the donated projects is far from certain. What is more clear, though, is it will no longer be wielding it's own considerable influence within the industry to shepherd its user base en masse towards OSGi.
This is a good thing. Firstly, the obsession with OSGi has distracted the community away from practical efforts which could work more comfortably within the existing enterprise Java model. Hopefully that obsession will go away, or at least be limited to those already converted to the OSGi way. Secondly, from a purely selfish, egotistical point of view, I feel vindicated. For years, I have been saying that OSGi is too complex for the Java mainstream. For years, I have been beaten over the head by a small group of hardcore OSGi evangelists who have persistently used the argument that if SpringSource is betting on OSGi, then it must be a good thing for everyone else, and that any alternative approach does not warrant any consideration. The bet has failed, and this argument has now fallen rather flat. If SpringSource, with all the credibility it has generated through the Spring Framework, all its intellectual and marketing muscle, and all the effort and expense it has incurred, cannot make work OSGi for mainstream enterprise Java, then no one else can.
But all of this is also points to a real missed opportunity. The fact remains that Spring users still need a modularity solution. They need a way of being able to take advantage of the best of what dynamic modularity has to offer - dynamically composable software with genuine decoupling between parts of the application, and rapid build/deploy/test cycles during development - without having to take on all the complexity of the full-blown OSGi approach. This need still exists, and will not go away. As Adrian suggests, this need will not be served by OSGi without some fundamental simplifications, something I could not imagine happening any time soon.
In the meantime, I have invited SpringSource to engage more with Impala. While they have flirted with the idea in the last few months, perhaps even seriously, they have backed away from it for now. In view of recent history, it is not that surprising. Imagine the uproar that would ensue among the OSGi zealots if SpringSource were to go down that route. It doesn't bear thinking about.
Monday, January 4, 2010
Impala 1.0 RC2 released
I am pleased to announce the release of Impala 1.0 RC2. With this release, support for Maven is introduced for the first time, along with various other enhancements, refactorings and bug fixes, including:
Cheers,
Phil Zoio
- simplifications to the default project structure, making it more intuitive and Maven-friendly
- a dynamic properties Spring namespace, making it easier to support properties which can be injected and dynamically updated without requiring module or application reloads.
- further refinements to the mechanisms for supporting multi-module web applications.
- initial support for Spring 3.0.
Cheers,
Phil Zoio
Thursday, November 26, 2009
Don't let OSGi put you off modularity
If you are interested in the ideas of modularity, there is quite a good chance you have looked at OSGi. But there is also quite a good chance that you have been put off by the extra development overhead required to set up and maintain OSGi-based applications.
If this is the case for you, my message is this: don't let fact that you are put off by OSGi put you off the ideas of modularity. Modularity is a bigger, more important and valuable idea than any particular technology. The ability to modularise an application can massively improve your application's ability to absorb complexity as new features and components are added, which in turn means that you remain much more productive as your application grows. It reduces the rate of entropy in your system, extending its potential life span, which of course if great for business.
This kind of modularity is one of the fundamental benefits of Impala. Also, because Impala's modules are dynamically reloadable, and you also get dynamic redeployment of small parts of your application, allowing you to greatly accelerate application development, maintain high levels of productivity, and retain high levels of code and functionality reuse as you application grows.
Impala does not solve all of the problems solved by OSGi. Notably, it does not provide versioning of third party libraries. However, it solves most of the important ones relevant for day to day development. Fundamentally, it allows you to modularise your application, without having to worry about micro-managing the dependencies of third party libraries in your application. Don't get me wrong - there are times when this capability can be important, especially for very large projects with large budgets and teams. But certainly not for every project, and probably not even for the typical one.
One way to think of choice is to look at the graph below.
The basic idea behind modularity is that the growth in complexity of your application slows as your application grows in size, compared to applications without modules. This applies both for Impala and OSGi-based applications. The difference is that because the barriers to entry are lower for Impala-based applications, the benefits kick in sooner, and accumulate for longer over the duration of the project, greatly reducing the overall cost of complexity over the lifetime of a project.
So, don't shy away from modularity just because OSGi looks complex. The benefits of modularity are too valuable, and an alternative like Impala make these attainable with fewer headaches.
If this is the case for you, my message is this: don't let fact that you are put off by OSGi put you off the ideas of modularity. Modularity is a bigger, more important and valuable idea than any particular technology. The ability to modularise an application can massively improve your application's ability to absorb complexity as new features and components are added, which in turn means that you remain much more productive as your application grows. It reduces the rate of entropy in your system, extending its potential life span, which of course if great for business.
This kind of modularity is one of the fundamental benefits of Impala. Also, because Impala's modules are dynamically reloadable, and you also get dynamic redeployment of small parts of your application, allowing you to greatly accelerate application development, maintain high levels of productivity, and retain high levels of code and functionality reuse as you application grows.
Impala does not solve all of the problems solved by OSGi. Notably, it does not provide versioning of third party libraries. However, it solves most of the important ones relevant for day to day development. Fundamentally, it allows you to modularise your application, without having to worry about micro-managing the dependencies of third party libraries in your application. Don't get me wrong - there are times when this capability can be important, especially for very large projects with large budgets and teams. But certainly not for every project, and probably not even for the typical one.
One way to think of choice is to look at the graph below.
The basic idea behind modularity is that the growth in complexity of your application slows as your application grows in size, compared to applications without modules. This applies both for Impala and OSGi-based applications. The difference is that because the barriers to entry are lower for Impala-based applications, the benefits kick in sooner, and accumulate for longer over the duration of the project, greatly reducing the overall cost of complexity over the lifetime of a project.
So, don't shy away from modularity just because OSGi looks complex. The benefits of modularity are too valuable, and an alternative like Impala make these attainable with fewer headaches.
Thursday, November 5, 2009
The granularity of change in dynamic Java web applications
When writing Java web applications, you are continually making changes to your application, and to be productive you need to be able to deploy and test these changes quickly. The kinds of changes you make are of all sorts: from changes to resources to changes to markup templates to changes in the way your application is wired to changes in the code itself.
The point of this article is that not all changes are equal, both in their frequency and in the difficulty in applying them dynamically in a running web application. Let's go through some examples, and how the changes might be applied in different types of frameworks:
1. Static resources
The simplest kinds of changes for any dynamic web framework to apply are those of static resources - images, JavaScript files, page templates etc. That's because these kinds of artifacts are inherently free of dependents.
2. Application configuration
Configuration consists of things such as settings for data sources, mail servers, etc, as well as switches in your application itself. While it is in general possible to reflect these kinds of changes dynamically, there is a cost. For example, if you are using database connection pooling, pointing to a different data source dynamically is a non-trivial exercise. Also, if your application checks particular application settings at source each time the affected functionality is used, then the system is more dynamic, but also less performant. By contrast, if you only load particular settings at startup (for example using wired in property placeholders in a Spring application context), the application is more efficient but is more likely to require reloads to reflect changes.
3. Application wiring
Application wiring is a configuration of sorts, but relates more to how parts of the system are composed or wired together to form the whole application. In a Spring application, the application wiring is simply your Spring configuration.
In general, changes to application wiring requires reloads. There are special cases where this doesn't apply. For example, you could introduce new Spring beans without reloading the application context. Changes to existing beans and their collaborators are harder to make.
4. Scripts
Scripts are programs in your application which by definition can be altered without having to reload your entire application or even significant parts of it. However, a scripting infrastructure needs to be in place to allow changes to scripts to be introduced, recognised and reflected in the system.
5. Application code
Application code in a Java application are your Java classes. Actually, considering this group as a single category is an oversimplification, especially in a dynamic module system, where making changes to core interfaces and domain classes will impose much greater requirements in terms of reloading than peripheral or implementation classes with fewer dependants.
6. Third party libraries
The libraries in your application are the jar files containing all the third party dependencies.
The challenge for frameworks
The key productivity challenge with a dynamic application framework is to make it as easy as possible to make the kinds of changes you need to make, while at the same time keeping the framework as lightweight as possible. In the next section I take a look a number of technology stacks, what they do to make different types of reloading possible, what they get wrong, and what they get right.
A. Traditional Java web application
A traditional Java web application might consist, for example, of a Struts or JSF front end, Hibernate back end, all wired together using Spring.
The traditional Java web application has no problem reloading static resources without having to reload any other part of the application. Most web containers are able to reload an entire web application, including third party libraries, Java code, application wiring etc.
The problem is they are not much good at reloading any finer grained changes. Any changes you make to your application wiring or code will normally require a full application reload.
B. Scripted applications
Scripted applications are based on scripting languages such as Groovy (Grails) and JRuby (Rails). As well as explicitly providing support for reloading capabilities, these frameworks rely on the fact that all application functionality is in scripts rather than in compiled Java code, making fine grained reloading of parts of the application possible. The downside (if you think of it this way) is that you have to work with scripted code without any of the type safety checking of a statically typed language such as Java.
C. OSGi applications
OSGi applications offer a fairly comprehensive solution to the reloading problem. All artifacts within the application, from resources to application code to libraries are contained within modules which are treated in a more or less uniform manner by the OSGi container. This is a strength, but it is also a weakness. The strength is that it does allow third party libraries to be reloaded in a fine grained way. The weakness is that in your high level view of the application, OSGi doesn't really allow you to easily distinguish between the parts of your application which should be easy to reload - e.g. resources - and the parts which are harder to reload, but are changed much less frequently during the lifetime of the application (third party libraries).
What about Impala?
Impala tries to find the right balance in the strengths of the various approaches. Resource reloading works as with traditional Java applications - nothing special needs to take place. Impala includes mechanisms which make it easier to change configurations dynamically without requiring any module reloading. For changing static configuration and application wiring, Impala allows you to reload parts of your application at exactly the right granularity. If only a single module is affected, then only that module needs to be reloaded. If the change affects core interfaces, then the reload will automatically ripple through to the right dependent modules.
Impala even allows you to dynamically change the structure of modules within the application. Unlike OSGi, it doesn't support reloading of third party libraries. For this, an entire application reload is required. However, Impala's approach does your application modules in central focus, which is important as these are the normally parts of your application which change most frequently.
The point of this article is that not all changes are equal, both in their frequency and in the difficulty in applying them dynamically in a running web application. Let's go through some examples, and how the changes might be applied in different types of frameworks:
1. Static resources
The simplest kinds of changes for any dynamic web framework to apply are those of static resources - images, JavaScript files, page templates etc. That's because these kinds of artifacts are inherently free of dependents.
2. Application configuration
Configuration consists of things such as settings for data sources, mail servers, etc, as well as switches in your application itself. While it is in general possible to reflect these kinds of changes dynamically, there is a cost. For example, if you are using database connection pooling, pointing to a different data source dynamically is a non-trivial exercise. Also, if your application checks particular application settings at source each time the affected functionality is used, then the system is more dynamic, but also less performant. By contrast, if you only load particular settings at startup (for example using wired in property placeholders in a Spring application context), the application is more efficient but is more likely to require reloads to reflect changes.
3. Application wiring
Application wiring is a configuration of sorts, but relates more to how parts of the system are composed or wired together to form the whole application. In a Spring application, the application wiring is simply your Spring configuration.
In general, changes to application wiring requires reloads. There are special cases where this doesn't apply. For example, you could introduce new Spring beans without reloading the application context. Changes to existing beans and their collaborators are harder to make.
4. Scripts
Scripts are programs in your application which by definition can be altered without having to reload your entire application or even significant parts of it. However, a scripting infrastructure needs to be in place to allow changes to scripts to be introduced, recognised and reflected in the system.
5. Application code
Application code in a Java application are your Java classes. Actually, considering this group as a single category is an oversimplification, especially in a dynamic module system, where making changes to core interfaces and domain classes will impose much greater requirements in terms of reloading than peripheral or implementation classes with fewer dependants.
6. Third party libraries
The libraries in your application are the jar files containing all the third party dependencies.
The challenge for frameworks
The key productivity challenge with a dynamic application framework is to make it as easy as possible to make the kinds of changes you need to make, while at the same time keeping the framework as lightweight as possible. In the next section I take a look a number of technology stacks, what they do to make different types of reloading possible, what they get wrong, and what they get right.
A. Traditional Java web application
A traditional Java web application might consist, for example, of a Struts or JSF front end, Hibernate back end, all wired together using Spring.
The traditional Java web application has no problem reloading static resources without having to reload any other part of the application. Most web containers are able to reload an entire web application, including third party libraries, Java code, application wiring etc.
The problem is they are not much good at reloading any finer grained changes. Any changes you make to your application wiring or code will normally require a full application reload.
B. Scripted applications
Scripted applications are based on scripting languages such as Groovy (Grails) and JRuby (Rails). As well as explicitly providing support for reloading capabilities, these frameworks rely on the fact that all application functionality is in scripts rather than in compiled Java code, making fine grained reloading of parts of the application possible. The downside (if you think of it this way) is that you have to work with scripted code without any of the type safety checking of a statically typed language such as Java.
C. OSGi applications
OSGi applications offer a fairly comprehensive solution to the reloading problem. All artifacts within the application, from resources to application code to libraries are contained within modules which are treated in a more or less uniform manner by the OSGi container. This is a strength, but it is also a weakness. The strength is that it does allow third party libraries to be reloaded in a fine grained way. The weakness is that in your high level view of the application, OSGi doesn't really allow you to easily distinguish between the parts of your application which should be easy to reload - e.g. resources - and the parts which are harder to reload, but are changed much less frequently during the lifetime of the application (third party libraries).
What about Impala?
Impala tries to find the right balance in the strengths of the various approaches. Resource reloading works as with traditional Java applications - nothing special needs to take place. Impala includes mechanisms which make it easier to change configurations dynamically without requiring any module reloading. For changing static configuration and application wiring, Impala allows you to reload parts of your application at exactly the right granularity. If only a single module is affected, then only that module needs to be reloaded. If the change affects core interfaces, then the reload will automatically ripple through to the right dependent modules.
Impala even allows you to dynamically change the structure of modules within the application. Unlike OSGi, it doesn't support reloading of third party libraries. For this, an entire application reload is required. However, Impala's approach does your application modules in central focus, which is important as these are the normally parts of your application which change most frequently.
Sunday, November 1, 2009
Slides for Impala talk at the Server Side Europe in Prague
I'm pleased to say that my talk at The Server Side Java Symposium in Prague went well and was apparently well received. There definitely is a growing interest in the ideas of modularity and how the benefits of modularity can be achieved in practice.
I've posted a copy of my slides for the talk here in PDF format. The document contains the slides that I presented, as well as quite a few which were held in reserve but weren't actually presented during the talk.
I've posted a copy of my slides for the talk here in PDF format. The document contains the slides that I presented, as well as quite a few which were held in reserve but weren't actually presented during the talk.
Subscribe to:
Posts (Atom)