XML-RPC Protocol

XML-RPC is a remote procedure call protocol encoded in XML (Extensible Markup Language).

Protocol name in port definition: xmlrpc.

XML-RPC Transport

XML-RPC has the characteristic that all exchanged variables need to be listed in a child array param (this one becomes XML-RPC's params vector). Arrays need to be passed as child values called array eg. val.array[0] = 1, in which case all other eventual child values and the root of a particular value are ignored.

Some other notes to value mapping: Jolie variables of type long are unsupported in XML-RPC and not considered further. Date values (dateTime.iso8601) cannot be generated within Jolie and are considered strings, base64 values are mapped into raw.

This is an example of a primitive XML-RPC server:

execution { concurrent }
type SumRequest:void {
.param:void {
.z:void {
type SumResponse:void {
interface SumInterface {
inputPort MyInput {
Location: "socket://localhost:8000/"
Protocol: xmlrpc { .debug = true }
Interfaces: SumInterface
[ sum( request )( response ) {
response.param = request.param.x + request.param.y + request.param.z.a + request.param.z.b
}]{ nullProcess }

XML-RPC Parameters

type XmlRpcConfiguration:void {
* Defines the aliases for operation names.
* Jolie does not support operation names with dots (e.g., myOp.operation),
* aliases are expressed as protocol parameters as
* aliases.opName = "aliasName"
* Default: none
* Supported values: any valid operation alias definition
.aliases: void {
.operationName[ 1, * ]: void {
.operationName: string
* Defines whether the underlying connection should be kept open.
* Default: false
.keepAlive?: bool
* Defines whether debug messages should be activated
* Default: false
.debug?: bool
* Enable the HTTP content compression
* On client side the "Accept-Encoding" header is set to "gzip, deflate"
* or according to "requestCompression". On the server the compression is
* enabled using gzip or deflate as the client requested it. gzip is
* preferred over deflate since it is more common.
* If the negotiation was successful, the server returns the compressed data
* with a "Content-Encoding" header and an updated "Content-Length" field.
* Default: true
* Enables the HTTP request compression feature.
* HTTP 1.1 per RFC 2616 defines optional compression also on POST requests,
* which works unless HTTP errors are returned, for instance 415 Unsupported
* Media Type.
* Jolie allows to set the parameter to "gzip" or "deflate" which overrides
* also the "Accept-Encoding" header. This invites the server to use the same
* algorithm for the response compression. Invalid values are ignored.
* If all conditions are met, the request content gets compressed, an
* additional "Content-Encoding" header added and the "Content-Length"
* header recalculated.
* Default: none/off