I had a great time at last years Richmond Code Camp (RichCC) and was thrilled and honored that I was picked to speak yet again! I was especially happy to help out by agreeing to do a second talk when another speaker had to cancel. As great as last years RichCC was, I think this was better. People seemed more engaged, yet more laid back. I had some great questions in both of my talks and would like to thank everyone who attended.

As promised, the content from my talks:

• How I learned to love Dependency Injection
• Getting Started With WCF

Getting Going with WCF: The Lost Scenes!

As mentioned above, Justin had a couple speakers who were unable to make it and asked me to sub in for one with my Getting Going With WCF talk. This is a talk I give at a lot of user group meetings, and usually clocks in around 1:30. I kinda had to “rip” through the last several slides to allow the next speaker time to set up. The way I tend to build my slide decks is based around the premise that I will actually be there when the slides are presented, so I didn’t think just putting the slides up here to be downloaded was quite enough. Below are the slides I hurried through and a brief explanation of each:

Among the things in ASMX and Remoting that were more difficult then they should be was security. Especially when you tried to accommodate all the various WS-* security needs. As a result, most people just didn’t secure their services and crossed their fingers. WCF addresses this by giving us a declarative security model that accommodates most common scenarios without having to write a lot of additional code, but allows us to use our own custom providers where we wish. But the great news is that even if you don’t explicitly an security, most out of the box bindings come with some sort of default form of security by virtue of the transport they employ.

When thinking about security in WCF, there are two ways to secure your messages. You can use either, both or neither forms.

Transport based security secures the channel that is used to send the message across the wire, in an effort to keep the message from being snooped by a hacker. If you’ve used SSL or TCP you’ve employed transport security. One of the main benefits of transport security is that it’s very fast. Once the initial secure connection is established there is really not much additional overhead. One drawback to transport security is that there can be some interoperability issues across platforms. The other being that transport based security is only “point to point” based security. This means that If there are any intermediary services between the client and the service the channel will only be secure between the client and the first intermediary service. After that first hop the message will be “in the open” and could be viewed and/or changed by a hacker.

Another way to secure your communications over WCF is to used message based security. When you this method the message, meaning anything in the body of the SOAP message is encrypted. If the message is spoofed, the encryption protects the message from being read or altered by hackers. This works well in situations where there are intermediary services between the client and the service since the header of the message, which contains the routing in formation is not encrypted and the intermediary service (generally) does not care or need to know what the content of the message is. The draw back is that this method can be a bit slow; encryption/decryption can be slow. The encrypted messages also tend to “bloat” a bit.

Both of these methods can be combined; you can send and encrypted message over a secure transport. This combines the benefits and costs of each method.

The great thing about WCF is that unless you select the basicHttpBinding (which should only be used for legacy, pre WS-I 1.1. Basic Profile services anyway) you have some implicit level of security by virtue of the transport you are using. This is a low-level of security; you should always do a security assessment as part of your design and determine what, if any additional security is needed.

There are some great new things coming in .NET 4. The most eagerly anticipated one is default endpoints and behaviors. As you write a lot of WCF services, you’ll see that you tend to repeat the configuration required for you endpoints over and over. WCF will now take this most common endpoint scenario and use it as a default endpoint. For example, if you tell WCF that you want you service to have a wsHttpBinding endpoint, but provide no other information, it will use the default definition of a wsHttpBinding endpoint. If you want to extend/change the configuration for your endpoints you can do that; WCF in .NET 4 supports the same configuration model used in .NET 3.5. But you’ll find that you spend less time in the configuration, which is where most problems with WCF occur.

The other big new feature is Dynamically Discoverable services. These allow you to create clients which probe the network to locate services that support the contract and requirements of the contract at runtime instead of having to have the address of the service statically stored in the client configuration. This allows you to move services, create services with different Quality of Service (QoS) settings and have the clients be able to locate and consume these services as needed.

Thanks again to everybody who came to my sessions. If you have any questions about Dependence Injection, WCF or anything please feel free ask them in the comments.

Code on!