Issue: Remote Procedures Calling
This document is part of the eXtensible Binary Universal Protocol project documentation. Provides description of the protocol for remote procedure calling.
Remote Procedures Calling
Protocol for remote procedure calls defines the way how to transmit parameters for remote procedure calls and how to return results and interface to identify available functions, especially those potentially remote. The goal is to provide a foundation for XBUP-based communication protocol built as alternative to protocols like HTTP, XML-RPC, WSDL, CORBA and more.
Common data formats are encapsulated using functional rules which defines which operations using the given data to be performed. Functional rules are implemented similarly as a function of the programs. They had list of parameters and the target to where result should be returned. Therefore it describes how to handle exceptions and how to define the type of result and parameters. Effort is focused on building a solution as close as possible to the XBUP protocol, so data transferred using this protocol may be used as part of the calls.
The solution should also include both stateful and stateless communication and support for transaction processing.
One possible solution is to use the direct evaluation of received data without any special construction. Parameters would be equivalent parameters and attributes of the used block. This solution is not suitable for transaction processing, where it is more appropriate to use the initiation, termination and transaction identification during it's lifetime. To address this problem there should be enough to wrap sent data using appropriate block, in order to distinguish the data returned by the service from data returned by the remote function. These wrapping blocks (for the request and return value) should be possible to omitted after a deal with client.
Remote Command Processing
Standard processing of the received command is to send a reply to the output channel. Primarily the root block is processed, optional auxiliary blocks may contain additional processing parameters. The actual execution task on the server side is fully in his responsibility. Sending the response may be started earlier than the known / send the result. As a call's return code the status code is returned and error conditions are defined as appropriate responses. Error conditions arising in the processing itself are not included in the basic definition of a remote call.
Groups of error conditions:
- Input processing errors
- Command execution errors
- Output processing errors
Valid Execution State
If the server will correctly process the command the following condition is returned and can optionally include the output returned by the executed command.
RPCStateOK
any RPCResult
Input Processing Errors
These error conditions occur in the processing of the input before execution of the real command. This might be following error states:
- Internal Server Error
- Service Unavailable (temporary, removed)
- Redirecting (temporary, single/multiple targets)
- Not Implemented
Command Execution Errors
These errors occur after you have read the command and are looking for valid handler to process it.
- Bad Request (unknown, reserved, insufficient parameters)
- Forbidden (temporary, required authorization, obsolete)
- Not Found
- Moved
Output Processing Errors
These errors occur when you run the handler and result is processed.
- Terminated (killed, resource overflow)
- Timeout
- Output truncated
Parameters Passing
In addition to own calls, we would certainly like to transmit the list of parameters. Seems appropriate to distinguish between mandatory and optional parameters.
It seems to be meaningful to consider the named and unnamed parameters. Possible implementation might use directly block type definition's mechanism a catalog extension NAME for block's naming.
Named Parameters
Transmitted parameters can be extended to give a name …
Connection Establishment
It is possible to establish a persistent connection to a service providing remote calls, as in the form of a sequence…
Transaction Processing
For the implementation of transaction processing following approach is used…
Specific Examples of Services
As a part of standard implementation, there is set of specific interfaces available, providing services for basic functionality, like for example catalog access…
Interface for the Available Remote Functions
This section describes the server interface which offers remote procedures execution.Features are described by identification keys, with which it is possible to trace their meaning.
Protocol of Remote Content
This protocol should provide alternative for the HTTP protocol, based on the principles of the XBUP protocol. Following basic functions are defined:
- GET(address) - read a value
- POST(address,data) - passing a value to given address (SEND,PUT - possible options without response)
- SET(address,data) - setting a value
- DELETE(address) - delete a value
The address here is represented similar to HTTP as a semi-structured text string. Data are then represented as a block of any type. Environment of this simple protocol expects on the remote side of the environment represented as a set of values on which it is possible to apply a set of commands CRUD]] (Create, Remove, Update, Delete). However, there is no requirement for atomicity, therefore the value written/read in the previous step may not be returned at the next reading in the same form (it is called stateless protocol).
Links
The list of related links:
RPC - Remote Procedure Call https://en.wikipedia.org/wiki/Remote_procedure_call
HTTP - HyperText Transfer Protocol https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
CORBA - Common Object Request Broker Architecture https://en.wikipedia.org/wiki/Corba
WSDL - Web Services Description Language https://en.wikipedia.org/wiki/Web_Services_Description_Language
CRUD -
Page Source