120 likes | 234 Views
Transactions in caCIS: Architecture to Development . John Koisch, Guidewire Architecture. Transaction Processing.
E N D
Transactions in caCIS: Architecture to Development John Koisch, Guidewire Architecture
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.
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
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
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
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
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
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
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
Things We are Leaving Out • Client-controlled transactions • Infrastructure Resolution for Compensating Transactions (See Contract Framework for placeholder information) • ESB Internal Transactions
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