Barcelona Summary
I wanted to blog a bit more, but I got too wrapped up in playing with technology while at the event (I also enjoyed the beer and food a bit too much in the evenings). I was really interested in the JSON message format, and I played around with getting an AJAX based tic-tac-toe implementation working with a WCF service using the new webHttpBinding. (http://dotnetslackers.com/articles/ajax/JSON-EnabledWCFServicesInASPNET35.aspx)
I had some real nice sessions, some of them actually relevant to the stuff that I'm busy with now! Here's a list of the sessions that I found really interesting:
Pat Helland - The Irresistible Forces Meet the Moveable Objects http://blogs.msdn.com/pathelland/
This session provided insight on the way we need to change the way we develop systems, due to the way CPUs are changing (more CPUs on the same board, instead of faster CPUs - due to heat), the cost associated with huge datacenters and their respective backup locations. My take away from this session is that it's sometime all right for a system in a distributed architecture to make a mistake (like saying a book is available when it isn't) and correcting it when it finds out, instead of trying to "code in the now" - which implicitly means distributed transactions.
Udi Dahan- Designing High Performance, Persistent Domain Models http://udidahan.weblogs.us/
I enjoyed Udi's session, because he approaches complex problems by doing simple OO magic. It was nice seeing some real code, using dependency injection, etc, instead of code with the sole purpose of demonstrating new tech.
Stefan Schackow - Building Highly Scalable ASP.NET Web Sites by Exploiting Asynchronous Programming Models
This was real relevant to what we are busy with at the moment. I've read about the async=true directive before, but this was a real practical and thorough presentation on using asynchronous patterns in asp.net. Stefan took care to point out some pitfalls and weirdness to expect when implementing async pages.
Justin Smith - Windows Communication Foundation Performance (interactive session)
This was the most relevant session that I attended. Justin went through all the areas that impacts performance in WCF. For each area, he showed us some findings from performance testing that they performed. He spoke about the effect of bindings, message format and serializers on performance.
He also highlighted the fact that ChannelFactory proxies have less overhead than generated proxies. He wrapped up with some common pitfalls to watch out for, in particular not closing your channels on the client as well as regeneration of the proxy for each call with the channelfactory, instead of reusing it. Unfortunately we are in a situation where we inject custom headers into our messages using behaviors, so it overcomplicates reusing the same proxy for different requests.
Because it was an interactive session, I also got to ask him some questions regarding using the async pattern on the client when using ChannelFactory. It turns out all you have to do is to have the correct methods on your contract, you don't need to implement them on your service, but it will allow you to use the proxy asynchronously.
Another question I had was whether it's actually useful to implement the async pattern on a service which needs to make a call to another service. Meaning, if you have service A, which calls service B, is it still useful to make an async call from service A to service B. The answer is that it's only useful if service A does not return a value. If it returns a value, there are no gains in making the call asynchronous, because the service needs to return a value in any case, so there is no gain in freeing the thread (except if you have to do multiple operations in parallel).
I asked him about the performance win that you can gain from using the JSON message format between services, which is substantial. Although, I'm sure a lot of ws-* fanatics will not be too happy with that solution.
I hope I'm in a position to attend teched again next year, because I feel that I left the conference as a better developer.