Вызов службы WCF без генерации сборки - PullRequest
8 голосов
/ 25 января 2011

Я пытаюсь написать некоторый код на C #, который будет вызывать службу WCF на лету, импортируя WSDL, проверяя его и затем вызывая его динамически.

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

Одним из возможных решений этой проблемы является импорт и компиляция справочной службы на лету.

Обрисовано здесь: Создание сборки на лету из WSDL

Я бы хотел избежать генерации сборки и затем размышлять над ней, если это возможно.

Я посмотрел код динамического прокси в ссылке, и они используют класс инфраструктуры для импорта.Этот класс WsdlImporter.Так что я отлично подумал - я могу использовать это, изучить схему WSDL и определить, какие вызовы присутствуют и какие входы и выходы доступны.

Проблема в том, что информация о типе отсутствует в объектах MessagePartDescription, которые создает WsdlImporter.Очевидно, это отсутствует , потому что он еще не может найти типы - см. Ответ на вопрос Брайана.

Итак, есть ли какой-нибудь совет, как мне поступить?Я совершенно не на том пути?

Ответы [ 2 ]

5 голосов
/ 26 января 2011

Вероятно, это не ответ, но я опубликую его, чтобы полностью описать свое мнение.

Динамический прокси: ИМО это пример неправильного использования технологий.Это элементарное поведение WSDL - если он меняется, вам нужно сменить клиента, или вам нужно сделать правильное управление версиями WSDL и создать нового клиента.

Вы все еще должны как-то сказать своему клиенту, чтобы получить WSDL - означает ли это, что вы будете анализировать WSDL перед каждым вызовом?Не кажется хорошей идеей.

Информация о типах действительно не является частью WSDL, потому что по умолчанию WSDL генерируется как совместимый.Типы CLR не являются операциями, необходимыми для взаимодействия.Когда вы создаете прокси сервиса с помощью Add service reference или Svcutil, он генерирует код для типов, определенных в WSDL.Затем этот код необходимо скомпилировать.

Вы можете попробовать использовать NetDataContractSerializer вместо значения по умолчанию DataContractSerializer.NetDataContractSerializer добавляет информацию о типе CLR в WSDL, но я все еще ожидаю, что новые типы должны быть известны вашим клиентам - это означает развертывание новой сборки с типами и использование ее клиентами.Это почти похоже на тот же подход при простом развертывании сборки с новым статическим клиентским прокси.

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

Смена WF Мы говорим о фундаменте Windows Workflow?Я с трудом представляю себе сценарий, в котором вы создаете WF, выставляете его как сервис и затем меняете его.Когда вы выставляете WF как службу, вы, вероятно, определяете долго работающую WF.Долгосрочные WF используют постоянство, основанное на сериализации (по крайней мере, в WF 3.5, но я думаю, что это то же самое в WF 4).Когда вы меняете определение WF, все сохраненные WF, скорее всего, обречены, потому что они никогда не будут десериализованы.Эта ситуация обычно решается параллельным развертыванием новой и старой версии, где старая версия используется только для завершения незавершенных WF.Опять это означает новых клиентов.

1 голос
/ 31 января 2011

Если вы посмотрите на проблему под другим углом.Вам нужно каждый раз перегенерировать прокси-сервер или вам нужен контракт, который продолжает работать при изменении ситуации?

В WCF есть механизм для этого IExtensibleDataContracts, см .: http://msdn.microsoft.com/en-us/library/ms731083%28v=VS.100%29.aspx

Рекомендацииверсии договоров можно найти здесь

...