У нас есть приложение, которое должно потреблять внешний веб-сервис. Для этого мы сгенерировали набор артефактов Java из WSDL через Maven, используя цель wsdl2java, предоставленную плагином cxf-codegen-plugin.JAXWS - проблемы с формированием правильной структуры SOAP-сообщения
Мы написали интеграционный тест как часть нашего набора тестов, который вызывает реальный веб-сервис, и все работает нормально.
Код для интеграции с фактической веб-службой затем упаковывается в набор JAR и используется внутри внешнего приложения, которое должно использовать веб-службу.
У нас возникла проблема, когда приложение FE использует код интеграции. Точно такой же код выполняется приложением FE, который используется в нашем рабочем тесте интеграции, но сообщение SOAP, которое в конечном счете генерируется, отличается от двух, и сообщение, генерируемое фактическим приложением, неверно.
запрос работает SOAP производства наших тестов интеграции является:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns12:ProcessUIRequest xmlns:ns10="http://zzz/yyyentityview/validation/"
xmlns:ns11="http://zzz/yyyview/search/list/"
xmlns:ns12="http://zzz/yyywebservice/v5/types/"
xmlns:ns2="http://zzz/yyyentityview/app/"
xmlns:ns3="http://zzz/yyyentityview/client/"
xmlns:ns4="http://zzz/yyyview/search/postcode/"
xmlns:ns5="http://zzz/yyyview/app/"
xmlns:ns6="http://zzz/yyyview/search/app/"
xmlns:ns7="http://zzz/yyyview/search/bank/"
xmlns:ns8="http://zzz/yyyview/uw/"
xmlns:ns9="http://zzz/yyybase/">
<ns12:ProcessUIRequest CallType="Submit" DisplayError="false"
IsAnonymous="false" IsCompactRequest="false" IsError="false">
<ns9:ModelData>
<ns9:TransactionData ApplicationReference="20000003CR3.00000003"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns5:QuoteLoadTxnDataVO" />
</ns9:ModelData>
<ns9:Activity ActionCode="QuoteLoad" ActionMode="Default"
ActivityCode="QuoteApplicationFull" ActivityMode="Default"
ActivityReference="" ActivityStatus="Inital"
ActivityTransaction="StartNewActivityAndLogOffUser"
CanProceedWithValidationsOutstanding="true">
<ns9:BusinessKeys>
<item>
<key>
<string>ADVREF</string>
</key>
<value>
<BusinessKeyVO KeyName="ADVREF" KeyValue="AVAGT01">
<BusinessKey KeyName="ADVREF" KeyType="Unknown"
KeyValue="AVAGT01" />
</BusinessKeyVO>
</value>
</item>
</ns9:BusinessKeys>
</ns9:Activity>
</ns12:ProcessUIRequest>
</ns12:ProcessUIRequest>
</S:Body>
</S:Envelope>
POJO, который выстроил в этот запрос SOAP является:
<tcp.ssgbase.BaseVO>
<modelData>
<transactionData class="tcp.ssgview.app.QuoteLoadTxnDataVO">
<applicationReference>20000003CR3.00000003</applicationReference>
</transactionData>
</modelData>
<activity>
<businessKeys>
<item>
<tcp.serializable__dictionary.BusinessKeyItem>
<key>
<string>ADVREF</string>
</key>
<value>
<businessKeyVO>
<businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
<keyType>Unknown</keyType>
</businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
</businessKeyVO>
</value>
</tcp.serializable__dictionary.BusinessKeyItem>
</item>
</businessKeys>
<actionMode>DEFAULT</actionMode>
<activityMode>DEFAULT</activityMode>
<activityTransaction>START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
<actionCode>QuoteLoad</actionCode>
<activityReference></activityReference>
<activityStatus>INITAL</activityStatus>
<activityCode>QuoteApplicationFull</activityCode>
<canProceedWithValidationsOutstanding>true</canProceedWithValidationsOutstanding>
</activity>
<displayError>false</displayError>
<isAnonymous>false</isAnonymous>
<isError>false</isError>
<isCompactRequest>false</isCompactRequest>
<callType>SUBMIT</callType>
</tcp.ssgbase.BaseVO>
запрос SOAP порождена фактического применения FE является :
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Body>
<ns2:ProcessUIRequest xmlns:ns2="http://zzz/yyywebservice/v5/types/">
<processUIRequest>
<activity>
<actionCode>QuoteLoad</actionCode>
<actionMode>DEFAULT</actionMode>
<activityCode>QuoteApplicationFull</activityCode>
<activityMode>DEFAULT</activityMode>
<activityReference />
<activityStatus>INITAL</activityStatus>
<activityTransaction>
START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
<businessKeys />
<canProceedWithValidationsOutstanding>
true</canProceedWithValidationsOutstanding>
</activity>
<callType>SUBMIT</callType>
<displayError>false</displayError>
<isAnonymous>false</isAnonymous>
<isCompactRequest>false</isCompactRequest>
<isError>false</isError>
<modelData>
<transactionData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:quoteLoadTxnDataVO">
<applicationReference>
20000003ESF.00000018</applicationReference>
</transactionData>
</modelData>
</processUIRequest>
</ns2:ProcessUIRequest>
</soapenv:Body>
</soapenv:Envelope>
POJO, который отправляется в этот SOAP-запрос т является:
<tcp.ssgbase.BaseVO>
<modelData>
<transactionData class="tcp.ssgview.app.QuoteLoadTxnDataVO">
<applicationReference>20000003ESF.00000018</applicationReference>
</transactionData>
</modelData>
<activity>
<businessKeys>
<item>
<tcp.serializable__dictionary.BusinessKeyItem>
<key>
<string>ADVREF</string>
</key>
<value>
<businessKeyVO>
<businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
<keyType>Unknown</keyType>
</businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
</businessKeyVO>
</value>
</tcp.serializable__dictionary.BusinessKeyItem>
</item>
</businessKeys>
<actionMode>DEFAULT</actionMode>
<activityMode>DEFAULT</activityMode>
<activityTransaction>START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
<actionCode>QuoteLoad</actionCode>
<activityReference></activityReference>
<activityStatus>INITAL</activityStatus>
<activityCode>QuoteApplicationFull</activityCode>
<canProceedWithValidationsOutstanding>true</canProceedWithValidationsOutstanding>
</activity>
<displayError>false</displayError>
<isAnonymous>false</isAnonymous>
<isError>false</isError>
<isCompactRequest>false</isCompactRequest>
<callType>SUBMIT</callType>
</tcp.ssgbase.BaseVO>
Вы можете увидеть, что структура этих двух запросов отличаются даже при том, что код выполняется в нашей интеграции JAR-файлы точно так же и структура POJOs, используемых для создания сообщения SOAP является (за исключением одного значения). Из запроса это похоже на то, что запрос, созданный в приложении FE, не подбирает правильные WSDL и связанные с ним XSD.
Наш код для создания правильной реализации конечной точки интерфейса сервиса:
private <T> T createServiceObject(final Class<T> p_seiClass) throws ApplicationException {
try {
final Service serviceFactory = Service.create(new URL(wsdlLocation), new QName(targetNamespace, serviceName));
final SoapHandlerResolver handlerResolver = new SoapHandlerResolver();
handlerResolver.addHandler(new SoapMessageLoggingHandler());
serviceFactory.setHandlerResolver(handlerResolver);
final T service = serviceFactory.getPort(p_seiClass);
((BindingProvider) service).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"endpoint");
return service;
} catch (MalformedURLException e) {
throw new ApplicationException(ApplicationErrorCode.COMM_ERR_UNEXPECTED_ERROR, e);
}
}
После выполнения некоторой отладки, я заметил, что экземпляр ServiceFactory отличается в тесте интеграции и когда мы бежим в пределах FE.
В тесте интеграции экземпляр класса (взятый из отладчика Eclipse, где мы запускаем интеграционный тест с использованием jUnit): «JAX-WS RI 2.1.6 в JDK 6: Stub for», и он кажется быть типа «SEIStub».
При запуске в приложении FE экземпляр класса является org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler. Приложение FE размещено и выполнено на WebSphere Application Server.
Итак, мой вопрос заключается в том, что может произойти при запуске в фактическом приложении FE, чтобы вызвать неправильные определения WSDL и XSD при сортировке POJO в запросе SOAP? Я долгое время пытался отладить это, но безрезультатно.
запрос два мыл отличаются потому, ** как вы уже сказали **, два ServiceFactory отличается и используя различные спецификации 1.1 и 1.2). Мое предложение состоит в том, что вы настраиваете свой проект maven для импорта правильных банок или обновления банки на контейнере (это банка, которая создает serviceFactory). Поскольку я не знаком с 'cxf-codegen-plugin', я не могу предложить больше этого. –
@JorgeCampos Да, вы действительно правы. Я изменил наше приложение так, что использует среду выполнения CXF JAXWS, а не среду выполнения Axis2 JAXWS, которую WAS использует по умолчанию, и проблема исправлена. Я заинтригован, почему я видел оригинальную ошибку, хотя, как мы использовали точно такой же схеме, как это (CXF генерировать клиентские артефакты, а затем с помощью выполнения Axis2 JAXWS на WAS) для интеграции со многими другими веб-сервисами и никогда были такие проблемы. Если вы хотите добавить свой комментарий в качестве ответа, я согласен с ним. – chrishern