com.r3corda.protocols / NotaryProtocol / Service

Service

class Service : ProtocolLogic<Unit>

Checks that the timestamp command is valid (if present) and commits the input state, or returns a conflict if any of the input states have been previously committed.

Extend this class, overriding beforeCommit to add custom transaction processing/validation logic.

TODO: the notary service should only be able to see timestamp commands and inputs





Constructors

<init> Service(otherSide: SingleMessageRecipient, sendSessionID: Long, receiveSessionID: Long, timestampChecker: TimestampChecker, uniquenessProvider: UniquenessProvider)

Checks that the timestamp command is valid (if present) and commits the input state, or returns a conflict if any of the input states have been previously committed.

Properties

otherSide val otherSide: SingleMessageRecipient
receiveSessionID val receiveSessionID: Long
sendSessionID val sendSessionID: Long
timestampChecker val timestampChecker: TimestampChecker
uniquenessProvider val uniquenessProvider: UniquenessProvider

Inherited Properties

logger val logger: <ERROR CLASS>

This is where you should log things to.

progressTracker open val progressTracker: ProgressTracker?

Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track progress.

psm lateinit var psm: ProtocolStateMachine<*>

Reference to the Fiber instance that is the top level controller for the entire flow.

serviceHub val serviceHub: ServiceHub

Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts

Functions

beforeCommit open fun beforeCommit(wtx: WireTransaction, reqIdentity: Party): Unit

No pre-commit processing is done. Transaction is not checked for contract-validity, as that would require fully resolving it into a TransactionForVerification, for which the caller would have to reveal the whole transaction history chain. As a result, the Notary will commit invalid transactions as well, but as it also records the identity of the caller, it is possible to raise a dispute and verify the validity of the transaction and subsequently undo the commit of the input states (the exact mechanism still needs to be worked out)

call open fun call(): Unit

This is where you fill out your business logic.

Inherited Functions

receive fun <T : Any> receive(topic: String, sessionIDForReceive: Long): UntrustworthyData<T>
fun <T : Any> receive(topic: String, sessionIDForReceive: Long, clazz: Class<T>): UntrustworthyData<T>
send fun send(topic: String, destination: MessageRecipients, sessionID: Long, obj: Any): Unit
sendAndReceive fun <T : Any> sendAndReceive(topic: String, destination: MessageRecipients, sessionIDForSend: Long, sessionIDForReceive: Long, obj: Any): UntrustworthyData<T>
subProtocol fun <R> subProtocol(subLogic: ProtocolLogic<R>): R

Invokes the given subprotocol by simply passing through this ProtocolLogics reference to the ProtocolStateMachine and then calling the call method.

Inheritors

ValidatingNotaryProtocol class ValidatingNotaryProtocol : Service

A notary commit protocol that makes sure a given transaction is valid before committing it. This does mean that the calling party has to reveal the whole transaction history; however, we avoid complex conflict resolution logic where a party has its input states "blocked" by a transaction from another party, and needs to establish whether that transaction was indeed valid