WCF хостинг для среднего уровня

Question

Мы разрабатываем новый средний уровень для нашего пакета приложений. Мы хотим переписать нашу бизнес-логику и слои доступа к данным в C#, так как они в настоящее время находятся в VB6 и публикуются через COM+.

Мы пытаемся решить, как именно сделать этот средний уровень доступным для разных клиентов. Мы будем использовать WCF для этого, и мы решили, что будем использовать различные привязки, чтобы удовлетворить потребности каждого клиента, включая netTcpBinding для нашего настольного приложения, net.Tcp и / или именованный канал. привязка для интернет-приложения, работающего локально или на компьютере в сети, и некоторая разновидность HTTP-привязки для внешнего веб-API.

Мы пытаемся решить, как разместить наш сервис. Кажется, что в большинстве мест, где я говорю, что IIS - это путь, но кажется, что вы получите лучшую производительность из части BLL/DAL, если бы она была под Windows Service, и @marc_s здесь, на SO, кажется рекомендовать самостоятельное размещение чаще, чем нет. Итак, размещаем ли мы его в IIS, в сервисе или в каком-нибудь гибридном, где, возможно, тонкий сервис размещен в IIS для конечной точки HTTP и использует основной сервис через net.tcp или привязку именованного канала? Разделение позволяет учесть физическое разделение, если это необходимо, а также допускает возможность отключения IIS, что по-прежнему оставит службу работающей для тех клиентов, которые получают доступ к конечным точкам, которые она публикует.

Кроме того, как насчет масштабируемости и надежности? Есть ли большая разница между двумя средами хостинга?

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

Answer 1

Чтение этого ответа может показаться, что сам хостинг - это предпочтение marc_s, основанное на принятии накладных расходов при самостоятельном кодировании хоста:

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

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

Попробуйте IIS, и если он действительно плохой, создайте свой собственный хост. Это не совсем дорого, чтобы запустить его в IIS - и есть несколько советов по настройке в Интернете.

Обновление: опубликовал это сразу после комментариев marc_s. Я согласен в принципе, но сам хостинг может оказаться бесполезным. IIS в какой-то степени из коробки и имеет свои ограничения - ограничения, с которыми вы можете никогда не столкнуться.

Я не уверен в актуальности этого отзыва, но мы используем IIS для размещения объектов.NET Remoting для нашего приложения. В настоящее время он проходит довольно значительный процесс сбора метрик производительности, готовясь к увеличению почти в 10 раз из-за нового клиента. Для нас IIS не был признан чем-то, о чем стоит беспокоиться. Единственным камнем преткновения для людей является то, что он работает через HTTP (более старая версия IIS для нас), поэтому он немного более насыщен сообщениями, чем, возможно, TCP.

Обновление: эта статья MSDN посвящена самодостаточному хостингу и обсуждает некоторые моменты, которые следует учитывать:

http://msdn.microsoft.com/en-us/library/bb332338.aspx