Как разместить службу WCF в Azure на внешних и внутренних конечных точках веб-роли? - PullRequest
Новая
       24

Как разместить службу WCF в Azure на внешних и внутренних конечных точках веб-роли?

3 голосов
/ 26 января 2010

В настоящее время я внедряю службу WCF REST для веб-роли в Windows Azure и пытаюсь добавить связь между экземплярами роли, чтобы они могли обновлять друг друга, например, когда некоторые данные обновлено в хранилище BLOB-объектов. Я хотел бы разместить одну и ту же службу WCF как на внешней, так и на внутренней конечных точках HTTP веб-роли. Однако из того, что я прочитал, WCF ограничен только одним базовым адресом на протокол при размещении в IIS. Когда я включаю внутреннюю конечную точку HTTP для своей роли и пытаюсь запустить службу с помощью WebServiceHostFactory, я получаю сообщение об ошибке:

Эта коллекция уже содержит адрес со схемой http. Там может быть не более одного адреса на схему в эта коллекция.

Имя параметра: элемент

Я немного погуглил, и один обходной путь, который я видел в разных местах, предлагает добавить baseAddressPrefixFilter в web.config. Однако, если я не знаю полного URL-адреса для любой конечной точки до запуска приложения, я не уверен, как заставить это работать.

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

Кто-нибудь знает, как обойти эту проблему? Кажется, что было бы довольно распространенным желанием разместить веб-сервис на обеих конечных точках веб-роли. Я относительно новичок в WCF, поэтому может быть что-то очевидное, что мне не хватает. Любая помощь приветствуется.

1 Ответ

0 голосов
/ 01 февраля 2010

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

  • У меня вообще нет раздела system.serviceModel в файле web.config. Это может быть несколько частей, которые вы можете настроить через web.config, но сделать все это в коде было просто для меня.
  • Каждая конечная точка должна работать самостоятельно. Когда обе конечные точки используют один и тот же протокол (в данном случае HTTP) и вы пытаетесь разместить на IIS, простого способа обойти это просто не существует.
  • Каждый сервис должен иметь свой собственный файл .svc. Я слышал, что якобы файл .svc не нужен для размещения в IIS, но если это правда, я не видел другого способа заставить его работать.
  • Каждый сервис также имеет свою собственную фабрику хостов. На фабрике при создании хоста я использовал параметр базового адреса, порт которого соответствовал конечной точке, которую я хотел использовать. Мне сказали, что этот базовый адрес на самом деле не имеет значения, но я не могу за это поручиться. Затем при создании конечной точки просто используйте пустую строку для адреса конечной точки.
  • Поскольку я хотел создать REST-сервис, я обычно использовал WebServiceHost, но это вызывало некоторые различные проблемы, поэтому я просто использовал вместо него ServiceHost и вручную добавил WebHttpBinding и WebHttpBehavior к конечной точке.
  • Наконец, при вызове внутренней службы из внешней я должен был убедиться, что вызов окружен новой областью контекста операции, например: 

using (new OperationContextScope((IContextChannel)myClientFromChannelFactory))
{
    myClientFromChannelFactory.MyServiceMethod();
}

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

Надеюсь, что это поможет любому, кто столкнется с той же проблемой.

...