Ryan moquin ching ping chan joshua tina chatterjee amit shah l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 83

XML-RPC and SOAP PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Ryan Moquin Ching-Ping Chan (Joshua) Tina Chatterjee, Amit Shah. XML-RPC and SOAP . What is XML?. XML - E X tensible Markup Language Defines rules for structure, but not content. Provides an format that is human-readable and very flexible. XML is inefficient for data transfer

Download Presentation


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Ryan moquin ching ping chan joshua tina chatterjee amit shah l.jpg

Ryan Moquin

Ching-Ping Chan (Joshua)

Tina Chatterjee, Amit Shah


What is xml l.jpg

What is XML?

XML - EXtensible Markup Language

Defines rules for structure, but not content.

Provides an format that is human-readable and very flexible.

XML is inefficient for data transfer

Tradeoff: While XML is inefficient, it's more readable and descriptive than a binary format.

XML is typically used to define other markup languages.

ie. XHTML – HTML conforming to XML rules.

Xml for communication l.jpg

XML for communication

XML data has no required definition (only syntax) therefore it's used to define protocols and data exchange formats

i.e. SOAP, WSDL, ebXML

XML is a purely textual representation of data, it is inefficient to send over a network, therefore compression should be used (text compresses very well).

XML is typically used for interapplication data transfer due it's ease of modification and understanding.

Xml rpc l.jpg


Remote Procedure Calling has had many incarnations usually very complex and difficult to understand.

XML-RPC is a protocol created to perform RPC functions using an XML definition and therefore provide more readability and understandability.

The merger of XML and RPC has generated a lot of interest, people like the simplicity and readability XML brings.

Xml rpc definition l.jpg

XML-RPC: Definition

XML-RPC is a protocol that provides RPC functionality in an XML format.

The whole protocol description can be printed on about 2 pages.

XML-RPC defines most data types that are necessary for communication while staying very simple.

Xml rpc for the java developer l.jpg

XML-RPC for the Java developer

XML-RPC provides a way to interoperate with clients on different platforms, not just ones running Java.

The decoupling of a protocol from a specific language, such as Java, provides interoperability with legacy systems.

Not everyone uses Java, uniting different platforms requires a platform independent protocol.

Xml rpc implementation l.jpg

XML-RPC Implementation

Now we elaborate on XML-RPC by building some actual working Java code, using XML-RPC.

We do that by implementing a “Hello World” type program.

A hello world application l.jpg

A “Hello World” application

First, our XML-RPC handler registers a server.

This handler takes in a Java String parameter, the user’s name, and returns “Hello” and the user’s name.

Then we need a server to make our handler available for XML-RPC clients.

Finally, we build a simple client to connect to the server and request the method invocation.

Step 1 getting xml rpc libraries l.jpg

Step-1: Getting XML-RPC Libraries

The XML-RPC classes are packages within the zip file, xmlrpc-1.1-src.zip. This can be obtained from http://xml.apache.org.

Extract all the source code in the xmlrpc-java/src/ directory. There is no included jar distribution, so manual compilation of these classes is required.

Once compiled, you may want to jar the classes yourself for easy inclusion in your classpath.

Other Information about XML-RPC and links to libraries can be obtained from


The xml rpc library l.jpg

The XML-RPC Library

The core distribution is made up of eight classes, all in the xmlrpc package.

XmlRpcServer, which is the server itself;

XmlRpcHandler, which allows total control

over XML encoding and processing; and

several support and helper classes like

XmlRpcException, XmlRpcServlet, WebServer.

Not included in the distribution, but required for operation, are the SAX classes and a SAX driver.

Slide11 l.jpg


Once you have all the source files compiled, ensure that the XML-RPC classes, SAX classes, and your XML parser classes are all in your environment’s class path.

This should have you ready to write your own custom code and start the process of saying “hello”.

What is a handler l.jpg

What is a handler ?

An XML-RPC handler is a method or set of methods that takes an XML-RPC request, decodes it’s contents, and dispatches the request to a class and method.

A response handler, or simply handler, is any method that can be invoked by an XML-RPC handler.

Step 2 writing the handler l.jpg

Step-2: Writing the handler

With the XML-RPC libraries for Java, we do not need to write an XML-RPC handler, as one is included in the XmlRpcServer class. We only need to write a class with one or more methods (the response handler) that we register with the server.

Creating a response handler requires no subclassing or other special treatment in our code. Any method can be invoked via XML-RPC as long as it’s parameter and return types are supported (able to be encoded) by XML-RPC.

Xml rpc supported java types l.jpg

