| Table of Contents |
|---|
Key Points
References
...
| Table of Contents |
|---|
Key Points
References
| Reference_description_with_linked_URLs_______________________ | Notes_________________________________________________________________ | |
|---|---|---|
| Ward Cunningham - Portland Pattern Repository | Gang of Four Design Patterns | |
| https://www.tutorialspoint.com/design_pattern/factory_pattern.htm | G4 Pattern summary tutorials point | |
| https://springframework.guru/gang-of- | Roots of OOP - Alan Kay Smalltalk keys encapsulation, abstraction, delegation, dynamic associations, collaboration via messages, events, listeners, promises benefits - decoupling to reduce complexity, avoiding shared state, adaptability to change ( CIC policy nbr ) | |
| Ward Cunningham - Portland Pattern Repository | ||
| Gang of Four Design Patterns | ||
| https://www.tutorialspoint.com/design_pattern/factory_pattern.htm | G4 Pattern summary tutorials point | |
| https://springframework.guru/gang-of-four-design-patterns/ | G4 Pattern summary Spring - 1 page | |
| JEE Enterprise Services Patterns | ||
| Enterprise Integration Patterns | ||
| https://microservices.io/patterns/index.html | Microservices Design Patterns | |
| https://microservices.io/patterns/monolithic.html | Monolithic Architecture pattern | |
| https://microservices.io/patterns/microservices.html | Microservices Architecture pattern | |
| Microservices orchestration vs |
Key Concepts
| choreography | |
| https://sites.google.com/a/mammatustech.com/ mammatusmain/reactive-microservices | Reactive microservices pattern |
Key Concepts
Declarative vs Imperative Coding
...
Microservices Application Pattern
Please see the example applications developed by Chris Richardson. These examples on Github illustrate various aspects of the microservice architecture.
Resulting Context
Benefits
...
- The coordinator is coupled with the services.
- If the coordinator goes down, it impacts the entire system.
Interoperable Blockchain ACID transaction pattern
blockchain interoperability on atomic transactions using escrow transactions
context
assume 2 different orgs on 2 different blockchains on 2 different platforms want to execute a sale using an order (any type of asset )
blockchains implement escrow transaction interface services in a smart contract
2 independent chains A and B can send messages using a common protocol ( gRPC or ??? )
party A wants to buy X from party B for Y currency amount
problems
how to ensure only authorized parties participate in the transaction
how to ensure both parties will execute their transaction once and only once to complete the purchase transaction
how to ensure that the purchase is cancelled if either party fails to complete their part of the purchase transaction within the designated time limit
pre-requisites
network connectivity
blockchain directory services and access
identity, registration and access management services for all parties in a transaction
each party implements the escrow transaction interfaces
each party communicates using one of the supported protocols: gRPC or ?
each party digital certificates to sign and execute transactions identifying the authorized party
gateway nodes connect 2 different logical blockchain networks directly or indirectly ( blockchain networks normally not physical but virtual overlay networks across multiple provider networks )
solution
use an escrow transction with smart contracts that
records each parties performance of the obligation
This follows a saga pattern to implement the escrow transaction (eg a purchase ) as a set of linked transactions in smart contracts
Singe Use Tokens are used to guarantee that only this single reservation transaction can be executed once by the designated party
step 0 - party A agrees to buy X from party B for Y currency amount agreeing to a set of policies to execute the transaction for the buyer and the seller roles
step 1 - reservation for payment from A to B with a token, reservation for delivery from B to A with a token
step 2 - when both reservations complete, the reservations are executable as smart contracts by each party
each party executes their reservation transaction via smart contract using the supplied single use token created for just this transaction
A executes B's reservation using the token from B
B executes A's reservation using the token from A
alternate scenarios
both reservations are not completed within the agreed time limit, all reservations and tokens are cancelled and resources revert to current owner control
the purchase policy agreed to may include automated contracts to execute actions to reverse one or both reservation executions or cancel the reservations updating the blockchain
step 3 - if both reservations are not executed as transactions within an agreed time limit, each party is notified to manage the purchase based on agreed policy
step 4 - when both reservations have been executed by each party, all parties are notified of the completion of the escrow transaction
...
RDD - Responsibility Driven Design - Wirfs-Brock
Why RDD?
more flexible than reactive services design
doesn't force everything to an API service model - just what should be an API vs a service vs a library vs a function
more natural way to find events produced and consumed by starting with business or client use cases
provides an easier way for business users to drive requirements specifications using natural language ( vs powerpoint logic )
Reactive Microservices based on event listeners
https://sites.google.com/a/mammatustech.com/mammatusmain/reactive-microservices
event maps, event storming in the context of microservices
effective really for software engineers but not so much for others
Benefits of Real OOP using Smalltalk before other languages improved
medium.com-The Forgotten History of OOP.pdf
https://medium.com/javascript-scene/the-forgotten-history-of-oop-88d71b9b2d9f
| Wow ! really well done on understanding the value of “intelligent objects”. The Smalltalk features and benefits called out are perfect. I had been developing in other languages for over a decade before picking up Smalltalk ( VisualAge Smalltalk ). Once you have the power, flexibility, protection it was hard to go back to other languages. The other languages are evolving ( as you nicely demonstrate ) to pick up those features. Building in Smalltalk, I could create components that could think for themselves. You could delegate responsibilities to them and they could learn new behaviors. Later I tried the approach with Groovy but it was less elegant. |
Interoperable Blockchain ACID transaction pattern
blockchain interoperability on atomic transactions using escrow transactions
context
assume 2 different orgs on 2 different blockchains on 2 different platforms want to execute a sale using an order (any type of asset )
blockchains implement escrow transaction interface services in a smart contract
2 independent chains A and B can send messages using a common protocol ( gRPC or ??? )
party A wants to buy X from party B for Y currency amount
problems
how to ensure only authorized parties participate in the transaction
how to ensure both parties will execute their transaction once and only once to complete the purchase transaction
how to ensure that the purchase is cancelled if either party fails to complete their part of the purchase transaction within the designated time limit
pre-requisites
network connectivity
blockchain directory services and access
identity, registration and access management services for all parties in a transaction
each party implements the escrow transaction interfaces
each party communicates using one of the supported protocols: gRPC or ?
each party digital certificates to sign and execute transactions identifying the authorized party
gateway nodes connect 2 different logical blockchain networks directly or indirectly ( blockchain networks normally not physical but virtual overlay networks across multiple provider networks )
solution
use an escrow transction with smart contracts that
records each parties performance of the obligation
This follows a saga pattern to implement the escrow transaction (eg a purchase ) as a set of linked transactions in smart contracts
Singe Use Tokens are used to guarantee that only this single reservation transaction can be executed once by the designated party
step 0 - party A agrees to buy X from party B for Y currency amount agreeing to a set of policies to execute the transaction for the buyer and the seller roles
step 1 - reservation for payment from A to B with a token, reservation for delivery from B to A with a token
step 2 - when both reservations complete, the reservations are executable as smart contracts by each party
each party executes their reservation transaction via smart contract using the supplied single use token created for just this transaction
A executes B's reservation using the token from B
B executes A's reservation using the token from A
alternate scenarios
both reservations are not completed within the agreed time limit, all reservations and tokens are cancelled and resources revert to current owner control
the purchase policy agreed to may include automated contracts to execute actions to reverse one or both reservation executions or cancel the reservations updating the blockchain
step 3 - if both reservations are not executed as transactions within an agreed time limit, each party is notified to manage the purchase based on agreed policy
step 4 - when both reservations have been executed by each party, all parties are notified of the completion of the escrow transaction
step 5 - any dependent actors are notified of the completion of the purchase which may trigger additional transactions ( eg start an automatic purchase warranty etc )
P2P Escrow Transaction Pattern
goals
- 2 parties complete an atomic swap of asset 1 for asset 2 without risk
- if swap can't meet completion criteria, swap transaction is reversed for all parties returning initial states for each
- optionally, a 3rd party notary service may need to approve the transaction
- optionally, a 3rd party observer service may record the transaction
- optionally, the 2 parties may be on different networks
model
a chain manager ( on a chain ) for other chain transactions ?? ( or a configurable chain model ? )
specific validators only for that transaction type and parties are active
- multi-party contract with roles where config defines terms of the swap
- each party is identified and claims a role ( eg buyer, seller etc )
- define multi-step transaction types
- create transaction instance using the shared transaction manager with workflow from the contract config for that transaction type
- each transaction has a unique ID
- set the parties who validate the transaction on each ledger
- contract takes control over both assets from each party using locks and confirms locks ( if funds or asset limited, policy may allow partial transactions )
- obligation set for each asset in the contract locking a portion of the assets for a time period
- after lock done, the lock status for all assets in the contract is shared
- if all assets in the contract locked, next step executes ( normally the trade )
- funds transferred to new party, assets transferred to new party
- after delivery completed, obligations removed
- after each step, the contract instance is updated for both parties and confirmed
- signatures and consents required by all parties for each step
- state changes are validated as complete on each ledger for the current step before moving to next step - 100% endorsement of each update by relevant parties
- if completion criteria for a step not fulfilled by X time, the transaction is cancelled and all parties are restored to initial states
- completion messages recorded and events published on success or failure of the transaction
context
assume 2 different orgs on 2 different blockchains on 2 different platforms want to execute a sale using an order (any type of asset )
a blockchain with 2 parties as nodes each running a ledger copy and a contract
assume direct payment ( no margin loan ) on purchase transaction
blockchains implement escrow transaction interface services in a smart contract
2 independent chains A and B can send messages using a common protocol ( gRPC or ??? )
party A wants to buy X from party B for Y currency amount
problems
how to ensure only authorized parties participate in the transaction
how to ensure both parties will execute their transaction once and only once to complete the purchase transaction
how to ensure that the purchase is cancelled if either party fails to complete their part of the purchase transaction within the designated time limit
pre-requisites
network connectivity
blockchain directory services and access
identity, registration and access management services for all parties in a transaction
each party implements the escrow transaction interfaces
each party communicates using one of the supported protocols: gRPC or ?
each party digital certificates to sign and execute transactions identifying the authorized party
gateway nodes connect 2 different logical blockchain networks directly or indirectly ( blockchain networks normally not physical but virtual overlay networks across multiple provider networks )
solution
use an escrow transction with smart contracts that
records each parties performance of the obligation
This follows a saga pattern to implement the escrow transaction (eg a purchase ) as a set of linked transactions in smart contracts
Singe Use Tokens are used to guarantee that only this single reservation transaction can be executed once by the designated party
step 0 - party A agrees to buy X from party B for Y currency amount agreeing to a set of policies to execute the transaction for the buyer and the seller roles
step 1 - reservation for payment from A to B with a token, reservation for delivery from B to A with a token
step 2 - when both reservations complete, the reservations are executable as smart contracts by each party
each party executes their reservation transaction via smart contract using the supplied single use token created for just this transaction
A executes B's reservation using the token from B
B executes A's reservation using the token from A
alternate scenarios
both reservations are not completed within the agreed time limit, all reservations and tokens are cancelled and resources revert to current owner control
the purchase policy agreed to may include automated contracts to execute actions to reverse one or both reservation executions or cancel the reservations updating the blockchain
step 3 - if both reservations are not executed as transactions within an agreed time limit, each party is notified to manage the purchase based on agreed policy
step 4 - when both reservations have been executed by each party, all parties are notified of the completion of the escrow transaction
step 5 - any dependent actors are notified of the completion of the purchase which may trigger additional transactions ( eg start an automatic purchase warranty etc )
Hashed Timelock Contract | Hashed Timelock Agreement
https://www.investopedia.com/terms/h/hashed-timelock-contract.asp
https://academy.binance.com/en/glossary/hashed-timelock-contract
Hash Time Locked Contracts (HTLCs) Explained
https://medium.com/liquality/hash-time-locked-contracts-htlcs-explained-e88aa99cc824
Refund scenario for HTLC
leverage HTLCs in Atomic Swaps, but also lead industry-wide efforts to standardize their implementation across different applications and blockchains.
Bitcoin UXTO model
https://river.com/learn/bitcoins-utxo-model/
- Bitcoin does not have accounts with balances. Instead, individual coins are owned by Bitcoin users.
- An Unspent Transaction Output (UTXO) is a discrete piece of bitcoin. UTXOs are used as the inputs of every Bitcoin transaction.
- The UTXO model makes Bitcoin more auditable, transparent, and efficient than traditional financial systems, which rely on accounts, balances, and third parties.
Potential Value Opportunities
...