Scenarios for creating an adapter using WCF LOB Adapter SDK and relationship with WCF Service
Windows Communication Foundation (WCF) is Microsoft's unified programming model for building service-oriented applications with managed code. It extends the .NET Framework to enable developers to build secure and reliable transacted Web Services that integrate across platforms and interoperate with existing investments. WCF can be used to create adapters to existing applications and these adapters help in integrating disparate systems for end business solution. An adapter is fundamentally a module that bridges a client program and a target system, exposing well-defined standardized interfaces over various programming models to the client applications, while internally mapping them to the proprietary interfaces and protocols supported by the target system. One of the things I personally like most of about WCF is its extensibility which can support many custom scenarios including development of adapters. The developers can create a WCF Service, a WCF Channel or use WCF LOB Adapter SDK to expose the existing system functionality as a WCF Endpoint. Nicholas Allen’s post provides details on type of problems that work naturally with channels. The Adapter built using WCF LOB Adapter SDK is exposed as a WCF Transport Binding Element and a WCF Binding to the WCF clients. Consuming an adapter is just like consuming a WCF Service. The Adapter Consumer doesn't have to learn a new programming model to consume adapters. So when is it more appropriate to build a WCF Service to service-orient existing application instead of using ASDK to build adapters? Let’s talk about that!
The following diagrams demonstrates that even though a WCF Service can be used to surface existing applications with service-oriented interfaces, the adapter built using ASDK explicitly provides that functionality. ASDK is targeted towards creating tools and plumbing code for Adapter Developers. And it is most appropriate when the target system has a large amount of metadata and is changing frequently!!
|
Diagram Description |
WCF Service |
WCF LOB Adapter |
|
WCF LOB Adapter SDK extends WCF with metadata harvesting extensions and generates consumer-driven contracts |
 |
 |
|
Metadata Tooling -->
SvcUtil Tool vs. Adapter Metadata Utility Tool |
 |
|
|
Contract Creating -->
Static Contracts vs. Contract Compositon / Metadata Harvesting |
 |
 |
WCF LOB Adapter SDK provides a first unified framework for building service-oriented WCF-based adapters. ASDK eases adapter development by providing simplified abstractions that handle common infrastructure and plumbing aspects of interaction with target systems, besides providing common runtime services. This enables Adapter Developers to focus on business logic required to interface with and surface target system functionality. Technically, the Adapter is exposed as a WCF Transport Binding Element to clients, enabling extensibility, connectivity, message exchange and metadata exchange with the existing applications. ASDK extend WCF with target system LOB metadata provision. A WCF Service is typically defined using a top-down paradigm with contract-first methodology. In order to surface metadata from the target system, one or more contracts need to be defined followed by implementation of each contract for message exchange. ASDK, on the other hand, allows the adapters to generate the contracts based on the available target system metadata and user selection. This means if the target system is changed, the contract generated from the adapter will reflect that change. If it was a WCF service, a developer would have to manually make that change in the contract, implement, compile and re-deploy the service.
|
When to create a WCF Service? |
When to create an Adapter using ASDK? |
|
· A brand new application is being created for integration.
· The target system is relatively static.
· The target system has little or no metadata.
· A pure transport channel is required without any need for metadata exploring and resolution.
· Existing application / system is written using .NET. Decorate with ServiceModel attributes such as ServiceContract, OperationContract, MessageContract, DataContract, etc.
|
· It is impractical to capture the metadata of target system in a monolithic contract.
· The target system is dynamic and has updates to it frequently.
· The target system has large amount of metadata.
· The target system is an existing, non-WCF (and non-Web Service) system.
· There are multiple implementations of the target system. For example – SAP system has varied implementations based on customer scenarios. Sometimes, many instances of an application exist in the same organization within different adapters.
· Adapter Consumers should be able to explore available metadata from target system and compose a WCF contract with a “click-of-a-button”.
· There is a large, diverse number of users for the target system’s data.
|
The following figure summarizes under the conditions based on which a choice can be made for creating a typical WCF Service or creating an adapter using the ASDK.
No doubt, WCF fits into all the boxes in the above mentioned figure. ASDK is just another extension of WCF. The decision to select one method over another for enabling existing applications with service-oriented interfaces depends on the requirements and capabilities offered by the target system. The time-to-market and developer productivity will be another factor to consider when making the final decision.
