Аналогия между WCF endpoints и Receive/Send ports в BizTak'e настолько разительна, что я не удивлюсь, если следующая его версия (после R3) полностью заменит BizTalk EPM на WCF WAS.

Создание WCF Service в этой аналогии сопоставимо с созданием orchestration.
А(ddress). Выбор адреса, через который будет доступен сервис, зависит в обоих случаях только от требований клиентского приложения. Как одна и та же оркестрация может быть доступна через разные порты, так и WCF сервис может быть доступен через несколько независимых endpoints.Создание как портов, так и endpoints совершенно не зависит от самого сервиса.
B(inding). Привязка (binding) сервиса к адресу дается в BizTalk настройкой портов, а в WCF - настраиванием endpoints. Каждый endpoint/port имеет в свою очередь независимо-настраиваемые свойства, кот. в WCF называются behaviors. Аналог в - свойства порта, как, например, tracking, authentication etc.
C(ontract). Сервисы BizTalk ориентированы на сообщения, кот. имеют строгую структуру (XSD schemas). Сервисы WCF вместо XSD требуют строго структурированных контрактов/интерфейсов, т.е. описания данных в более свободной другой форме. Не забудем, однако, что сообщения BizTalk могут быть, вообще говоря, произвольными .Net-классами.

В то время как для порты BizTalk могут исполняться только внутри Windows service, известного как BizTalk host instance, существует несколько моделей хостинга для WCF сервисов. Они могут исполнятся 1) в специально созданном для этой цели приложении (т.наз. self-hosting model), 2) в IIS (конечно, речь идет о IIS 7) и 3) в WAS (Windows Activation Service). На этой картинке можно видеть WCF сервис, настроенный в IIS7 на поддержку и http, и tcp, и named pipes, и msmq.

[699x509]

По аналогии с тем, как поступающие сообщения записываются BizTalk адаптером в очередь сообщений для своего host'a, архитектура WAS использует для этих целей очередь того IIS Application Pool, который настроен исполнять WCF сервис. А именно, один из protocol listeners (для http это http.sys драйвер) по мере поступления сообщений записывает их в очередь Application Pool, далее задачей listener adapter является извлечение сообщений из этой очереди для передачи protocol handlers. Последние исполняются внутри WAS, который отвечает за активацию protocol handlers, их конфигурацию и проч. Можно сказать другими словами, что используя WAS, IIS больше не зависит от http для активации своих внутренних процессов (т.е. в конечном итоге - своих applications, которые и являются WCF сервисами).

Все это очень похоже на взаимодействие BizTalk адаптеров с Messaging Agent, причем для последнего, как и для WAS, обрабатываемый протокол не существенен.

Обычные Web-Services не вписываются в эту систему, но из-за их широкого распространения разработчики привыкли считать , что

1. разделение интерфейса и транспортного протокола является скорее теоретической выдумкой (что, право сказать, не далеко было от истины в года расцвета COM) и
2. легче создать клиентское приложение, поддерживающее SOAP поверх HTTP (особенно с повсеместной поддержкой  Ajax), чем заставить сервис поддержать нужное количество клиентских протоколов.