XML-RPC Supported Java types

















XML-RPC Data Type Java Data Type

Handler class with method to be invoked remotely l.jpg

Handler Class with Method to be Invoked Remotely

public class HelloHandler {

/*This will take in a <code>String</code> and return a hello message to the user */

public String sayHello(String name) {

return “Hello “ + name;



Slide16 l.jpg


In the above example, the method signature takes in and return legal XML-RPC parameters, so we can safely register it with our XML-RPC server and know it will be callable via XML-RPC.

Rmi vs rpc l.jpg


In RMI, a remote interface has the method signature for each remote method. If a method is implemented on the server class, but no matching signature is added to the remote interface, the new method cannot be invoked by an RMI client. This makes for quite a bit of code modification and recompilation in the development of RMI classes.

This process is considered easier and more flexible in RPC.

Working of the rpc l.jpg

Working of the RPC

In RPC, when a request comes in to an RPC server, the request contains a set of parameters and a textual value, usually in the form “cn.mn”. This signifies to the RPC server that the requested method is in the class “cn” and is named “mn”. The RPC server then tries to find a matching class and method that takes as input to that method parameter types that match the types within the RPC request. Once a match is made, the method is called, and the result is encoded and sent back to the client.

Advantage of xml rpc over rmi l.jpg

Advantage of XML-RPC over RMI

One of the major advantages of XML-RPC over RMI is that the requested methods are never explicitly defined in XML-RPC servers, but rather in the request from the client. Only a class instance is registered with the XML-RPC server. You can add methods to that class, restart the XML-RPC server with no code changes, and then immediately request the new methods within your client code.

There are no client stubs, skeletons, or interfaces that must be updated.

Step 3 writing the server l.jpg

Step-3: Writing the Server

With our handler ready, we need to write a program to start up the XML-RPC server, listen for requests, and dispatch these requests to the handler. We use the WebServer class as the request handler.

Although we could use a Java servlet, using this lightweight web server implementation allows us to avoid running a servlet engine on our XML-RPC server. A port number should be given at the command line when the server is started and the server will listen at that port for XML-RPC requests until shutdown.

Skeleton for hello xml rpc server l.jpg

Skeleton for Hello XML-RPC Server

import java.io.IOException;

import org.apache.xmlrpc.WebServer;

import org.apache.xmlrpc.XmlRpc;

public class HelloServer {

public static void main(String[] args) {

if (args.length < 1) {


“Usage: java HelloServer [port]”);



Server code continued l.jpg

Server code continued…

try {

// Use the Apache Xerces SAX Driver



// Start the server


“Sarting XML-RPC server…”);

WebServer server = new WebServer


Server code continued23 l.jpg

Server code continued…

//Register our handler class


(“hello”, new HelloHandler());


(“Now accepting requests…”);

} catch (ClassNotFoundException e) {


(“Could not locate SAX Driver”);

} catch (IOException e) {

System.out.println(“Could not start server: “ +




Sample output on running the server l.jpg

Sample output on running the server

$ java HelloServer 8777

Starting XML-RPC Server….

Registered HelloHandler class to “hello”

Now accepting requests…

Step 4 writing the client l.jpg

Step-4: Writing the Client

We implement the client by using the XmlRpcClient & XmlRpc classes from the class library. These classes take care of many of the details on the client side. We need to instantiate the XmlRpcClient class, which requires the hostname of the XML-RPC server to connect to.

For handling encoding of the requests, we must again set the SAX driver class to use with the setDriver() method.

Client code l.jpg

Client Code

import java.io.IOException;

import java.net.MalformedURLException;

import java.util.Vector;

import org.apache.xmlrpc.XmlRpc;

import org.apache.xmlrpc.XmlRpcClient;

import org.apache.xmlrpc.XmlRpcException;

public static void main(String args[]) {

if (args.length < 1) {


“Usage: java HelloClient [your name]”);



Client code continued l.jpg

Client code continued…

try {

// Use the Apache Xerces SAX Driver



// Specify the server

XmlRpcClient client =

new XmlRpcClient(http://localhost:8777/);

// Create Request

Vector params = new Vector();


Client code continued28 l.jpg

Client code continued…

// Make a request and print the result

String result =

(String)client.execute(“hello.sayHello”, params);


“Response from server: “ + result);

} catch (ClassNotFoundException e) {


“Could not locate SAX Driver”);

} catch (MalformedURLException e) {


“Incorrect URL for XML-RPC server format: ” + e.getMessage());

Client code continued29 l.jpg

Client code continued…

} catch (XmlRpcException e) {


“XML-RPC Exception: “ + e.getMessage());

} catch (IOException e) {


“IO Exception: “ + e.getMessage());



Running the application 1 l.jpg

Running the application[1]

First make sure that you have the XML-RPC classes and your code in your environment class path.

You also need to confirm that Apache Xerces or another SAX driver is in your class path and accessible, as the examples must load these classes for parsing.

Once that is set up, start the HelloServer class by giving it a port number.

Running the application 2 l.jpg

Running the application[2]


$ java HelloServer &

Starting XML-RPC Server…

Registered HelloHandler class to “hello”

Now accepting requests…

Run your client by specifying your name to the program as a command-line argument. You will quickly see a response as the HelloServer receives your request, handles it, and returns the result of the sayHello() method, which is then printed by the client.

Sample output l.jpg

Sample Output

$ java HelloClient Tina

Response from server: Hello Tina

Xml rpc vs soap l.jpg



basic scalars yes yes

structs yes yes

arrays yes yes

named structs

and arrays no yes

detailed fault handling yes yes

short learning curve yes no

Xml rpc vs soap continued l.jpg

XML-RPC vs. SOAP Continued


Developers specified

character set no yes

Developer defined data types no yes

Can specify recipient no yes

require client understanding no yes

message specific

processing instructionsno yes

Xml rpc vs corba l.jpg


Getting Started - With CORBA, you'll need a huge amount of knowledge, downloading, and configuring. With XML-RPC, you'll be able to do something useful in less than thirty minutes.

Bandwidth - The XML data format adds overhead compared to CORBA's binary format. If this becomes a problem, one could compress the text en route.

Latency - Creating a connection for each invocation could add up. CORBA has configurable policies to let you choose how this works. With XML-RPC, you'll have to figure out something with persistent HTTP.

Xml rpc vs corba continued l.jpg

XML-RPC Vs CORBA Continued

Rigid Interface Specs - CORBA forces you to explicitly define interfaces for types. With XML-RPC you don't have to (though you can via DTD's). It's up to you to decide which is better.

Co-location advantages - That is, if the sender and implementer of a method are both on the same machine or program, CORBA does what it can to reduce the overhead of the invocation. One might wonder, though, how often this is a problem -- why are you using a distributed object system if loopback calls are too expensive?

Why soap l.jpg

Why SOAP ?

SOAP is the successor to XML-RPC

SOAP is a broad protocol that forms a layer in the Web Services stack.

SOAP includes RPC as well as other communication types in it's definition.

Slide38 l.jpg

What Does SOAP Define?

  • Standard expression for

    • message envelopes

    • headers

    • Bodies

  • Standard encoding rules for structured data

  • RPC mechanism

Slide39 l.jpg

SOAP Defined

  • SOAP is a simple, lightweight XML protocol for exchanging structured and typed information on the Web

  • Overall design goal: KISS

    • - Can be implemented in a weekend

    • - Stick to absolute minimum of functionality

  • Make it Modular and Extensible

    • - No application semantics and no transport semantics

    • - Think “Web based datagram”

Slide40 l.jpg

SOAP Definition (Cont)

  • A Light weight protocol for information exchange in a distributed environment

    • Typically it's XML over HTTP.

    • Usually used for Web Services.

Slide41 l.jpg

SOAP Generality

  • use any XML content as payload.

  • use SOAP in an RPC model or any other model.

  • use SOAP object encoding with or without envelopes and RPC.

Slide42 l.jpg

SOAP-based Protocols

Are based on Unicode.

  • Can transmit structured information.

  • Are automatically extensible.

  • Can inherit the SOAP information encoding system

Slide43 l.jpg


SOAP does not address certain issues:

  • object references

  • distributed garbage collection

  • batch messaging

  • Other, post-SOAP specs may arise to handle these.

Slide44 l.jpg

SOAP is a Protocol

  • What does this mean?

    • It is not a distributed object system

    • It is not an RPC system

    • It is not even a Web application

  • Your application decides what your application is!

    • You can build a tightly coupled system …or…

    • You can build a loosely coupled system

  • Why does this matter?

    • It means that you have to think about how you design your application

Slide45 l.jpg

SOAP Message Paths

  • SOAP messages travel from an originator to intermediate nodes to a final destination.

  • Each intermediate node handles some part of the message and then passes it along.

Slide46 l.jpg

SOAP Application

A SOAP application must perform the following steps:

  • Identify parts of the message intended for particular application.

  • Process mandatory parts or quit if it cannot.

  • Remove the parts that have been handled and forward to the next recipient (if any).

Slide47 l.jpg

  • SOAP and XML

  • SOAP messages are made of XML elements.

  • SOAP has two XML namespaces:

    • http://schemas.xmlsoap.org/soap/envelope/

    • http://schemas.xmlsoap.org/soap/encoding/

  • For clarity, we use the arbitrary prefixes SOAP-ENV, SOAP-ENC to represent these.

Slide48 l.jpg

SOAP's Four Parts:

  • 1) An extensible envelope expressing (mandatory)

