Concept: Remote Invocation

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 in procedural programming languages. 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 of the block 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 native processing is execution mode where server establish input stream where it receive blocks representing commands and output stream where to send replies. Primarily the root block of the commands is processed, optional auxiliary blocks may contain additional processing parameters.

The actual execution task on the server side is fully in its responsibility. Sending the response may be started earlier than the actual complete result is known.

If the server is able to correctly process the command the following block is returned and can optionally include the output returned by the executed command:

InvocationSuccesful
  any Result
  any ExecutionException

If server is unable to invocate method, it will return following block:

InvocationFailed
  any ErrorInfo

Some of these errors can be also fatal, which will lead to connection termination.

These error conditions typically occur in the processing of the input block before execution of the real command.

Input block processing:

• Internal Server Error (out of memory, dead-lock, …)
• Service Unavailable (temporary, removed)
• Service Redirecting (temporary, single/multiple targets)
• Forbidden (temporary, required authorization, obsolete)
• Parsing Exception

Before execution:

• Bad Request (unknown block, reserved, insufficient parameters)
• Command Not Found
• Command Moved (Command Redirecting)
• Resource Not Available

Execution exceptions are typically defined in command execution, which is not part of the server responsibility.

Server execution exceptions:

• Not Implemented
• Forbidden (temporary, required authorization, obsolete)
• Terminated (killed, resource overflow)
• Timeout
• Output truncated

Also if there is failure during partial result transmission, connection might be terminated with general ExecutionException.

Handled execution provides ability to execute commands safely with partial data processing. Data are sent and received using data blocks. It is slightly less effective and requires native data transformation. This method can be used using following block:

HandledInvocation
  any Command

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 -