Хостинг IIS WCF и служба Windows

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

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

Мы также читаем в StackOverflow, что базовый адрес игнорируется, когда служба WCF является узлом в IIS (см. вопрос о файле конфигурации службы WCF относительно <baseAddresses> )

ОТВЕТЫ

Ответ 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, установленной в настройке, вы поместите

http, net.tcp в Разрешенных протоколах

После этого вы перейдете в IIS. Поместите свою привязку для http normaly и добавьте новую привязку net.tcp, в конфигурации привязки поместите порт и виртуальный каталог, например

8001: *

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

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

Ответ 2

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

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

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

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

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

Марк

Ответ 3

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

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

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

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

Ответ 4

Интересный 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

Ответ 5

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

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

  • Оперативная система
  • ожидаемая производительность
  • доступно HW
  • ожидаемая доступность

и вы увидите, что во многих ситуациях наилучшим вариантом является "самостоятельный хостинг".

Ответ 6

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

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

Ответ 7

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

Как настроить службу WCF из кода при размещении в IIS?

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

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

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