Transactions for SOA with Guaranteed Interoperability
Imagine a light-weight transaction (and BPM) model for REST with the following characteristics:
- Guaranteed interoperability
- Easy and intuitive to use
- No technology dependencies, so no configuration required
- Compatible with the REST architectural constraints
Example Use Case
To get an idea of what it is like, consider the following example: a telco operator wants to allow customers to acquire ‘personalized’ phone numbers for a fee. The process is the following, assuming an incoming request for a given customer and a chosen phone number:
- The system checks if the number is available, and if so then reserves that number for some time (on behalf of the customer).
- The customer’s credit is checked in the billing system.
- If OK, then the phone number reservation is confirmed and the billing is done.
- Otherwise, the phone number is released again and no billing is done.
BPM or Not?
Imagine the BPM modeling you would need to do to handle all failure scenarios and confirmation scenarios from that last 2 steps. We know from experience that this does not scale… Besides, BPM does not really fit REST (yet).
Our Solution: TCC for REST [Light-weight BPM]
Instead, what we offer is a complete and reliable automation of the confirmation and cancellation steps - letting you focus on the happy path of the workflow. We do this via a service called TaaS (TCC
as a Service) and we offer a REST implementation
of that. Any error paths are taken out of the workflow and entirely handled by Atomikos. Also check out the API docs
Get It Here!
So if your SOA should be lightweight and involves the concept of reservations of business resources then try out Atomikos ExtremeTransactions®
with TCC support for REST
... Alternatively, just check out our API docs