About WCF LOB Adapter SDK (ASDK)

Many large enterprises have disparate systems including legacy mainframe, packaged and homegrown applications that need to be integrated with each other to provide end user solutions. The technology integration becomes more complex after companies go through Mergers and Acquisitions, which are prevalent in Financial and Telecom Industry verticals. Back-end systems such as SAP, PeopleSoft, Siebel, Oracle, IBM CICS, IMS, VSAM and Relational Databases are collectively known as Line-of-Business (LOB) applications. Adapters provides legacy modernization by bridging existing back-end applications with the modern interfaces. Windows Communication Foundation (WCF) provides a unified framework for building distributed applications, including creating adapters to existing applications.

The WCF Line-of-Business (LOB) Adapter SDK is a collection of runtime engine and tools to help Adapter Developers in creating service-oriented interfaces to existing LOB applications using WCF. The goal of the WCF LOB Adapter SDK is to facilitate uniform development of reusable metadata-oriented WCF-based adapters that enable enterprise applications, databases and messaging platforms to integrate with each other. The Adapter SDK is based on WCF Channel Model and it surfaces an adapter to a LOB application as a WCF Binding.

The Adapter Consumer can access an adapter like a typical WCF Service and doesn't have to learn a new programming model. The same adapter developed using the Adapter SDK can be reused in multiple .NET applications including Custom WCF Client Applications, BizTalk Server, SharePoint Server and SQL Server Integration Services (via adapter developer provided ADO.NET shim). In addition, this SDK provides a common facility for Adapter Developers to expose rich LOB metadata to the Adapter Consumers, who can selectively browse, search and retrieve WCF contracts from this available metadata in the adapter.

Architecture

WCF LOB Adapter SDK is based on WCF Channel Model and the adapter built using ASDK is technically a Transport Binding Element, representing a transport channel at the bottom of a WCF Channel Stack. A pre-defined binding is created for an adapter to complement the standard system-provided bindings including BasicHttpBinding, NetTcpBinding and NetNamedPipeBinding. This pre-defined binding can be customized to include other aspects of communication such as Protocols, Security, Reliability, Transanction Propagation and Interoperability. A WCF Custom Binding can also be written using the scratch to add custom Quality of Service (QoS) behaviors on top of the adapter.

The following diagram(s) shows how a WCF LOB Adapter fits within a WCF channel stack.

Goals

Here are three main goals of the WCF LOB Adapter SDK

1. Uniformity

o Includes API for adapter developers to build adapters in a consistent and repeatable manner

o Every “integration technology” implements its own adapter framework - with WCF LOB Adapter SDK there is just one

o Provides an abstraction layer between service oriented world and proprietary application interfaces

2. Reusability

o Provide building block application components

o Enable uniform interfaces across various integration technologies

o Surfaces adapter as a WCF binding, widening reach

3. Consumer-Driven Contract Generation

o Generate operations and business objects by introspecting target system

o Browse/Search and generate WCF contracts

o Service Contract reflects changes using live function and type model of the target system

WCF LOB Adapter SDK Features

Relationship with BizTalk Server

Microsoft BizTalk Server ships with BizTalk Adapter Framework which promotes creating custom adapters for use within BizTalk Server. BizTalk adapters use the BizTalk Server Administration Console for adapter management, BizTalk Explorer for adapter configuration, and the Adapter Framework for design-time APIs. WCF LOB Adapter SDK is the evolution of BizTalk Adapter Framework. Since WCF LOB Adapter SDK is based on new architecture, the adapters built to Adapter SDK will continue to co-exist side-by-side with the adapter written using BizTalk Adapter Framework. Microsoft and Microsoft’s Technology Partners have built adapters using BizTalk Adapter Framework. The future direction recommended by Microsoft is to start using WCF LOB Adapter SDK for building new adapters. The following diagrams show how the new adapters built using the Adapter SDK can co-exist with the adapters built using BizTalk adapter framework.

Relationship with WCF

The base adapter class in WCF LOB Adapter SDK derives from WCF System.ServiceModel.Channels.TransportBindingElement and includes browse, search and resolve metadata interfaces for Adapter Consumer to selectively generate the ServiceDescription. The adapter created using this SDK is surfaced as a WCF binding and is technically a line-of-business system channel.

The following characteristics make adapter channels different from regular WCF transport channels:

• Adapters are metadata-centric

o Require metadata at run-time

o Require metadata cache management

o To provide design-time experience, they need to implement search/browse/resolve API

• Adapters are always connection-oriented

o Connection is very central concept for the adapter

o Require connection pooling and connection life-cycle management

• Adapters are effectively “in-proc WCF Services”

Even though an adapter is NOT a WCF Service, consuming an adapter is similar to using a WCF Service, due to metadata generation capabilities provided by the adapter. The adapter consumer is not required to learn a new programming model. The client can use either the WCF Service Model or WCF Channel Model to communicate with an adapter.

A typical WCF service programming lifecycle begins by a Service Provider defining a static service contract, implementing this contract and hosting the service. Each service is defined entirely by a fixed monolithic contract. This contract needs to be updated by the service provider in order to reflect any changes in the existing application. The Adapter built using WCF LOB Adapter SDK, on the other hand, surfaces the contracts on-demand by consumer. The consumer browses through the available metadata in the adapter using the standard interfaces and then selects the operations and types for inclusion in a dynamic contract. This metadata reflects live changes from the back-end application. Let's take an example of creating service-oriented interfaces for stored procedures in a database. If you were to use WCF service programming model, you can use the very intuitive declartive attributes (ServiceContractAttribute, OperationContractAttribute, etc.) to map each stored procedure as an operation in a WCF contract. But whenever there is a change in the stored procedure or a new stored procedure is added, the service developer has to make changes in the contract and re-host the service. With WCF LOB Adapter SDK on the other hand, the metadata resolver API in the adapter can be implemented to generate the WCF contract dynamically at design-time by querying the stored procedure input/output parameters. So, if there are 50 stored procedures, the adapter consumer can browse/search through these 50 service operations. He/she can then select the desired operations, pass these selected identifiers back to the adapter, so adapter can resolve the operation input and output for these operations and return back a WCF contract. This WCF contract can be then used as raw XML Schemas (in BizTalk Server 2006 R2) or as Common Language Runtime (CLR) proxy (in custom .NET applications).

Adapters are more appropriate in scenarios where a non-WCF based system is required for integration, and this system is dynamic with large amount of metadata.

Related Posts

Using Adapter Development Code Generation Wizard