Соц сети



  • Безымянный 222304

  • My Top 100

  • Аналогия между 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. Аналог в BizTalk - свойства порта, как, например, 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. На этой картинке можно видеть WCF сервис, настроенный в IIS7 на поддержку и http, и tcp, и named pipes, и msmq. 

    IIS7 hosting WCF service 

    По аналогии с тем, как поступающие сообщения записываются 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 сервисами).

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


     








  • Безымянный 222304

  • My Top 100