These are the reasons why I make this claim.
When Spring was introduced 2004-2005, it brought a big shift in the frontier of Java enterprise software development, offering solutions to many of the challenges faced by developers in a way which other technologies before, notably EJB, had conspicuously failed. Spring is still very much a valid technology in today's environment, but the frontiers have shifted.
One shift is in the increasing recognition of the shortcomings of the Java language itself, and the need for an eventual replacement as the premier JVM language. Another shift is the increasing awareness of the need for modularity in application development. My view is that without the backing of a truly modular framework, it is almost impossible to build a large enterprise application which does not end up becoming unwieldy, difficult to manage, and slow to build and deploy. This more than anything else leads to the perception that Java is unproductive to work with.
1. Impala gives your project a massive productivity boost
The reason for this stems from Impala's dynamic reloading capability. When you make changes to an Impala application, you only need to reload the affected modules and their dependents. Indeed, you can set Impala up so that these modules will be reloaded automatically. This allows code/deploy/test cycles to be reduced to an absolute minimum. In some of the next few points we give some further examples of how Impala improves your productivity.
2. With Impala you can make your applications truly modular
Modularity is about removing all unnecessary coupling between parts of your application, and is essential for building large applications which don't grow exponentially in complexity as they grow linearly in size.
With Impala and other dynamic modularity frameworks, modularity is achieved through a separation of interface and implementation which is just not possible in traditional Java applications. With Impala, modularity is enforced at the class loader level.
Impala makes it simple to deploy multiple flavours of the same application simply by choosing which modules to deploy. Impala gives you mechanisms for configuring individual modules, so that you can support different deployment options in a clean and simple way.
3. Impala works "out of the box"
I can't resist using this term because it features often in Rod Johnson's books. If you try any of the Impala examples, you will notice that all you typically need to do is to check out the code, then run it in your IDE. (If a database is involved, you may need a little extra setup there.) There is no need for any extra build steps, installation of third party environments, containers, etc. It's all self-contained.
4. With Impala, Spring integration testing is a doddle
Impala makes it really simple to write Spring integration tests. Gone is the need for convoluted test application context definitions such as
new ClasspathApplicationContext(new String[] {
"config-context.xml",
"dao-context.xml",
"config-context.xml",
"some-context-which-you-you-need-for-your-test.xml",
"some-context-which-you-you-dont-need-for-your-test.xml",
"another-context-which-you-you-dont-need-for-your-test.xml",
}
With Impala, all you need to do in a typical integration test is to specify which modules you want to include (dependent modules get included automatically), and use Impala's API to access beans either from the root or one of the module application contexts. For example:
public class InProjectEntryDAOTest extends BaseDataTest {
public static void main(String[] args) {
InteractiveTestRunner.run(InProjectEntryDAOTest.class);
}
public void testDAO() {
//get the entryDAO bean from the root module
EntryDAO dao = Impala.getBean("entryDAO", EntryDAO.class);
... test methods
}
public RootModuleDefinition getModuleDefinition() {
return new TestDefinitionSource("example-dao", "example-hibernate").getModuleDefinition();
}
}
Tests work equally well whether you are running them interactively (without the need to reload the entire application or even any part of it between successive test runs), or whether you are running it as part of a suite (in which case the application modules are incrementally loaded as required). In both cases, running integration tests is very efficient, allowing you to be much more productive while still practicing TDD.
5. With Impala you can write truly multi-module web applications
A big barrier to truly modular web applications is the reliance on web.xml, because changes to web.xml require a full application reload. The forthcoming release of Impala allows you to define servlets and filters within the modules themselves, with their life cycle tied to that of the containing module. It also allows you to map requests with arbitrary URL path prefixes to individual modules. Once within a module, requests can be mapped to filters and servlets based on file extension.
These capabilities allow you to create a web application tier which is truly modular: you can package all of the filters, servlets, controllers, templates, images, Java script files required to service URLs with a particular prefix into the module jar itself. Indeed, you can even reduce your web.xml filter and servlet declarations to the following:
<filter>
<filter-name>web</filter-name>
<filter-class>org.impalaframework.web.spring.integration.ModuleProxyFilter</filter-class>
<init-param>
<param-name>modulePrefix</param-name>
<param-value>urlmapping-web</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</filter>
<filter-mapping>
<filter-name>web</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
See the web.xml from the URL mapping sample for the full example.
6. Impala does not reinvent the Spring programming model
Spring has been a huge success for a good reason - because it offers a much simpler programming model than was offered before. Spring offers a great solution for dependency injection as well as for making otherwise key technologies - transactions, AOP, JMX, remoting, etc - accessible or very simple to use.
Impala does not reinvent the Spring programming module - within modules you will recognise all the artifacts familiar to Spring applications: collaborators wired together via dependency injection, configured using XML configuration files, annotations, etc. The big difference is that Impala gives you a well defined way for expressing relationships between modules within the application, allowing for simpler implementations of - and clear boundaries between - the constituent parts of a bigger application.
7. With Impala you can forget about the build (most of the time)
Impala allows you to develop your applications in a vanilla Eclipse environment without having to invoke any build scripts or do any extra environent setup to run your application. This makes getting new developers started on projects extremely simple. Simply check out and go.
Of course, you will need to build for production environment. Impala includes an ANT-based build system which allows you to build either a WAR file or a Jetty-based standalone web application, which you simply unzip in the target environment and run.
8. Impala fundamentally simpler to use than OSGi-based alternatives
OSGi is a powerful technology, a very complete modularity solution. It is also quite a complex technology, requiring a non-trivial investment in time and energy to understand it, both conceptually and in its effect on the application environment.
From a practical point of view, applying OSGi to enterprise environments is far from trivial, and involves solving a number of challenging technical problems. For example, many common Java libraries do not ship out the box in an OSGi-friendly way. Also, the use of the thread context class loader in many libraries poses a problem for OSGi-based applications.
Solutions to these problems do exist, but they typically involve creating a more complex, more restrictive, or less familiar environment than required for traditional Java enterprise apps. Nothing comes for free. The question is whether it is worth paying the price.
9. Impala poses no extra requirements for third party library management
In terms of the management of third party libraries, Impala is no different from traditional Java applications. Third party library jars are bundled in the lib directory of a WAR file. If you change a third party library, you will need to reload your application to apply these changes.
Where Impala differs from traditional applications is the way that you manage application modules. In a WAR file, these will be bundled in a the modules directory under /WEB-INF.
The relationship between modules can be hierarchical, or even in the form of a graph of dependencies. The important point is that modularity is applied to your application's code. That is in my opinion the part which needs it most because that's the part of your application which changes frequently. If you are not sure whether you agree with this point, ask yourself the questions:
- How often would you actually want to run multiple versions of the same third party library in the same application?
- If you made changes to third party libraries in your application, how often would you want to apply these without restarting the application
Some may regard the traditional approach to third party libraries as broken - but it is also very convenient when it works!
10. Impala is a practical solution for practical problems
Impala did not evolve from an ivory tower view of how Java enteprise applications are supposed to be written. Instead, it was borne around two years ago out of the need to solve practical real world problems which were harming the productivity and maintainability of a large Java project. The most notable of these were the lack of any first class modularity in traditional Spring-based application development, and the slow build/deploy/test cycles arising from unwieldy integration tests.
Impala has been designed and refactored to be simple and intuitive to work with, once you've grasped the basic concepts. It allows you to get the benefits of a modular approach to application development without many of the costs, and without being swamped by technobabble.
What are you waiting for?
Working with Impala will give you the programmer's equivalent of a "spring in your step" - you will be amazed by how easily it is to get things done.
So give it a go. Try one of the samples, read the tutorial, or kick start your own application, and let me know how you get on.
No comments:
Post a Comment