1 / 83

XML-RPC and SOAP

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

thad
Download Presentation

XML-RPC and SOAP

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ryan Moquin Ching-Ping Chan (Joshua) Tina Chatterjee, Amit Shah XML-RPC and SOAP

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

  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 environment’s 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 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.

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

  14. XML-RPC Supported Java types int int boolean boolean string java.lang.String double double dateTime.iso8601 java.util.Date struct java.util.Hashtable array java.util.Vector base64 byte[] XML-RPC Data Type Java Data Type

  15. 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; } }

  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 < 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(args[0]));

  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 < 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://localhost:8777/); // Create Request Vector params = new Vector(); params.addElement(args[0]);

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

  31. Running the application[2] 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 it’s POSTed! • HTTP Post controls the initial destination (Server & Function) of the SOAP message

More Related