Creating Efficient, High Performance XML Web Services (DEV319)
It was a very good session Christian, one of the best in this TechEd! I'd like to see a little bit more of demos, just to convince the people in the room, not for me :-), that I already totally agree with you. I really apreciated the agenda of the session and the ideas expressed. You confirmed in my mind many of the ideas that I've already had and suggested to my customers, but above all you confirmed me that I'm on the right way. Here are the main rules expressed:
- Schema first, contract first
- Use caching whenever is possible, but not always, keep in mind that real time data cannot be and should not be cached
- Asynchronous Web Services:
- Call web services asynchronously from Windows Forms apps, always!, with callback well-designed (using custom Delegates or at least MethodInvoker)
- Call web services asynchronously from Web Forms apps very carefully, mind the ThreadPool, avoid callbacks in order to not charge the ThreadPool. Consider PreHttpRequestHandler to improve performance
- On the service side (not server side!) consider Begin/End[WebMethod] paradigm very carefully. Use it only when you completely own the subject. Don't call it to use an async delegate or you'll quickly finish your ThreadPool threads ... [Who was in Bologna or in Naples for DevCon knows that I completely agree with this point of view!]
- Remember that ASP.NET process/AppDomain can be recycled, use external worker processes (ES, MSMQ, Queued components, etc.) in order to handle long running tasks
- Use doc/literal bare messages
During the session Christian spoke about Mvp.Xml a project, hosted on SourceForge, in which he is working with other guys of the XML world: I've already downloaded it!
There was a demo about a SoapExtension to compress SOAP traffic. To tell the true I'm a little bit sceptical about this. Of course its usefull in some scenarios, but you completely loose interoperability challenges ... as always it depends, but usually I'm not so convinced to use these technique. On the other side, as also Christian showed us, I often consider the use of a Validation SoapExtension, especially when working in the interoperability range. Even if XSD validation introduces a little bit of overhead, without it we won't have any kind of real validation of messages, we'll have just to trust XmlSerializer rules.
Great job Christian!