XML/WSDL-Vergleichstool

Question

Für diejenigen, die viel mit Webdiensten arbeiten, ist es keine Überraschung, dass sie von Zeit zu Zeit aktualisiert werden. Und Sie müssen immer die Änderungen dieser Updates verfolgen.

In meinem Fall habe ich es mit einem Webservice zu tun, der durch eine WSDL definiert ist, und ich erhalte Klassen, die auf der Grundlage dieser WSDL generiert werden.

Aber vor der Regeneration von Klassen aus der aktualisierten WSDL möchte ich sehen, was in der WSDL geändert wurde und den Umfang der Änderungen bestimmen - um zu sehen, worauf ich mich einstellen muss.

Wenn ich nur .wsdl-Dateien der neuen und alten Version vergleiche, funktioniert das aus einem Grund leider nicht immer sehr gut - wsdl-Inhalte können neu geordnet werden (intern umstrukturiert). Das ist der Grund, mehr semantische Werkzeug zu finden.

Ich habe das Oxygen XML Diff-Tool ausprobiert, aber es funktioniert bei mir auch nicht gut.

Ich bin auf der Suche nach einem Tool, das zwei XMLs nimmt und mir nur semantische Unterschiede liefert, z.B:

• Element A hinzugefügt
• Unterelement b7 zum Element B hinzugefügt

Damit das funktioniert, muss das Tool wohl die Struktur laden und tief analysieren. Oxygen XML Diff sollte das gut machen, aber es ist nur eine verbesserte Version des Textdateivergleichs.

Könnten Sie eine Arbeitsmethode dafür empfehlen, insbesondere um Aktualisierungen in WSDL-basierten Webdiensten zu sehen?

UPDATE 1 : Die neue Idee ist, generierte Quellen statt WSDLs zu vergleichen.

Ich danke Ihnen.

Answer 1

http://membrane-soa.org hat eine Java-API für den Vergleich von WSDL in ihrem SOA-Modell .

package sample.wsdl;

import java.util.List;
import com.predic8.wsdl.*;
import com.predic8.wsdl.diff.WsdlDiffGenerator;
import com.predic8.soamodel.Difference;

public class CompareWSDL {

  public static void main(String[] args) {
    compare();
  }

  private static void compare(){
    WSDLParser parser = new WSDLParser();

    Definitions wsdl1 = parser.parse("resources/diff/1/article.wsdl");

    Definitions wsdl2 = parser.parse("resources/diff/2/article.wsdl");

    WsdlDiffGenerator diffGen = new WsdlDiffGenerator(wsdl1, wsdl2);
    List<Difference> lst = diffGen.compare();
    for (Difference diff : lst) {
      dumpDiff(diff, "");
    }
  }

  private static void dumpDiff(Difference diff, String level) {
    System.out.println(level + diff.getDescription());
    for (Difference localDiff : diff.getDiffs()){
      dumpDiff(localDiff, level + "  ");
    }
  }
}

Nach dem Ausführen erhalten Sie die in Listing 2 gezeigte Ausgabe. Es ist eine Liste von Unterschiede zwischen den beiden WSDL-Dokumenten.

Port ArticleServicePTPort removed.
Port ArticleServicePTPort2 added.
Operation create removed.
Operation create2 added.
Schema http://predic8.com/wsdl/material/ArticleService/1/ has changed:
  Element createResponse has changed:
    ComplexType  has changed:
      Sequence has changed:
        Element NewElementForTest added.

Hier finden Sie ein Beispiel für die Ausgabe des Tools, http://www.service-repository.com/ bietet eine Online-WSDL-Vergleichswerkzeug die einen Bericht über die Unterschiede zwischen zwei WSDL zurückgibt. Bei dem Bericht handelt es sich nicht um einen einfachen XML-Diff.

Answer 2

Die aufgeworfene Frage ist eigentlich für jedes System, das auf einer SOA aufbaut, sehr häufig. In der Regel haben Sie einige Verbraucher für eine WSDL oder einige Dienste, die dieselbe WSDL verwenden, und nun muss diese WSDL aktualisiert werden.

