Setting up WSE inproc messaging
public class MessagingReceiver : SoapReceiver
{
protected override void Receive(Microsoft.Web.Services.SoapEnvelope envelope
{
System.Diagnostics.Debug.WriteLine(
string.Format("Receive: {0}", envelope.OuterXml));
// TODO: Add a more interesting implementation
}
}
Then you register an instance of that class with WSE to listen on an inproc endpoint. That url uses a custom protocol to identify soap inproc delivery:
SoapReceivers.Add(
new Uri( "soap.inproc://locahost/myrec" ), new MessagingReceiver() );
Note the soap.inproc protocol and, since IIS is out of the picture, that there is no more requirement web service Urls having .asmx extensions (which gave me quite a bit of grief last week).
Sending messages is equally easy. You pass the Soap message you want to send to a SoapSender object:
SoapSender soapSender =
new SoapSender(new Uri( "soap.inproc://locahost/myrec" ) );
SoapEnvelope env = new SoapEnvelope();
// TODO: setup envelope with header, body and Action
soapSender.Send( env );
The obvious departure from Microsofts previous web services model is that they support real messaging, not just the RPC model. It seems like they finally learned the lesson from the DCOM days: Many “developers” don't understand why “simple method calls” are so slow. They don't understand that the “method call” really went across a network and what's involved with that because the tools make it look like a piece of cake. Even more so, they just slap the [WebMethod] attribute on to an interface designed for inproc use and BOOOOM.
Another important reason to focus on SOAP messaging instead of RPC is keep web services interoperable. With messaging at least you have an opportunity to think about the message design since you have to code the message interpretation by hand and there are no auto-generated proxies.