Archive for the ‘Design’ Category

End of the app server and the ESB

Monday, December 8th, 2014

Another great independent article on how the app server is disappearing, with the ESB going along:

Micro services on light weight containers like Docker or maybe Dropwizard or Spring Boot are the end of the application server that served us so well last decade. If you can scale your application by starting a new process on a fresh VM you don’t need complex software to share resources. That means you don’t really need a lot of infrastructure. You can deploy small components with negligible overhead. Key-value data stores allow you to relax constraints on data that where imposed by relational databases. A service might support two versions of an interface at the same time. Combined with REST, a DNS and a load balancer this is the end of ESBs.

Interested in going one step further and moving into implementation? Download our JEE without application server vision to see some concrete tips on how this can work in Java…

Our REST API docs are going public!

Saturday, February 8th, 2014

Good news for those who are curious: our REST API docs are ready to go public - see TCC for REST.

Any comments are more than welcome!

TCC for REST to be presented at

Saturday, February 8th, 2014

A paper covering the design / implementation of our API for TCC for REST has been accepted for ws-rest 2014.

This news comes at a great time since we are about to release a milestone build of our 4.0 release of ExtremeTransactions that includes support for precisely this API. Thank you Cesare Pautasso for co-authoring this work, and thanks to all the reviewers for the very useful comments that helped us improve the design even more!

Watch this blog for more updates soon…

Check out our new OSGi documentation

Sunday, January 26th, 2014

If you’re into OSGi then you might want to check out our new OSGi documentation, explaining how to use Atomikos in OSGi (thanks to Pascal Leclercq).

Of course, this page will be updated once we support even more OSGi goodies - we have enough of those waiting in our backlog…

The “ports and adapters” architecture (aka “hexagonal architecture”)

Saturday, December 15th, 2012

Atomikos is designed along the ports and adapters/hexagonal architecture as described here by Alistair Cockburn.

Among other things, this means that it is relatively easy to:

  • Implement new transaction APIs / standards / models
  • Add new types of two-phase commit resources

Examples of things we’ve been able to realize thanks to this:

  • JTA (port) / XA (adapter)
  • TCC (port/adapter)
  • RMI (port/adapter)
  • WS-AT (port/adapter)
  • CORBA’s OTS (port/adapter)
  • TaaS - Transactions for REST (port/adapter)

The port and adapter model is also an important concept in the new book Implementing Domain-Driven Design. Our domain is 2-phase commit. Our adapter is our Participant model. Our ports are all the ways you can interact with our core system.

Important question to the community

Thursday, March 22nd, 2012

Your input is needed for our release planning:


Inquiry: redesign of init property lookup

Thursday, December 22nd, 2011

We are asking for community input on the following: over time, our initialization mechanism (property file, system properties, properties supplied programmatically) has been polluted a bit and as a result the lookups are not always intuitive. We would like to improve this and are working on a new design proposed here. Let us know what you think!

Proposed new property lookup procedure when Atomikos starts:

1. default properties are looked up via a property file in the Atomikos jars (should always be found)
2. override with specific custom properties looked up in the file in the classpath (like now)
3. if no found: NO logging to System.err any more (so no need to disable that with system props either)
4. override with specific properties that are set programmatically on the UserTransactionService
5. resolve any placeholder properties (i.e., ant-style expansion of references to other props)
6. this yields the final properties to use for the init procedure

What do you think? Did we miss something important?