public DealState extends LinearState
Interface representing an agreement that exposes various attributes that are common. Implementing it simplifies implementation of general flows that manipulate many agreement types.
LinearState.ClauseVerifier<S extends LinearState,C extends CommandData>| Modifier and Type | Method and Description |
|---|---|
TransactionBuilder |
generateAgreement(Party notary)
Generate a partial transaction representing an agreement (command) to this deal, allowing a general
deal/agreement flow to generate the necessary transaction for potential implementations.
|
java.util.List<net.corda.core.crypto.Party> |
getParties()
Exposes the Parties involved in a generic way.
|
java.lang.String |
getRef()
Human readable well known reference (e.g. trade reference)
|
getLinearId, isRelevantgetContract, getParticipantsjava.lang.String getRef()
Human readable well known reference (e.g. trade reference)
java.util.List<net.corda.core.crypto.Party> getParties()
Exposes the Parties involved in a generic way.
Appears to duplicate participants a property of interface ContractState. However participants only holds public keys.
Currently we need to hard code Party objects into interface ContractStates. class Party objects are a wrapper for public
keys which also contain some identity information about the public key owner. You can keep track of individual
parties by adding a property for each one to the state, or you can append parties to the parties list if you
are implementing interface DealState. We need to do this as identity management in Corda is currently incomplete,
therefore the only way to record identity information is in the interface ContractStates themselves. When identity
management is completed, parties to a transaction will only record public keys in the interface DealState and through a
separate process exchange certificates to ascertain identities. Thus decoupling identities from
interface ContractStates.
TransactionBuilder generateAgreement(Party notary)
Generate a partial transaction representing an agreement (command) to this deal, allowing a general deal/agreement flow to generate the necessary transaction for potential implementations.
TODO: Currently this is the "inception" transaction but in future an offer of some description might be an input state ref
TODO: This should more likely be a method on the Contract (on a common interface) and the changes to reference a Contract instance from a ContractState are imminent, at which point we can move this out of here.