В чем преимущество использования ChannelFactory для вызова службы wcf

Question

, если я знаю URL-адрес службы, тогда я могу нажать на ссылку добавления и добавить URL-адрес службы для создания прокси-сервера на стороне клиента, чтобы его использовать, но без создания прокси-сервера на стороне клиента мы можем потреблять и звонить с помощью ChannelFactory.

, так что мне нравится знать, когда люди будут использовать ChannelFactory для создания прокси во время выполнения и в чем преимущество?

Если я хочу, чтобы другие люди знали мой служебный url, то они также не смогут добавить мою службу в качестве ссылки на сервисную службу .... как включить эту функцию? Я хочу, чтобы другие люди не смогли создать прокси в конце, если они знают мой URL-адрес службы ... это возможно. Я хочу, чтобы людям всегда приходилось звонить через службу ChannelFactory. пожалуйста, обсудите этот вопрос в деталях. спасибо

Answer 1

Если у вас есть клиенты, которые не являются .NET (например, Java или PHP), ChannelFactory не будет работать для них, как это характерно для .NET и WCF. В этом случае вам нужно будет либо опубликовать метаданные, либо отправить клиенту WSDL, чтобы они могли создавать прокси-сервер, используя любой способ выбора языка (я мало знаю о Java, PHP и т. Д. t сказать гораздо больше, чем это окончательно).

Что касается использования ChannelFactory, я предполагаю, что вы говорите о ChannelFactory<T>, так как ChannelFactory сам является абстрактным классом и не может быть создан. Использование фабрики каналов дает большую степень контроля (как указывали другие) - для ChannelFactory<T> клиенту потребуется контракт на обслуживание (интерфейс, а не реализация), поэтому либо с использованием общей сборки, доступной каждому, либо для предоставления интерфейса клиентам это два простых способа достичь этого.

Вы можете отключить публикацию метаданных (WSDL,), повернув httpGetEnabled к «ложным» в файле конфигурации в <serviceMetadata> тег:

<system.serviceModel> 
    <behaviors> 
    <serviceBehavior> 
     <behavior name="MyServiceBehavior"> 
     <serviceMetadata httpGetEnabled="false" /> 
     </behavior> 
    </serviceBehavior> 
    </behaviors> 
</system.serviceModel> 

Вы бы затем ссылаться на это поведение, установив атрибут в конечной точке элемента behaviorConfiguration к "MyServiceBehavior".

Вы также должны удалить конечные точки mex, поскольку (на основе моего понимания) это новый способ для веб-сервисов разоблачить их метаданные. Если метаданные не отображаются, клиенты не могут создать прокси-сервер через WSDL и должны будут сделать это другим методом. Клиенты .NET специально не смогут использовать ссылку «Добавить службу».

Наконец, если вас беспокоит доступ к вашей службе, вы должны действительно реализовать какую-то схему аутентификации. Если вы просто хотите отключить публикацию метаданных (выставляете), то установите httpGetEnabled на false и удалите любые конечные точки mex, чтобы сделать трюк.

Answer 2

Я использовал ChannelFactory вместо автогенерированных прокси, чтобы использовать одну и ту же объектную модель на стороне сервера и на клиенте. Также здесь Sharing Interfaces Between a WCF Service and Client (marked w/ ServiceContract) обсуждаются некоторые проблемы с автогенерированными прокси.

Что касается метаданных тайника, ответ, вероятно, здесь How to hide wsdl information on WCF?

Answer 3

Я обычно создаю два узла, один с метаданными службы (интерфейсы [сервисные контракты] и объектов данных [datacontracts]) и один с фактической службы реализация.

Обычно я сам обслуживаю wcf-сервисы и пропускает конечную точку данных DataExchange, необходимую для клиентов, которые не имеют метаданных (для создания прокси-сервера). Клиенты получают DLL метаданных и записывают свои собственные прокси или используют специальную библиотеку вместе с метаданной dll для создания прокси. Оба подхода используют канал для создания прокси. Если служба используется в локальной сети, я обычно настраиваю службу обнаружения, чтобы клиенты могли найти URL-адреса службы для определенного служебного интерфейса (код пользовательской библиотеки).

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

Возможно, вы должны использовать IIS и служебные страницы (SVC) и создание автоматического прокси в Visual Studio, если вы хотите быстро протестировать сервис или не нравится с моделью программирования WCF. Используйте Channelfactory, если вы пишете свои собственные библиотеки услуг и нуждаетесь в более мелкомасштабном управлении связью (общая стратегия обнаружения сервисов, общие конфигурации/общие настройки привязки, общие настройки безопасности, подключение к событиям в стеке связи для запуска пользовательского кода и т. Д.).