Most CloudBees Java EE runtimes are based on "Web Profile". This profile defines a subset of Java EE APIs that are enough for most uses-cases and make JavaEE simpler and lighter for alternate vendors to implement the spec.
Some customers requested JMS support (that isn't part of Web Profile). Main reason this isn't provided, is that JMS requires a centralized messaging service to distribute messages on cluster's nodes. But after discussion with customers, the main reason they wanted JMS was not for actual message-oriented-middleware (MOM) but for asynchrony.
A typical use-case is application that has to send a mail to user as part of registration process. Making this process fully sequential expose the application to JavaMail delays an failures, so a better implementation is to immediately tell the web user a mail has been sent and run the mail sending code asynchronously.
Such asynchrony is not trivial to implement with base JRE classes as java.util.concurrent.Future is a low-level API, and don't let the application handle failures to re-run the process. As a workaround, many Java EE developers use to rely on a JMS queue, that offer persistence and transactional model, and define asynchronous tasks runners as JMS listeners (Message Driven Bean). Spring Batch SimpleAsyncTaskExecutor offers an alternative implementation, but some may prefer to rely on "standard" APIs.
This looks an abuse for JMS API, anyway is an easy way to get the async-task pattern implemented without extra efforts - assuming JMS is enabled. So Cyrille worked on a persistent JMS implementation, demonstrated on Glassfish 4 "full" runtime.
I'm not sure we have to encourage this pattern, if it's considered a legitimate JMS usage, or if anybody cares. But for legacy application to migrate to CloudBees this can be a reasonable solution.
Nicolas De Loof
Hacker
CloudBees