This post originated from an RSS feed registered with .NET Buzz by Christian Weyer. Original Post: Hosting my WSE 2.0 services Feed Title: Christian Weyer: Web Services & .NET Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/cweyer/Rss.aspx Feed Description: Philosophizing about and criticizing the brave new world ... Latest .NET Buzz Posts Latest .NET Buzz Posts by Christian Weyer Latest Posts From Christian Weyer: Web Services & .NET

Today I got inspired ;)
Just listened to Keith Ballinger (Keith, your blog is dead ...?) talking about WSE 2.0 - it was good and fun and he showed some live coding samples. OK. But there is always some 'toy factor' with those demos. They are hosted in command line applications or maybe in a Windows Forms app to show how powerful SOAP messaging can be. But we all know that in many cases - if not all - it is very important to have a good, a rock solid process model for your applications. When we do production-ready applications with Web services facades then we really need a good place where all this runs - and do not want our customers to have to run command line apps.

No, I do not want to stress on the various different options of available hosting models and technologies on the Windows platform. Don Box did quite a good job on that.

But, I think there is one really good hosting model you can leverage for this: COM+. Not talking about using the services COM+ offers, like transactions, security et. al. Just the fact that COM+ is a mature and good technology with a good process model (whatever you want to understand by 'good' here).

So I wrote a small and very simple sample for this scenario. Let's take the famous StockService project from the WSE 2.0 Quickstart samples, just for convenience. We are especially interested in doing WSE-based SOAP messaging based on TCP. We do not talk about extending ASMX with WSE, we want 'true' messaging capabilities. Therefore we use a SoapService-derived class for our Web service.

[SoapActor("soap://StockService")]
public classStockService : SoapService
{
  [SoapMethod(http://Stockservice/StockQuoteRequest)]
  publicStockQuotes GetStockQuotes(StockQuoteRequest message)
...

Now, in order to being able to host a WSE-based Web service inside COM+, I decided to let the COM+ server application run as an NT Service. This NT Service is the host process for the Web service with COM+ delivering the process model and thus we do not have to care about the nasty scalability, robustness issues we would have to implement manually, otherwise.

Obviously, we need a piece of code in order to actually start-up and register our WSE-based Web service so that service consumers can send messages to our endpoint. This is achieved by implementing the IProcessInitializer interface. The WSEShim class is soley there to properly set up all needed COM-related information so that our DLL may be registered with COM+. There are no public methods and we surely do not want to open up our actual service methods (like GetStockQuote) by connecting to the component via DCOM - all we want is SOAP messaging over TCP, fine.

public classWSEShim : ServicedComponent, IProcessInitializer
{
  EndpointReference endpoint = null;

  public void Startup(objectpunkProcessControl)
  {
    Uri via = newUri("soap.tcp://" + System.Net.Dns.GetHostName() + "/StockService");
    Uri address = newUri("soap://StockService");
    endpoint = newEndpointReference(address, via);
    SoapReceivers.Add(endpoint, typeof(StockService));
  }

  public void Shutdown()
  {
    SoapReceivers.Remove(endpoint);
  }
}

As a last step, register the DLL as a COM+ app (regsvcs.exe) and start the COM+ NT service and off we go: a WSE-enabled SOAP messaging service hosted inside COM+, with a powerful process model.
Thanks to my friends Dariusz, John, and Benjamin for discussing this topic.