public class MyDocService : SoapService
{
   [SoapMethod(MyDocCenter.ActionSend)]
   public void SendDoc(MyDocument doc)
   {
      // Implementation here
   }
}

Register the method as being accessible, like this :

SoapReceivers.Add(new Uri(string.Format("soap.tcp://{0}/MySoapBox", System.Net.Dns.GetHostName())),  new MyDocService());

And now everybody can send messages to your method using the TCP protocol. The most promising thing in this approach is that the protocol to use is a parameter to the listener started. In WSE 2 you can choose between tcp and http, in Indigo I expect message queues (and maybe smtp/pop) to be a possible choice as well. In the consumer is an interesting point as well. A consumer inherits from the SoapClient base class. This class has two methods two send the soap-message, SendRequestResponse and SendOneWay, pushing the metaphor of "making a call" to "sending a message".

In the current asp.net the consumer of the service has to know the endpoint address of the machine who is going to service the request. WSE introduces routing. A web service router receives requests from consumers and can route these request to another address which will service it. This routing is quite basic, the request can only be routed to an endpoint which provides the service. To keep up the networking  analogy I would call this a web-services-switch. But the potential of all of this is gigantic. Imagine a real router which can route a message to another router and switches transport protocols as needed. In what I think (hope) will be Indigo we don't have to care to much about this and can fully concentrate on the content of the messages. In a month we'll all know more, for the moment I will browse some more in the WSE stuff, I don't think that will hurt.

blog on,

Peter