They had an overview session for this stuff this morning. HUGE is an understatement! I won't even try to do it justice. If you are an Architect, PM, Developer, Tester or System Admin, you should check it out on the Microsoft site ASAP.
One thing that I was really psyched about was the Unit Test tools. They look just like NUnit. They are coded and run inside VS.NET with the results stored and preserved. The unit test code can even be GENERATED automagically! I am not a fan of code generators in general, but here's a good use for one.
P.S. I am adding some digital photos from TechEd to my image area.
I attended a talk by Clemens Vasters about handling state. (I know Clemens from a few years ago when I was the Technical Editor on a book he wrote about BizTalk.) He had some very interesting ideas about handling state data.
He started out with the statement “There is no such thing as a stateless component”. Considering how much time and money Microsoft has spent pushing the idea that stateless components are the solution to the scalability problem, it was interesting to hear that. His point was that what we generally call a “stateless” component is just a component that has no “transient” state within the object between calls. This led into his main point which was to define state in one of four categories:
Volitile Data - Short-lived data in memory: local variables, stack data, etc.
Transient Data - Medium-term data in memory: ASP session data, heap objects, data connections, TCP connections, etc.
Durable Data - Working data stored on a non-volitile media: MSMQ messages, intermediate results stored on disk or in SQL, etc.
Permanent Data - Data that is the final outcome of a process.
He pointed out that all software is designed to transform data from one permanent state to another. Nothing else matters since it isn't permanent. All other types of data are just part of the transformation process.
What we call “stateless“ components are really designed to reduce (but not eliminate) the use of transient data.
Think of a “stateless“ component that calls other objects. It creates stack (volitile) for the calls and local variables. That data scales well because it is automatically reclaimed on exit. It creates the other objects. This involves heap and may involve network sessions, ASP sessions, database connections and other transient data as needed. As long as the call is going on, those resources are locked, limiting scalability. Even if all of the components dispose of and release all of these resources properly, they are still resources that are consumed for the life of the call. If they are not cleaned up properly, and left to garbage collection or something like it, they impact scalability significantly. It's not that you can or should eliminate this transient data, you just have to be aware of it and manage it correctly.
Another interesting point he made had to do with COM+ or EnterpriseServices proxies. Obviously, making a call into COM+ is very expensive. That's why you want the interface to be “chunky“ instead of “chatty“. The biggest expense though is in setting up the proxy used to call it. He suggested a method to create a “Proxy Pool“ that consists of a set of reusable proxies that are handed out to threads in the client as needed instead of creating new proxies from strach all the time. Using JIT activation, you only recreate the object itself on each call. You don't have to recreate the IPC or network connection and object context surrounding it.