Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://manosbatsis.github.io/partiture/
Compact component framework for your Corda apps
https://manosbatsis.github.io/partiture/
Last synced: about 1 month ago
JSON representation
Compact component framework for your Corda apps
- Host: GitHub
- URL: https://manosbatsis.github.io/partiture/
- Owner: manosbatsis
- License: lgpl-3.0
- Created: 2019-01-30T13:23:16.000Z (over 5 years ago)
- Default Branch: master
- Last Pushed: 2021-07-12T00:22:32.000Z (about 3 years ago)
- Last Synced: 2024-05-13T13:34:00.037Z (4 months ago)
- Language: Kotlin
- Homepage: https://manosbatsis.github.io/partiture/
- Size: 1.05 MB
- Stars: 5
- Watchers: 3
- Forks: 2
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
- awesome-corda - Partiture - A compact component framework for your CorDapps. Currently, its primary goal is to simplify flow composition. (Tools)
README
# Partiture [](https://mvnrepository.com/artifact/com.github.manosbatsis.partiture/partiture) [](https://travis-ci.com/manosbatsis/partiture)
Partiture is a compact component framework for your Corda apps.
## Documentation
See https://manosbatsis.github.io/partiture
## What Does It Do?
For the time being, Partiture's primary goal is flow composition.
The following sections demonstrate simple examples of initiating and
responding flows.
### Sample Initiating Flow
Start with a `Yo!` sending flow, that uses `List` and `List`
for `PartitureFlow`'s `IN` and `OUT` type variables respectively:
```kotlin
/** Create a Yo! transaction/state for each input recipient/party */
@InitiatingFlow
@StartableByRPC
class YoFlow(input: List) : PartitureFlow, List>(
// Can be any type, just match with PartitureFlow's IN generic argument above
input = input
) {
/** Override to manually init the flow's CallContext */
override fun processInput(): CallContext {
// do stuff...
}
/** Override to manually create the flow's OUT instance */
override fun processOutput(): List {
// do stuff...
}
}
```
Better yet, use an `InputConverter` and `OutputConverter` instead of
overriding `processInput()` and `processOutput()` as we did above,
thus reducing the flow to a declaration-only class that binds everything together:
```kotlin
/** Create a Yo! transaction/state for each input recipient/party */
@InitiatingFlow
@StartableByRPC
class YoFlow(input: List) : PartitureFlow, List>(
// Can be any type, just match with PartitureFlow's IN generic argument above
input = input,
inputConverter = YoInputConverter(),// Our custom IN converter
outputConverter = FinalizedTxOutputConverter()) // build-in converter matching OUT
// No implementation needed!
```
Both of the above flow implementations will:
1. Use the overriden `processInput()` or provided `inputConverter` respectively to initialize a `CallContext` with a call/tx entry per input `Party`
2. Use the build-in _default_ `TxStrategy` (since we have not provided one) on each of `CallContext.entries` to:
1. Sign an initial transaction
2. Create flow sessions for counter-parties, if any exist
3. Perform an identity sync if any own anonymous parties are participating in the input/output states in context
4. Gather and verify counter-party signatures
5. Verify the original transaction builder
6. Finalize the transaction
3. Use the provided `outputConverter` to produce and return the flow's `call()` result, i.e. a signed TX per _Yo!_ state created
### Sample Responding Flow
This is our responder flow. It uses the biuld-in `SimpleTypeCheckingResponderTxStrategy`:
```kotlin
@InitiatedBy(YoFlow::class)
class YoFlowResponder(
otherPartySession: FlowSession
) : PartitureResponderFlow(
otherPartySession = otherPartySession,
responderTxStrategy =
SimpleTypeCheckingResponderTxStrategy(YoContract.YoState::class.java)
)
```
The above responder flow will verify the transaction
and ensure all output states are instances of `YoState` before signing.
## Partiture Components
Partiture provides a number of build-in components:
input/output converters, TX strategies, responder strategies, flow utilities
and so on.
However, it's main feature is the conventions and ease with which you can develop and
reuse components specifically for your application requirements - see the
[documentation](https://manosbatsis.github.io/partiture) for more details.