The current version is a first Alpha of a 0.5 and there’s still room for improvement, so ideas are more than welcome. In addition, the UI itself is not as “Rich” as “RIA” and not a major change in layout since the previous version. This is mostly because I didn’t want to invest too much effort in this direction just yet (and as we all know, professional UI is always a bitch in terms of effort).

I’ve managed to put up a demo .war file that can be dropped in a Tomcat or anything like it. It uses the HSQLDB engine so no additional setups will be required (except for what’s already here). Username and password for the demo .war are admin/admin.

I’m also trying to get some decent VPS hosting for a Live-Demo so it can get more exposure. I’ve evaluated some options so it should be sorted in a few weeks.

Anyways, any ideas or any kind of help is more than welcome. So if you like it, find it useful or want to contribute, just let me know.

We also had a chance to take a look at Eclipse RAP in another presentation by Gabriel Ciuloaica – “From Eclipse RCP to RAP”.

Many thanks to Gabi Pop who always takes care of planning and organizing the TJUG meetings.

• First draft of questionnaire life-cycle management – The operations on a questionnaire will no be in strict correlation with it’s state: In Work, Published, Closed (more will probably be added later). The application will allow certain actions only while the questionnaire is in a certain status. At the moment is very rough, but hopefully I’ll have the time to elaborate it more in a 0.4 (also hoping to get a decent documentation for it).
• Complete new layout – The Administrator Console layout has been completely reworked (screenshots here). I am pretty ok with this and I don’t expect to allocate any more effort in this direction any time soon.
• New sample data – Both the MySQL and the HSQL demo script now contain enough data with all stages of the application so anyone can easily have a look at all the workflow.
• Demo movies – I wanted to start providing some demo movies that should be bundled in the (future) documentation. For the moment I only have two, but I plan to create more. It is not rocket science to make such movies with Ubuntu, but it’s pretty time consuming if you want to get it right.

There is still a lot of effort to be put in Quizine and mostly in overall testing and getting a feeling about usability and overall workflow. So, if you are interested in helping out with any part of the application/documentation/etc, or just have some suggestions, you are more than welcome to contact me at .

In addition, the application demo can now be downloaded with a bundled Tomcat. This package contains the demo .war file and can be downloaded as a .zip or as a .tar.gz (see Download section from the project page).

I hope I’ll find some time to write some decent documentation about it, including both setup and user guide.

Since this .war is for demo purposes only, it uses an HSQL database running in-process and memory-only. As a consequence, all changes that you make will only be consistent until you restart the container, at which point they will be reset.

