AltRMI - Overview

A lot of beans coding is 'bean invokes method in bean which invokes method in bean'. In this case there are several places in the invocation stack where the container's logic is delegating between beans. Container could easily handle failing connections and take multiple actions: re-establish report, redirect, abend services or server. If there is a configurable policy for such events that may include the invoking of methods in, say, 'contingency' beans.

AltRMI has a pluggable architecture for re-establishing connections (and reporting timings etc). Whilst in the middle of an invocation, if the connection is lost, AltRMI can try to re-establish the connection and complete the method invocation normally. A delay would of course be encountered, but if administrators are watching the logs, then they can determine where failures are happening and what to do long term about it. Programmed policies (configured in the container) could be "try perpetually to reconnect", "try five times only, one a second", "fail immediately".

Referring to the various ways EJB teams handle RemoteException, in the thousands of places in a typical J2EE solution where it is thrown, different solutions are...

3.1. Declare throws RemoteException on every applicable method.

3.2. Have a standard catch block and pass the RemoteException to a standard handle method that does something with it.

3.3. Try the failing method call again, or n times.

Your EJB team has developed a huge amount of code for the business logic, and consequentually loads of code concerning RemoteException. Question how do they test the "connection failing" logic? Do they rip out cables while the machine is in use? No that does not yield good coverage. Do they have test cases and mock beans that throw RemoteException? Yes probably, but that is an artificial connection outage. However most teams do not test more than a single case, and are happy for the same RemoteException handler block to be used all over the place.

Webapps that use multiple beans (assuming a decent MVC separation or a framework like Velocity) already have a place where central exception handling is going on. With AltRMI, you can catch InvocationException where you feel is fit. EJB teams that choose to have throws RemoteException on all methods (percolating it up the stack) probably also choose to finally handle it centrally. Like so ...

public Template handleRequest(HttpServletRequest req, HttpServletResponse resp, Context ctx) {
    Template template = null;
    String templateName = null;
    HttpSession sess = req.getSession();
    sess.setAttribute(ERR_MSG_TAG, "all ok");
    try {
        try {
            // Process the command
            templateName = processRequest(req, resp, ctx);
            // Get the template
            template = getTemplate(templateName);
        } catch (InvocationException aie) {
            template = getTemplate("commfailure.vm");
        }
    } catch (ResourceNotFoundException rnfe) {
        // blah blah
    } catch (ParseErrorException pee) {
        // blah blah
    } catch (Exception e) {
        // blah blah
    }
    return template;
}

We have implemented an experimental callback structure. We have had to make the communication asynchronous to do this.

We curently use javac to compile stubs from source. It feels natuaral to use this technique as we think in terms of the Java the language. We know that the main interface to Javac is deprecated in JDK1.4 and feel we should move to some less static and more beanlike tool. An obvious choice would be BCEL and we are working on an implementation.

Some variations on the current transports to allow SSL connections.

The Excalibur Instrument package as part of Avalon.

An EJB replacement, current hosted at SourceForge

A functional test runner for Swing applications at SourceForge