The JMS Application Container Swiftlet provides containers to run JMS applications as a component within the virtual machine of a SwiftMQ router.
These kinds of JMS applications are not different from any other JMS application. They do not have to implement any SwiftMQ interfaces nor do they have to have any special kind of code structure. The only exceptions are an optinal method to stop the application by the router and to avoid System.exit() calls. If a shutdown method is defined, this method is discovered by Java reflection. So there is no proprietary code and therefore no vendor lock-in involved.
A JMS application running within a container typically uses JNDI with a JNDI provider URL like
smqp://intravm/timeout=1000
which connects to the router via an intra-VM JMS connection. Once a JNDI InitialContext is created, it obtaines an intra-VM connection factory from JNDI:
TopicConnectionFactory tcf = (TopicConnectionFactory)ctx.lookup("IVMTopicConnectionFactory");
All connections created from this connection factory connect to the router also via an intra-VM connection.
The start of a JMS application takes place by calling its "main" method. The arguments to the "main" method can be configured. The "main" method may block, e.g. due to a loop, or it may return immediately, e.g. if only a message listener has been registered. An attribute "main-return-is-stop" can be specified which states whether a return from the main method should mark the application as stopped. The default is false. In that case, the only way to stop is to call the "shutdown" method.
A running JMS application is automatically stopped during the router's shutdown sequence. To stop it manually, a shutdown method has to be defined:
Example:
public static void stopMyApp()
{
try
{
connection.close();
} catch (JMSException e)
{
}
}
The method has to be "public static" with a return type "void". The method name can be configured and is discovered by Java reflection. Within the shutdown method, all resources should be closed and all threads, started from the JMS application, should terminate.
If the application stops by returning from its "main" method, the container's attribute "main-return-is-stop" must be set to true.
A JMS application runs inside the virtual machine of the router, therefore you should avoid to call System.exit(). For example, instead of this kind of error handling within the "main" method:
public static void main(String[] args)
{
if (args.length < 4)
{
System.err.println("<smqp-url> <tcf> <topic> <nmsgs>");
System.exit(-1);
}
...
}
you should use this:
public static void main(String[] args)
{
if (args.length < 4)
{
System.err.println("<smqp-url> <tcf> <topic> <nmsgs>");
return;
}
...
}
The JMS Application Container Swiftlet provides 2 different container types: Static containers and hot deploy containers.
A static container is configurable via SwiftMQ Explorer/CLI and the router's configuration file. It contains definitions of the class name, class path, system properties, shutdown method, etc. If a shutdown method is defined, the JMS application can be started and stopped by SwiftMQ Explorer/CLI. If not, the application is typically started during the router's startup and stopped during its shutdown.
A hot deploy container listens on a deploy space of the Deploy Swiftlet. Deploying a JMS application takes place by copying a deployment descriptor and at least 1 jar file into the deploy space. The JMS application is automatically started during deployment and stopped during undeployment. A shutdown method is mandatory for hot deployable JMS applications. The deployment descriptor contains the definitions of the JMS application (class name, system properties etc). Hot deployment enables you to upgrade a JMS application automatically without stopping the router, e.g. deploying a new version of a JMS application with totally different classes into a production system during runtime.
Any Java Application can run as a job invoked from the Scheduler Swiftlet, scheduled at specific times or in intervals, based on calendars and so on. You don't have to implement proprietary code like with other scheduler products! SwiftMQ is your job scheduler! From SwiftMQ 5.x onwards you can even hot deploy your jobs!
Everything runs within the router's virtual machine. No matter how many JMS clients you have, you have only a single process to start and everything is up and running. SwiftMQ is your JMS application server.
Your JMS clients connect via intra-VM connections. No sockets but fast virtual in-memory connections. This gives you up to 30% more throughput.
Intra-VM JMS clients schedule their threads directly within router managed threadpools from the Threadpool Swiftlet. These thread pools are shared from all container-managed JMS clients so you have less overall threads on your machine.
Forget everything about connection loss, because it will not happen! The router is always up if your JMS application is up. So you can remove all your reconnection code from your application. You don't even have to register an ExceptionListener on connections.
Put all your start scripts for your JMS application into the trash. You can manage everything via the router's configuration file, SwiftMQ Explorer/CLI or even the CLI Admin API.
This is the coolest feature at all! Are you a supplier of a JMS based product? Just supply it as a hot deployable bundle. Your customer will copy it into a deploy space and it will be deployed during runtime. This works even with version upgrades! Or use hot deployment during testing. Just put your new version into the deploy space and it will be deployed. Only the sky is the limit!
It's just plain JNDI/JMS. You don't have to implement any proprietary interfaces from us. A container-managed JMS client will run with any other JMS vendor's product.