Сервис против клиентских узлов / разделов в Web.Config

#wcf

#wcf

Вопрос:

В чем разница между сервисным узлом / секцией и клиентским узлом / секцией в разделе конфигурации? Зачем настраивать конечные точки в одном разделе поверх другого? Что лучше всего подходит для взаимодействия?

В настоящее время я создаю службу, которая взаимодействует с другой службой. У меня есть конечные точки для моих клиентов и конечные точки для другой службы. Visual Studio, похоже, объединяет все конечные точки в клиентский раздел.

Я думал, что клиентский узел предназначен для вашего потребления, а сервисный узел — для производства. Но когда вы создаете новую службу wcf, visual Studio помещает ваши новые настройки конечной точки службы под клиентским узлом. Я переместил свою конечную точку между обоими разделами, пытаясь выяснить, в чем разница.

Когда я должен использовать сервис вместо клиента?

 <system.serviceModel>
<services>
  <service> <!--I noticed some tutorials and using wcf config edit tool 
                puts producer endpoint settings here -->
    <endpoint  blah settings/>
    <endpoint  blah settings/>
  </service>
</services>
<client> <!--Visual Studio puts both producer and consumer endpoint 
             settings here -->
  <endpoint  blah settings /> 
  <endpoint  blah settings /> 
  <endpoint  blah settings /> 
</client>
<bindings>.....
</system.serviceModel>
  

Ответ №1:

Многие настройки в WCF web.config (или app.config, если уж на то пошло) могут быть общими как для потребителей сервиса, так и для издателей сервиса, включая:

  • Привязки
  • Поведение конечной точки
  • Диагностика

Однако, как вы обнаружили, некоторые конфигурации специфичны для службы. Хорошо написанный сервис обычно определяет:

  1. Это базовый адрес. Это удобно при определении сервиса, поскольку позволяет определять конечные точки, используя относительные адреса. Клиенты, однако, не используют этот конкретный параметр, поскольку им нужен абсолютный путь. По этой причине нет смысла указывать в разделе
  2. Сервисы также могут быть клиентами. Если бы конечные точки клиента и сервера были объединены вместе, WCF не смог бы узнать, какая из них должна использовать базовый адрес для одной вещи
  3. Поведение сервиса

Разделяя конфигурацию между клиентом и сервером, WCF лучше знает, где искать конечные точки.

Что лучше всего подходит для взаимодействия?

Я не думаю, что это имеет к этому какое-либо отношение. WCF — это средство для достижения совместимости, но простое использование WCF не означает, что вы этого достигнете. Совместимость устанавливается, когда обе стороны соглашаются, скажем, с конкретным контрактом на обслуживание; канонической моделью данных; преобразованием данных; версией сообщения или многими другими шаблонами, определенными SOA Patterns.org Итак, существуют различные шаблоны, которым вы должны следовать. например Если вы изменили метод в сервисном контракте, но не обновили клиентов, то вы нарушили совместимость, нарушив схему сервиса.

Visual Studio, похоже, объединяет все конечные точки в клиентский раздел

Если ваш процесс WCF является одновременно потребителем и производителем сервисов WCF, то он не должен помещать все конечные точки под

Комментарии:

1. Я обновил свой вопрос. потому что размещение настроек конечной точки моего производителя под клиентским узлом, похоже, не имеет никакого значения. Вы размещаете все свои производящие конечные точки под узлом service? Почему, кажется, не имеет значения, под каким узлом вы его размещаете? Кажется, в любом случае все работает нормально. Я собираюсь несколько раз перечитать ваш ответ, чтобы убедиться, что я просто не понимаю, что вы опубликовали.

2. Я не совсем уверен, в чем здесь конкретная проблема, но, как правило, вам не следует редактировать конфигурацию WCF вручную. Во-первых, потому что это XML; и во-вторых, потому что нет проверки ошибок, а WCF очень сложный. Настоятельно рекомендую использовать SvcConfigEditor от Visual Studio. Щелкните правой кнопкой мыши свой web.config / app.config и выберите Изменить конфигурацию WCF . Попробуйте, и это должно сработать. Затем, если вам интересно, взгляните на базовый файл .config. Настоятельно рекомендую эту книгу Программирование служб WCF: освоение WCF и служебной шины Azure AppFabric