12:37:22 pm on April 16, 2011 |

So you’re building your typical database-driven web application. You turn to your story board and see that your business analyst has raised a story to allow your testers to stub some of the services you call. It’s a reasonable request so off you go, writing your stub code.

But how will your tester modify your stub settings? They need some interface to hook into the application and pass in stub test data so they can perform their testing. You figure ‘I’ve already got a web interface set-up, I’ll leverage that and create a secure web console for my application’.

Right? Well, I think you might be wrong and you should use JMX instead. Here are three reasons why:

Security: Most web application frameworks start with the assumption that your web resources are publicly available and you have to put security in after the fact. By default JMX usually has to be explicitly switched on. What is more, JMX is served off non-standard ports that won’t be open on your firewall unless you explicitly request it. Less code: JMX managed beans are lightweight and don’t have the overhead of controllers or front-ends. Separate security model: Inevitably, the security requirements for your web application will be different to those for your console, so using JMX makes sense because it has a completely separate security model.

In reality, the main problems stem from mixing user-facing front-ends with internal web console interfaces. For example, you might sensibly block all access to your test console on production. However, you may find yourself forced to work around production configuration copied on your staging configuration.

Of course, there are disadvantages to JMX over web consoles. For example, JMX requires specialist software to be installed and users need to be trained with this software, whereas a web console can be operated with a common web browser. What is more, most test frameworks like Selenium are designed to work with web interfaces automatically.