The relationship between BizTalk and WCF

So, are WCF and BizTalk Server competing technologies or complementary ones? Let's review the role of each:

Given this information, we see that the intersection of these two technologies occurs at the point where the BizTalk messaging and orchestration engine needs to communicate effectively with the outside world. WCF extends BizTalk Server's base capability to provide and consume rich service interfaces through powerful security and customization options. BizTalk Server provides WCF solutions with an enterprise-class messaging engine, which brings along service orchestration and access to numerous adapters that WCF does not have out-of-the-box bindings for.

BizTalk WCF adapters

BizTalk Server 2006 R2 introduced us to the BizTalk WCF adapters. In reality, BizTalk Server 2006 R2 has seven WCF adapters that directly correlate to a subset of bindings available in WCF. These adapters are:

• WCF-BasicHttp: Just like the built-in WCF binding, this adapter is your safest best for simple service clients that conform to SOAP Basic Profile 1.1
• WCF-WSHttp: When you need an HTTP endpoint juiced up with the robustness of WS* standards for greater security, transactions, and encoding, this is the ideal adapter
• WCF-NetTcp: If WCF technologies are on both ends of the channel, this adapter provides the most efficient means for transporting information while still providing all the hearty WS* capabilities
• WCF-NetMsmq: In scenarios where disconnected operations are vital, this adapter provides integration with queuing through MSMQ
• WCF-NetNamedPipe: When you have the source or target WCF application on the same physical server as BizTalk itself, the most adept adapter is this one
• WCF-Custom: When you need rich customization of the WCF endpoint, you use this adapter to manipulate the binding details and add behaviors
• WCF-CustomIsolated: For WCF endpoints hosted by the local web server and requiring binding or behavior customizations choose this adapter

BizTalk Server 2010 added some additional WCF adapters (deprecating some existing non-WCF adapters) via the BizTalk Server Adapter Pack 2010 which includes the following adapters:

WCF-OracleDb: This provides connectivity to the Oracle Database

• WCF-SQL: This provides connectivity to Microsoft SQL Server database, deprecating the SQL adapter
• WCF-SAP: This provides connectivity to SAP
• WCF-OracleEBS: This provides connectivity to Oracle E-business Suite
• WCF-Siebel: This provides connectivity to the Siebel eBusiness Suite

BizTalk Server 2013 added the following adapters:

• WCF-BasicHttpRelay: Microsoft BizTalk Server uses the WCF-BasicHttpRelay adapter when receiving and sending WCF service requests through the BasicHttpRelayBinding, which allows you to leverage Azure Service Bus Relays to expose your on-premise services to the outside world without any reverse proxy or other infrastructure changes.
• WCF-NetTcpRelay: Microsoft BizTalk Server uses the WCF-NetTcpRelay adapter when receiving and sending WCF service requests through the NetTcpRelayBinding which allows you to leverage Azure Service Bus Relays to expose your on-premise services to the outside world without any reverse proxy or other infrastructure changes.
• WCF-WebHttp: This adapter allows you to expose or target RESTful services.

  Note

  Note that there are additional WCF bindings available in .NET Framework 4.5 but they do not have specific BizTalk adapters. These include WS2007HttpBinding, WsFederationHttpBinding, NetPeerTcpBinding, and NetMessagingBinding. But these can be used with the WCF-Custom adapter.

You can see all the bindings available by creating a new send or receive location, selecting WCF-Custom, clicking on Configure, selecting the Binding tab, and dropping down Binding Type, as shown in the following screenshot:

So how do these adapters actually fit into the BizTalk architecture? As they are adapters, they reside at the edges of BizTalk Server. A message sent to a WCF-BasicHttp receive location might follow this path:

The inbound message arrives from the client to Internet Information Services (IIS), which determines the service endpoint to instantiate. The WCF service host is activated, and BizTalk Endpoint Manager is called in order to retrieve the settings of the receive location that matches the service endpoint. The message is processed through any relevant WCF channels and extensions before the message is passed off to the BizTalk Messaging Engine (residing in an isolated host). The Messaging Engine cycles through any receive pipeline components and maps before sending the message to the MessageBox via the BizTalk Message Agent.

In Chapter 2, Windows Communication Foundation Primer, we saw how WCF services require a service host in order to operate. In the BizTalk Server world, a host is a processing container that encompasses a wide range of runtime activities. BizTalk has the concept of an in-process host and an isolated host. An in-process host simply refers to a Windows Service that is owned and operated by BizTalk Server. In-process hosts manage most BizTalk adapters, run the Orchestration Engine, and contain the Messaging Engine. A BizTalk isolated host is used when BizTalk Server does not own the life cycle of the container process. For all practical purposes, this refers to processes hosted within Microsoft IIS. The BizTalk web-based receive adapters (such as SOAP and HTTP) have to run in the same domain as IIS; therefore, they run in the special BizTalk isolated host.

All this all matters because the BizTalk WCF adapters have some flexibility when it comes to BizTalk hosting. All of the WCF bindings (including the HTTP-based ones) can be technically hosted by an in-process BizTalk host by using a WCF-Custom adapter. The following adapters will only run in isolated hosts for a Receive Port:

• WCF-BasicHttp
• WCF-CustomIsolated
• WCF-WebHttp
• WCF-WSHttp

If you wish to maintain an HTTP-based receive endpoint within an in-process host, you may use the WCF-Custom adapter and choose one of the HTTP-based bindings. For all these in-process adapters, the BizTalk Server receive location actually acts as the WCF service host. When you start the receive location, you are opening the WCF host. Likewise, when you disable the receive location, the WCF host is closed.

For adapters hosted in isolated hosts, while the BizTalk receive location still plays a role in the availability of the service, the adapter lifetime is actually managed by IIS. Starting and stopping the receive location linked to an isolated host impacts the ability to call the related service but does not physically impact the service host.

Is there any reason that you would host HTTP endpoints within a BizTalk in-process host instead of inside IIS? On the plus side, you get greater control over the service life cycle and can define any URL you like. On the downside, you make it more difficult to participate in web server load balancing and give up the rich set of service management features that IIS offers.

Let's now take a look at how we actually use these WCF adapters to generate both services and metadata as well as hosts for WCF endpoints.