In my last post I mentioned the registry content for registering a custom WCF LOB SDK binding as an adapter. I am still working out the details of how this should be done for a custom adapter and will be hoping how to do this in a walkthrough in a later post.
To give you some preview of the process, the adapter class just needs to inherit from Microsoft.Adapters.Common.BizTalk from the BizTalk adapter pack rather than Microsoft.ServiceModel.Channels.Common.Adapter from the WCF LOB SDK. The abstract classes for Microsoft.Adapters.Common.BizTalk are included with the BizTalk Adapter Pack. The GUID values mentioned in the .reg file are set in the derived adapter classes and when calling the base class constructor for the adapter, WcfBtsAsdkAdapterBinding.
While it looks like it is possible to register a custom WCF LOB SDK binding as an adapter, the question comes up as to why would you ever want to do this when you can just use the custom binding in the WCF-Custom adapter anyway. This is one question I have asked repeatedly in reference to why the BizTalk adapter pack gives the developer the option of using the separate adapter rather than the bindings with the WCF-Custom adapter. At this time I am not sure if some of the scenarios I have come up with explain why the BizTalk adapter pack bindings are also exposed as custom adapters.
I wanted to take this post and describe a few scenarios that would be useful for having the capability of an adapter rather than a WCF-Custom binding.
Deciding whether to expose a WCF LOB SDK binding vs. a full adapter is an important question that depends largely on the consumers of your data. If you want the same data and management of the connection to your data to be the same whether it is being called from .NET or BizTalk then use of the standard custom binding makes sense. You will only need to code the logic once as the custom binding. But there are typically many differences between .NET applications and BizTalk applications so it seems like there would be compelling reasons to have other settings or different settings based on whether the binding is being called from a BizTalk system. For example, SSO settings like the SSO Application Name and key should not be exposed unless the binding is being called from BizTalk. These properties will not make sense if you are providing a way to connect to your custom LOB data without going through BizTalk.
The full adapter does have a configuration limitation that prevents it from fully functioning as an equivalent to the WCF-Custom binding. The custom binding configuration exposes the custom behavior config window for all WCF-Custom adapter handler properties. At this point I am not sure if it is possible to have the custom full adapter to provide a customized property page for the adapter handler properties. Interestingly, all of the BizTalk adapter pack custom adapters have the properties button grayed out in the adapter handler window. So it is not even possible to choose the same adapter handler configuration as found on the WCF-Custom adapter handlers so if you did use a full adapter rather than WCF-Custom you would still need to register the custom WCF behaviors in the machine.config. This could possibly be an overlooked scenario in the current implementation.
So theoretically it is possible to come up with a reasonably good scenario for splitting apart the properties and implementation based on the caller type. But due to the current BizTalk admin console limitation on the adapter handlers configuration, there may unfortunately be some tradeoffs.