Wir sind dabei, eine WebLogic 10.3.5-Webanwendung auf WebLogic 12.1.3 zu migrieren, und es ist ein Problem aufgetreten, von dem wir glauben, dass es möglicherweise mit der Sicherheit von Webdiensten zusammenhängt. Die App verwendet Axis 1.5.6, um zu einem SOAP-Suite-SOAP-Service aufzurufen (der immer noch unter WebLogic 10.3.5 ausgeführt wird). Wenn Web-Service-Sicherheit deaktiviert ist, erhalten wir die erwartete Antwort zurück:SOA Suite auf Axis2-Daten wird gelöscht
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:getNamesResponse
xmlns:ns2="http://www.example.com/ABC/Common"
xmlns:ns3="http://www.example.com/ABC/Profile">
<ns3:OperatingName>
<ns3:Number>123456789</ns3:Number>
<ns3:Name>Company Name, Inc.</ns3:Name>
</ns3:OperatingName>
</ns3:getNamesResponse>
Aber sobald Web-Service-Sicherheit aktiviert ist (unter Verwendung von Apache Rampart 1.5.2, 2.0.5 Apache Neethi), beginnen wir empfangen leere Antworten :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:getNamesResponse
xmlns:ns2="http://www.example.com/ABC/Profile"
xmlns:ns4="http://www.example.com/ABC/Common" />
das seltsame, dass, wenn durch die SOA-Suite-Konsole suchen, die Antwort von SOA zurück auf den Web-App (mit Sicherheit aktiviert) sieht richtig:
<message>
<properties>
<property name="tracking.compositeInstanceId" value="2110209"/>
<property name="tracking.ecid" value="0058XKIkdpHFw00Fzzw0w00004Et005Kmk"/>
<property name="ws.wsu.id" value="Body-Body_tTzuB5XmRNQPR7Y7"/>
</properties>
<parts>
<part name="getNamesResponse">
<bp:getNamesResponse>
<bp:OperatingName>
<bp:Number>123456789</bp:Number>
<bp:Name>Company Name, Inc.</bp:Name>
</bp:OperatingName>
</bp:getNamesResponse>
</part>
</parts>
</message>
Es werden keine Ausnahmen protokolliert. Hat jemand anderes diese Art von Problemen erlebt und gelöst?
Haben Sie Protokolle auf Fehler überprüft? Weblogic hat seine eigenen XML-Bibliotheken, also könnte es ein Bibliothekskonflikt sein. –
Verwenden Sie dieselbe Soap-Anfrage? Ich verstehe, dass sollte neue Tags für die Sicherheit haben (WS - Sicherheit 1.1, etc.) Und wahrscheinlich der SOA interne Client trifft direkt auf Ihren Endpunkt (Umgehung der Sicherheitsschicht). – devwebcl
Die Protokolle zeigen keinen Fehler an. Der SOAP-Client-Code wurde nicht geändert, ebenso wenig wie die oben beschriebenen Versionen der Client-Komponenten (Wall, etc.). Es scheint mir, dass SOA die Sicherheit umgehen würde, dann würden wir eine Sicherheitsausnahme bekommen. Alles scheint aus Sicherheitsgründen zu funktionieren. Es ist einfach die Antwort-XML, die gelöscht wird. – 6006604