Tim and Aaron have both pitched in on this Perils of WSDL First thread. I just want to point out that I largely agree with what they are saying. Which is good, because disagreeing with either of them on matters pertaining to web services would be enough to make someone with even my huge ego question themselves! ;)
They advocate use of an abstraction layer between your domain types and the XmlSerializable types you use as your web service paramaeters. This is a fantastic idea, and it's the way I write web services myself, having been bitten more than once by direct exposure of domain classes. Generally speaking, this will go a long way towards preventing the sort of problems I warn about in my original post. In many cases, it will even be sufficient, especially when coupled with Tim's idea of having the serializable types be in a separate assembly owned by someone who understands the implications of code changes on the wire protocol. And the DCS stuff that Aaron talks about looks like an excellent further step in the right direction.
So if I still appear skittish, it's because I know that most people don't program this way. Most people follow the path of least resistance, and will hesitate to implement writing the boring, repetitive mapping code involved in the most straightforward implementation of such an abstraction layer. Yes, I realize more sophisticated implementations are possible, but I'm talking here about people and organizations that don't necessarily recognize the long-term benefits of such a setup. As a consultant, I've seen this more than once.
The other thing that makes me a bit nervous is that even with an abstraction layer, you still have to be very careful not to muck with it in ways that would change the contract - a fact that both Tim and Aaron are clearly aware of. This is obvious to people who've been doing web services for a while, but for a lot of developers the angle brackets are still invisible. Basically, I'm trying to point out that web service development needs to be both first. Fragile code sucks; the more things you have to remember, the more likely you are to make a mistake.
Whether or not any of this means your organization needs to go whole-hog and implement IXmlSerializable really depends on the dynamics of your development process. Probably you don't need to go that far, especially given XmlElementAttribute.Order. At the end of the day, just remember that when you let the infrastructure generate your XML automatically, seemingly innocuous changes in your code can create breaking changes in your wire protocol. Remember it, and use appropriate techniques to address the risk.
This seems like a good argument for better tooling. Additionally, there should be better guidance on writing schema or wsdl that has the proper flexibility/extensibility coupled with the proper amount of restrictions - Perhaps also some more tooling.
ReplyDeleteOn the tooling front, Microsoft will argue that that's Indigo.
ReplyDeleteOn the guidance front, I'm sort of hoping that's what my (and Tim's and Aaron's) blog provides. :)
When you say "abstraction layer between your domain types and the XmlSerializable types you use as your web service paramaeters" what I think you should be thinking about in the back of your mind is how DTOs are marshalled across service boundaries. A common, and fairly natural way of handling this is with a combination of the Service Gateway and Assembler patterns. This is essentially the same problem that's been kicking around for quite awhile: you don't want to couple your domain model to a data contract. See Patterns of Enterprise Application Architecture by Fowler for more on some of these patterns.
ReplyDeleteSpring.NET has started to do some rough groundwork on an implementation of these patterns for web services. You might want to check out the work that they are doing. It builds on top of standard ASP.NET web services and interoperates with WSE and WCF.
Craig,
ReplyDeleteYou do provide that! However, your posts aren't yet popping up in the Dynamic Help window in VS2005. Perhaps you should use your influence.
In my mind, instead of what I actually wrote, I was thinking more of Guidance Automation (I am finding 'Software Factories' fascinating, but I have a nagging suspicion that there is at least one more as yet unknown huge hurdle to clear).
For the record, the back and forth with concrete exapmles has been very good.
Heh, I know what you mean - there's a lot of value if the good advice comes from Microsoft instead of having to hunt around for it. We'll see what the SF stuff turns out to be - there are some inherent tensions that will make it difficult for them to always tell us to do the right thing.
ReplyDeleteAs far as popping up in the Dynamic Help window...well, I can't say I'm working on *that*, but I do have some pending announcements to make that might move us a tiny bit in that direction. Can't say more just now.
Cool MSDN ASP.NET 2.0 GridView Control
ReplyDeleteArticle [Via: Scott Guthrie ]
How to Link Stylesheets from...
You do provide that!
ReplyDelete