    • features and services represented in

      a message; who should deal with them,

    • whether they are optional or mandatory.

  • 2) A set of encoding rules for data (optional)

    • - Exchange instances of application-defined data types and directed graphs

    • - Uniform model for serializing non-syntactic data models

  • 3) A Convention for representation RPC (optional)

  • 4) A protocol binding to HTTP (optional)

Slide49 l.jpg

SOAP Message Structure

  • SOAP Messages are contained within SOAP-ENV: Envelope elements.

  • Envelope may have SOAP-ENV: Header.

  • Envelope must have a SOAP-ENV: Body.

Slide50 l.jpg

The Envelope

Encloses the SOAP header and body

  • Can Specify

    • Encoding

    • Name Space definitions

    • Versioning Data

  • When is an envelope not a destination address?

    • When it’s POSTed!

    • HTTP Post controls the initial destination

      (Server & Function) of the SOAP message

Slide51 l.jpg

SOAP Envelope

  • <SOAP-ENV:Envelope>

  • <SOAP-ENV:Header> …</SOAP-ENV:Header>

  • <SOAP-ENV:Body>…</SOAP-ENV:Body>

  • <My:OtherStuff > …</My:OtherStuff>

  • <Your:OtherStuff > …</Your:OtherStuff>

  • </SOAP-ENV:Envelope>

