WCF LOB Adapter SDK and its relationship with WCF Channel Model

In this post, I will show how WCF LOB Adapter SDK relates to WCF Service Model and WCF Channel Model.

WCF Service Model provides an intuitive programming model to create service-oriented interfaces. There is plethora of information available on WCF (aka Indigo) now since its inception few years ago. Typically when you are reading about WCF, the most common usage is using classes/interfaces/attributes in System.ServiceModel namespace.

WCF Channel Model can be used for development of custom protocol and transport channels to communicate with existing systems that expose its functions through proprietary network API. The channels adapt the proprietary network API to WCF.

WCF LOB Adapter SDK utilizes the extensibility features of WCF Channel Model and surfaces an adapter to target line-of-business system as a WCF Binding.

You can write a custom channel using WCF LOB Adapter SDK and using WCF Channel Model. Here are some of the resources you can use when developing a custom channel (aka creating an adapter) using WCF Channel Model:

1) Channel Model Overview

2) Developing Channels

3) Nicholas Allen’s Blog (an excellent resource)

4) Building Custom Channels

So if you can create a WCF binding using WCF Channel Model, why WCF LOB Adapter SDK? Whatever you can do with WCF LOB Adapter SDK, it is definitely doable with WCF Channel Model.

WCF Channel Model fits in very well for creating transport adapters. Here is an excerpt from Building Custom Channels:

Custom channels are a powerful and versatile extensibility point. You'd write a custom protocol channel if you want to implement a wire protocol. Examples of wire protocols include the WS-ReliableMessaging protocol (WCF already implements that one for you as a channel) and a chunking protocol (see the chunking channel sample below). You'd write a custom transport if you want to send/receive WCF messages over a transport other than the ones we ship in the box (we ship TCP, HTTP, Named Pipes, MSMQ, and PeerChannel). For example, you could write a UDP transport (there's a sample of that in the WCF SDK) or an SMTP transport. Another reason to write a WCF transport is to integrate with an existing system that's not exposed as a Web service. In this case your transport acts as an adapter adapting WCF messages to the existing system's message format or API allowing a WCF client to talk directly to the existing system. An example of that is the WSE 3.0 TCP transport sample.

If you are writing a pure transport and/or protocol channel, Microsoft recommends utilizing WCF Channel Model. WCF LOB Adapter SDK is an application of WCF Channel Model and provides following additional features more suitable for systems that can be described using rich metadata.   

1) Code Generation Wizard

It facilitates creation of WCF channels and bindings through Adapter Development Code Generation Wizard. The adapter developer only focuses on three key aspects of building an adapter – connectivity, metadata and message exchange. The channel concepts like message exchange patterns, channel factory, channel listener, binding element, binding, WSDL export/import and Policy export/import are not exposed to the adapter developer.

The adapter developer focuses on mapping of the message from/to their line-of-business messages in inbound and outbound handlers.

2) Metadata Explorer

It provides an ability to generate WSDL / WCF Contract dynamically at design-time. Let’s say you are creating a database adapter with each stored procedure exposed as an operation. The number of stored procedures in the database can vary from implementation to implementation and the parameters/return values can change. Such functionality shouldn’t be captured in a static contract. WCF LOB Adapter SDK promotes inspecting the live line-of-business system for its metadata and allows generation of contract from this live metadata. Even though you can provide metadata support for a WCF binding element in WCF Channel Model using IWsdlExportExtension.ExportContract, WCF LOB Adapter SDK provides the API to enable browsing and searching of metadata. And … when the message flows over the channel during run-time, the code has knowledge of metadata of the message (via SOAP action) and can use it during construction, transformation and verification.

The adapter developer can provide the metadata exploring and export functionality through metadata browse handler, metadata search handler and metadata resolver handler.

3)  Connection Pooling

Typically when a line-of-business adapter is created for a database, messaging system and/or packaged application, there is a concept of a connection. WCF LOB Adapter SDK provides an efficient way of using these connections through a pool of connections. Using the WCF Channel Model, the adapter developer can provide own implementation of connection pooling.

