Since the release of ILOG Rules for .NET 3.0 in February of this year I have seen a good number of questions now regarding best practices with RES.NET integration and deployment. In many cases, the question is around what provider to use–Local or Remote. Given the WCF underpinnings, is there anything one should think about that would affect performance? The short answer is yes. Below are some general facts and guidelines that should be understood and followed:

1. The RES.NET execution API wraps WCF by dynamically generating the proxy client (ChannelFactory) and exposes a limited set of options that we must do in our client code. This pattern is used regardless of how you are invoking the API–local or remote.

2. In the case of the local invocation, the execution API spawns a ServiceHost object programmatically in the background. This is a lightweight service running within managed code and shares the same process that launched it. When this is done, the ServiceHost spawns its own thread pool using the .NET library and is built into WCF.

3. If your project is a thick client (.NET managed code) you should cache the session object for reuse—make it a high-level member of the EXE. All threads in the application will in turn point to the ServiceHost that was created.

4. For a managed application or fat client, the most efficient configuration is the local provider. Do not attempt to add your own thread pool or create multiple instances of the session you created on the first invocation of the RES.NET client.

5. If you have an ASP.NET application, you should always deploy RES.NET to IIS and ASP.NET. This is because WCF will share the thread pool with IIS and WCF will reuse the thread for processing the WCF request. This is only the case where both the application and RES.NET share an IIS instance on the same machine. If they are on separate machines, again, you should use the ASP.NET deployment option for RES.NET (this requires the use of the remote provider when using the execution API).

6. Do not use the local provider for ASP.NET applications. This will spawn the ServiceHost and will create an additional thread pool.

7. If you have a class library that is uses RES.NET but need to run in both a fat client and ASP.NET, then you should write a little factory and load the correct provider for the deployment model.

If you would like to start a thread on this topic, post your question or comment to the RES.NET forum (click here for the forum) .

Hope this helps many of you and have fun.

CCB

Posted by Chris Berg in Rules for .NET. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.