We're developing software that allows our custom scheduling application (master role) to synchronize with Microsoft Exchange Server 2010/2007 (slave role). Our solution is based on .NET 4.0, the EWS Managed API and Parallel Fx, and of course our own C# code. We've taken special care of the fact that "ExchangeService" class instances are not used by multiple threads concurrently and are conservative regarding the total number of instances (we currently have 10 live instances at any given time). We do however make a lot of calls (FindItems, CreateItems, UpdateItems, DeleteItems, LoadPropertiesForItems).
Digging deeper, we've found that this approach doesn't buy us really much. Whenever an operation is issued a new HttpWebRequest is created, executed and closed. For authenticated requests (in our case: https + WebCredentials) it appears that the underlying tcp connection is returned to the OS with a state of TIME_WAIT (as described in this article: msdn.microsoft.com/en-us/library/aa560610(BTS.10).aspx) and sits there, doing nothing for 4 minutes (by default). We already applied the suggestions in the above article (further discussion can be found here: blogs.msdn.com/b/dgorti/archive/2005/09/18/470766.aspx), and reduced the "sits there" time to 30 seconds. This is all fine in a test environment, but not on a production system where tcp connections are a more scarce resource and our app is not the only one using them.
I think the problem has to do with how the EWS Managed API is using HttpWebRequest (or even deeper in System.Net). We wanted to toy with msdn.microsoft.com/en-us/library/system.net.httpwebrequest.unsafeauthenticatedconnectionsharing.aspx and msdn.microsoft.com/en-us/library/6y3d5dts.aspx but since everything in the EWS Managed API is either internal or sealed, it becomes difficult to extend/try this out.
Advice on how to proceed welcome!