The adapter developer can tweak the adapter settings for connection pool and connection pool manager.

4) Adapter Data Reader / Adapter Data Writer

Rather than having to use XmlDictionaryReader / XmlDictionaryWriter to walk through the WCF Message, since the adapter has the knowledge of the metadata of the message, the adapter operation and type readers/writers can get callbacks (e.g. OnAfterOperationParameterWrite) in which the adapter developer can then do line-of-business system specific mapping and transformation.

The adapter developer can use these readers and writers within the message exchange handlers.

Here is a high level synopsis:

* If the adapter developer is using WCF Channel Model to create the line-of-business system adapter, then the N/A items can be supplemented with developer's own implementation.

Enterprise Application Integration is the secure and orchestrated sharing of processes and/or data between applications which weren’t originally designed for such sharing. To enable such applications to participate in integration processes one has typically had to write an integration adapter or write a web service wrapper around the existing line-of-business system APIs to enable them to be “normalized” for consumption by integration brokers such as BizTalk Server. Adapters traditionally have achieved the normalization by reducing the target systems to appear like “messaging systems” and capture the LOB specific aspects in the actual message that is transferred to the backend systems. While this approach is simple it is practically unusable in regular applications where typically the levels of abstraction are much higher and semantically richer than just exchanging messages. Web services on the other hand offer a much more “human friendly” programming model and the appeal of wide reach and support for several popular WS-* standard protocols. But web services today require a static monolithic service contract declared a priori describing a strongly typed service interface that is the public face of the service.

For LOB systems which have an enormous amount of operations that are constantly changing and evolving it is impractical for such a contract to capture the capabilities of the system with 100% fidelity. One of the more common ways of exposing such a dynamic system to EAI systems is to have a generic InvokeWebMethod() operation exposed as the extensibility mechanism to deal with any new or changing metadata. Here is an example of one such implementation. So the client of the system will invoke the newer methods by passing in the appropriate method name, parameters etc packaged in generic array data structures to be “interpreted” by the InvokeWebMethod() function and turn around and make the actual call. Although this provides the “dynamic” functionality in being able to call any method, it expects the client to be fully aware of the details of the new methods on the LOB system. This is a fundamental violation of the SOA tenets where the boundaries between client and service are expected to be strictly limited to what is exposed in the service contract and nothing more. To expect the client to be deeply aware of the internals of the LOB system leads to tight coupling between service and client and this is total anathema in the SOA world.

What we need in this situation is an intermediary sitting in between the LOB system and the consuming client that lets the client “carve out and construct” a strongly typed service contract dynamically from the live metadata in the LOB system. The WCF LOB Adapter SDK enables the development of adapters which act as an “uber service” that can incarnate any service from the available backend metadata. This allows the clients to keep up with the changing functionality in the LOB system at design-time without being intimately aware of these changes. If the target system changes, the client can easily regenerate updated proxy and tremendously increase the develop-test-deploy web service cycle. This approach also enables a more consumer- friendly experience for exposure of LOB systems with large and unwieldy metadata although the metadata may remain more or less static.

Additionally, adapters written to the WCF LOB Adapter SDK eventually manifest themselves as WCF bindings which can be invoked via WCF Service Programming Model and WCF Channel Programming Model (via the client proxy generated from one such composed contract) thereby combining the advantages of both traditional adapters as well as web services.

Summary

WCF Service Model is the next-generation distributed application technology for developing and consuming services in Windows. The client and service communicate with each other using endpoints.

WCF Channel Model provides extensibility by enabling creation of custom protocol and transport channels for a binding in an endpoint.

WCF LOB Adapter SDK is a utility of WCF Channel Model to surface target line-of-business systems as WCF Bindings to the WCF clients. This means a client can access an existing line-of-business system the same way as they would any other WCF Service. The client is abstracted from having to learn the proprietary access mechanism of the target line-of-business system.