Ich habe kürzlich ein Projekt ausgewählt, das einen ziemlich bösen Build-Prozess hat. Handcodierte XSD-Schemas werden von JAXB gelesen, um ein Java-Modell von Klassen und Fabriken zu generieren, das in handcodierten Java-Webservice-Klassen (kommentiert) verwendet wird, die dann auf einem Server bereitgestellt werden, der als Quelle zum Lesen des kompletten verwendet wird WSDLs von, um ein zweites Java-basiertes Modell zu generieren, das die Service- und Factory-Klassen für die komplette WSDL enthält, die in Client-Programmen verwendet wird.
Das hört sich furchtbar an und ich glaube nicht, dass ich es so kompliziert brauche. Irgendwann möchte ich das alles wegschmeißen und entweder
In jedem Fall möchte ich eine Quelle für das Modell haben, die sowohl der Server als auch die Kunden nutzen können und eine "Quelle der Wahrheit" für das, was das Modell sein soll, wo ich mich gerade fühle mehrere.
Im Moment stehe ich auf die zweite Option, aber welche würden Sie wählen? Und welche Technologien würden Sie verwenden?
In dem Projekt, an dem ich gerade arbeite, wiederholen wir gerade unsere Webdienste vollständig. Diese Dienste bieten den Kunden Serverfunktionen über SOAP. Von dem, was ich gelernt habe, wenn ich alle Feinheiten dieses Protokolls betrachte, die das Layout der WSDL stark beeinflussen, würde ich lieber nicht selbst eine WSDL schreiben. Es gibt so viele Dinge, die Sie falsch machen können (besonders wenn es um Dinge wie Parameter Stil und all das geht). Und sobald Ihre WSDL "da draußen" ist und Kunden, die von dieser WSDL generiert werden, glücklich mit Ihrer Anwendung kommunizieren, können Sie sie nicht mehr ändern (oder Sie denken über eine Versionierungsstrategie nach, die sich als ziemlich schmerzhaft herausstellen kann).
Mein starker Vorschlag ist also, Ihren Service-Code in Java zu schreiben und Ihre Bibliothek eine WSDL für Sie generieren zu lassen. Sie können dann sehr leicht mit verschiedenen Bindungsstilen spielen (was wiederum die Interoperabilität mit anderen Clients beeinflusst). Ein sehr gründlicher Artikel, der all das beschreibt, findet sich hier:
Außerdem sind WSDLs für Menschen nicht besonders lesbar und daher (zumindest aus meiner Sicht) für Menschen schwerer aufrechtzuerhalten. Java-Code hingegen ist ziemlich einfach zu lesen (oder zumindest kann man es so schreiben), was ein noch besserer Grund ist, den Java-Code und nicht die WSDL zu entwickeln.
Ich hoffe, das hilft Ihnen bei Ihrer Entscheidung.
Die sauberste Methode besteht darin, die WSDL manuell oder mithilfe eines Designers zu generieren - und daraus die Proxies und Stubs zu generieren.
Die Logik dahinter ist, dass die WSDL den Servicevertrag definiert, der implementationsunabhängig sein sollte - Und die Java-Klassen sind implementierungsspezifisch - und diese Implementierungsdetails werden oft in die WSDL übertragen.
Die genauen Probleme hängen vom Java-zu-WSDL-Konverter ab, den Sie verwenden (oder, noch wichtiger, dem Java-zu-XSD-Konverter) - aber sie sind ziemlich üblich, besonders wenn Sie nicht-Java-Server oder -Clients in Ihrer Umgebung hinzufügen möchten. p>
Wenn Sie es vorziehen, die Dienste in Java zu schreiben, sollten Sie einige Richtlinien befolgen, die die Implementierungssperre minimieren, wie zum Beispiel:
Ich hätte gedacht, dass das Abrufen der wsdls und Schemas mit einem einfachen HTTP-GET-Prozess entweder manuell oder über einen einfachen Code-Aufruf (ant-Task usw.) machbar sein sollte, anstatt diesen ziemlich verschachtelten Prozess, den Sie beschrieben haben. Nachdem ich gesagt habe, dass ich in der Regel mit Web-Services arbeite, die einen Release-Zyklus haben, bekomme ich normalerweise die WSDLs und Schemas manuell.
Wenn Sie die WSDLs und Schemas bei jedem Build erneut holen müssen, würde ich den get-Prozess als vorbereitenden Schritt in den Build einbauen (in maven wäre das die initialize -Phase) Ich würde mit der GET ant-Aufgabe nachschauen, gefolgt vom wsdl2java-Schritt (in maven hänge ich normalerweise den wsdl2java ant-Aufgabe in die generate-sources -Phase).
Kürzlich habe ich den Weg verfolgt, um automatisch die Java-Klassen von der WSDL zu generieren. Dafür habe ich die wsdl2java.bat aus dem Apache cxf-Projekt verwendet. Ссылка
Ich musste einige kleinere Änderungen (XmlElementWrapper) für die Sammlungen und einige Korrekturen des Namespace vornehmen, aber alles andere war in Ordnung.
Sobald Sie sich daran erinnern, dass Webdienste und Java zwei völlig unterschiedliche Dinge sind, wird dieser Ansatz Sinn machen.
Angesichts dieser Präambel ist der Grund dafür, dass XSDs handgeschrieben sind, eine Kontamination von Methodenparametern nach Java-Typen zu vermeiden . Dieses Kontaminationsproblem existiert von Anfang an.
Das Problem ist zweigeteilt: Typdefinition, Einschränkung einer Sprache. Die Typen, die von Webservices vom Typ JAX-RPC generiert wurden, waren für viele Nicht-Java-Konsumenten nicht geeignet. Die Java-Gruppe arbeitet ständig daran, und ich denke, eines der beiden Probleme wurde mit JAX-WS weitgehend umgangen. Der Versuch, Web-Services außerhalb des Kontextes einer Programmiersprache zu definieren (XML ist eine Sprache), ist der Grund dafür, Definitionen von Hand zu schreiben.
Die WSDL-Generierung ist schwierig, wie viele gezeigt haben, und wird am besten mit einem Werkzeug oder einer IDE, die WSDL generiert, gemacht - Transport ist also kein Problem mehr. Auf diese Weise werden die XSDs in Ihre WSDL aufgenommen, und während Sie die XSDs "handcodieren", haben Sie die Kontrolle über Ihre Inhalte.
Ein Ansatz besteht darin, ein XML-Schema (XSD) zu verwenden, um ein Modell zu definieren. Sobald dieses Modell definiert ist, definieren Sie Service-Interfaces (WSDL), die die Objekte aus dem Modell (XSD) als Inputs / Outputs der Services verwenden.
Dies definiert Ihre abstrakten Service- und Model-Layer.
Sie können dann Ihre bevorzugten Tools und Technologien verwenden, um konkrete Implementierungen zu entwickeln. Sie können sogar JAXB verwenden, um ein Java-Äquivalent der XSD-Modellbibliothek zu definieren und es im Client und Server zu verwenden.
Ссылка - Blog über SOA, XML, Integration und verwandte Themen
Ich mag Spring-WS wirklich. Es ist ein Vertrag erster Ansatz. Warum zuerst Vertrag
Sie definieren Ihr XML-Schema und Spring generiert die WSDL für Sie. Es verstecken die technischen Aspekte der WSDL, es ist wirklich sauber.
Tags und Links java java-ee web-services wsdl soa