Доступ к веб-сервису SOAP с неверным wsdl - PullRequest
Новая
       29

Доступ к веб-сервису SOAP с неверным wsdl

0 голосов
/ 20 мая 2011

Справочная информация:

Мне нужно использовать существующий веб-сервис (SOAP через http), у которого есть несколько проблем:

1) wsdl на сервере даже не похож на веб-сервис, как описано в их документации, которая включает в себя совершенно другой файл wsdl

2) Файл wsdl, предоставленный вместе с их документацией, похоже, близок к описанию веб-службы на сервере, но когда я сгенерировал код Java-клиента с помощью cxf и использовал его для доступа к веб-службе, cxf выдает исключения, подобные следующим 

 javax.xml.bind.UnmarshalException: unexpected element (uri:"http://us-labs.companyxyz.com/", local:"searchResponse"). Expected elements are <{http://companyxyz.com/xyz-xml/2.0/}searchResponse>
... 33 more

Я не эксперт по SOAP, но при условии, что это означает, что пространства имен в их ответах не совпадают с определенными в wsdl.

Поскольку мое приложение написано на java, я смог подключиться и получить ответ, используя http-клиент commons и ручной SOAP-запрос, поэтому в худшем случае я могу вернуться к этому и проанализировать ответ, чтобы получить то, что мне нужно.

Мои вопросы:

  1. Правильно ли я истолковал исключение?
  2. Если нет: какие-либо предложения о том, как я могу это отладить?
  3. Если да: может ли кто-нибудь предложить лучшие альтернативы ручному созданию http-запросов и синтаксическому анализу xml вручную? (Получение правильного wsdl, к сожалению, не вариант)

Заранее спасибо.

Ответы [ 3 ]

0 голосов
/ 20 мая 2011

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

Это тоже не совсем неожиданно. Это факт жизни, что поставщики поставляют wsdls не всегда правильно. Именно поэтому мы пишем свои собственные WSDL и XSD для приложений поставщиков.

Вы можете использовать свой собственный WSDL даже во время выполнения. На этот счет есть несколько вопросов: здесь и здесь .

Вы также можете посмотреть здесь . Я не пробовал, но это может сработать.

Мы фактически расширяем сгенерированную службу и создаем порт, предоставляющий WSDL, расположенный на пути к классам, используя JaxWS Конструктор службы . Это хорошо работает для нас.

Мы отлаживаем CXF, выгружая входящие и исходящие сообщения. Кажется, есть много способов сделать это. Мы используем либо прокси между веб-сервисом и нашим клиентом, либо недавно где-то файл cxf.xml. Используя флаг -D, мы временно настраиваем это. 

-Dcxf.config.file=/home/me/cxf-debug.xml

и cxf-debug.xml содержит что-то , например : 

<beans xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:cxf="http://cxf.apache.org/core"
      xsi:schemaLocation="
http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

    <cxf:bus>
        <cxf:features>
            <cxf:logging/>
        </cxf:features>
    </cxf:bus> 
</beans>

http://cxf.apache.org/docs/debugging-and-logging.html

0 голосов
/ 23 мая 2011

В обоих ответах предлагался один и тот же базовый подход, который оказался правильным. Я исправил предоставленный wsdl, чтобы он соответствовал веб-сервису, и смог использовать cxf, что избавило меня от большого количества ручного кодирования.

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

{http://us-labs.companyxyz.com/}searchResponse

было определено в WSDL, чтобы содержать 0 или более 

{http://companyxyz.com/xyz-xml/2.0/}searchResponse

Но в их ответе вложенный searchResponse не был квалифицирован {http://companyxyz.com/xyz-xml/2.0/}, поэтому cxf интерпретировал его как {http://us-labs.companyxyz.com/}searchResponse

Я исправил это, введя новый тип.

Спасибо обоим респондентам.

0 голосов
/ 20 мая 2011

  1. Скорее всего. В ответе используется пространство имен "http://us -labs.companyxyz.com /", но в WSDL этот же элемент объявлен с пространством имен "http://companyxyz.com/xyz-xml/2.0/".

  2. Я не знаком с CXF, но другие платформы SOAP обычно предлагают какие-то возможности ведения журналов. Вероятно, это поможет вам, если SOAP-запросы и ответы будут зарегистрированы где-то для более конкретного анализа.

  3. Почему нельзя получить правильный WSDL? Если вы действительно способны «вручную» корректировать запросы SOAP и ожидаете, что сможете «разбирать» ответы вручную, вы также сможете написать WSDL самостоятельно. Конечно, WSDL должен быть предоставлен вам оператором сервиса, но если вы имеете в виду, что никто не может предоставить вам правильный WSDL, я бы подумал написать его сам, а не создавать и анализировать сообщения SOAP вручную.

...