XML-RPC

1
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.
2
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.

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

4
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)) lt 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)) lt
0) return 2 nread read(sockfd, time_buf,
sizeof(time_buf)) time_bufnread '\0'
close(sockfd) return 0
5
model
6

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

7

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

8
Basic process for building server

• Server program defines the servers 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.

9
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

10
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

11
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 servers 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.

12
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 its doing
• XML is broad support

13
XML-RPC

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

14
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
• lt?xml version"1.0"?gt
• ltmethodCallgt ltmethodNamegtexamples.getStateNamelt/
  methodNamegt ltparamsgt
• ltparamgt ltvaluegtlti4gt41lt/i4gtlt/valuegt lt/paramgt
  lt/paramsgt
• lt/methodCallgt

15
header requirements

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

16
Payload format

• The payload is in XML, a single ltmethodCallgt
  structure.
• The ltmethodCallgt must contain a ltmethodNamegt
  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
  ltmethodCallgt must contain a ltparamsgt sub-item.
  The ltparamsgt sub-item can contain any number of
  ltparamgts, each of which has a ltvaluegt.

17

• Scalar ltvaluegts
• ltvaluegts can be scalars
• lti4gt or ltintgt
• ltbooleangt
• ltstringgt
• ltdoublegt
• ltdateTime.iso8601gt
• ltbase64gt

18
ltstructgts A value can also be of type ltstructgt.
A ltstructgt contains ltmembergts and each ltmembergt
contains a ltnamegt and a ltvaluegt. Here's an
example of a two-element ltstructgt ltstructgt
ltmembergt ltnamegtlowerBoundlt/namegt
ltvaluegtlti4gt18lt/i4gtlt/valuegt lt/membergt
ltmembergt ltnamegtupperBoundlt/namegt
ltvaluegtlti4gt139lt/i4gtlt/valuegt lt/membergt
lt/structgt ltstructgts can be recursive, any ltvaluegt
may contain a ltstructgt or any other type,
including an ltarraygt.
19

• ltarraygts
• A value can also be of type ltarraygt.
• An ltarraygt contains a single ltdatagt element,
  which can contain any number of ltvaluegts.
• Here's an example of a four-element array
• ltarraygt
• ltdatagt
• ltvaluegtlti4gt12lt/i4gtlt/valuegt ltvaluegtltstringgtEgyp
  tlt/stringgtlt/valuegt ltvaluegtltbooleangt0lt/booleangtlt/v
  aluegt
• ltvaluegtlti4gt-31lt/i4gtlt/valuegt
• lt/datagt
• lt/arraygt
• ltarraygt elements do not have names.
• You can mix types as the example above
  illustrates.
• ltarraysgts can be recursive, any value may contain
  an ltarraygt or any other type, including a
  ltstructgt

20

• Response example
• HTTP/1.1 200 OK
• Connection close
• Content-Length 158
• Content-Type text/xml
• Date Fri, 17 Jul 1998 195508 GMT
• Server UserLand Frontier/5.1.2-WinNT
• lt?xml version"1.0"?gt
• ltmethodResponsegt
• ltparamsgt
• ltparamgt
• ltvaluegtltstringgtSouth Dakotalt/stringgtlt/valuegt
• lt/paramgt
• lt/paramsgt
• lt/methodResponsegt

21
Response format

• 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 ltmethodResponsegt, which can contain
  a single ltparamsgt which contains a single ltparamgt
  which contains a single ltvaluegt.
• The ltmethodResponsegt could also contain a ltfaultgt
  which contains a ltvaluegt which is a ltstructgt
  containing two elements, one named ltfaultCodegt,
  an ltintgt and one named ltfaultStringgt, a ltstringgt.
  
• A ltmethodResponsegt can not contain both a ltfaultgt
  and a ltparamsgt.

22

• Fault example
• HTTP/1.1 200 OK
• Connection close
• Content-Length 426
• Content-Type text/xml
• Date Fri, 17 Jul 1998 195502 GMT
• Server UserLand Frontier/5.1.2-WinNT
• lt?xml version"1.0"?gt
• ltmethodResponsegt
• ltfaultgt
• ltvaluegt
• ltstructgt
• ltmembergt
• ltnamegtfaultCodelt/namegt
• ltvaluegtltintgt4lt/intgtlt/valuegt
• lt/membergt
• ltmembergt
• ltnamegtfaultStringlt/namegt

23

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

24

• 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

25

• A Perl Client example
• use FrontierClient
• Make an object to represent the XML-RPC server.
  
• server_url 'http//xmlrpc-c.sourceforge.net/api
  /sample.php'
• server FrontierClient-gtnew(url gt
  server_url)
• Call the remote server and get our result.
• result server-gtcall('sample.sumAndDifference'
  , 5, 3)
• sum result-gt'sum'
• difference result-gt'difference'
• print "Sum sum, Difference difference\n"

26

• Reference
• Demo
• http//www.scottandrew.com/xml-rpc/blogger/
• http/www.xmlrpc.com
• http//www.cs.nyu.edu/rgrimm/teaching/sp03-web/032
  503.pdf
• http//hissa.nist.gov/rbac/titlehce/node19.html
• http//nscp.upenn.edu/aix4.3html/aixprggd/progcomc
  /ch8_rpc.htm