XMLRPC and SOAP

1
XML-RPC and SOAP

• Ryan Moquin
• Ching-Ping Chan (Joshua)
• Tina Chatterjee, Amit Shah

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

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

4
XML-RPC

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

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

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

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

8
A Hello World application

• First, our XML-RPC handler registers a server.
• This handler takes in a Java String parameter,
  the users name, and returns Hello and the
  users 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.

9
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
• http//www.xml-rpc.com

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

11
Note

• 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
  environments class path.
• This should have you ready to write your own
  custom code and start the process of saying
  hello.

12
What is a handler ?

• An XML-RPC handler is a method or set of methods
  that takes an XML-RPC request, decodes its
  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.

13
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 its parameter and return types are
  supported (able to be encoded) by XML-RPC.

14
XML-RPC Supported Java types
XML-RPC Data Type Java Data Type
15
Handler Class with Method to be Invoked Remotely

• public class HelloHandler
• /This will take in a ltcodegtStringlt/codegt
  and return a hello message to the user /
• public String sayHello(String name)
• return Hello name

16
Note

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

17
RMI Vs RPC

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

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

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

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

21
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 lt 1)
• System.out.println(
• Usage java HelloServer port)
• System.exit(-1)

22
Server code continued

• try
• // Use the Apache Xerces SAX Driver
• XmlRpc.setDriver(
• org.apache.xerces.parsers.SAXParser)
• // Start the server
• System.out.println(
• Sarting XML-RPC server)
• WebServer server new WebServer
• (Integer.parseInt(args0))

23
Server code continued

• //Register our handler class
• server.addHandler
• (hello, new HelloHandler())
• System.out.println
• (Now accepting requests)
• catch (ClassNotFoundException e)
• System.out.println
• (Could not locate SAX Driver)
• catch (IOException e)
• System.out.println(Could not start server
• e.getMessage())

24
Sample output on running the server

• java HelloServer 8777
• Starting XML-RPC Server.
• Registered HelloHandler class to hello
• Now accepting requests

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

26
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 lt 1)
• System.out.println(
• Usage java HelloClient your name)
• System.exit(-1)

27
Client code continued

