...
Code Block | ||||
---|---|---|---|---|
| ||||
<model> <buses> <bus name="hello-bus"> <provider>solace</provider> <host>192.168.1.100</host> <port>55555</port> <channels> <channel name="hello-requests"> <key>hello/requests</key> <qos>BestEffort</key>qos> </channel> <channel name="hello-replies"> <key>hello/replies</key> <qos>BestEffort</key>qos> </channel> </channels> </bus> </buses> <apps> <app name="hello-app" mainClass="com.example.HelloApp"> <messaging> <factories> <factory name="com.example.messages.HelloMessageFactory"/> </factories> <buses> <bus name="hello-bus"> <channels> <channel name="hello-requests" join="true"/> <channel name="hello-replies" join="false"/> </channels> </bus> </buses> </messaging> </app> </env>apps> <servers> <server name="hello-vm"> <apps> <app name="hello-app" autoStart="true" /> </apps> </server> </servers> </model> |
...
- Replication: The primary means of achieving persistence for an ODS Store is by pipelined, memory-memory replication of transactions to one or more hot backup peers. If a primary application instance fails the backup takes over with no loss of data.
- Transaction Logs: An ODS Store can also log to binary transaction logs as a secondary persistence mechanism if the connection to the backup is lost or a cold restart is required.
- Change Data Capture (CDC): To allow asynchronous yet transactionally consistent syphoning of application state to back end or legacy systems, ODS supports the ability to perform Change Data Capture with a simple callback-based mechanism to push state changes.
- Inter Cluster Replication (ICR): Inter-Cluster Replication allows replication of the store's recovery stream to another data center over messaging, providing an asynchronous and transactional consistent disaster recovery mechanism.
See Application Storage.
XVM
A A Talon XVM serves as a container for Talon micro apps and provides management capabilities for the XVMs apps that it contains. Key features of the Talon XVM include:
...
The platform's discovery facilities provides plugin mechanisms for ODS store's to discover one another, and for tooling to discovery discover running instances of applications. Out of the box, the platform supports discovery of over multicast and over messaging.
Talon Application Flow
...
In traditional application architectures the problems of state/messaging atomicity and exactly once processing are often solved using distributed transactions. For example, in J2EE state changes would be committed to a databases and messaging sent over JMS with XA transactions used to coordinate commit on both. Such schemes involve a lot of overhead and kill performance. The application flow in Talon provides the same level of reliability without the synchronous overhead of distributed transaction coordination. The following diagram depicts the application flow in a Talon application:
Elaborating on the diagram above, Talon ensures the same level of reliability as traditional architectures as follows:
...