The Deuce - Plans for Immutant 2
We haven't blogged about anything in a few months because we've been thinking about how we'd like to improve Immutant. We've come up with a couple of high-level goals:
- Fully-functional libraries; no container required
- Applications using those libraries should be optionally deployable to a stock WildFly or EAP container
One goal we don't have is API compatibility with Immutant 1.x.
Just Libraries
For its second major release, Immutant will simply be a collection of libraries, one for each of the commodity services currently available to applications using an Immutant 1.x container: web, scheduling, messaging, caching, and transactions. These services will be provided by the following underlying components: Undertow, Quartz, HornetQ, Infinispan, and Narayana, respectively. All but Quartz are the same as those used in WildFly 8.
So when you embed any Immutant 2.x library in your app, it will not require a "container" to be fully-functional. There is no required "installation" step. There is no required "deployment" step.
Just libraries.
Just WildFly/EAP
Fully-functional libraries are great, but there are still good reasons to deploy an app to a container, e.g. security, monitoring, clustering, etc. We want developers to be able to run the exact same application either outside or inside an app server. When outside, all functions in the Immutant namespaces will work as expected. But inside, you get more, automatically, without any changes to your code:
- Web session replication
- Load-balanced message distribution
- Highly-available "singleton" scheduled jobs
- Flexible Infinispan cache replication
- Multiple polyglot app deployments
Immutant 1.x consists of modules and subsystems repackaged on top of a now-quite-old, forked AS7 distribution. AS7 is no longer under active development. All of the innovation is occurring in WildFly, and it became increasingly difficult to cherry-pick relevant changes into our fork.
So we're going to eliminate that headache in 2.x. Immutant applications will be deployable into stock, vanilla WildFly/EAP servers. No modules or subsystems or special deployment descriptors required. Just a jar file with a little code to setup the classpath and engage the container's services.
This means no more using Leiningen to resolve dependencies at
deployment, which has been a source of bugs from the more
adventurous project.clj files.
This also obviates overlay, another source of bugs. TorqueBox 4.x apps will work like Immutant 2.x, simple jar files deployed to stock WildFly/EAP installations, achieving the same features available from overlay today, without the brittle complexity.
Same Features, Less Hassle
Development is occurring on our thedeuce branch right now, but we'll merge it to master once we cut a 1.1.1 release. And we're publishing incremental releases here. We'll include more detailed instructions on how to try them in a future post. We currently have basic ring and scheduling support implemented, with both working standalone and inside a WildFly container. We hope to cut our first 2.x release this summer.
Immutant was inspired by its sister project, TorqueBox, under active development for almost 6 years now. Embracing Clojure's REPL, we strove to make Immutant's libraries more dynamic than TorqueBox. This caused the API's in each project to diverge somewhat, even though we have a number of community members who use both together via messaging, caching, etc.
So Immutant 2.x and TorqueBox 4.x represent an opportunity for both teams to work together to realign and harden the service API's, with an eye toward supporting other languages and implementations in the future. Please join us in either #torquebox or #immutant on freenode, to express your opinions and desires.
