Messing Around with XML Serialization

In order to work through some of these issues with when to use xml in thin services (previous post), I have been trying to push the use xml serialization (System.Xml.Serialization) on classes which enforce the schema used for messages to the backend service. This xml serialization is also used by the framework for types exposed via web services. If you have XmlSerialization attributes on your own classes, then this automatic serialization will take place in a predictable fashion, and you can also serialize object yourself (say, for sending a stream to a non-soap/non-wsdl service) and expect the same xml. Nothing new in any of this, it has been in the framework all along.

In any case, two minor gotchas I encountered which are both well documented aspects of using the attribution, but were easy for me to miss:
1) Serialized properties read/write, except for arrays/collections. Of course this is true, how else could the object be deserialized - yet when most of my properties were collections, the couple that didn't seem to work were very confusing.
2) Use of the [XmlAnyElement] attribute on types exposed via your webservice can break your wsdl schema due to UPA issues. This UPA concept is explained well by Priya Lakshminarayanan on the Xml team blog. The primary problem is that if you don't differentiate your known types elements from the possible open-ended types, the parser doesn't know what to do with the types it encounters if you can have 0 (minOccurs=0) of the known type. If you use a different namespace to identify unknown (#any) elements, then you can avoid this issue. Or, from the docs:

"You can apply multiple instances of the XmlAnyElementAttribute to a class member, but each instance must have a distinct Name property value. Or, if the same Name property is set for each instance, a distinct Namespace property value must be set for each instance."

For my purposes, names couldn't be identified, so it had to be namespace.

Web Services Interfaces On Thin Layers -

We are all familiar with the SOA buzz, and have probably already built many web services. I think that Visual Studio has gone a long way toward making web services extrememly easy to code, hiding most ugly XML-oriented details from you. Its good to know how and why the xml functions, but actually being burdened with the angle-bracket writing is unnecessary. Anyhow, one of the issues that comes up is how to write your methods such that the contract for the service is SOA-compliant and also instructive to consumers. Web Methods and xml serialization in .net try to answer this by allowing the contract writer to use concrete types to define the interface, and then auto-magically converting this information into schema-based wsdl messages and port types.

If you design a good interface in terms of the SOA concerns (expose business processes only, make the interface immutable, decoupled from implementation, etc) you can use familiar objects underneath that will enhance the explicit understanding of your service contract. .Net takes care of making sure the web service exposure of your code is WS-I Basic Profile compliant.

Now let me get to the issue with thin services. By that I mean services which have boundaries just beneath the surface, such that they do minimal handling of the data before pushing it back to another layer - be it another service, or to the database. I find this leaves us with the sticky design question of what to do about how tightly types are defined when we want the interface to remain generic enough that it can remain unchanged over time, and we don't want to code a lot of serialization objects just to serialize and deserialize for very brief use.

The magical open interface is one that accepts a single xml parameter. Xml can be used to define anything, so I tell the consumer to send me such and such xml. I take that xml directly, modify it slightly and push it back to the next layer that knows how to use it. From the other side, I receive some xml, make a change or two and push it out directly to the consumer. But, as a contract this interface sucks. See the anti-pattern 'loosey goosey'.

Ok, so you go and design some serializable classes, but then you are building these thin classes that do little more than express the xsd as concrete language types. Feels like monkey-work to me. But, given the monkey-work you have classes that can be used by developers of extensions to the service, and you are further away from the angle-brackets .Consumers also have a nice idea of what you are after. Not sure what the 'right' way to do it is. Still considering.

Working through the TFS system a bit more, I am trying to clean up several minor issues.

1. I had errors on the ReportServer services site - compilation issue for reportservices.asmx. This is handled by the following blog. See the section on changing the assembly section of web.config.

2. The team site web parts regularly throw an error concerning ctl00oReportServer. This has been handled most effectively by Mike Attili.

3. Build Server wouldn't install. The install log only pointed to the lack of SqlServer based services. Since I am using a two-tier model this didn't make any sense. The answer turned out to be a Firewall/ICS dependency issue for 2K3 SP1 servers.

4. I am still trying to get an answer on the bug rate report...

An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for data set 'AreaPathPath1'. (rsErrorExecutingCommand)
The default members for the dimension 'WorkItem_FactProject' do not exist with each other.

5. I am also looking for a reason all my reports are empty. I have some hope that when cubes refresh overnight, I might see something new now that i fixed the web service.

A head-slapper for me. If you are familiar with Cockburn's 'Agile Software Development', then you know the methodology he espouses he calls "Crystal". You probably also know that he classifies projects within crystal by color and hardness (size and criticality). So 'Crystal Clear' is the methodology pertaining to implementing Crystal in teams from 1-8 people. Aha, thus the name of his book.