You can also check the project’s main page (http://code.google.com/p/quizine) where you can find additional details about getting the application, building it, running, etc.

Although it is in only a first draft, I am hoping to find some time to finalize it and create a comprehensive and robust quiz tool. For this, any suggestions or contributions are highly appreciated at this stage, as the concept is still in the process of being defined.

For now we will take a look at how Spring handles RMI while peeking into the code of a small demo application. Our example contains a simple delivery service exposed through a DeliveryServiceIntf interface that has two methods for handling Delivery objects. Below is some of the code for these objects.

public class Delivery implements Serializable {

    private String requesterName;
    private Date deliveryDate;

    public Delivery(String requesterName, Date deliveryDate) {
        this.requesterName = requesterName;
        this.deliveryDate = deliveryDate;
    }
    ...
}

public interface DeliveryServiceIntf {

    void newDelivery(Delivery delivery);

    List getDeliveries();

}

As you can see, the service interface does not need to extend the java.rmi.Remote in order to be used as an RMI service. Also, it’s remotely accessible methods don’t need to throw java.rmi.RemoteException. This is a Spring enhancement that applies to all it’s remoting solutions, not just to RMI. But this is no reason to get scared, because Spring will manage the invocation failure in it’s own fashion by throwing a org.springframework.remoting.RemoteAccessException. This is an unchecked exception so the client can decide if it wants to catch and handle this exception or just ignore it when it’s occurrence it’s considered fatal. This is however Spring’s recommended approach, but you can also expose traditional RMI implementations with Spring. Actually, this is an important issue that you should consider and analyze when remoting with Spring. While both traditional and Spring-managed RMI clients can access a traditional RMI server implementation exported through Spring, only a Spring client will be able to access a Spring exported RMI service that uses a POJO-based model.
Getting back to our example, we have below the implementation of our service which I tried to keep as simple as possible:

public class DeliveryServiceImpl implements DeliveryServiceIntf {

    private List deliveries = new ArrayList();

    public void newDelivery(Delivery delivery) {
        deliveries.add(delivery);
    }

    public List getDeliveries() {
        return deliveries;
    }
}

After we have everything implemented on the server side, we need to configure Spring to export the service through RMI. The following Spring configuration snippet does just that.

    <bean id="deliveryService" class="com.test.rmi.server.DeliveryServiceImpl">        
    </bean>

    <bean class="org.springframework.remoting.rmi.RmiServiceExporter">
        <property name="serviceName" value="delivery-service"/>
        <property name="service" ref="deliveryService"/>
        <property name="serviceInterface" value="com.test.rmi.common.DeliveryServiceIntf"/>
        <property name="registryPort" value="1234"/>
    </bean>

This is the point where we can choose which one of Spring’s remoting solutions we want to adopt. In our case we will use org.springframework.remoting.rmi.RmiServiceExporter which will also manage the RMI registry for us. The serviceName and registryPort properties are RMI specific settings that will constitute the information the client side needs to access our service. The URL for the service in this case will look something like rmi://hostname:1234/delivery-service. The serviceInterface property indicates the POJO whose methods will be the subject of RMI invoking and the service property references a bean implementing the business logic of the service.
At this point, having all up-and-running on the server side requires a small amount of effort and it only consists of classic Spring context initialization.

public class RmiServerTest {

    public static void main(String[] args) {
        ApplicationContext ctx = new ClassPathXmlApplicationContext("com/test/rmi/server/rmi-server-context.xml");        
    }
}

Now let’s see how does it work on the client side and how should we proceed to access the remote service. Here is actually a little bit easier because everything relies on the Spring bean configuration file, as seen below, while the rest of the code is pretty straightforward.

    <bean id="deliveryService" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
        <property name="serviceUrl" value="rmi://localhost:1234/delivery-service"/>
        <property name="serviceInterface" value="com.test.rmi.common.DeliveryServiceIntf"/>
    </bean>

As you can see, we just need to define the deliveryService bean of class org.springframework.remoting.rmi.RmiProxyFactoryBean. This will indicate Spring that the deliveryService bean will actually be a proxy accessing the remote service at the URL rmi://localhost:1234/delivery-service, and that the business logic of the service will be used by the client through the methods of the DeliveryServiceIntf interface.
Accessing this bean will create a proxy that we can cast to the DeliveryServiceIntf interface and that will dispatch all the calls on this interface to the RMI service. Below is the pretty self-explanatory client-side code.

public class RmiClientTest {

    public static void main(String[] args) {
        ApplicationContext ctx = new ClassPathXmlApplicationContext("com/test/rmi/client/rmi-client-context.xml");
        DeliveryServiceIntf deliveryService = (DeliveryServiceIntf) ctx.getBean("deliveryService");
        deliveryService.newDelivery(new Delivery("John Doe", new Date()));
        ...
    }
}

Therefore, the client will not be aware of the fact that the service is running remote and even less about the fact that its method calls are marshaled through RMI. The Spring bean configuration file takes care of these details, so the client code will not be affected if we change the remoting strategy or even if we choose to run the service in-process.

The code for this demo can be found here. The first step is to run ant run-server in order to launch the RMI server and afterwards you need to run ant run-client from another console to start up the RMI client.
Hope this post can give you a basic feeling about Spring’s RMI support. Please feel free to comment on any aspect of this article.