Версии рабочего процесса WF4, в которых изменяется контракт на обслуживание - PullRequest
2 голосов
/ 25 марта 2011

Я только что успешно внедрил систему управления версиями WF4, используя службу маршрутизации WCF. У меня была служба рабочего процесса версии 1, в которую я добавил новое действие Decision и сохранил его как службу версии 2. Итак, теперь у меня есть 2 конечные точки (с одинаковыми контрактами на обслуживание, т. Е. Все действия получения одинаковы для обеих служб) и маршрутизатор, который проверяет содержимое сообщения (строка «versionId» для объекта, который все мои приемники принимают как аргумент), чтобы решить, какую конечную точку ударить.

У меня такой вопрос, хотя это работает нормально, когда в контракт на обслуживание не вносятся никакие изменения, как мне справиться с необходимостью добавить или удалить методы из моего контракта на обслуживание и создать службу версии 3? Моя первоначальная мысль заключалась в том, что, когда я добавляю ссылку на сервис к моему клиенту, я использую конечную точку последней версии сервиса документооборота, чтобы получить последний контракт на обслуживание. Затем в файле конфигурации я изменяю конечную точку, к которой подключаюсь, к конечной точке маршрутизатора. Но это не будет работать, если v1 и v2 имеют контракт, отличный от v3. Мой прокси будет иметь методы v3 и забудет все о v1 и v2.

Есть идеи, как с этим справиться? Должен ли я создать действующий интерфейс контракта на обслуживание в своем решении рабочего процесса (вместо того, чтобы просто указывать ServiceContractName в моих действиях приема)?

Ответы [ 3 ]

1 голос
/ 03 мая 2011

Пока WCF был молодым, я слышал несколько голосов, утверждающих, что управление версиями конечной точки (для веб-служб) должно осуществляться с использованием структуры папок. Я никогда не пытался сам испытать это, но просто анализ последствий такой стратегии кажется мне великолепным решением. У меня нет опыта работы с WCF, но я собираюсь запустить довольно комплексное решение, используя версию 4.0 .NET (ASP.NET, WCF, WF ...), и на этом этапе я бы сказал, что использование структуры папок для разделения версий конечных точек было бы хорошим решением.

Суть такой стратегии заключается в том, чтобы никогда не изменять или не удалять контракт конечной точки (конкретной версии), пока вы не будете уверены на 100%, что он больше не используется. Пока ваши услуги развиваются, вы просто добавляете новые контракты и конечные точки. Это может привести к дублированию кода, если вы не такой структурированный разработчик, как следовало бы. Но при внедрении сервисного фасада дублирование будет незначительным

1 голос
/ 26 марта 2011

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

0 голосов
/ 01 сентября 2014

Я прошел через ту же ситуацию.Вы можете поддерживать версию с помощью пользовательской реализации.сохранить URL-адрес службы Workflow в базе данных.И вызывайте их по своему желанию.

Вы можете получить информацию о вызове WF-службы по URL-адресу клиента.

http://rajeevkumarsrivastava.blogspot.in/2014/08/consume-workflow-service-45-from-client.html

Надеюсь, это поможет

...