This document is part of the eXtensible Binary Universal Protocol project documentation. Provides description of the protocol for remote procedure 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.

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

If the server will correctly process the command the following condition is returned and can optionally include the output returned by the executed command.

RPCState_OK
any RPCResult

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

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

These errors occur when you run the handler and result is processed.

• Terminated (killed, resource overflow)
• Timeout
• Output truncated

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.

Transmitted parameters can be extended to give a name …

It is possible to establish a persistent connection to a service providing remote calls, as in the form of a sequence…

For the implementation of transaction processing following approach is used…

As a part of standard implementation, there is set of specific interfaces available, providing services for basic functionality, like for example catalog access…

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.

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).

The list of related links:

RPC - Remote Procedure Call http://en.wikipedia.org/wiki/Remote_procedure_call
HTTP - HyperText Transfer Protocol http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
CORBA - Common Object Request Broker Architecture http://en.wikipedia.org/wiki/Corba
WSDL - Web Services Description Language http://en.wikipedia.org/wiki/Web_Services_Description_Language
CRUD -