Saturday 15 March 2008

Dynamic Java Applications

I am investigating best ways of deploying new functionality to my running application at runtime, without having to restart my application.

OSGi framework is the way to go! (Feel free to read other options below, but OSGi seems to be the way to go - if you can)...

- OSGi framework - Have any of the framework implementations been used for any significant sized systems?

OSGi
OSGi Wikipedia

- OSGi implementations

Knopflerfish
Felix
Equinox OSGi
Embeded Server Equinox OSGi



OSGI, SCA and Spring

- Creating/recreating a Classloader. You can do this by hand with Java but I would prefer to not have to play with this. Weblogic 9/10 has a ChangeAwareClassLoader which could be of use, but in general, dropping / recreating the class loader is too heavy weight for my requirements, I just want to make available small units of change, maybe sometimes just a new class or a single code line change ie. to fix a bug. If I ditch the classloader, my calling threads will have to block until the application has sorted itself out.

- Hotswapping (Java Rebel or Weblogic 10.3 has FastSwap)

Much of the motivation behind hotswapping so far appears to be around speeding up development cycles. The hotswapping revolves around deploying your app as (ie. an exploded WAR file and compiling up source directly into the WEB-INF/classes dir where the new class will be picked up.

Weblogic 10 is offering FastSwap, but it only works if weblogic server is running in development mode.

Java Rebel will run in Weblogic 9 and 10 (plus a bunch of other app servers). Java Rebel is not recommended for production use at present though. JavaRebel dev team are aiming for Q4 2008 to getting out a beta version.

So hotswapping, for the time being, does not work reliably for production servers.

- Deploy new service on another server? - I could leverage a SOA principle 'discoverability' to discover a new service on the fly. However, I don't want the overhead of making a remote call (which this would have to be using this approach, unless I was running with SCA and OSGi for example), I still have SLA's on round trip times to support regardless, and making a remote call is not going to help.

- COTS support for adaptability?

IBM bought BowStreet in 2005 who offer an adaptable framework, although I cannot seem to find any info on the product.

- Academic research

There are a few papers written on adaptive middleware platforms. These appear to be largely academic excerices though.

- Java 7

JSR-292 talks about support for dynamic typed languages, specifically scripting languages, but does mention hotswapping as well. JSR-292 The main motivation behind this appears to be for adding support to call scriping languages.

- Beanshell could be used, in fact there are a number of different scripting options available, jython etc.. But I am not sure whether they allow change at runtime and whether they will compile on the fly or whether the scripts are all interpreted?

- Java Assist. There is a nice clean API available for bytecode instrumentation, which will the job, you could even point the classpath to point to a jar file sitting on a remote web server, (although I am sure security would have a thing to say about that!).. Once Java has loaded a class, it will not reoad it (unless running with JPDA switched on), but you can change the class at runtime so this would be fine for my purposes. I could even publish a JMX api with appropriate authentication to allow ops to remotely deploy new classes in a stream. But if OSGi really does the job, I am not sure it is worth rolling my own framework for this.

Source article summarising the current state of play

Weblogic FastAwap

Java Rebel

Friday 7 March 2008

Parallel Processing in Java EE 5

There are a number of options. It depends on your situation as to which is the right choice:

- Use JMS and message driven pojo's/beans

This is a strategy that is often used. You have a choice over whether you want to make the JMS persistent or not. If your JMS queue is not persistent and the server fails, you can lose messages and therefore some of your processing is not guaranteed to complete. So if you want guarantees that all the processing will be performed then you should make your queue persistent.

- Java 5 Concurrency API

The concurrency API is an addition in Java 5. It will allow you to execute work in parallel safely within a J2EE container, however, for typical Master/Worker pattern processing the API does expose you to more complexity than you need.

- Work Manager API - JSR 237

Weblogic has a work manager API (available in Weblogic 9). I like the API as it is clean and simple to use. If you are a J2EE purist however, and you want your J2EE to remain portable, then this is not for you.

- Java EE 6

Java EE 6 will include an evolved version of JSR 237. Doug Lea is working on this:

http://gee.cs.oswego.edu/dl/concurrencyee-interest/

- Use Terracotta (or Gigaspaces) and distribute your units of work across JVM's. Grid products like these two seem to be gaining rapidly in popularity. The technology is being used in Investment banks where systems are processing high volumes of transactions per second and the technology seems to back the trend of scaling by having more processors doing the work (dual core, quad core etc.). Terracotta works by using bytecode instrumentation (basically taking your java class and inserting some extra logic to allow synchronization etc. across multiple JVM's). Terracotta supports the Master/Worker pattern to allow you to distribute your units of work across multiple JVM's.

- Use business process management software (JBPM / WS-BPEL) which provide parallelism. Webloigc Integration for instance allows you to define a 'flow' which is some processing that can be performed in parallel.

- Parallel processing frameworks like JPPF, Gridgain, Hadoop.

- Spring batch

Links