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.