XML-RPC Remote Procedure Call (RPC) is a model that specifies how cooperating processes on different nodes in a heterogeneous computing environment can communicate and coordinate activities. The paradigm of RPC is based on the concept of a procedure call in a higher level programming language. The semantics of RPC are almost identical to the semantics of the traditional procedure call. The major difference is that while a normal procedure call takes place between procedures of a single process in the same memory space on a single system, RPC takes place between processes on clients and servers in a heterogeneous computing environment.

Ordinary procedure call Value parameters the actual value of the parameter is placed on the stack. This can then be used and modified by the procedure without any change to any original variable. Reference parameters The address of the parameter is passed into the procedure. Any use of the parameter within the procedure uses the address to access/change the value.

Remote procedure call The remote procedure call act like a procedure call, but act across the network. The process makes a remote procedure call by pushing its parameters and a return address onto the stack, and jumping to the start of the procedure. The procedure itself is responsible for accessing and using the network. After the remote execution is over, the procedure jumps back to the return address. The calling process then continues.

Without RPC Consider how you would implement a procedure to find the time on a remote machine as a string, using the IP socket calls: int remote_time(char *machine, char *time_buf) { struct sockaddr_in serv_addr; int sockfd; int nread; if (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) return 1; serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = inet_addr(machine); serv_addr.sin_port = htons(13); if (connect(sockfd, &serv_addr, sizeof(serv_addr)) < 0) return 2; nread = read(sockfd, time_buf, sizeof(time_buf)); time_buf[nread] = '\0'; close(sockfd); return 0; }

model

1.The client calls the local stub procedure. The stub packages up the parameters into a network message. This is called marshalling. 2.Networking functions in the O/S kernel are called by the stub to send the message. 3.The kernel sends the message(s) to the remote system. This may be connection-oriented or connectionless. 4.A server stub unmarshals the arguments from the network message. 5.The server stub executes a local procedure call. 6.The procedure completes, returning execution to the server stub. 7.The server stub marshals the return values into a network message. 8.The return messages are sent back. 9.The client stub reads the messages using the network functions. 10.The message is unmarshalled. and the return values are set on the stack for the local process.

When the calling process calls a procedure, the action performed by that procedure will not be the actual code as written, but code that begins network communication. It has to connect to the remote machine, send all the parameters down to it, wait for replies, do the right thing to the stack and return. This is the client side stub. The server side stub has to wait for messages asking for a procedure to run. It has to read the parameters, and present them in a suitable form to execute the procedure locally. After execution,it has to send the results back to the calling process.

Basic process for building server Server program defines the server’s interface using an interface definition language(IDL) The IDL specifies the names, params, and type for all server procedures A stub compiler reads the IDL and produces two stub procedures for each server procedure: a client-side stub and a server-side stub The server writer writes the server and links it with the server-side stubs; the client writes her program and links it with the client-side stubs.

RPC Binding The server, when starts up, exports its interface, identifying itself to a network name server and telling the local runtime its dispatcher address The client, before issuing any calls, imports the server, which causes the RPC runtime to lookup the server through the name service and contact the requested server to setup a connection

RPC Stubs A client-side stub looks to the client as if it were a callable server procedure A server-side stub looks to the server as if it were a calling client The client program thinks it is calling the server, in fact it calling the client stub The server program thinks it is called by client, in fact, it is called by the server stub The stubs send messages to each other to make the RPC happen

RPC Marshalling Marshalling is the packing of procedure parameters into a message packet. The RPC stubs call procedures to marshal(or unmarshal)all parameters. On the client side, the client stub marshals the parameters into the call packet; on the server side the server stub unmarshals the parameters in order to call the server’s procedure On the return, the server stub marshals return parameters into the return packet; the client stub unmarshals return parameters and returns to the client.

XML-RPC XML-RPC is remote procedure call using HTTP as the transport and XML as the marshalling format. XML is as important as c++ or java. With XML, it is easy to marshal With XML, it is to see what it’s doing XML is broad support

An XML-RPC message is an HTTP-POST request. The body of the request is in XML, and the value returned is also XML. Procedure parameters can be scalars, numbers, strings, dates and structures. XML-RPC

Request example POST /RPC2 HTTP/1.0 User-Agent: Frontier/5.1.2 (WinNT) Host: betty.userland.com Content-Type: text/xml Content-length: 181 examples.getStateName 41

The format of the URI is not specified. For example, it could be empty, a single slash, if the server is only handling XML- RPC calls. However, if the server is handling a mix of incoming HTTP requests, we allow the URI to help route the request to the code that handles XML-RPC requests. (the URI is /RPC2, telling the server to route the request to the "RPC2" responder.) A User-Agent and Host must be specified. The Content-Type is text/xml. The Content-Length must be specified and must be correct. header requirements

Payload format The payload is in XML, a single structure. The must contain a sub- item, a string, containing the name of the method to be called. It's entirely up to the server to decide how to interpret the characters in a methodName. The methodName could be –the name of a file containing a script. –the name of a cell in a database table. –A path to a file If the procedure call has parameters, the must contain a sub-item. The sub- item can contain any number of s, each of which has a.

Scalar s s can be scalars – or –

s A value can also be of type. A contains s and each contains a and a. Here's an example of a two-element : lowerBound 18 upperBound 139 s can be recursive, any may contain a or any other type, including an.

s A value can also be of type. An contains a single element, which can contain any number of s. Here's an example of a four-element array: 12 Egypt elements do not have names. You can mix types as the example above illustrates. s can be recursive, any value may contain an or any other type, including a

Response example HTTP/ OK Connection: close Content-Length: 158 Content-Type: text/xml Date: Fri, 17 Jul :55:08 GMT Server: UserLand Frontier/5.1.2-WinNT South Dakota

Unless there's a lower-level error, always return 200 OK. The Content-Type is text/xml. Content-Length must be present and correct. The body of the response is a single XML structure, a, which can contain a single which contains a single which contains a single. The could also contain a which contains a which is a containing two elements, one named, an and one named, a. A can not contain both a and a. Response format

Fault example HTTP/ OK Connection: close Content-Length: 426 Content-Type: text/xml Date: Fri, 17 Jul :55:02 GMT Server: UserLand Frontier/5.1.2-WinNT faultCode 4 faultString Too many parameters.

Firewalls. The goal of this protocol is to lay a compatible foundation across different environments, no new power is provided beyond the capabilities of the CGI interface. Firewall software can watch for POSTs whose Content- Type is text/xml. Discoverability. We wanted a clean, extensible format that's very simple. It should be possible for an HTML coder to be able to look at a file containing an XML-RPC procedure call, understand what it's doing. Easy to implement. We also wanted it to be an easy to implement protocol that could quickly be adapted to run in other environments or on other operating systems.

Disadvantages of xml-rpc –XML-RPC is impoverished in the type of data it can transmit and obese in its message size –XML-RPC transmits messages lacking statefulness and incurs channel bottlenecks. –Compared to SOAP, XML-RPC lacks both important security mechanisms and a robust object model –As a data representation, XML-RPC is slow, cumbersome, and incomplete compared to native programming language mechanisms like Java's

A Perl Client example use Frontier::Client; # Make an object to represent the XML-RPC server. $server_url = ' $server = Frontier::Client->new(url => $server_url); # Call the remote server and get our result. $result = $server->call('sample.sumAndDifference', 5, 3); $sum = $result->{'sum'}; $difference = $result->{'difference'}; print "Sum: $sum, Difference: $difference\n";

Reference: Demo web/ pdf omc/ch8_rpc.htm