Мобильная версияСлужба, созданная JAX-WS, VS WCF – несоответствие фильтра контракта ⇐ C#
-
Гость
Служба, созданная JAX-WS, VS WCF – несоответствие фильтра контракта
Итак, в моей компании есть сценарий, когда нам нужно прекратить использование одной из служб, которые в настоящее время использует одна из систем нашего поставщика. Наша компания уже заявила, что не платит поставщику за изменения, которые могли бы облегчить нам жизнь.
В любом случае проблема в том, что исходный сервис, который мы используем, был создан на Java. Wsdl выглядит примерно так (это всего лишь часть файла. Я заменил некоторую конфиденциальную информацию)
Теперь, поскольку мы не можем заставить поставщика обновлять программное обеспечение, команде компании пришла в голову идея заменить этот сервис другим, написанным на .NET (в конечном итоге нам придется развернуть его в облаке), и когда они начали делать какие-то тесты при указании на этот новый сервис, начинают получать ошибку такого типа:
Сообщение с действием не может быть обработано получателем из-за несоответствия ContractFilter...
Проверив WSDL созданного ими нового сервиса, я увидел, что это было так:
Честно говоря, я не эксперт в SOAP, но из того, что я читал (и это выглядит очевидным), что контракты оригинального и нового контрактов не имеют ничего общего. Мы хотели сначала протестировать только один метод (GetStagedOrderId), но получили описанную выше ошибку.
Я пытался воспроизвести эту ошибку, создав несколько служб локально, и получил ее только тогда, когда изменил URL-адрес конечной точки на другую службу, у которой не было метода, который я пытался вызвать, и это примерно то, что мы пытаемся вызвать. связано с системой поставщика.
У нас есть некоторые переменные среды, которые мы можем изменить, и одна из них — это URL-адреса конечных точек.
Настоящий вопрос вот в чем:
Есть ли какой-нибудь способ создать новую услугу с аналогичным контрактом, который позволит нам использовать новую услугу из системы поставщика?
.NET создает WSDL совсем по-другому, меняя имена сообщений (путем добавления интерфейса и пространства имен), и я думаю, что это часть проблемы.
Знаете ли вы о каком-нибудь механизме, который позволит мне создать сервис с тем же контрактом, что и оригинал?
Спасибо.
Итак, в моей компании есть сценарий, когда нам нужно прекратить использование одной из служб, которые в настоящее время использует одна из систем нашего поставщика. Наша компания уже заявила, что не платит поставщику за изменения, которые могли бы облегчить нам жизнь.
В любом случае проблема в том, что исходный сервис, который мы используем, был создан на Java. Wsdl выглядит примерно так (это всего лишь часть файла. Я заменил некоторую конфиденциальную информацию)
Теперь, поскольку мы не можем заставить поставщика обновлять программное обеспечение, команде компании пришла в голову идея заменить этот сервис другим, написанным на .NET (в конечном итоге нам придется развернуть его в облаке), и когда они начали делать какие-то тесты при указании на этот новый сервис, начинают получать ошибку такого типа:
Сообщение с действием не может быть обработано получателем из-за несоответствия ContractFilter...
Проверив WSDL созданного ими нового сервиса, я увидел, что это было так:
Честно говоря, я не эксперт в SOAP, но из того, что я читал (и это выглядит очевидным), что контракты оригинального и нового контрактов не имеют ничего общего. Мы хотели сначала протестировать только один метод (GetStagedOrderId), но получили описанную выше ошибку.
Я пытался воспроизвести эту ошибку, создав несколько служб локально, и получил ее только тогда, когда изменил URL-адрес конечной точки на другую службу, у которой не было метода, который я пытался вызвать, и это примерно то, что мы пытаемся вызвать. связано с системой поставщика.
У нас есть некоторые переменные среды, которые мы можем изменить, и одна из них — это URL-адреса конечных точек.
Настоящий вопрос вот в чем:
Есть ли какой-нибудь способ создать новую услугу с аналогичным контрактом, который позволит нам использовать новую услугу из системы поставщика?
.NET создает WSDL совсем по-другому, меняя имена сообщений (путем добавления интерфейса и пространства имен), и я думаю, что это часть проблемы.
Знаете ли вы о каком-нибудь механизме, который позволит мне создать сервис с тем же контрактом, что и оригинал?
Спасибо.
