Cook Computing


February 17, 2003 Written by Charles Cook

Oren Novotny posted an interesting question to the XMLRPCNET Yahoo group today:

Is there any way to create a tool similar to WSDL.exe that will query an XML-RPC service and then generate the required interfaces and structs? Does the XML-RPC spec have any way of returning that information?

While it's very nice that only an interface definition is currently required as opposed to creating the classes, it is the structs that a real pain. Many times a method will use a struct that has 15-20 members, with some of those being other structs with a similarly large number of members. It would be really, really nice if those could be auto-generated.

I replied:

I agree it would be very useful to have a wsdl.exe-like tool for XML-RPC. This would only be possible if XML-RPC servers returned a standard high-fidelity description of their services.

The only existing "standard" is the Introspection API, which is worthless from this point of view. I was involved in discussion with some members of the XML-RPC Yahoo group a long time ago about defining something more useful but that fizzled out. Another effort was Dave Winer's ALIDL which had about as much potential value as the Introspection API.

However I see no reason why an XML-RPC binding could not be defined for WSDL. The use of the XSD would allow accurate description of the types in XML-RPC requests and responses. The main problem with WSDL from an XML-RPC perspective is that it might seem over-complicated by XML-RPC standards.

But assuming you can extract the type information from your server code, which would be the case with something like XML-RPC.NET which is written in a statically typed language, the WSDL could be generated automatically by the server and then consumed automatically on the client side by the wsdl.exe-like tool, so there would be no need for manual handling of WSDL.

It could be an interesting project Broadly the work would involve tasks such as:

  • defining the XML-RPC WSDL binding
  • implementing the code to generate WSDL on the server using reflection
  • implementing code to dynamically build an interface which could then be fed into the XmlRpcProxyGen.CreateAssembly method (which outputs an assembly to disk)
  • extending other implementations of XML-RPC in the same way (or persuading their implementors to do the same)

As I hinted earlier the use of something like WSDL does go slightly against the spirit of XML-RPC. However as Oren suggested, once your requests and responses contain complicated types, the dynamic free-form nature of the protocol becomes a hindrance. Although the public XML-RPC APIs tend to be fairly simple, I've seen some of the types that companies are passing around in their internal XML-RPC-based applications and they can be very complicated. I can't see why the two approaches couldn't co-exist: use of WSDL or something similar for complex requirements would not in any way affect the more dynamic uses of XML-RPC.

I think the last point is important. If XML-RPC is a viable alternative to SOAP then people will want to use it in complicated ways and when you start doing that you need some way of specifying and verifying what a server implements. The very informal API specs that XML-RPC seems to attract are often wrong, or misunderstood so that the server implement something different. Businesses are using XML-RPC for serious purposes and this potential for confusion wastes time and money.