| Both sides previous revision Previous revision Next revision | Previous revision |
| dido:99_annexes:annex-b-terms-and-definitions:r:rpc [2026/07/11 11:15] – ↷ Links adapted because of a move operation nick_dido | dido:99_annexes:annex-b-terms-and-definitions:r:rpc [2026/08/04 07:09] (current) – ↷ Links adapted because of a move operation nick_dido |
|---|
| An RPC interface typically presents interactions as named operations with input parameters, output results, errors, and invocation semantics. RPC implementations may use different protocols, data formats, service definitions, transport mechanisms, authentication mechanisms, and runtime frameworks. | An RPC interface typically presents interactions as named operations with input parameters, output results, errors, and invocation semantics. RPC implementations may use different protocols, data formats, service definitions, transport mechanisms, authentication mechanisms, and runtime frameworks. |
| |
| In the FX Demo [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]], RPC references identify possible implementation mechanisms. RPC does not define the logical meaning of a [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]], [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]], data structure, policy decision, command, acknowledgement, release package, or runtime plane. | In the FX Demo [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]], RPC references identify possible implementation mechanisms. RPC does not define the logical meaning of a [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]], [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Node]], data structure, policy decision, command, acknowledgement, release package, or runtime plane. |
| |
| An RPC interface can realise, expose, or support a logical communication pattern selected by an implementation profile. The logical architecture remains independent of RPC operation names, parameter formats, service definitions, transport protocols, framework selection, and deployment boundaries. | An RPC interface can realize, expose, or support a logical communication pattern selected by an implementation profile. The logical architecture remains independent of RPC operation names, parameter formats, service definitions, transport protocols, framework selection, and deployment boundaries. |
| |
| ===== Definition ===== | ===== Definition ===== |
| ===== Source ===== | ===== Source ===== |
| |
| Generalised from common distributed-systems usage and specialised for use in the FX Demo [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]]. | Generalised from common distributed-systems usage and specialized for use in the FX Demo [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]]. |
| |
| ===== Note ===== | ===== Note ===== |
| |
| RPC is not a logical [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]], [[dido:99_annexes:annex-b-terms-and-definitions:a:api|Application Programming Interface (API)]], command, data structure, runtime plane, deployment artefact, or policy mechanism. An RPC interface may implement or expose an architectural interaction selected by an implementation profile. | RPC is not a logical [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]], [[dido:99_annexes:annex-b-terms-and-definitions:a:api|Application Programming Interface (API)]], command, data structure, runtime plane, deployment artifact, or policy mechanism. An RPC interface may implement or expose an architectural interaction selected by an implementation profile. |
| |
| ===== Example ===== | ===== Example ===== |