Archive for the ‘Design’ Category

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 ws-rest.org

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:

http://fogbugz.atomikos.com/default.asp?community.6.2714.0

Thanks!

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 jta.properties file in the classpath (like now)
3. if no jta.properties 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?

Thanks!