A pedant that hangs out in the dark corner-cases of the web.

Wednesday, June 10, 2009

Easy XML serialization of complex objects with C# 3.0

C# 3.0 Update! If you've got complex, XML-serializable objects you'd like to trace easily, such as SOAP objects, here's a handy way to dump their contents to an XML string:

using System.IO;
using System.Text;
using System.Xml;
using System.Xml.Serialization;

public class XmlExporter
{
  /// <summary>
  /// Serialize an object as an XML string.
  /// </summary>
  /// <param name="o">The object to serialize.</param>
  /// <param name="defaultNamespace">The default XML namespace of the object (to supress noisy namspaces).</param>
  /// <returns>The object, serialized as an XML string.</returns>
  public static string ToString(object o, string defaultNamespace)
  {
    if (o == null) return "<NULL />";
    var utf8 = new UTF8Encoding(false);
    using (var ms = new MemoryStream())
    using (var x = new XmlTextWriter(ms, utf8) {Formatting = Formatting.Indented})
    {
      var xs = String.IsNullOrEmpty(defaultNamespace)
        ? new XmlSerializer(o.GetType())
        : new XmlSerializer(o.GetType(), defaultNamespace);
      xs.Serialize(x, o);
      return utf8.GetString(ms.GetBuffer(), 0, (int) ms.Length);
    }
  }
}

Tuesday, June 09, 2009

Lye Service: A SOAP service that uses XML strings rather than objects

I've decided on a name for SOAP services that use XML strings for input and output rather than objects: Lye Services.

These services completely miss the point of the SOAP overhead, which is to hide the obnoxious XML string manipulation in the SOAP layer, to avoid the tedious and error-prone process of building XML strings manually via concatenation or templates. This means you get all of the drawbacks of SOAP (high network overhead, heavy library dependence, XML serialization load) without any of the benefit (a complete service description; straightforward updating; working with objects and not worrying about XML strings, serialization, de-serialization, and validation).

The result is a service definition that is not complete: the schema and documentation for the XML to input is elsewhere, usually out-of-band, that does not automatically update when the service is updated.

Worse still, these POX-y services often omit a schema for the input XML that could be used to generate or validate the XML before sending it to the service, making the process much more error-prone. Sometimes the service is so poorly specified or documented that the developer is forced into tedious trial and error to figure out the appropriate input.

Thus, "Lye", an archaic and harsh soap that homophonetically implies an untrue implementation.

When encountering a Lye Service, it's worth asking whether a more structured approach (objects, rather than XML strings) could be used. If not, REST may be a better fit than SOAP.

Monday, June 01, 2009

Remembering IE databinding

I was recently thinking about Internet Explorer 4's HTML data binding support, and it occurs to me that it is similar, at least superficially, to ASP.NET AJAX 4.0 declarative data controls. Where they differ tells a story about the difference between Microsoft 1997 and Microsoft 2009.

Cross-browser
MSAJAX doesn't demand IE loyalty, or pretend that other web browsers do not exist.
Generalized framework
Rather than play whack-a-mole with very specific features built in at the browser level, MSAJAX is extensible by ordinary web developers.
Security
Databinding had some issues it could never really overcome, in that it was essentially sending SQL straight from the client to the database server. MSAJAX naturally shows a great deal of maturity in anticipating security problems.
Standards
Microsoft, in recent years, clearly values standards more than it did back in the days of browser-war HTML-extensions, using normal XML/HTML/CSS2.1/REST to continue to advance the web platform.