Usage pattern for IInstanceContextInitializer vs IInstanceContextProvider

I mentioned in my previous post that June CTP introduces a new extension to enable sharing. One common question being raised internally is the difference between IInstanceContextProvider.InitializeInstanceContext and IInstanceContextProvider.Initialize. Both these methods are called whenever a new InstanceContext is created and so the question is why did IInstanceContextProvider duplicate this method?

Let me talk about why this method was introduced in IInstanceContextProvider. To implement sharing users need to know when a new InstanceContext is created so they can wire up the caching logic. So if we did  not provide this API, users would need to implement IInstanceContextInitializer just to get this notification. Also, for sharing one needs to associate the Channel on which the message came with the InstanceContext created so that the InstanceContext lives till that Channel is functional. One look at the IInstanceContextInitializer.Initialize parameters tells us that it currently doesnt pass the Channel. So one possible solution is  to change Initialize signature. But we felt that the sharing extension should be the all that the users need to worry about when designing sharing and the API's in that extension should be designed such that all necessary information is available to the implementor. So we decided to go with one interface for the extension.

The one may wonder that IInstanceContextInitializer is redundant and that it can be removed. The reason its still there is because both these interfaces are there for two very different scenarios. Think of them like two kind of saws, one a chain saw and the other a low power precision saw. IInstanceContextProvider is the heavy duty one which lets you bypass InstanceContext lifetime logic, enable sharing and InstanceContext leasing, while IInstanceContextInitializer is for more finer things like adding extensions to newly created InstanceContext.

Also, your service can have exactly one IInstanceContextProvider while it can have any number of IInstanceContextInitializer's.

Maheshwar Jayaraman[WCF]