InterProScan 5 is being developed using the Java programming language, together with a small number of 'best of breed' Java Enterprise technologies.
To simplify configuration and encourage code reuse, Spring (http://www.springsource.org/) is being used to support dependency injection. To support interoperability on disparate clusters and other platforms, Java Messaging Service (JMS, http://java.sun.com/products/jms/) is being employed. JMS provides a very simple and robust programming model for distributed applications. The individual components of the application can be run on the same, or separate machines with each component communicating with the others via a message broker. Messages can be very simple (a piece of text for example) or very complex (a serialized Java object model). JMS provides clear advantages, such as guaranteed message delivery and the ability to control whether messages are sent to a single destination or are broadcast to many destinations. This allows tasks to be designed to run on exactly one machine or tasks to be broadcast to multiple machines, the latter being useful for software management and control. In the case of running on a single machine, the messages are in the form of simple method calls, allowing for very efficient processing.
For data persistence to a relational database, we are using the Java Persistence API (JPA) with Hibernate (https://www.hibernate.org/). This choice allows InterProScan to be run on a variety of different database platforms. We will be supporting the use of Oracle, H2 and PostgreSQL, however it is likely that InterProScan will work successfully with other relational database management systems without modification. Together, the combination of Spring, JPA, Hibernate and JMS provide a solid technology platform upon which to develop InterProScan 5.
The figure below illustrates the JMS architecture design at the time of writing. From the perspective of the user, the two most important components in this architecture are the 'Master' and the 'Worker' (of which there may be many.) The Master is responsible for scheduling and tracking the tasks that make up analyses. These tasks are placed on a queue and are taken off the queue by individual Workers,which attempt to complete the task and report success or failure. The use of JMS guarantees that any individual step in an analysis is only performed once.
More documentation of JMS, with details of the I5 architecture can be found in this PowerPoint presentation