Блог

У нас есть система EPOS, встроенная в VB6. Клиент использует Microsoft Dynamics AX в качестве CRM-системы. Третья сторона создала реализацию AX для нашего клиента, и они предоставили набор веб-сервисов WCF, которые нам нужно использовать для синхронизации данных между EPOS и AX CRM. Зная, что у VB6 будут проблемы с вызовом служб WCF, я создал следующие компоненты для обработки связи между EPOS и AX CRM.

VB6 EPOS, который вызывает —>
1) Оболочка DLL VB6, которая вызывает… —>
2) .NET (3.5) Вызываемая DLL-оболочка прокси-сервера COM, которая вызывает… —>
3) Обработчик веб-службы .NET (3.5) (где фактически вызываются веб-службы) ->
Microsoft Dynamics AX CRM.

Я создал тестовое консольное приложение в Vb.NET имитировать вызовы из VB6 для помощи в отладке, чтобы приложение test console вызывало компонент 2.

При этом я получал следующее исключение:-

«(не удалось найти элемент конечной точки по умолчанию, который ссылается на контракт ‘X’ в разделе конфигурации клиента servicemodel. это может быть связано с тем, что для вашего приложения не был найден файл конфигурации или потому, что в элементе client не удалось найти элемент конечной точки, соответствующий этому контракту.)»

Я поискал в Google и обнаружил, что мне пришлось скопировать раздел привязок и конечных точек из app.config компонента 3 в новый app.config для моего тестового консольного приложения. Я не знаю WCF и на данный момент у меня нет времени, чтобы действительно изучить его до такой степени, чтобы я понял, почему это исправило эту ошибку.

Теперь, однако, я пытаюсь вызвать службы из VB6 EPOS, и эта ошибка появляется снова. Поэтому я добавил app.config в компонент 2, думая, что, поскольку компонент 2 является первым компонентом .NET (3.5) в цепочке, именно туда должно идти объявление конечной точки, но нет. Ошибка все еще появляется.

У кого-нибудь есть какие-либо идеи? Какие-нибудь герои программирования, которые могут пролить некоторый свет на это для простака, пожалуйста??? Пожалуйста, не спрашивайте, почему мы не переписываем EPOS. Мы будем. пока нет. Там более 3 миллионов строк спагетти-кода, и я работаю над этим всего 8 месяцев!!!

Кроме того, не нарушает ли этот сценарий одно из золотых правил ООП, то есть инкапсуляцию. Почему мой VB6 EPOS должен знать, какие конечные точки использует компонент 3 для доступа к службе WCF???

Отличный вопрос здесь…

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

При работе с .ЧИСТАЯ Windows или веб-приложения данные конфигурации как на стороне клиента, так и на стороне сервера служб WCF находятся в файле конфигурации приложения. Для приложения Windows этот файл будет app.config, тогда как для веб-приложения это будет web.config .

В вашем случае вы хотели бы поместить логику прокси в некоторую форму COM-visible .dll.

Это вызовет у вас некоторые grief…in платформа .NET, файл .config для хост-приложения верхнего уровня (web или Windows) — это место, где считываются все данные конфигурации. Даже если ваше приложение использует десятки сборок .NET (каждая с пользовательскими потребностями в настройке), среда выполнения будет ожидать, что все эти элементы конфигурации будут находиться в самом верхнем файле конфигурации приложения.

Чтобы решить вашу проблему, вам нужно будет связаться со службой, к которой у VB6 есть доступ (например, веб-службы ASMX), и чтобы эта служба перенаправила ваш вызов на соответствующую службу WCF.

Другой альтернативой является передача переменных конфигурации непосредственно из вашего приложения VB6 в вашу сборку Com-visible, чтобы вы могли использовать модель расширяемости WCF для создания прокси (переопределяя поведение по умолчанию для чтения данных конфигурации из файла) с вашей переданной конфигурацией.

Я бы сказал, что последний сценарий может идти обоими путями, поскольку является нарушением SOA / ООП .. в зависимости от ситуации приложению VB6 может быть / может не подходить знать / хранить сведения о конфигурации для связи с (возможным) Конечная точка WCF