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