Writing an XML-RPC server or client in ASP.Net: Part 2

9 March 2007, 18:33, by Jon

In my previous article I covered how to setup an XML-RPC server in .Net, in particular looking at how to service XML-RPC MetaWebLog API requests. In this second part I am looking at how we can easily construct an XML-RPC client to ping blog directory or search services such as Technorati, Google BlogSearch, blo.gs etc.

If you have not read part one, I recommend you take a look at this article first as it covers the set-up and configuration of CooksComputing XML-RPC provider, which is required for this tutorial.

Creating an XML-RPC client proxy class

Before we can make and XML-RPC client request, we need to create a proxy/wrapper class to handle our client requests for us. In this example I am going to create a client that pings blogflux.com . To use their XML-RPC service you need to sign-up for a free account.

To ping blogflux.com we need to send an XML-RPC call to http://pinger.blogflux.com/rpc/

Which is configured to accept pings that follow the WebLog ping format.

Firstly, we will create our proxy class in our App_Code directory as follows:

using System.Reflection;
using CookComputing.XmlRpc;
 
[XmlRpcUrl("http://pinger.blogflux.com/rpc/")]
class BlogFlux : XmlRpcClientProtocol{
 
     [XmlRpcMethod("weblogUpdates.ping")]
     public XmlRpcStruct ping(string weblogname, string weblogurl)
     {
          return (XmlRpcStruct)Invoke(MethodBase.GetCurrentMethod(), new object[] { weblogname, weblogurl });
     }
 
}

Here we need to insert a compiler directive before the class definition which indicates the URL we want this proxy to communicate with, in this case: pinger.blogflux.com/rpc/. We then need to insure that our class inherits from XmlRpcClientProtocol. Once we have done this we can define the methods that we want to call on the remote RPC-XML server. the WebLog ping protocol supports two method calls, weblogUpdates.ping and weblogUpdates.extendedPing. The most widely implemented in the weblogUpdates.ping method, which takes two parameters, the first being a string containing the name of your blog, the second (again a string) the URL of your blog. webblogUpdates.ping returns a XML-RPC struct indicating whether the ping succeeded or not, so our method returns and XmlRpcStruct and to initiate the call we use the following code:

Invoke(MethodBase.GetCurrentMethod(), new object[] { weblogname, weblogurl});

As you can see we pass the parameters onto the XML-RPC client call within the second parameter of the Invoke method call and all XML-RPC methods are stored in an array of type object.

Once we have our client proxy defined, we can easily create and invoke a remote XML-RPC call as follows:

BlogFlux bf = new BlogFlux();
bf.ping("Jon Milet Baker’s Blog", http://www.miletbaker.com/blog/);

And if we want to check the results of our client XML-RPC call we can do the following.

XmlRpcStruct struct = bf.ping("Jon Milet Baker’s Blog", http://www.miletbaker.com/blog/);
label1.text = struct["errMsg"];

The XML-RPC protocol is widely adopted especially by blog platforms. This tutorial covers the basics of XML-RPC and I recommend reading Charles Cooks FAQ for more information, but as you can see this code could easily be adapted for any Remote Procedure Call requirement and provides an alternative to SOAP based Web Services.



7 comments below:


[...] Part Two available here [...]

Pingback by Clockwork Objects » Writing an XML-RPC server or client in ASP.Net: Part 1 — 4 December 2007 @ 15:04

Hi,

Do you know how to use XML-RPC.NET to create a client that can connect to a non-html endpoint (where there is no http server, just IP address and port number)?

Thank you!

Comment by Fulin Xiang — 12 August 2008 @ 06:23

Hai,

Can you please send me a link for a video tutorial to understand clearly about xml rpc.

Comment by mohammad — 23 September 2008 @ 06:18

Hi

unfortunately I do not know the answer to either of these. XML-RPC is quite an enigmatic protocol I have not seen any videos. As for using XML-RPC over sockets directly. This should be possible I have not done any .Net for a very long time but I think you can transmit strings rather than have to byte encode. Just transafer your XML-RPC as a string between a client socket and server socket (I may be confusing with Java here sorry) and then constuct an XMLRPCStruct. In fact you can possibly serialize the XMLRPCStruct over the wire. Maybe someone with more recent .Net experience can help you.

Regards,

Jon

Comment by Jon — 23 September 2008 @ 08:36

Hi.
I am using CookComputing.XmlRpc to write a client.
The service I’m working against have one method I’m struggling with.
Its a method for importing file. Making a struct with the file in bytes is easy, but sending this struct don’t work.
I’m not able to use struct as a type in the interface when declaring the method.
Don’t CookComputing.XmlRpc support struct?
Any ides..

Comment by Hugo — 27 February 2009 @ 11:29

Jon,

You frickin’ rule! This is exactly what I was looking for.

Thanks a ton!

Joe

Comment by Joe — 20 April 2009 @ 06:35

[...] Part Two available here [...]

Pingback by Writing an XML-RPC server or client in ASP.Net: Part 1 « Go Tripod Ltd — 3 August 2009 @ 17:46

Leave a comment

About Jon

Jon started his career hacking code on his Sinclair Spectrum before moving on to more sophisticated machines ( ...such as a Commodore 64 ). He graduated from the University of Kent in 2000 with a degree in Computer Science and since then has worked in finance and education before co-founding Go Tripod. He is passionate about usability and design and his favourite development technologies are Ruby, and Objective-C/Cocoa. When he is not sat at his desk he is standing on his head doing yoga, refining his taste for food or on an adventure exploring the great outdoors.

Go Tripod Ltd

Go Tripod Ltd is a UK-based development company working with some of the most exciting software technologies around. Simon Ashley, Jon Baker and Colin Ramsay are the brains behind projects such as Stubmatic, and are developing bespoke web, mobile and desktop software for clients with household names. We believe in good service as well as good software, and we’re eager to work with people who feel the same.