V ERSION CONSISTENCY IMPLEMENTATION

C ONTENTS Apache Tuscany VcContainer Domain manager VcContainer communication 2

D YNAMIC UPDATES Dynamic update of software systems is often desired, sometimes required How to achieve version consistency is one of the key challenges Version Consistency Intuitively, any extant transaction, with all its (direct and indirect) sub-transactions, is executed as if entirely in the old or entirely in the new configuration. 3

D YNAMIC UPDATES Goal: implementing a framework to execute dynamic update of component-based systems verify the correctness of version consistency algorithm 4

T ECHNOLOGIES Varieties of technologies is available SCA specification defines a common programming model for different technologies Apache Tuscany is an open source implementation of SCA, it’s stable and makes component-based development much more easier 5

C OMPONENT - BASED DISTRIBUTED SYSTEMS Static configuration of an example CBDS 6

C OMPONENT - BASED DISTRIBUTED SYSTEMS Runtime Portal component Tuscany components communicate via endpoint service endpoint: the service a components expose reference endpoint Interceptor handles messages passing through it transaction, security, … 7

O UR CONCERNS Local dynamic dependences maintaining Dependences management Transaction ID allocation Component lifecycle management On-demand setup Achieving freeness 8

M AINTAINING LOCAL DEPENDENCES We need to maintain following local dependences future/past arcs entering current component InArcsRegistry future/past arcs leaving current component OutArcsRegistry sub transaction and its root transaction TransactionRegistry 9

O UR CONCERNS Local dynamic dependences maintaining Dependences management Transaction ID allocation Component lifecycle management On-demand setup Achieving freeness 10

M ANAGEMENT OF DEPENDENCES When a transaction starts When a transaction is running When a transaction ends 11

M ANAGEMENT OF DEPENDENCES When a transaction starts create future arcs store future arcs notify parent/sub components When a transaction is running When a transaction ends 12

W HEN A TRANSACTION STARTS When root transaction T0 starts, setting up is needed 13

W HEN A TRANSACTION STARTS Portal need to create future arcs Setting up future T0T0 T0T0 14

W HEN A TRANSACTION STARTS Notify algorithm module that T0 starts; create future arcs to Auth and Proc component add future arcs to OutArcsRegistry notify Auth and Proc that a future arc is created 15

M ANAGEMENT OF DEPENDENCES When a transaction starts When a transaction is running update local future/past OutArcsRegistry notify sub component to update their InArcsRegistry identify root and its sub transaction When a transaction ends 16

W HEN A TRANSACTION IS RUNNING When root transaction T0 is running, processing is needed 17

W HEN A TRANSACTION IS RUNNING Update future arc Progressing past T0T0 18

W HEN A TRANSACTION IS RUNNING update related future arc in OutArcsRegistry notify Auth that future arc of T0 needs to be updated Notify algorithm module that T0 is running and Auth component will not be used 19

I DENTIFICATION OF ROOT TRANSACTION When root transaction T0 is initiated on Portal, how does sub-transactions T1 on Auth component know its root transaction? 20

I DENTIFICATION OF ROOT TRANSACTION Define a trace interceptor to add root transaction ID T0 to the message that is passing through it to resolve message to get root transaction T0, and map current sub transaction root(T1)=T0 21

M ANAGEMENT OF DEPENDENCES When a transaction starts When a transaction is running When a transaction ends update local dependences notify parent component 22

W HEN A TRANSACTION ENDS Transaction T0 ends 23

W HEN A TRANSACTION ENDS Update arcs Cleaning up past T0T0 T0T0 T0T0 T0T0 24

W HEN A TRANSACTION ENDS update related future arc in OutArcsRegistry notify Auth that future arc of T0 needs to be updated Notify algorithm module that T0 ends and all components will not be used 25

V C CONTAINER A business component and its related VC modules are wrapped in a VcContainer as a single node 26

O UR CONCERNS Local dynamic dependences maintaining Dependences management Transaction ID allocation Component lifecycle management On-demand setup Achieving freeness 27

A LLOCATION OF TRANSACTION ID In one domain, for each transaction, it should have an unique ID define a domain manager component allocate and destroy transaction ID 28

F UTURE WORK Maintaining local dynamic dependences Management of dependences Allocation of unique transaction ID Component lifecycle management On-demand setup Achieving freeness 29

C OMPONENT LIFECYCLE MANAGEMENT When a component needs dynamic update, it must be deactivated and messages it receiving must be cached. When dynamic update is done, the component should be activated 30

O N - DEMAND SETUP Dynamic configuration management could introduce significant overhead Solution: a configuration can be set up on-demand 31

A CHIEVING FREENESS 32