What is {:tunguska}?

Tunguska was either a comet or space ship. It is hard to say after 90 years... The tunguska project aims to bridge Java EE 6 world with different comet implementations like grizzly

The idea is simple: Java EE apps (the inner space) are sending events to e.g. a JMS topic which is received and distributed by the comet "edge" servers (the outer space). The project was inspired by UMS. Why the name? The first implementation of tunguska is based on comet. Later we will evaluate the use of Servlet 3.0 (and indirectly comet) or something else. Exactly like tunguska. It was a comet, or something else :-).

Use Cases

1. Event broadcasting over HTTP - with plain GET
2. JMS / HTTP bridge. Web clients (Java FX, Flash, AJAX) can listen to a JMS destination, without knowing about it.

Essential Architecture

The tunguska core consists of two parts:

1. Outer space: a highly scalable, edge to which various HTTP clients (subscriber) can connect and listen to events.
2. Inner space: accepts events from the business logic, which will be broadcaster through the outer space.

Tunguska can be used in local and remote setup. In the remote case multiple edge servers are listen to a JMS topic and wait for a message from the business logic. Only a single topic (jms/tunguska) is needed for that purpose. In the local configuration the Java EE application and the edge server are executed in the same JVM. JMS, as well as HTTP-call can be used for this purpose. The only coupling between the application and the tunguska "framework" is the name of the topic and a dedicated string property in the JMS text message.

The Feel Of Tunguska

A message can be send directly with the following interface:

public interface EventFire {

     public void send(String toChannel,String message);
}

It is actually a local EJB 3.1 interface with two implementations:

1. JMSEventFire: distributes the event to all edge servers using a topic
2. HttpEventFire: sends a message directly to a single edge server using Http in an @javax.ejb.Asynchronous, fire and forget style.

Both implementations are EJB 3.1 no-interface-view beans - you can inject them directly to your Service or ServiceFacade. This API is part of the tunguska-client (maven) project. For test purposes both implementations are exposed via @WebService as well, so you can interact with them directly.

Why EJB 3? Because it is the simplest possible solution.

The HTTP client can listen to the channel using the following URL: http://localhost:8080/tunguska/sub/channelName The channel name in the URL and the method parameter have to correspond. The payload can be any String you like - in most cases it will be probably a JSON string.

@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public class MessageService {
    @PersistenceContext
    EntityManager em;

    @EJB
    JMSEventFire eventFire;

    public void save(HelloMessage hm){
        this.em.persist(hm);
        //posts the contents of toString as payload to the "message" channel.
        this.eventFire.send("message", hm.toString());
    }

    public List<HelloMessage> getMessages(){
        return this.em.createNamedQuery(HelloMessage.findAll).getResultList();
    }
}

The message will be pushed (= the lock will be released) to the following URL: http://localhost:8080/tunguska/sub/message

The JMSEventFire service is a Stateless session bean, which is transactional per default. The transaction started in the MessageService boundary will be transparently propagated to the JMSEventFire service. Either the HelloMessage entity will be persisted and the message sent, or the whole transaction rolled back. This is only true for the JMSEventFire. HttpEventFire is not transactional. You will find the whole project (messenger) in the repo. It was originally developed as an EJB 3.1 sample for javaee-patterns. See also detailed description of this JSF 2, EJB 3.1, JPA 2.0 component in this post.

Scalability

The 0.1 version (tag observation), was tested with 1500 clients. The tests were performed with Glassfish v3b70 - no additional tuning was required. The only limitation was the load generator. JMeter had to start 1500 threads on one machine...

There were no additional threads need to handle the load. Glassfish v3 needed about 230 MB heap to handle the load.

System Requirements

Tunguska was built with maven and developed with NetBeans 6.8. Tunguska requires Glassfish v3 and grizzly. In later releases it might be ported to Servlet 3.0 API and be then entirely application server independent.