To Indigo, the CLR contract is *not* the messaging contract

In a blog comment recently, I explain why a method marked 'private' can still be used to receive Indigo messages. To recap: in the conceptual model we're propounding with Indigo, an object that implements a web service can be accessed as a regular local CLR object, and it can be accessed (probably remotely) as a web service; and these are two entirely distinct interfaces to the service, with independent access controls, despite the fact that they both end up calling the same method on the CLR service object. In true Microsoft fashion, I will now begin a sentence with the word 'so'...

So, this means that the following two web services expose the same web service interface, and accept exactly the same SOAP messages, even though they are two separate CLR classes that could be in entirely different assemblies and namespaces:

[ServiceContract]
class Sample
{
      [OperationContract]
      private string Hello(string name) {...}
}

[ServiceContract]
class Sample
{
      [OperationContract]
      public string Hello(string name) {...}
}

if the default mapping for converting a CLR interface into a messaging interface doesn't give the same messaging contract, we can override that mapping:

[ServiceContract(Name="Sample")]
class Reality
{
      [OperationContract(Name="Hello")]
      private string Aloha(string name) {...}
}