Konzept eines Software-Rollout/Synchronisation via WebService

[raphaa]

Hallo @ all,

ich versuche mich gerade an der Aufgabe, ein Update-Mechanismus in eine Java-Anwendung (Server und Client) zu integrieren/implementieren.

Fachliche Anforderungen dabei:
Ein Java-Client (mit Swing-Oberfläche), welcher aus mehreren Modulen (JARs) besteht, soll sich beim Start auf einen Server verbinden und eine Versionskontrolle der Module durchführen. Die aktuellsten Module der Client-Anwendung liegen auf dem Server. Erkennt die Update-Logik auf dem Server ein Versionskonflikt zwischen einem Modul auf dem Server und dem Client, soll der Update-Mechanismus das alte Modul auf dem Client mit dem neuen Modul, welches auf dem Server liegt, ersetzen/updaten.

Dieser Mechanismus soll über einen WebService passieren. Eine grobe Idee wäre einen Service mit 2 Methoden zu schreiben: 1.) synchronise, 2.) dateUp

Im Allgemeinen heißt das, es soll Software (in meinem Fall JARs) über einen WebService verteilt werden.

Ich habe natürlich schon Google danach gefragt, aber leider ist die Fülle an Informationen so groß, dass es mich noch mehr verwirrt.

Deswegen wollte ich hier nach möglichen Ideen bzw. Ansätzen zu diesem Problem nachfragen. Hat jemand schon mit einem JAVA-Software-Rollout Erfahrung gemacht? Wo bekomme ich 'richtige' Lektüre zu diesem Thema?

PS: Falls ich die Problemstellung zu ungenau formuliert habe, bitte ich dringenst nachzuhaken ;-)

Danke im Voraus!

 

[maki]

Bevor du das Rad neu erfindest, sieh dir zumindest Java WebStart an 😉

 

[jule37]

falls du einen webservice schreiben möchtest, benutze doch SOAP, da ist diese funktionalität bereits integriert. da enthält der client nur methoden 'stubs' und compiliert sich die benötigten klassen dann selbst und man braucht bloß noch den server updaten.

edit: google doch mal "java soap"

 

[raphaa]

Hi,
ich würde nochmal gerne auf die Nachricht von jule37 eingehen.

Wie ist das gemeint, dass SOAP diese Funktionalität schon integiert hat? Ich habe mal danach gegoogelt, jedoch nichts dazu gefunden.
Es ist so, dass auf dem Server schon die Kompilierten JARs liegen. Das heißt, wenn das Programm ein Entwicklerupdate bekommt, werden diese Updates in Form eines JARs nur auf den Server geschoben. Wenn jetzt ein Benutzer den Client öffnet, sollen nur die entsprechenden JARs, wo ein Versionskonflikt vorliegt, vom Server auf den Client übertragen werden. Das verstehe ich unter Client-Update. Es ist nicht so, dass nur der Webservice upgedatet wird, sondern die einzelnen Komponenten der Clientanwendung (JARs).
Ich denke, dass so die einfachste Wartbarkeit des Programms erreicht wird. Falls es andere Ideen gibt, bitte ich um Rückmeldung.

@jule37: Wenn meine Anforderungen immer noch dazu passen, würde ich dich bitten noch 2-3 Stichworte an deine Anfrage "java soap" anzuhängen um mich vielleicht auf den richtigen Weg zu führen. Falls du noch Beispiele hast, wie diese Problematik realisiert werden kann, wäre ich dir sehr dankbar.

Danke im Voraus!

 

[jule37]

okay, ich fürchte, ich hab deine anforderung falsch verstanden. soap hält nur den webservice aktuell, aber nicht deine applikation. mit z.b. org.apache.axis.wsdl.WSDL2Java werden aus WSDL (web service description language - basiert auf xml) dateien automatisch die clientseitigen webservice klassen erzeugt. das kann dann halt automatisiert erfolgen.

insofern war meine aussage auch etwas ungenau, weil nicht SOAP sondern WSDL dieses feature ermöglicht, aber es gehört dennoch zusammen. der vorteil in dieser technologie ist eine einfach erreichte sprach und protokolunabhängigkeit der clients. so können z.b. gleichzeitig ohne weitere anpassung java und c++ clients zu dem server connecten. (auch für andere sprachen gibt es die automatische klassenerzeugung). für RPC basierte webservices DIE technologie schlechthin.

aber wie gesagt, das gilt nur für client klassen des webservices. ich habe mit dieser implementierung gearbeitet: WebServices - Axis

edit: die funktionalität, die du suchst könnte man zum beispiel mit einem solchen webservice lösen: vor dem start der anwendung läuft erst der webservice und checkt die files auf dem server und vergleicht die versionen. dann läd er die aktuelleren jars herunter und startet den eigentlichen client. könnte man z.b. mit einem launcher tool lösen (?). also wirkt jetzt auf den ersten blick nicht so dramatisch. man muss sich halt ein gutes system überlegen, in dem versionschaos nicht den überblick zu verlieren.

 

[raphaa]

Hi,

danke für die Antowort (sogar am Sonntag) ;-)

Genau das habe ich auch unter den Begriffen SOAP und WSDL gefunden. Leider passt das, so wie auch es erkannt hast, nicht zu meiner Anforderung.

OK. Ich sehe ein, dass es mit einer dafür entwickelten Architektur kein Problem wäre den Client vor dem Starten des eigentlichen Clients-Programms über einen WebService upzudaten.

Was ist mit der Idee bezüglich Java Web Start? Kann man das mit einer Art WebService vergleichen?

Gruß