The response is also a simple XML file that has a root element, or has or has no child elements. This contrasts with the complex soap corresponding.
The original XML-RPC protocol was invented by web pioneer Dave Winer in the Userland software company in 1998. Its first implementation is on the Userland Frontier Development platform (in fact, Userland Software's trademark is "XML-RPC"). The natural use of the "Transfer XML text over HTTP" method is to create SOAP, which includes the contributions of Winer, Don box, and other Microsoft people. However, soap-RPC is noteworthy because many of them become very heavyweight because of the fact that they do not have to be required for applications at all.
The original XML-RPC uses only some data types, and does not require namespaces. It obtains considerable flexibility by defining and containing types of other values. Here is an example from an XML-RPC specification. It specifies the input parameters for the "Getstatename" method in the sample application.
The following are the referenced contents: <?xml version= "1.0"?> <methodCall> <methodname>examples.getstatename <params> <param>41 </params> </methodCall> |
You may have guessed that the label represents a 4-byte integer, and the following is all the type tags used to specify how to translate the content in the label. If no label is used, it is considered a string value. Note that the parameters are not named, and the order of the elements is the same as the order of the method parameters.
The following are the referenced contents: Java Type XML Tag Description Integer or A bit signed integer Double A double precision (64bit) signed floating point number Boolean 0 (false) or 1 (true) String string Date or A timestamp in the ISO8601 style but simplified Calendar with resolution to the second. Byte[] A base-64 encoded array of bytes Map Pair (s) of tags where the name is a string and The value can is any other type, including Object[] An array of objects where the elements can is any other type. |
In the original manual, there is no way to indicate any type of "null" value, but the extended version allows additional types.
The response is also a simple XML file that has a root element, or has or has no child elements. This contrasts with the complex soap corresponding.
XML-RPC Implementation
The implementations listed in xmlrpc.com give links to 79 different implementations that implement basic XML-RPC protocols in a variety of languages, including the 5 December 2003 Java language implementations. However, many of these projects are stagnant. Projects hosted by Apache Web Services Project are active. I tried to run the current version of 3.0A1, but found it strangely dependent on other Web service project libraries. It seems that Apache Web Services Project is developing version 3, so if you're interested in open source XML-RPC solutions, you might want to focus on it.
Jax-RPC: Java APIs for XML RPC
The earliest Java API starts with JSR 101. This work begins in early 2001 and reaches 1.0 by 2002. The 1.1 version was released in 2003 and shipped with the Java Web Services Developer pack by Sun's reference implementation. In Jax-RPC, the definition of a Java original type is closely related to the type of XML schema. It also supports more Java standard library objects, such as BigInteger and BigDecimal, and objects that conform to the JavaBeans standard. People using JSR 101 can develop soap and other XML technologies in parallel.
The Java Web Services Developer Pack (JWSDP) version 1.6 includes a number of other things and an implementation of JAX-RPC 1.1.3.
JAX-WS 2.0: Next jax-RPC
The next version of the manual, called Jax-ws 2.0, is for xml-based Web services that replace the JAX-RPC Java API. The standard was developed as a Java specification Request (JSR) 224来 and is now in the final draft phase.
The next version of Jax-RPC will significantly reduce the complexity of web service development, partly by using the features of the Java 1.5 standard library. You can track the reference implementation in the source list on the site. As for this article, you can already access the 3rd edition of the reference implementation.
using JWSDP 1.6
JWSDP 1.6 A useful feature is support for Web Services Description Language (WSDL). Assuming that you have a WSDL document that describes the Web service, you can automatically generate the client code that accesses the service and the server-side code that supports the service. In order to use a simple interface for the client's request for a published Web service, I created the client class in JWSDP 1.6 using the Wscompile tool, which can describe possible actions based on three or four input parameters. As a result, an astonishing 32 classes can be created in a matter of seconds.
Once I point out which of these classes provides the starting point for a real creation request, it's easy to write code that implements a simple command-line interface. And when I want to run the program, the problem comes along. The client needs to add 10 jar packages from the JWSDP to his own Java program.
Since I can't help you to debug a potential conflict between these jar packs and other Java programs, I abandoned this practice by writing a simple program with a string template to create a SOAP request and XPath to translate the returned results. Like its name, I think JWSDP will be used primarily to create Web services, not consumer Web services.
is XML-RPC still useful?
JAX-RPC complexity leads to some sort of backsliding by programmers. Search for "Jax-RPC complexity" from Google to see some user response. I think you should consider XML-RPC rather than JAX-RPC in the following situations:
Your application requires a relatively simple request.
You can control server side and client, you do not need to publish WSDL
You want to simply parse the client (just like an AJAX application)