• try
• // Use the Apache Xerces SAX Driver
• XmlRpc.setDriver(
• org.apache.xerces.parsers.SAXParser)
• // Specify the server
• XmlRpcClient client
• new XmlRpcClient(http//localhost8777/)
• // Create Request
• Vector params new Vector()
• params.addElement(args0)

28
Client code continued

• // Make a request and print the result
• String result
• (String)client.execute(hello.sayHello,
  params)
• System.out.println(
• Response from server result)
• catch (ClassNotFoundException e)
• System.out.println(
• Could not locate SAX Driver)
• catch (MalformedURLException e)
• System.out.println(
• Incorrect URL for XML-RPC server format
  e.getMessage())

29
Client code continued

• catch (XmlRpcException e)
• System.out.println(
• XML-RPC Exception e.getMessage())
• catch (IOException e)
• System.out.println(
• IO Exception e.getMessage())

30
Running the application1

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

31
Running the application2

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

32
Sample Output

• java HelloClient Tina
• Response from server Hello Tina

33
XML-RPC vs. SOAP

• Feature XML-RPC SOAP
• 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

34
XML-RPC vs. SOAP Continued

• Feature XML-RPC SOAP
• 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 instructions no yes

35
XML-RPC Vs CORBA

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

36
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?

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

38

• What Does SOAP Define?
• Standard expression for
• message envelopes
• headers
• Bodies
• Standard encoding rules for structured data
• RPC mechanism

39
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

40

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

41

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

42

• SOAP-based Protocols
• Are based on Unicode.
• Can transmit structured information.
• Are automatically extensible.
• Can inherit the SOAP information encoding
  system

43

• SCOPE
• SOAP does not address certain issues
• object references
• distributed garbage collection
• batch messaging
• Other, post-SOAP specs may arise to handle
  these.
•  

44

• 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

45

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

46

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

47

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

48

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

49

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

50

• 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 its POSTed!
• HTTP Post controls the initial destination
• (Server Function) of the SOAP message

51

• SOAP Envelope
• ltSOAP-ENVEnvelopegt
• ltSOAP-ENVHeadergt lt/SOAP-ENVHeadergt
• ltSOAP-ENVBodygtlt/SOAP-ENVBodygt
• ltMyOtherStuff gt lt/MyOtherStuffgt
• ltYourOtherStuff gt lt/YourOtherStuffgt
• lt/SOAP-ENVEnvelopegt

52

• SOAP Header
• The header contains application-specific
  elements.
• The equivalent of mime headerswould 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

53

• 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

54

• Header Attributes
• Headers may have two SOAP-defined attributes
• SOAP-ENVactor processed by final recipient or
  an intermediary (proxy)
• SOAP-ENVmustUnderstand may the actor ignore
  the header entry if it doesnt understand

55
Example SOAP Header ltSOAP-ENVBodygt
ltmynsFromgtMarkHlt/mynsFromgt ltmynsTogtDickHlt/myn
sTogt ltmyns2SubjectgtBeerlt/myns2Subjectgt lt/SOAP
-ENVBodygt
56

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

57
SOAP Header ltSOAP-ENVHeadergt ltmynsDategtWed,
20 Sep 2000lt/myns Dategt ltmynsFromgtMarkH_at_Active
State.com lt/mynsFromgt lt/SOAP-ENVHeadergt
58
SOAP Body ltSOAP-ENVEnvelope xmlnsSOAP-ENV"http
//schemas.xmlsoap.org/soap/envelope/"
SOAP-ENVencodingStyle"http//schemas.xmlsoap.or
g/soap/encoding/"gt ltSOAP-ENVBodygt
ltmGetLastTradePrice xmlnsm"Some-URI"gt
ltsymbolgtDISlt/symbolgt
lt/mGetLastTradePricegt lt/SOAP-ENVBodygt
lt/SOAP-ENVEnvelopegt
59

• SOAP Faults
• SOAP predefines only one body entry
  SOAP-ENVFault.
• Its sub-elements are
• faultcode a namespace-qualified fault name
• faultstring a human-readable string
• faultactor what actor raised the fault?
• detail more information

60

• SOAP Fault Codes
• You may define your own fault codes.
• SOAP defines a base set for SOAP-defined
  errors
• VersionMismatch
• MustUnderstand (but I didnt!)
• Client (bad message format)
• Server (server error)

61

• SOAP Encoding
• The SOAP encoding is optional.
• Use your own encoding if you wish.
• Declare an encodingStyle attribute on any
  element.

62

• Why use SOAP Encoding?
• The encoding doesnt 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.

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

64
Web Services

• Web Services are comprised of several
  technologies
• SOAP (already talked about)
• UDDI
• Universal Description, Discovery and Integration
• WSDL
• Web Service Description Language

65
UDDI

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

66
WSDL

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

67
Other XML Technologies

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

68
XSL Example

• Sample XML

lt?xml version"1.0" encoding"UTF-8"
standalone"yes"?gt ltHotelgt
ltNamegtPhiladelphia Hiltonlt/Namegt
ltNamegtPhiladelphia Marriottlt/Namegt lt/Hotelgt
69
XSL Example

• Sample XSL

lt?xml version"1.0" encoding"UTF-8"?gt ltxslstyles
heet version"1.0"gt ltxsltemplate match"/"gt
ltxslapply-templates select""/gt
lt/xsltemplategt ltxsltemplate match"Hotel"gt
ltxslvalue-of select"."/gt lt/xsltemplategt lt/xs
lstylesheetgt
70
XSL Example

• Applying the XSL to the XML will render this
  result

Philadelphia Hilton Philadelphia Marriott
71
XSL Example

• While the example doesn't look very exciting,
  clever uses of XSL exist
• i.e. Using XSL/XML to perform validation

ltxslchoosegt ltxslwhen test"Hotel/Name"gt lt!-- do
something --gt lt/xslwhengt ltxslotherwisegt
ltpgtHotel doesn't have a namelt/pgt lt/xslotherwisegt
lt/xslchoosegt
72
XSL Uses

• XSL can also be used to convert an XML document
  into a form
• i.e.

ltHotelChoicesgt ltnamegtPhiladelphia
Marriottlt/namegt ltnamegtPhiladelphia
Hiltonlt/namegt lt/HotelChoicesgt
73
XSL Uses

• Example XSL
• i.e.

lt?xml version"1.0" encoding"UTF-8"?gt ltxsloutput
method"html" /gt ltxslstylesheet version"1.0"gt
ltxsltemplate match"/"gt ltselectgtltxslapply-templ
ates select""/gtlt/selectgt lt/xsltemplategt
ltxsltemplate match"HotelChoices/Name"gt
ltoptiongtltxslvalue-of select"."/gtlt/optiongt
lt/xsltemplategt lt/xslstylesheetgt
74
XSL Uses

• Applying this stylesheet to the XML would render

ltselectgt ltoptiongtPhiladelphia
Marriottlt/optiongt ltoptiongtPhiladelphia
Hiltonlt/optiongt lt/selectgt
75
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.

76
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

77
XUL

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

78
XUL

• 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

79
XUL Example
lt?xml version"1.0"?gt lt?xml-stylesheet
href"chrome//global/skin/" type"text/css"?gt ltwi
ndow id"findfile-window" title"Find
Files" orient"horizontal"
xmlns"http//www.mozilla.org/keymaster/gatekeeper
/there.is.only.xul"gt ltbutton id"find-button"
label"Find"/gt ltbutton id"cancel-button"
label"Cancel"/gt lt/windowgt
80
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.

81
XML-RPC References

• TEXT BOOKS
• JAVA and XML By Brett McLaughlin
• Programming Web Services with XML-RPC By Simon
  St. Laurent
• WEBSITES
• http//www.xmlrpc.com
• http//xml.apache.org

82
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

83
XML References

• http//www.mozilla.org/projects/xul/