I'm working on another article. I'm hoping to have it done within the week and start looking for people to publish it (I'm aiming for MSDN this time). So - that's where my spare mental CPU cycles have gone....

The conference is over and I'm really, really, really ready to get back home. I'm tired and my brain is full. I'll probably take a couple days to digest some of the information I gathered from the conference and hopefully have some interesting content to put up....see you all in a couple days....

I went to a fairly good talk this morning on the topic of managed/unmanaged interop issues when programming for VISTA. The core problem is that many of the development tools you'd use to program for this platform won't be ready by the time of release, and so some of the fancy .Net tools and short-cuts we're accustomed to won't be available. As a result, certain situations may require interop to the native APIs of the platform. Cases discussed included:

1. UAC-aware applications
1. User Access Control
2. Windows VISTA desktop search,
1. Integrated into the client experience in many ways
3. CommandLinks
1. The new "button" that's available in Windows VISTA giving allowance for a more descriptive text region.
4. Common File Dialogs
1. Presenting the new file dialog interface to clients.

...and so forth. The actual points made, however, wasn't of special interest to me as I believe I could find my way around them if I encountered them, but the fact that I may have to do interop to catch up to certain user interfaces was the most important "point" I took away from the talk.

Unfortunately I just haven't had time to totally wrap my head around all the new features coming out in the Windows VISTA security infrastructure; namely those in the firewall. One technology I'd like to look at more is the Windows Filtering Platform.

If you are interested in platform security or the firewall or anything related to these things, I would recommend checking it out.

http://www.microsoft.com/whdc/device/network/WFP.mspx
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWNE05008_WinHEC05.ppt
http://windowssdk.msdn.microsoft.com/en-us/library/ms686658.aspx

I had a chance to speak with a Russ Humphries who is the Sr. Product Manager for the Windows VISTA Security team and was very impressed with this man's overall intelligence, but especially impressed with a technology called BitLocker. I dont' want to go into it at the moment as I'm a bit short on time, but it's basically a mechanism for very securely encrypting content on disk in such a manner that nobody can retrieve it regardless of their manner of attack.

Check out this site here for more information (I'll try reducing it to something more palletable later): http://www.microsoft.com/technet/windowsvista/security/bitlockr.mspx.

Clemens Vasters gave a great talk on WCF today concerning binding and contracts; I got a lot out of it even though a lot was review, but it was good review because it solidified a lot of things that were nebulous to me still. Here are some basic notes:

1. There are three basic types of contracts
1. Service: which concerns the ports, operations and behaviors.
2. Data: data types,
3. Message: which define the format of the message on the wire.
2. There are three ways to talk:
1. One way: send the message and "forget" about it,
2. Request/Reply: where there is a request .... wait ..... response model,
3. Duplex: most easily thought about in terms of "callbacks"
3. One way requests are important because they're effecient. If the protocol is reliable that it's being sent on, you don't ahve to worry about it not getting there...you can send the message and forget about it. This is a good choice for several solutions.
4. Duplex is back channel, callback based.
5. Take note of "Channel Builder",
6. You can declare the back channel as [OperationContract(IsOneWay=True )]
7. Take note of "Dispatcher"
8. Duplex: [ServiceContract(Session=true), CallbackContract=typeof(IMYCALLBACKTYPE)]. The IMYCALLBACKTYPE is the interface the client is going to be using to reach the methods to call back.
9. Fault tolerance:
1. [FaultContract(typeof(SOMETYPE))] .....
2. ......
3. throw new FaultException<SOMETYPE>
1. These things are handled as soap exceptions
10. If you wish to work on the actual XML format, use the XMLSerializer
11. Bindings:
1. BasicHTTPBinding: "Old style"
2. WSHTTPBinding: "New style". Secure, reliable.
3. NetTCPBinding: Becoming very fast, almost as fast as COM+/DCOM. Instant firewall feedback/ NAT feedback.
4. NetNamedPipeBinding: maximum performance, same machine, on windows.
5. NetMSMQBinding: robust, reliable, queue-based transport.
6. MSMQIntegrationBinding: integration with old-style MSMQ applications.
7. NetPeerTCPBinding: for building peer to peer meshes.

The remainder of his talk was very informative, but difficult to express here as he went through particular case scenarios. This was an excellent way of seeing these protocols actually walk and therefore very a very expressive way of showing how to use the various binding types and why.

Warning, rough notes:

I went to a notable talk this morning about versioning web services using WCF (though, many of the concepts could have been applied to ASMX too, or for that matter, any web service technology). The basic question the session tried to answer was how do you adjust a contract over time (version it) so that you don't break existing cilents?

In short, there are two potential answers:

1. Put up a completely seperate and new endpoint,
2. Carefully adjust what you currently have.

Simple in theory, but in practice the second part is typically the more difficult one. The benefit of the first is that you don't haev to worry about breaking any clients in the field as the original logic isn't touched; however you will more than likely experience code-bloat. The second option is tougher to write as you have to make sure what you're touching dosen't break existing clients, but it's also more conservative as you typically can reuse existing blocks of code (less code = fewer bugs, etc).

If you must adjust your existing service contract (option #2), then you typically can do so in one of three ways:

1. Add new stuff - new types
2. Extend old stuff - add new functions or fields
3. Change old stuff - adjust parameter types, etc.

The 3rd option is usually the least preferrable, and if you're faced with this then it's recommended to just create a new endpoint (service) altogether. Adding new stuff is simple as you simply add new types and they don't interfere with the existing contracts. Extending older stuff, however, is possible but takes some thought:

1. The DataContract serializer (I believe it's called) expresses members of data types in alphabetical order into the WSDL. You must use the [DataMember(order=X)] ordering feature to properly order them since new additions must be placed at the end (so you don't break existing clients). The 'order' is done by group, so that the first versioned group is 1, the second 2, etc.
2. The XMLSerializer uses the same concept but is ordered like [XMLElement(Order=1)]......[XMLElement(Order=N+1)] with each value N going from 0 on.
3. If a client is calling in with less information than the service expects, then either the DataContract serializer and the XMLSerializer represent the value of the type as Nullable<T>, so test for this. Express new additional types that support nullable with the question mark (ex: [DataMember(order=x)] public int? age; )
4. Also note the benefits of IExtensibleDataObject, XMLAnyElement, and XMLIgnore.

....they'd be a MUCH more aggressive towards growing a monopoly.