WCF - WSDL или предварительно скомпилированный прокси

Question

это сценарий B2B, один клиент (по крайней мере, пока).

Серверная среда: Служба WCF, IIS6, .NET v3.5

Клиентская среда: Магазин разработчика - это .NET 2.0 / VS2005. Буду звонить в мою службу WCF.

Вопрос: должен ли я
(a) открыть WSDL gen для клиента (не желательно по соображениям безопасности)
(б) отправить файл (ы) WSDL клиенту
(c) предварительно скомпилировать Proxy в dll (на моей стороне) и отправить его клиенту
(г) ???

Какие-либо предложения о том, что было бы лучшим вариантом для этого сценария, какие-либо плюсы / минусы?

Заранее спасибо,
Игорь

Answer 1

Почему общедоступный WSDL нежелателен по соображениям безопасности?

Я могу согласиться с тем, что публикация API (в основном то, что вы делаете с WSDL) делает вас бит более уязвимым, чем если бы вы этого не делали, но было бы неправильно предполагать, что сокрытие WSDL представляет собой любой вид безопасности. По иронии судьбы это называется безопасность от неизвестности , и она будет взломана любым решительным атакующим.

Веб-сервис должен быть безопасным сам по себе. WCF предлагает множество функций безопасности, но это перпендикулярно вашему вопросу.

Я бы предпочел опубликовать WSDL. Если вы не хотите этого делать или если существует политика, запрещающая это, отправьте WSDL группе клиентов, чтобы они могли использовать ее по своему усмотрению.

Предварительная компиляция прокси-сервера только приведет в исполнение ваши соглашения о кодировании в клиентской команде, и они могут этого не оценить - например, я часто предпочитаю, чтобы мои прокси-серверы создавались с ключом / i, который делает сгенерированные классы внутренними. Мне также нравится иметь возможность указывать пространства имен .NET, чтобы они соответствовали остальной части моего кода. Это было бы невозможно, если бы я получил предварительно скомпилированную сборку (я мог бы использовать ее в любом случае, но это только раздражало бы меня).

Answer 2

В порядке предпочтения я бы склонялся к:

1. Предоставить службе доступ к WSDL (с включенной защитой)
2. Отправка файла WSDL потребителю сервиса

Я собирался перечислить вариант 3 как отправку прокси-библиотеки DLL, но подумал, что даже не перечислю ее как вариант. Мне кажется, что отправка вашему клиенту прокси-библиотеки DLL открывает большую банку червей, с которыми я бы не хотел иметь дело.

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

• Может быть, они не установили прокси DLL?
• Может быть, есть проблема с разрешением?
• Может быть, они не знают, что делают (да, я знаю, что этого никогда не случится. :)).
• Может быть, обновление .NET на их стороне повлияло на ваш прокси?
• Вы можете даже столкнуться с некоторыми проблемами с версионностью при отправке им новых прокси.

Если ваш клиент не настолько подкован, вместо того, чтобы пытаться помочь ему путем создания прокси-библиотеки DLL, возможно, лучше будет потратить некоторое время и усилия на помощь в получении правильной конфигурации и использования вашего сервиса?

Answer 3

Если вы не хотите на самом деле публиковать WSDL и делать его доступным в сети для вызывающих клиентов, то я бы предпочел подход «отправьте мне WSDL и XSD».

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

Я бы рассмотрел использование предварительно скомпилированного прокси в сборке, только если вызывающая сторона не смогла или не желала создавать прокси самостоятельно, и только если они попросили меня предоставить этот код в форме сборки.

Марк