• Müssen wir alle Clients und den Server gleichzeitig aktualisieren (das ist teuer!)?
• Welche Vorgänge in der WSDL sind bei einer stufenweisen Bereitstellung betroffen (defekt), wenn der aktualisierte Client einen nicht aktualisierten Dienst aufruft?
• Und andersherum: Können einige Clients später aktualisiert werden?
• Wie ändert sich die XML-Struktur? Können diese Änderungen von einigen Parsern toleriert werden (z. B. brechen einige Parser nicht ab, wenn sie ein neues Element am Ende der Sequenz finden, wohl aber, wenn es in der Mitte gefunden wird).

Und nein, weder diff für WSDL noch diff für generiertes XML können zuverlässig helfen.

Zusätzlich zu den Schemaänderungen kann WSDL die Art und Weise ändern, wie die Nutzdaten strukturiert sind (Body/Header), die Kodierung/Qualifizierung, die SOAP-Action, die Bindungseigenschaften - all dies kann den Verlust der Interoperabilität zur Folge haben.

Erschwerend kommt hinzu, dass einige Arten von Änderungen, die in der Eingabe vorgenommen werden, das Szenario "aktualisiert auf alt" aufheben, während sie in der Ausgabe als nicht aufhebend betrachtet werden sollten. So würde beispielsweise ein neues optionales Element in der Anfrage den alten Dienst unterbrechen, wenn es übergeben wird, aber das gleiche Element in der Antwort wird vom alten Dienst nicht erzeugt (weil er es nicht kennt), und das Fehlen des Elements wird vom aktualisierten Client toleriert, weil das Element optional ist.

Mein Team ist etwa einmal pro Woche mit diesen Aufgaben konfrontiert. Bis vor kurzem haben wir einen manuellen Vergleich der WSDL-/Schemadateien durchgeführt und versucht, die Auswirkungen herauszufinden. Manchmal ist es offensichtlich, aber manchmal führte unser Ansatz zu Fehlern. Wir brauchten einen besseren Weg.

Membrane SOA war eine Hilfe. Leider werden in einigen Fällen die Änderungen im Schema nicht erkannt, so dass ein Vorgang fälschlicherweise als nicht betroffen gemeldet wird, obwohl er in Wirklichkeit defekt ist. Außerdem ist aus der Ausgabe nicht sofort ersichtlich, welches Szenario ("alt zu aktualisiert" oder "aktualisiert zu alt") gemeldet wird.

Nach einigen Jahren der Qual musste ich also meinen eigenen Code schreiben, der die obigen Fragen in einer Weise beantwortet, die ich unseren BAs/PMs direkt als unterstützende Dokumentation für die Folgenabschätzung vorlegen kann.

Siehe hier: https://wsdldiff.mockmotor.com/

1. Laden Sie Ihre WSDL und Schemata hoch:

2. Der Dienst gibt Ihnen eine Zusammenfassung der Auswirkungen: Sind die Änderungen fehlerhaft und welches Einsatzszenario ist betroffen?

3. Jeder Vorgang wird als "breaking" oder "non-breaking" Änderung sowohl in den Ports als auch in den Bindungen markiert:

4. Sie können einen Blick auf die Details einer bahnbrechenden Änderung werfen (d.h. welche Schema-/wsdl-Änderung sie verursacht). Hier wurde zum Beispiel ein obligatorisches Element in der Mitte einer Sequenz hinzugefügt:

Das soll nicht heißen, dass man sich blind auf Instrumente wie dieses verlassen sollte, aber es spart eine Menge Zeit bei der Folgenabschätzung.

Answer 3

Dies ist zwar nur eine Teillösung, aber Sie könnten die alte und die neue WSDL in SOAPui .

Anhand der generierten Methoden und Beispielanforderungen sollten Sie erkennen können, was sich geändert hat, ob es sich um Typen oder Methoden handelt.

Ich hoffe, das ist eine Hilfe