Slide52 l.jpg

SOAP Header

  • The header contains application-specific elements.

  • The equivalent of “mime headers”would go here.

  • In SOAP they are called “header entries”.

  • Entirely Optional

  • Data contained must follow basic rules for encoding and attributes

  • Extra Application specific data

    • A flexible mechanism for extending a message in a

      decentralized and modular way without prior knowledge between the communicating parties

Slide53 l.jpg

Semantics of Headers

* Contract between sender and recipient

  • - Recipient is described by "actor" attribute

    * Allows for different types of negotiation:

  • - Take it or leave it

  • - Let's talk about it

    * And for different settings:

  • - Server dictated

  • - Peer-to-peer

  • - Dictated by third party

Slide54 l.jpg

Header Attributes

  • Headers may have two SOAP-defined attributes:

    • SOAP-ENV:actor – processed by final recipient or an “intermediary” (proxy)

    • SOAP-ENV:mustUnderstand – may the actor ignore the header entry if it doesn’t understand

Slide55 l.jpg

Example SOAP Header






Slide56 l.jpg


  • Application specific data

    • All properties of an instance are encoded as child elements, never as attributes.

      Body Entries

  • The body entries have the following semantics

    • Body entries always intended for the “ultimate recipient.”

    • Body entries must always be completely understood for appropriate processing.

    • Otherwise, they are essentially identical to headers.

Slide57 l.jpg

SOAP Header


<myns:Date>Wed, 20 Sep 2000</myns: Date>

<myns:From>[email protected]

</myns:From> …


Slide58 l.jpg


<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"



<m:GetLastTradePrice xmlns:m="Some-URI">





Slide59 l.jpg

SOAP Faults

  • SOAP predefines only one body entry: “SOAP-ENV:Fault”.

  • It’s sub-elements are:

    • faultcode: a namespace-qualified fault name

    • faultstring: a human-readable string

    • faultactor: what actor raised the fault?

    • detail: more information

Slide60 l.jpg

SOAP Fault Codes

  • You may define your own fault codes.

  • SOAP defines a “base set” for SOAP-defined errors:

    • VersionMismatch

    • MustUnderstand (but I didn’t!)

    • Client (bad message format)

    • Server (server error)

Slide61 l.jpg

SOAP Encoding

  • The SOAP encoding is optional.

  • Use your own encoding if you wish.

  • Declare an encodingStyle attribute on any element.

Slide62 l.jpg

Why use SOAP Encoding?

  • The encoding doesn’t give all semantics anyhow – your app still needs to know what to do.

  • Still, type information helps with

    • automatically validating,

    • converting (e.g. to COM/CORBA),

    • building application data structures,

    • minimizing storage space.

Web services l.jpg

Web Services

