WCF LOB Adapter SDK Q & A

C. Venkatesh, Principal Group Manager of WCF LOB Adapter SDK at Microsoft provides following answers to these commonly asked questions about this adapter SDK.

Q1. What is WCF LOB Adapter SDK, who should be using it and why?

The WCF LOB Adapter SDK is targeted at developers that are interested in exposing their line-of-business (LOB) systems for integration purposes to any .NET integration broker/integration application. For purposes of this discussion a LOB system may be defined as a metadata rich back end systems whose functionality is too rich and dynamic to be captured in traditional static Web Service Description Language (WSDL) contracts. This SDK enables development of metadata driven, host-agnostic adapters i.e. independent of consuming app, which helps you avoid duplication of effort in writing adapters.


Q2. How do the adapters written to this SDK fit into the Microsoft .NET stack?

Adapters written to this model are surfaced as WCF bindings. Much like a traditional WCF web service can be consumed by the client using the BasicHttpBinding or WsHttpBinding, an adapter to a system, say SAP, can be consumed using the “SAP binding” or “SAP adapter”.


Q3. It seems like from consumer’s point of view, a WCF LOB Adapter looks and behaves like a WCF Service. So how does this adapter differ from a WCF Service?

An adapter may be conceptually thought of as an “uber service” atop an LOB system that will let you carve out and compose a contract that is most relevant to your application and still retain all the advantages of a traditional service like loose coupling and strong typing.


Q4. Given all these choices, when would a developer write a WCF LOB Adapter or a WCF Service or a WCF Channel?

If the target system that you are trying to integrate with is not metadata aware and your intent is to simply transport bits to the target system, then you write a WCF transport channel using the WCF Channel Model framework directly. Examples of such systems include MSMQ, ftp etc.

If the target system is metadata aware but its metadata/functionality is easily captured in a static contract (or a manageable set of contracts) then it is best to write a traditional WCF service wrapper around the system native calls. E.g. a proprietary Math calculator program written in Fortran.

If the target system’s functionality is large and dynamic, and you want to be able to expose the entire gamut of functionality for integration, creating an adapter to the WCF Adapter SDK is your best bet. Examples of such systems include SAP, databases, etc.


Q5. How are adapters written to WCF LOB Adapter SDK different from adapters created using BizTalk Adapter Framework?

Adapters created using BizTalk Adapter Framework are consumable from only within BizTalk Server. On the other hand, adapters written to WCF LOB Adapter SDK are surfaced as custom WCF bindings which widen their reach to any application that consume a service – which for all practical purposes is any .NET application including BizTalk Server 2006 R2. The WCF-based adapters are used within BizTalk Server 2006 R2 using BizTalk WCF Adapter and continue to exist in parallel with the native BizTalk Adapters.

Figure: BizTalk Integration with back-end applications using adapters written to BizTalk Adapter Framework


Figure: BizTalk Integration with WCF Client and Services using BizTalk WCF Adapter 


Figure: BizTalk Integration with back-end applications using adapters written to WCF LOB Adapter SDK

Q6. How are these WCF-based adapters used in SQL Server? Does WCF LOB Adapter SDK include a generic ADO.NET provider?

When we talk about WCF-based adapters in the context of SQL – let’s talk about these two possible scenarios: 1) SQL Server invoking the adapter (i.e. a stored procedure calling into SAP) and 2) Data mining using SQL Server Integration Services.

For the first scenario, SQL Server can use adapters in two modes: as a Web Service client or as an ADO.NET client. As a Web Service client, the adapter can be hosted within IIS and then invoke the web service exposed by the adapter as an ASMX endpoint.

For SSIS, WCF LOB Adapter SDK V1 release doesn’t include a generic ADO.NET provider. Adapter Developers can choose to build an ADO.NET provider for SSIS integration.