Any comments are more than welcome!
Archive for the ‘Design’ Category
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…
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.
Your input is needed for our release planning:
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?