Enterprise Java

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:

  1. The administrative password that you will use to log in to JBoss Fuse, for managing A-MQ.
  2. A new public key that clients must have in order to communicate with A-MQ. This information looks like:

    —–BEGIN CERTIFICATE—–

    —–END CERTIFICATE—–

  3. 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 

  1. Copy the text of your key into a file called amqpublic.cer. Copy each line, inclusive of the BEGIN and END lines.
  2. Import the public certificate into a trust store that your clients will use.
    keytool -importcert -alias openshiftamq -file openshiftamq.cer openshiftamq.jks
  3. 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.
  4. 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.

Markus Eisele

Markus is a Developer Advocate at Red Hat and focuses on JBoss Middleware. He is working with Java EE servers from different vendors since more than 14 years and talks about his favorite topics around Java EE on conferences all over the world. He has been a principle consultant and worked with different customers on all kinds of Java EE related applications and solutions. Beside that he has always been a prolific blogger, writer and tech editor for different Java EE related books. He is an active member of the German DOAG e.V. and it's representative on the iJUG e.V. As a Java Champion and former ACE Director he is well known in the community. Follow him on Twitter @myfear.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button