Making Java applications more easy to re-use with embedded scripting
Lets admit it - writing an application in Java takes a lot more code lines and configuration than in other languages like Python or Ruby. However, Java has been around for many years and it will stay around for many years simply because of the number of applications in various enterprises built around Java. However, of late with the new kid’s on the block like Rails, Django and all these rapid development paradigms that are out there, poor Java programmers do feel left out. Of course we have Groovy that is borne out of Java and a couple of such options, we do have to stick to Java and the different Java frameworks like Spring, Hibernate etc for our day jobs.
There are different ways in which you can build a Java application correctly using the age old known best practices and get the rapid development and agility that you want. In this blog I will describe a probably known but less frequently used way to add more agility to your Java applications. This could be used for web or non-web Java applications alike.
So whats the silver bullet?
Its not really a silver bullet, and it has been around for a while - its the JSR-223 Java Scripting extension. This part of Java, available under the javax.script package enables developers to embed a scripting language of their choice in the Java application and let it execute scripts. These scripts can be user entered or maybe loaded from a file or socket.
The earliest I remember seeing something like this was in the JMS monitoring tool Hermes JMS. We used that to monitor and manage our TIBCO JMS servers and this provided a small embedded Jython console that let us interact with the application. I probably saw another application in one of old companies using something like this add interactivity and evalute user entered expressions. But that’s it - nothing major.
How will we use this to make applications more easy to re-use?
Before we get into how, lets spend some time revising some of the enterprise Java application use cases and see how we can apply this there. Being a messaging and connectivity guy, one of the most common problems that I have solved is getting a message from one application to the other, or from the messaging layer to the application and vice versa. This always involves only the following steps:
- Connect to the source system
- Get some data, parse and translate it
- Push it to the target system.
Thinking again with a more clear mind
- Write a new class to process data from known connections
- Edit spring configuration to add the new class as a bean, and reference it
- Re-build and deploy.
So how do we bite the bullet?
- Your assignment is to connect to a database and execute a query on some data and publish that to your messaging layer.
- In future, you will connect to this database again and again and will run more queries and publish the data.
- Because the data is different and to help performance, each of these queries will be run as a different batch or polling application.
- It will be the same type of database - Sybase, MySQL etc and same messaging layer
- Write the database connectivity and the messaging connectivity code
- When integrating these two, create an instance of the Scriptable class and pass it two binding variables - database connection and messaging connection.
- Write a small script in Python or Groovy or whatever you prefer and in that script write the logic to execute the query and process results.
- You might as well hard code the query in there.
- You can pull and push data using the connection variables.
- Write the main code in such a way that it takes the script from somewhere and passes to the engine with the two connection variables.
- When creating the application configuration in XML, put this script in the XML and have the application load it and execute it.
- If not using XML config, put the script in a file and pass it as a parameter - whatever suits your deployment.
- When the application is run, it will take the script and do the magic.
- All this takes about a day or two to test thoroughly.
- Job done.
Does this really work or is it performance killer?