JMS with JBoss A-MQ on OpenShift. Lessons learned about remote Clients and Encryption.
OpenShift is the “open hybrid cloud application platform by Red Hat”. It comes in different flavors and the most interesting part for most of the things you want to do is the public cloud application development and hosting platform “OpenShift Online“. You can easily try it out because using OpenShift Online in the cloud is free and it’s easy. All it takes is an email address. The free offering allows for up to three basic small gears and host up to three applications from a variety of different languages and frameworks. If you need more, you can upgrade your plan to a paid version. For more details look at the online feature comparison website.
JBoss A-MQ on OpenShift
The Java Message Service is an effective method for cross-system communication, even among non-Java applications. By basing itself on open source technologies and strong standards, RedHat OpenShift allows developers to easily move their JMS applications to the cloud or write new systems that leverage JMS messages with encrypted internet connectivity.
This post will cover the means for using two major applications: WildFly 8 for hosting web applications, and JBoss A-MQ for asynchronous messaging. Both applications can run on gears within the free tier of OpenShift.
Creating an A-MQ Gear
By deploying A-MQ to the OpenShift cloud, your gear will receive several publicly accessible ports. Client systems can then use these remote ports to connect to your A-MQ service. The endpoints require encryption, so no JMS message will ever be sent in plain-text across the internet.
The first step in creating your A-MQ gear is to clone the existing JBoss Fuse A-MQ cartridge. For those interested in cartridge management, you can view full details on this cartridge. (Note: If you are looking for an upstream cartridge with ActiveMQ, take a look at this blog.)
rhc create-app amq http://is.gd/Q5ihum
Upon creating, the gear provides three important pieces of information:
- The administrative password that you will use to log in to JBoss Fuse, for managing A-MQ.
- A new public key that clients must have in order to communicate with A-MQ. This information looks like:
—–BEGIN CERTIFICATE—–
…
—–END CERTIFICATE—–
- A list of public ports A-MQ is using for remote connections.
Managing the encryption on OpenShift
The difference between clients and your OpenShift gear is that OpenShift needs the private key. If you need to change the keys, the keystore file is FILENAME. If you change keys, clients must have the public key before they will trust it. If you change the keys, you must restart the gear. If you forgot to copy your certificate during gear creation of you changed the keystore and need to extract is, use the following commands:
keytool -list -keystore ~/jboss-amq/jboss-a-mq-6.1.0.redhat-378/etc/keystore.jks
keytool -exportcert -alias (whatever it says) -keystore -file openshiftamq.cer
Download the openshiftamq.cer file using an SFTP client and configure clients.
Managing the encryption on clients
- Copy the text of your key into a file called amqpublic.cer. Copy each line, inclusive of the BEGIN and END lines.
- Import the public certificate into a trust store that your clients will use.
keytool -importcert -alias openshiftamq -file openshiftamq.cer openshiftamq.jks
- Put the openshiftamq.jks file as a classpath resource of your application or somewhere memorable. You won’t need the .cer file anymore but can still keep it around.
- Within client code, configure this trust store to be used with A-MQ connections. If you do not do this step, clients will not trust the server.
private ConnectionFactory connection(String url) { ActiveMQSslConnectionFactory connectionFactory = new ActiveMQSslConnectionFactory(url); try { connectionFactory.setTrustStore("openshiftamq.jks"); //or file if not in classpath root } catch (Exception ex) { Logger.getLogger(getClass().getName()).log(Level.SEVERE, "Unable to load trust store.", ex); } connectionFactory.setTrustStorePassword("put your password here"); return connectionFactory; }
Remote communication from clients
One benefit of using the OpenShift Fuse A-MQ gear is that is exposes several external ports. As a result, your A-MQ service is available without requiring the rhc port-forward command. The URL for your A-MQ clients will look like this:
ssl://gearname-YourDomain.rhcloud.com:PORT
- Gearname – the name of your gear within the administrative console.
- YourDomain – Your standard OpenShift domain.
- PORT – the numeric port number provided when you created the cartridge.
Configure clients using the ConnectionFactory code from above.
Additional ActiveMQ Configurations in your OpenShift Gear
Many configuration options from a standard A-MQ instance are available within your OpenShift instance. The configuration file for this is:
~/jboss-amq/jboss-a-mq-6.1.0.redhat-78/etc/activemq.xml
with a few caveats. Namely, you can change the protocol of a <transportConnector /> but must not change the IP or port. The ports are controlled by your OpenShift Gear and are the only ones actually allowed from external areas.
Prevent accidental Gear idling
OpenShift is designed as a resource sharing system, and idle resources will essentially be put to sleep until accessed. JMS poses a particular problem on OpenShift in that if it is idle, connections will not function and new clients cannot connect.
To prevent this behavior, automate a script that periodically interacts with the JBoss Fuse web console or always keep at least one client connected to your A-MQ.
| Reference: | JMS with JBoss A-MQ on OpenShift. Lessons learned about remote Clients and Encryption. from our JCG partner Markus Eisele at the Enterprise Software Development with Java blog. |
