I dont think i need to say more than this picture as to what an experience it was at techready :)Was a pretty exciting moment to see Dox Box if you notice in a sells brothers Tee :)

We would expect this to be a simple transport level security scenario.Think again. I had this question answered from Shy on this at techready.

The point is that IPSec removes any trace of security and so by looking at the packet WCF cannot say if it is secured or not. Hence if you had a operation contract that required some kind of protection level and you expected this requirement to be satisfied by IPSec then think again. If you plan to use IPSec as a deployment option and then you will have to remove this attribute decoration on the operation cause the underlying transport cannot claim that its secure.

Another work around would be to use a custom transport that claims it is secure and you can turn on IPSec on that. This would enable the usage of ProtectionLevel on an operation but WCF cannot gurantee the security as it takes the custom transport claim unless ofcourse you can somehow query and figure out if IPSec is enabled. This is left as an excercise.

I met up today with Sarathy who was with the BizTalk WCF adapter team. The interesting thing was the comfort level that WCF gave for Service orientation. I was discussing about the various scenarios we face with customers and how WCF was something that was missing for a long time. I was quite new to Biztalk and so he gave me a walkthrough of the adapter. I met a few of the team members and realized the amount of enthusiasm that they had in churning this out.

Fundamentally WCF has bought that sense of freeing yourself from the protocol and the security and well its time to get your SO blahs up and running and stop whining about security cause right now WCF just delivers.

Standing by OO principles we would have to say "Private memebers are only visible to to the class in which it is defined"

This is the MSDN Defintion for the C# private keyword
"The private keyword is a member access modifier. Private access is the least permissive access level. Private members are accessible only within the body of the class or the struct in which they are declared.

Nested types in the same body can also access those private members.

It is a compile-time error to reference a private member outside the class or the struct in which it is declared."

The whole idea of Private access modifier being only a language construct and not an runtime principle is quite interesting.It brings up one of the core concepts of accessmodifiers only down to the degree of language compilation and enforcing them during runtime still takes a back seat.

The whole fundamental of .NET is the CLR and if we can me an excution of a private method at runtime, would this defeat the the purpose of making something private? To lay it out, this is what I am trying to ask.

using System;

using System.Reflection;

using System.Collections.Generic;

using System.Text;

public class A

{

    private static void YouCantCallMe()

    {

        Console.WriteLine("I got called.");

    }

}

class Program

{

    static void Main(string[] args)

    {

        Type t = typeof(A);

        t.InvokeMember("YouCantCallMe", BindingFlags.InvokeMethod |

                                BindingFlags.Static | BindingFlags.NonPublic, null, null, null);

    }

}

The runtime with the help of reflection helps you get around one of the principles of OO which prohibits visibility of private memebers outside the current body. Personally i find it pretty cool that i can do stuff like this with reflection.
Any thoughts on this ?

I just wanted to list out the basic parts of a WSDL and what they map to when you use/generate metadata.

I am really happy that hey kept the side bar. Really makes it an awesome space utilization for more wider monitors.