Хостинг IIS WCF хостинга vs Windows Service

Question

Мы разработали сервис WCF, и мы планируем его развернуть. Наши клиенты будут использовать его с basicHttpBinding, но наша внутренняя команда будет использовать его с namedPipesBinding.

Нам интересно, стоит ли размещать его в IIS 7 или с помощью службы Windows. Мы проверили несколько тестов, и выяснили, что когда мы добавляем привязки в IIS, он не обновляет файл конфигурации нашего сервиса. Это означает, что нам нужно будет поддерживать конфигурацию в двух разных местах. Это не логично, не так ли?

Мы также читаем на StackOverflow, что базовый адрес игнорируются, когда служба WCF является хозяином в IIS (см WCF service configuration file question regarding <baseAddresses>)

Answer 1

Чтобы ответить на те вопросы:

Мы провели несколько тестов, и мы обнаружили, что когда мы добавляем привязок в IIS, не обновлять конфигурационный файл нашего сервиса. Это означает, что мы должны поддерживать конфигурацию в двух разных местах. Это не логика, не так ли?

При использовании IIS для размещения службы, необходимо настроить файл App.config или файл web.config, чтобы позволить IIS раскрыть некоторые привязки, так и в файле конфигурации, вы поставите все ваши привязки вы позволяете к вашему сервису wcf. Http, net.tcp и т. Д.

В вашей привязке вы не укажете адрес, потому что вы укажете этот адрес в IIS напрямую.

В IIS вы должны разрешить привязку, доступную в расширенных настройках вашего веб-сайта. После этого вы установите новую привязку для своего веб-сайта «веб-сервис» и добавьте все привязки, которые хотите прослушать, и укажите адрес.

Вы укажете адрес непосредственно в IIS.

Приведен пример.

Файл конфигурации:

<services> 
    <service name="ServiceName">      
     <endpoint address="" 
      binding="basicHttpBinding" 
      bindingConfiguration="httpMode" 
      contract="IContract" />     
     <endpoint address="" 
      binding="netTcpBinding" 
      contract="IContract" /> 
     <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> 
    </service> 
</services> 

В вашем IIS Advenced настройки вашего поместит

HTTP, Net.Tcp в Enabled протоколов

После этого вы отправитесь в вашем привязка к IIS. Поместите ваши привязки для HTTP и нормально добавить новую связывающую Net.Tcp, в связывающем конфигурации поместить порт и виртуальный каталог как

8001: *

Этот параметр позволяет все соединение в 8001 порт для любого виртуального каталога.

Вы также должны иметь функцию «Активация WCF (активация Http и активация без Http)», установленная на вашем сервере.

Answer 2

IIS предоставляет много вышедших из коробки функций, такой как домен приложения перезагрузки, мониторинга и т. д.

Вот почему вы должны сначала ответить на эти вопросы: вам нужны все эти функции или нет? Если нет - можно воспользоваться услугами Windows.

Answer 3

Хостинг в IIS имеет много плюсов и многих минусов.

Да, IIS дает вам по требованию загрузку - это может быть плюс или минус. Когда приходит запрос, создается ServiceHost, затем запускается класс обслуживания, который обрабатывается, и обрабатывается запрос. Ничто не должно работать круглосуточно. Но в то же время для этой установки требуется больше времени и усилий каждый раз, когда приходит сообщение, и вы, как программист, не имеете большого контроля над своим хостом.

И да, с IIS, виртуальный каталог, в котором находится файл * .svc, определяет ваш адрес - любые базовые адреса или явно определенные адреса в вашей конфигурации не учитываются. И без особых усилий вы не можете изменить расположение служебных адресов - они всегда будут http://servername/virtualdirectory/YourService.svc (включая расширение .svc).

Самостоятельный хостинг часто бывает быстрее, так как ваш ServiceHost уже запущен и работает, но вам решать, действительно ли он запущен и работает, при поступлении сообщения нет загрузки по запросу, либо он работает, либо может обслуживать запрос, или нет. Но у вас намного больше контроля над хостом службы - когда и как он построен и т. Д., И вы можете выбрать и определить свои служебные адреса по своему усмотрению.

Я лично почти всегда предпочитаю использовать самостоятельный хостинг - в консольном приложении для тестирования, в службе NT для производства. Для меня это, скорее всего, более подходящий способ сделать это, и более контролируемый путь. Вы должны делать больше работы, но вы точно знаете, что делаете.

Марк

Answer 4

marc_s обычно дает большие ответы, которые я согласен с полностью, но в данном случае я не знаю.
Самостоятельный хостинг WCF - не очень хорошая идея, особенно с выпуском Microsoft технологий Dublin. Управление и работа приложений WCF (и WF) намного проще при размещении внутри IIS.

Кроме того, вы получаете по запросу по требованию.

Всегда существует опция для IIS7.5 (WS2008 R2).

И вы можете легко переписать URL-адрес, чтобы опустить .svc, если это вас беспокоит.

Answer 5

Интересный tidbit-> после прочтения этой нити я наткнулся на эти слова в MSDN о размещении службы WCF с помощью службы Windows:

Ниже приведены некоторые из недостатков служб Windows:

• Развертывание. Службы должны быть установлены с помощью утилиты .NET Framework Installutil.exe или с помощью специального действия в пакете установщика.
• Ограниченные возможности: службы Windows по-прежнему имеют ограниченный набор готовых функций для поддержки высокой доступности, простоты управления, управления версиями и сценариев развертывания. По сути, вы должны сами соблюдать эти требования с помощью настраиваемого кода, в то время как, например, IIS поставляется с несколькими из этих функций по умолчанию. Службы Windows действительно добавляют возможность восстановления и некоторые функции безопасности, но вам все равно придется выполнять некоторые работы самостоятельно.
http://msdn.microsoft.com/en-us/library/bb332338.aspx

... и по следующей ссылке:

хостинг: (хороший сравнение график)
http://msdn.microsoft.com/en-us/library/ms730158.aspx

Answer 6

Там нет стандартного ответа на этот вопрос. Я полностью не согласен с ответом от Cheeso (Self-hosting WCF - не очень хорошая идея).

Пожалуйста, проверьте следующие ссылки: (http://msdn.microsoft.com/en-us/library/ms730158.aspx, http://msdn.microsoft.com/en-us/library/bb332338.aspx) и думать о своих ограничениях:

• оперативной система
• ожидается выступление
• недоступны HW
• ожидается наличие

и вы увидите, что во многих ситуациях «самостоятельный хостинг» - это t альтернатива.

Answer 7

Несмотря на то, что здесь выбран ответ, я позволю себе опубликовать ссылку на тему Q/A.

How to configure WCF service from code when hosted in IIS?

Что вы найдете в моем ответе там (и ссылка на него) ваш точный контроль над хозяином службы ли вы загрузить его в WService или в IIS.

После запуска службы вы можете взаимодействовать с IIS, какие привязки у него есть, и создать соответствующие конечные точки. Ищите конфигурацию IIs через пространство имен Microsoft.Web.Administration.

Надеюсь, это поможет.