Adding XML & JSON Reps: Sprint Update

We began a two week sprint began on 9/14/2010 with the primary goal of adding XML & JSON representations to all resources in all the existing services to complement the XHTML offering. The addition of XML is the #1 requested feature on UserVoice  and follow-up polling indicated that JSON was similarly desired and can be done without too much additional effort. Other technology renewal work will be done concurrently, including upgrading to .NET 4.0, Visual Studio 2010 IDE and Enterprise Library 5.0.

9/14: Discussed the possible tasks, prioritized each, decided which will actually be done/attempted, and assigned pairs to work on each task. Work began in earnest.

9/15: Accomplished/decided the following:

  • Gathered baseline performance numbers for several of the services. We will compare the new versions against this baseline to be sure we haven’t introduced performance problems during our work.
  • Technical deep dive compared the XMLSerializer with the DataContractSerializer to decide which one we will use to automatically generate the XML representation. We decided to stick with the DataContractSerializer for a number of compelling reasons, even though it means we won’t use element attributes, just elements.
  • Alpha versions of the Financial Web Service Budget and Budget Search resources delivering XML and JSON are working.
  • .NET 4.0 and Enterprise Library 5 upgrades are proceeding nicely.

We chose the DataContractSerializer(DCS) over the XMLSerializer(XS) for these primary reasons:

  • Microsoft guidance, and beyond, recommends the DCS over the XS. It’s about 10% faster, for starters.
  • DCS supports both JSON and XML serialization and the XS does only XML; using one serializer means much less possibility for introducing unforseen bugs.
  • DCS is an ‘opt-in’ serializer, meaning that properties that are to be included in the serialized XML must be decorated with an attribute. XS is ‘opt-out’, serializing anything that is public. Opt-in is a better model for us since we are dealing with explicit contracts.
  • XS requires a public setter on each property to be serialized. In read-only services (the majority) we don’t want this, and having it could introduce bugs.

The effort is progressing nicely and so far we are optimistic we can complete it in the two week window.