Cook Computing

Dave Winer uses an article on Web Services interop to knock .NET Web Services:

Read this article on Web Services interop. It's an eye-opener because they include sample code for a web service in .NET. Look at all the overhead. Did they really design an environment for web services? If so what are all those magic incantations about?

The code in question is:

<%@ WebService Language="C#" Class="Hello" %>

using System.Web.Services;

[WebService(Namespace="urn:Hello")]
public class Hello {
  [ WebMethod ]
  public string sayHello(string name) {
     return "Hello " + name;
  }
}

Taking it line by line from the top, the initial line specifies the .NET language that is being used to create the Web Service (e.g. C#, VB.NET or JScript), it also specifies the class name that is being exposed as a Service - this may be defined in the .asmx file or in an assembly in the \bin directory of the application. The using statement provides access to classes in the specified namespace without having to use fully qualified names. The WebService attribute is actually optional but is being used here to specifiy a namespace that will be used in the SOAP request. The WebMethod attribute specifies that the method is being exposed as a method of the Web Service, after all you might want to define other methods in the class which you don't want exposed.

Pretty straightfoward really and no more complex than the Perl or Java samples (both of which are split into two examples and so are arguably more complex). Anyway, the amount of application code in a non-trivial Web Service would dwarf the plumbing code described above.

This Microsoft support article explains the problem I had with configuring ASP.NET. Interesting to note that they suggest changing the account to SYSTEM without mentioning the potential security issues with that account.

As part of continuing testing, last night I implemented an XML-RPC.NET proxy class for the Blogger API. As well as throwing up a bug in deserializing of arrays (when retrieving the type of an array element from the array type an assembly qualified name must be passed to GetType if the type is defined in a different asembly), this also raised the issue of more flexiblity in mapping .NET struct types to/from XML-RPC structs. I defined

public struct UserBlog
{
  public string blogID;
  public string blogName;
  public string Url;
}

and, of course, when making a call to getUsersBlogs only the blogName had a value in the returned array of UserBlog's - because the names of the first and last members should be "blogid" and "url". Off the top of my head I can't remember what the XML-RPC spec says about naming of struct members but it could be useful to be able to map .NET struct members to XML-RPC struct members in the same way as the XmlRpcMethod attribute does for methods. So in this example I could have done something like this (ok, its a feeble example):

public struct UserBlog
{
  XmlRpcStructMember["blogid"]
  public string blogID;
  public string blogName;
  XmlRpcStructMember["url"]
  public string Url;
}

I'll include the Blogger API proxy class in the next release of XML-RPC.NET.

Nice feature of Visual Studio.NET that was mentioned on the DOTNET mailing list today: add a TODO: comment to your code, e.g.:

Object ParseStruct(XmlNode node, Type ValueType) // TODO: test ParseStruct

and the TODO automatically appears in the Task List window.

Today I'm working on a simple HTTP server to make it easier to write test code for XML-RPC.NET. This makes it possible to implement a client and server in the same executable, which makes setting up test cases easier, and debugging much easier, than when a service class is running in IIS (or even in just a separate executable). The class hierachy on the server-side is being modified to allow a service application to be run in either IIS or the simple HTTP server: a new class XmlRpcHttpServerProtocol specializes XmlRpcServerProtocol to add HTTP-related functionality. XmlRpcHttpServerProtocol implements this interface (the three new interfaces being in the CookComputing.Web namespace):

public interface IHttpRequestHandler
{
  void HandleRequest(IHttpRequest httpRequest, IHttpResponse httpResponse);
}

IHttpRequest is then called from either the new WebServer class or XmlRpcService which specializes XmlRpcHttpServerProtocol to run in the IIS environment.

I ran a .NET app from the Internet the other day - Internet - Code Access Permissions - from Chris Sells' site (just click on the link if you have IE6 and .NET runtime installed). This impressed me, mainly because it was the first time I had done this and it also made more tangible the promise of downloadable .NET apps with rich UI's and no client installation hassles.

It led me to experiment with the sample XML-RPC.NET client apps to see whether the library could be used with a downloadable client, the sort of thing you might want to do, for example, if you were providing a .NET Blogger API client.

As a guide to fiddling around with the security settings that are necessary to allow the XML-RPC.NET library to call out to an XML-RPC server on the Internet I found this article by Saurabh Nandu very helpful.

I placed the MathApp sample on two sites:

MathApp 1 - http://members.eraserver.net/cookcomputing/mathapp.exe
MathApp 2 - http://www.cookcomputing.com/mathapp.exe

And used them with the instance of the MathService XML-RPC server running at http://members.eraserver.net/cookcomputing/mathapp.exe (this is the default URL when MathApp runs).

Following the example of Saurabh's article, I experimented with various levels of security. For example, giving them the Medium Trust security level (one level less than Full Trust) meant that I could make XML-RPC MathService calls from MathApp at Eraserver but not MathApp at CookComputing - because this level allows a downloaded app to connect only to the site from which it was downloaded

A .NET RTM build (0.4.2) of XML-RPC.NET now available. It now includes support for the Introspection API but I'm still undecided about system.methodSignature. According to the CLS documentation 'so-called jagged arrays are CLS-compliant' but the C# compiler rejects string[][] as a return type.

On reinstating the Introspection API methods I found a problem. The implementation of system.methodSignature in beta 1 of XML-RPC.NET returned string[][]. The compiler now marks this as not being CLS-compliant. So I'm reimplementing the method to return an instance of Array containing arrays of strings. This has brought up some issues with the handling of arrays which need some further work.

I had just completed installation of .NET RTM this morning on my dev machine and was about to build and test the XML-RPC.NET samples when I checked my mail and discovered that JT Perry had beaten me to it. JT confirmed that the client code worked fine under .NET RTM.

I had problems getting ASP.NET to work. Event Viewer had this event:

aspnet_wp.exe could not be launched because the username and/or password supplied in the processModel section of the config file are invalid.

I changed the username in the processModel section of machine.config from ASPNET to SYSTEM and everything started working again. Probably not recommended on a production server. When I get the time I'll fix the problem properly.

I'm planning on making some further changes this weekend and plan to put a 0.4.2 RTM-compatible release on the website Monday evening.

Updated the site with version 0.4.1 of XML-RPC.NET. This contains working code in XmlRpcClientProtocol for making async calls but this still needs further coding and testing. Along with this I've implemented a simple WinForms sample - AsyncBettyApp - to illustrate usage of the async functionality.

A public instance of the MathService sample XML-RPC service is now available at this URL:

http://members.eraserver.net/cookcomputing/math.aspx

I'm currently working on the XmlRpcClientProtocol class to add support for async calls. I was hoping this would be pretty straightforward by deriving from the abstract WebClientProtocol class in the same way that SoapHttpClientProtocol does. Unfortunately this is not possible because some members of WebClientProtocol are internal and so cannot be accessed in a derived class which is outside the System.Web.Services assembly. So I have to code much more of the functionality myself.

An essential tool for any dev work involving HTTP is Simon Fell's proxyTrace.

XML-RPC.NET is now updated to version 0.4.0. This contains classes for implementing both XML-RPC clients and services.

This release has only been tested with .NET beta 2. I'll upgrade to a release candidate build of .NET as soon as possible but there should not be any major changes because of this.

I'm still working on a suite of unit tests so this release is still at the "alpha" release stage.

The release contains a sample XML-RPC service to be run in the IIS web server and a couple of WinForms samples, one to call the sample service and the other to call the Betty server at Userland.