Transactions in caCIS: Architecture to Development

1. Transactions in caCIS: Architecture to Development John Koisch, Guidewire Architecture

2. Transaction Processing • In computer science, transaction processing is information processing that is divided into individual, indivisible operations, called transactions. Each transaction must succeed or fail as a complete unit; it cannot remain in an intermediate state. • In distributed computing, we are striving to insure that all designed processes complete deterministically. With rich information, this may mean that we have to handle rich exception models • A deadlock is a situation where in two or more competing actions are each waiting for the other to finish, and thus neither ever does. • A livelock is similar to a deadlock, except that the states of the processes involved in the livelock constantly change with regard to one another, none progressing. Livelock is a special case of resource starvation; the general definition only states that a specific process is not progressing.

3. Services and Transactions • caCIS uses Service Boundaries to hide complexity, including transactional processing • From a conformance and design point of view, transactional performance is detailed by the contract, but the implementation details are deferred • Does not mean that they are not important, just that they are implied

4. Contract Boundaries for the Service • The Allergy Service makes certain claims about providing allergy records • In the simplest case, where this service is providing access against one source of record, then you still need transactional integrity to insure data integrity • May be deferred to JDBC transactions ? • At any rate, Service Implementation MUST be able to manage data integrity, which means at least awareness of transactions • In the simplest case (query), the hard work may be deferred to other systems (Tolven?) or to “built in” transactions processing (JDBC?) • However, caCIS can very quickly move past this level of complexity

5. Contract Boundaries for the Service (cont’d) • In the graph below, the response for an allergy concern is displayed • There are potentially 5 calls (or more?) to assemble this graph • Each call likely is distributed against different data stores

6. Contract Boundaries - Summary • We have only dealt with Query • Additional topics in service implementation that are affected by Transaction Processing include • Compensating Transactions • Exception Management • Multiple Service Infrastructure (validation, verification (against registries), transformation (to other syntaxes), translation (from one code system to another)) • Information Aggregation • In some deployment cases, one service interface can provide authoritative records against multiple databases • Somehow, you need to manage multiple calls to multiple records • You may need to manage missing information (if DB3 is off line, is my information still valid?) • Information Dissemination • Updating multiple record stores

7. Solution Specifications and Long Running Transactions • Long-running transactions are computer database transactions that avoid locks on non-local resources, use compensation to handle failures, potentially aggregate smaller ACID transactions (also referred to as atomic transactions), and typically use a coordinator to complete or abort the transaction. In contrast to rollback in ACID transactions, compensation restores the original state, or an equivalent, and is business-specific. The compensating action for making a hotel reservation is canceling that reservation, possibly with a penalty. • A number of protocols have been specified for long-running transactions using Web services within business processes. OASIS Business Transaction Processing [1], and WS-CAF [2] are examples. These protocols use a coordinator to mediate the successful completion or use of compensation in a long-running transaction. • WS-Coordination is a separate standard

8. Referral is a matter of managing a Shared Context. The Referral Manager needs to handle the Long Running Transaction involved in coordinating Trading Partner Communications

9. Service Calls form the basis of the Transaction Description

10. Solution Specifications - Summary • Transactions MUST be handled for Solution Specifications • We suggest using standards like • WS Coordination • WS Business Activity • WS Atomic Transaction • Known Solution Specifications for caCIS • Document Exchange • Document Builder • Order Management, including Image, Lab, Referral, and Path

11. Things We are Leaving Out • Client-controlled transactions • Infrastructure Resolution for Compensating Transactions (See Contract Framework for placeholder information) • ESB Internal Transactions

12. Things We are Leaving Out (cont’d) • The caCIS Platform will involve multiple processes • It is a design decision as to whether to use Coordinating Transactions to handle vEHR Scaffolding internal transactions