Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

Around the same time that SOAP came around, another competing spec emerged called XML-RPC. While XML-RPC has nothing to do with web services from an enterprise point of view it still has its place. Notably among open source enthusiasts and bloggers. Indeed the little Perl script I wrote yesterday uses it. I finally decided it was time to look at this more closely today.




The first thing to do was to get a library, something from Apache would do nicely . Now that's taken care of I can extract it to a local directory and add it to the class path of a NetWeaver Developer Studio project in order to use it. Now what services are out there to interact with? Well, quite a lot actually. Most blog software works with XML-RPC as I mentioned, but lets do something new. Since I have a soft spot for O'Reilly we'll try the Meekrat service as introduced here by Rael Dornfest . If you are not familiar with Meekrat its an online news aggregator, one of the earliest examples. It has a number of operations we could play with but we'll stick with meerkat.getItems which takes just a couple of parameters and will return you titles of articles with a link. We'll setup a default jsp page to take a search term and a results page to display what we get and link to the articles. Easy right? Well...

</p>
<p>
The thing about XML-RPC is that no matter how well you have documented your interfaces it is up to you as a developer to figure out how to package up your parameters properly to pass them to the service, no automatic generation of proxies here, there is no corrolary of WSDL in this world. That said the rest is fairly simple, though personally I don't see much advantage over SOAP. If a service offered both interface I think I'll stick with SOAP thank you.
</p>
<p>
The setup for this project was pretty simple, a web module project I called meekrat-web and a enterprise application project called meekrat to deploy it. The web module has two jsp pages, default.jsp and results.jsp. The default page is very simple, all it does is collect user input to pass for use on the results page.
</p>
<p>
<code>
<%@ page language="java" %><br/>
<html><br/>
 <head><title>Meekrat search with xml-rpc</title></head><br/>
 <body><br/>

  

Meekrat search with xml-rpc

<br/>
  <form method="post" action="results.jsp"><br/>
    Search for: <input type="text" name="search" size="30"><br/>
    <br/><br/>
    <input type="submit"><br/>
  </form><br/>
 </body><br/>
</html>
</code>
</p>
<p>
The results page has all the interesting stuff in it. To start with we will import the Apache classes we need and setup our variables.
</p>
<p>
<code>
<%@ page language="java" %><br/>

<%@ page import="java.util., org.apache.xmlrpc." %><br/>
<html><br/>
 <head><title>Meekrat search results with xml-rpc</title></head><br/>
 <body><br/>
  <%!     String search;<br/>
         Vector respobj = new Vector();<br/>
         Hashtable results = new Hashtable();<br/>
  %>
</code>
</p>
<p>
Next we'll grab the search parameter we passed from the default page and establish the connction to the XML-RPC server with the XmlRpcClient object. The tricky part comes with the parameters. We need to pass a hashtable to this service but the execute method of the XmlRpcClient takes a string of the method to be executed and a Vector. Clear as mud. Sure it's not really that hard, but coming from working with SOAP I've got to say this is a step backwards and I can't believe anyone would prefer it.
</p>
<code>
<%     try{<br/>
              search = request.getParameter( "search" ); <br/>
              XmlRpcClient client = new XmlRpcClient("http://www.oreillynet.com/meerkat/xml-rpc/server.php");<br/>
              Hashtable element = new Hashtable();<br/>
              element.put("search", search);<br/>
              element.put("num_items", "5");<br/>
              element.put("descriptions", "0");<br/>
              Vector params = new Vector();<br/>
              params.addElement(element);<br/>
              respobj = (Vector) client.execute("meerkat.getItems", params);<br/>
       }<br/>
       catch (Exception e){out.write(e.toString());}
%>
</code>
</p>
<p>
Note also that the execute method returns an object, it's up to you to do the necessary casting to make it useful. In this case what is actually returned is another hashtable, but I can't cast from object to that so I cast as a Vector first. In the final code snippet below we grab the keys from the hash table we are interested in and format them for output.
</p>
<p>
<code>

            

Meekrat search results with xml-rpc

<br/>

            First five results for "<%= search %>"<br/>
            <p><br/>
            <% <br/>
                   for (int i = 0; i <= 4; i++ ) {<br/>
      results = (Hashtable) respobj.get(i);<br/>
      out.write("<a href=\"" + results.get("link") + "\">");<br/>
                          out.write(results.get("title") + "</a><br/>");<br/>
&nbsp&nbsp&nbsp&nbsp               }<br/>
&nbsp&nbsp          %><br/>
&nbsp&nbsp          <p><br/>

&nbsp&nbsp          Search again

 






Compile the EAR and deploy to the server. From the root of your web app you can now enter a search term, like java, and see what you get back. Note that there is no error handling in this code and it's hard coded to return just five hits. The for loop is so bad it assumes you are getting five. When I realized that the size operation of vector returns a value counting up from 1 and hashtable starts from 0 I hard coded the loop. This is just an example after all and I'm not pretending there is anything "elegant" about this.


The biggest beef I have with this is the lack of introspection for what the types are in the parameters I need to send and in what is returned to me. If you start playing around with the WS-* stack of web services you'll see that such things are second nature, you can actually get it right on your first try without reading the docs or inspecting raw output to see what you should do. It is interesting that XML-RPC has found a niche for itself; I don't think its going away, but its not evolving either.



Will I continue to use it? Only if its my only option.