Служба IIS WCF и служба Windows

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

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

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

13.10.2009 14:33:47
Это всегда зависит от контекста. По словам Microsoft, «вам не следует рассматривать возможность хостинга для корпоративных сценариев. Самостоятельный хостинг подходит на этапах разработки или демонстрации вашего корпоративного проекта» msdn.microsoft.com/en-us/library/bb332338.aspx
Jayee 22.06.2016 04:35:28
7 ОТВЕТОВ
РЕШЕНИЕ

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

Мы провели несколько тестов и обнаружили, что при добавлении привязок в 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 во включенных протоколах

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

8001: *

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

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

11
30.05.2012 14:09:39
должна ли существовать http-привязка вместе с net.tcp. если у меня есть только net.tcp в привязке, сервис будет активирован
user55474 2.02.2011 13:00:24

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

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

5
13.10.2009 14:45:47
Вы правы, но прежде чем задавать себе эти вопросы, я хочу знать, может ли IIS управлять первоначальной конфигурацией моей службы (привязок).
esylvestre 13.10.2009 14:48:56

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

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

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

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

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

Марк

76
13.10.2009 14:59:21
Это именно то, что я искал, но я хотел бы знать, есть ли инструменты для управления службами WCF, когда они размещаются самостоятельно? На самом деле, основной целью его размещения в IIS было предоставление удобного инструмента для настройки наших сервисов.
esylvestre 13.10.2009 15:14:10
«Дублин», вероятно, тот инструмент, который я ожидаю. Большое спасибо.
esylvestre 13.10.2009 17:09:46
История управления WCF сейчас не блестящая - Microsoft обещает гораздо больше поддержки инструментов с «Dublin» (надстройка для сервера, которая выйдет через некоторое время после .NET 4.0)
marc_s 14.10.2009 09:34:19

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

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

Для IIS7.5 (WS2008 R2) всегда включена опция.

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

26
14.10.2009 09:17:11
Я полностью согласен, плюс вы можете создать собственный ServiceHostFactory, чтобы получить больший контроль над ServiceHost.
Piotr Owsiak 21.06.2010 13:28:45
Также «проще» управлять SSL-сертификатами и привязками портов htttp через IIS.
Dasith Wijes 26.09.2016 13:51:18
В качестве недавнего примера, приведенного в качестве примера, размещение той же службы регистрации сообщений net.tcp в IIS потребляет в 3 раза больше памяти и обрабатывает вдвое меньше запросов, чем при «самостоятельном» размещении той же службы в службе Windows.
StingyJack 13.10.2017 12:07:20
вау @ StingyJack это хорошая информация. Какая версия Windows Server?
Cheeso 13.10.2017 22:52:37
В основном Windows 7 Pro, но также некоторые серверы Windows 10 и 2012 (обычная цель - скорее «устройство», чем сервер общего назначения). Это все еще может быть параметр конфигурации, который отключает IIS, который я не нашел. Мне трудно поверить, что он не успевает за собственным хостом до количества запросов.
StingyJack 14.10.2017 14:34:55

Интересный тидбит-> после прочтения этой ветки я наткнулся в 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

16
10.05.2011 20:55:03

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

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

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

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

7
4.12.2012 11:00:38
Процитируем недостатки самостоятельного хостинга: ограниченные возможности: автономные приложения имеют ограниченную поддержку сценариев высокой доступности, простоты управления, надежности, восстановления, управления версиями и развертывания. По крайней мере, готовый WCF не предоставляет их, поэтому в сценарии с самостоятельным размещением вы должны реализовать эти функции самостоятельно; IIS, например, поставляется с некоторыми из этих функций по умолчанию. Microsoft говорит, что сам хостинг не является корпоративным решением для служб именно по этим причинам. См. Сравнение здесь. Msdn.microsoft.com/en-us/library/ms730158.aspx
Dasith Wijes 26.09.2016 14:00:33

Хотя здесь есть выбранный ответ, я позволю себе опубликовать ссылку на тему вопросов и ответов.

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

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

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

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

0
23.05.2017 12:02:12