If you read the product documentation, you will find
that the ASDK-based adapters are built on top of the WCF Channel model
and surface as custom WCF bindings. What this means is that WCF clients
are able to communicate with ASDK-based adapters as if they were WCF
services. Likely, the very first question you want to ask is whether the
ASDK-based adapters are in fact WCF services just presented under the
new fancy name. No, they are not! The use of the acronym WCF in the WCF
LOB Adapter SDK is somewhat misleading; WCF forms the basis of the
technology but the software does not revolve around web services. To
understand how the adapters fit into the WCF infrastructure, let's
recall some of the WCF fundamentals.
In order to
establish communication process with clients, any WCF service must
expose at least one endpoint. The WCF endpoints are based on three
elements, known as the "A, B, and C" of the WCF. These three elements
are:
Address: It takes a form of the URI specifying the address where the service can be reached at.
Binding: Bindings specify a communication protocol between the client and the service.
Contract: Contracts specify what operations are exposed by the service.
Communication
between client and service is conducted through communication channels;
one channel on the client side and its equivalent on the server side. On
the server side, when you instantiate the ServiceHost
class, it instantiates a channel listener, which in turn builds a
communication channel for the service. On the client side, the proxy
creates a channel factory, which is responsible for building the channel
for the client. The channels consist of binding elements, each
responsible for its own part of message processing to form a stack of
binding elements.
As you can notice in the
previous diagram, the bottom layer in the communication channel is a
transport layer, and that's exactly where the ASDK-based adapter fits
within the channel stack.
The great thing about WCF is
that it has been designed with extensibility in mind, which allows you
to use custom transport bindings tailored to your specific needs. Much
like the standard WCF transports, such as TCP, named pipes, HTTP, and
MSMQ, the ASDK-based adapters are just a custom transport binding
elements consumable from BizTalk applications using a standard
WCF-custom adapter. As you can see in the following image, in the
outbound scenario, the ASDK-based adapter instead of sending a message
over the network like standard WCF transports, just communicates with
the LOB system and then sends a response message to the client.
In the inbound scenario,
ASDK-based adapter either monitors or listens for a notification from
the target LOB system for particular events and generates a message
containing event-specific data for the hosting application.
ASDK-based Adapters vs. WCF services
One of the frequently asked
questions in relation to the new adapters is what is the reasoning
behind introducing the ASDK technology? What's wrong with good old
fashioned WCF-services that have been used for years to provide access
to LOB applications and are perfectly consumable from virtually all
applications? Why did Microsoft re-invent the wheel? Well, these are
absolutely valid questions and here is the answer. There is nothing
wrong with the WCF-services; they are as good as they have always been,
but there is one big "but"—only if the LOB application is relatively
static. Imagine the situation where your LOB application is evolving and
you, as a developer, have to expose new metadata to the client
applications? You either have to update existing contracts, or implement
new ones with subsequent configuration steps applied to both the host
and WCF-service. This has been a major pain for the development teams
working on the LOB side.
Metadata is usually
defined as data about data. This is a very broad definition; metadata in
the WCF LOB Adapter SDK can be defined as the data types and the
operations available in the target LOB system. For example, for SAP, it
can be IDOCs and BAPIs or it can be stored procedures and data tables
for the DBMS-based applications. It is up to the adapter designer to
determine and expose the metadata for a particular LOB application.
In contrast, the
ASDK-based adapters provide design time metadata discovery and
resolution automatically, with no efforts from the development team to
make new metadata (or functionality, according to our definition of the
metadata) available for consumption. Take a look at how the Contoso sample adapter located in the C:\Program Files\WCF LOB Adapter SDK\Documents\Samples directory implements the IMetadata*group
of interfaces and the magic behind the automatic metadata discovery and
resolution will become clear. Implementation of the IMetadata*
interfaces does require substantial efforts from the adapter developers,
but the end result is certainly worth it.
Now that you are familiar with the architectural foundations, let's proceed with installation of the adapters.