SOAP is part of the Web Service stack

It is one of the protocols used in web service communication.

Web services are meant to provide interoperability between systems by defining a specification for reusable services.

Web services64 l.jpg

Web Services

Web Services are comprised of several technologies

SOAP (already talked about)


Universal Description, Discovery and Integration


Web Service Description Language

Slide65 l.jpg


Usually compared to looking up a phone number in a phone book.

Provides a place to publish web services for public consumption.

Is a registry that others can look for a web service to perform a needed task.

Promotes sharing and reusing of web services.

Slide66 l.jpg


WSDL is a format to describe a web service, it's operations and access information.

Used by clients to understand how to talk to a specific webservice.

SOAP requests are generated from the information contained in a WSDL.

Other xml technologies l.jpg

Other XML Technologies


eXtensible Stylesheet Language

Provides a standard mechanisms to convert XML into another format.

Can be used to convert XML into a wide variety of formats, MS Word, PDF, HTML, or even another XML document.

It is an XML document itself, so it's readable and fairly easy to use.

Xsl example l.jpg

XSL Example

Sample XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>


<Name>Philadelphia Hilton</Name>

<Name>Philadelphia Marriott</Name>


Xsl example69 l.jpg

XSL Example

Sample XSL

<?xml version="1.0" encoding="UTF-8"?>

<xsl:stylesheet version="1.0">

<xsl:template match="/">

<xsl:apply-templates select="*"/>


<xsl:template match="Hotel">

<xsl:value-of select="."/>



Xsl example70 l.jpg

XSL Example

Applying the XSL to the XML will render this result:

Philadelphia Hilton

Philadelphia Marriott

Xsl example71 l.jpg

XSL Example

While the example doesn't look very exciting, clever uses of XSL exist

i.e. Using XSL/XML to perform validation


<xsl:when test="Hotel/Name">

<!-- do something -->



<p>Hotel doesn't have a name</p>



Xsl uses l.jpg

XSL Uses

XSL can also be used to convert an XML document into a form:



<name>Philadelphia Marriott</name>

<name>Philadelphia Hilton</name>


Xsl uses73 l.jpg

XSL Uses

Example XSL


<?xml version="1.0" encoding="UTF-8"?>

<xsl:output method="html" />

<xsl:stylesheet version="1.0">

<xsl:template match="/">

<select><xsl:apply-templates select="*"/></select>


<xsl:template match="HotelChoices/Name">

<option><xsl:value-of select="."/></option>



Xsl uses74 l.jpg

XSL Uses

Applying this stylesheet to the XML would render


<option>Philadelphia Marriott</option>

<option>Philadelphia Hilton</option>


Xsl is powerful l.jpg

XSL is powerful

XSL provides the ability to convert XML into not just other readable formats, but into formats that can be processed and possibly executed!

Imagine takes an input XML and using XSL documents to convert one into an HTML report, one into a set of SQL statements, and one into a business process document for order processing.

Other xml technologies76 l.jpg

Other XML technologies

Because all XML documents have the same syntactical format, they can all be generically parsed by the same parser, regardless of the content.

This allows XML documents to have a strict format but free content.

XSL isn't the only technology used to process XML

Slide77 l.jpg


XML User Interface Language

Considered a cross platform description of user interfaces.

Describing a user interface using XML allows you to translate it into just about any programming language for implementation

This flexibility can bring a new technology to more than just one user base.

Slide78 l.jpg


Primarily used in the Mozilla web browser

Can be natively opened by the browser to generate a user interface.

Supports the creation of different types of common GUI components

i.e. textboxes, checkboxes, tabed dialogs

Xul example l.jpg

XUL Example

<?xml version="1.0"?>

<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>



title="Find Files"



<button id="find-button" label="Find"/>

<button id="cancel-button" label="Cancel"/>


Xml versatility l.jpg

XML Versatility

The XUL illustrates how XML can be used to represent some pretty complex stuff but it's readability shows the simplicity XML brings to the table.

XML isn't just for boring protocols and platform abstraction but can be used for distributed GUIs and data transformations.

Xml rpc references l.jpg

XML-RPC References


JAVA and XML By Brett McLaughlin

Programming Web Services with XML-RPC By Simon St. Laurent




Soap references l.jpg

SOAP References

DevelopMentor - www.develop.com/soap

SOAP mail list - discuss.develop.com

W3C protocols - www.w3.org/2000/xp/

IBM - alphaworks.ibm.com

Microsoft - msdn.microsoft.com

Apache - xml.apache.org

Xml references l.jpg

XML References


  • Login