12.4.4. Multiple Transaction Handling Points
Two peers synchronise the representation of the state of entities located within the Perspectives Universe that falls in their respective horizons. Their Transaction Handling Points construct and process deltas and ship them in transactions.
But again, note that synchronization does not imply they send copies of these resources to each other. They send deltas that deal with each other’s perspectives.
A THP is also the place where bots execute actions on behalf of their users. Now reconsider the use case of witnessing. The actual actions that should be carried out by the witness lend themselves perfectly to bot handling. As a witnessing service grows, the bot should scale with it. Above a certain volume it will not be practical for the THP of the witness (the human) to handle all those transactions: the bot will compete for resources with the actions the human user wants to carry out himself.
So here arises the wish to have some types of transactions to be handled by another processing unit: a THP dedicated to a few types of transactions. In other words: we want the witnessing bot to run on some server or in the cloud and not on the laptop of the witness himself!
The PDR (as our only current THP implementation) looks up, for each delta, to what THP it should be sent. It finds that information with the User of the System and it finds this system user by following filled by links, starting with the role in the context where the delta applies. In our example this would be a financial transaction, where the witness role would be filled by a ‘telescope’ of roles that bottoms out in the system user of the employee designated responsible for the service by his employer.
To paint the picture in a little more detail, let’s assume that we have a company context (WeWitness), with Employee roles, with a WitnessEmployee role in the actual WitnessingDepartment, with WitnessContract contexts with a customer role and a Witness role. We then would have the following telescope:
-
Witness in FinancialTransaction
-
Witness in WitnessContract
-
WitnessEmployee role in the WitnessingDepartment
-
Employee role in WeWitness
-
User role in System.
Conceptually it is simple to add THP properties to the WitnessEmployee role that will shadow the THP properties in the User role. So when the PDR of a client looks up the THP properties starting from the FinancialTransaction, it will find the location of the THP that is run on WeWitness’s high volume servers. The transaction of deltas will be sent to that server.
12.4.4.1. A THP that is not a PDR
The service that executes the bot actions on behalf of the WitnessEmployee needs not be implemented as a full Perspectives Distributed Runtime. We know, by design, exactly what the form of the transactions is that it receives and that it must send. The actual processing is extremely simple. So we can write such a service in any language, as long as it accepts and produces the correct transactions for this use case.
Such simplifications will bring great scaling benefits.
12.4.4.2. A use case for Database Query Link
As the number of financial transactions grows, it will soon be impractical to represent the filled roles link in the WitnessEmployee role with a list of all those filled Witness in FinancialTransaction roles. So here we have a perfect use case for a DQL.