Java Axis2 Webservice aufsetzen

Hallo Leute,

ich würde gerne mit Axis2 ein Webservice aufsetzen, der folgendes macht:
- ein bereits implementierter Server schickt in zufälligen Zeitabständen eine PUSH SOAP Nachricht (in einer WSDL definiert) an einen zweiten Server (HTTPS-Protokoll wird hier für den Transport verwendet)
- Diesen zweiten Server gilt es via Axis2 zu implementieren


Meine Kenntnisse in Webservices und Axis2 sind allerdings etwas beschränkt.
Ich habe mir das ganze eigentlich so vorgestellt, dass ich eine Anwendung schreibe, die diese Pushnachrichten als Input erhält.

Ich bin gerade http://axis.apache.org/axis2/java/core/docs/installationguide.html am durchlesen und bezweifel, dass dies auf diese Weise funktioniert, da in dieser Anleitung über die Installation eines "Axis2 Standalone Server" geschrieben wird.

Deswegen wollte ich hier einmal nachfragen, ob jemand der sich mit Axis2 auskennt mir erklären könnte was dieser "Axis2 Standalone Server" ist und wie genau mein obiger Server den ich implementieren möchte letztendlich implementiert werden müsste (grober Aufbau wenn ich Axis2 verwenden möchte).

Vielen Dank im Voraus
Tim

Warum muss es denn Axis2 sein? Java SE unterstützt bereits von Haus aus das Schreiben von WebService-Clients und Server per Annotations.

Ist eine selbstauferlegte Vorgabe von dem Kumpel mit dem ich das zusammen mache.
Da ich ihm nicht direkt auf die Nase binden wollte, dass ich keinen Plan von Webservices habe, werde ich mich jetzt einlesen und Dinge die sich mir nicht selbsterschließen im Internet erfragen.

Und was versprecht ihr euch davon? Um von dem erlangten Wissen irgendeinen Nutzen zu haben, bräuchtet ihr eine Zeitmaschine, um in's Jahr 2005 zu gelangen.

Schaut euch lieber an, wie man WebServices heutzutage schreibt. Dann könnt ihr mit dem Wissen wenigstens noch ein paar Jahre was anfangen.

Abgesehen davon, hat sich der Programmierstil in Java in den letzten Jahren schon etwas verändert. Und es gibt in zwischen viele Möglichkeiten, um noch schöneren Code zu schreiben. Davon wird bei dem Steinzeit-Code von Axis2 nichts angekommen sein.

Nostalgie und Retro in allen Ehren, aber speziell in der Softwareentwicklung gilt: wer rastet der rostet, wer rostet ist schrott (und darf dann irgendwelche Legacy Produkte mi CORBA maintainen).

Welche Bibliotheken würden denn für die Anwendung am besten sein?

Nochmal zur Wiederholung:
- Ein bereits existierender Server pusht per HTTP SOAP Nachrichten in regelmäßigen Abständen

Der aufzubauende Server nimmt diese Nachrichten an und baut aus den inneren XML-Dateien eine Datenbank auf. Programmiersprache muss Java sein.

Uralt schein Axis2 ja nicht zu sein. Die letzte Version ist von 2017.
Ich verstehe nicht so ganz was gegen Axis2 sprechen sollte ? Mit der selben Argumentation ist Java auch eine alte Technik und nicht mehr zu nutzen!?

Die bringen nur noch Bugfixes raus und sorgen dafür, dass man Axis auch mit neuen Java Versionen nutzen kann. Abgesehen davon passiert da nicht viel. Kann ja auch gar nicht. Wenn sie größere Änderungen bzw. ein Redesign machen würden, gäbe es Inkompatibilitäten. Und dann hätte sich sicherlich auch die Major-Versionsnummer mal geändert, aber sie sind ja immer noch bei 1.x.x

Die einfachste Lösung für solche Fragen ist wie immer: Google
Suchbegriff: java + soap
Such-Zeitraum eingrenzen auf die letzten 2-3 Jahre.
https://www.google.de/search?q=soap+java&source=lnt&tbs=cdr:1,cd_min:6/1/2016,cd_max:&tbm=

Dann findet man auf jeden Fall viele aktuelle Lösungen. Für was man sich nun entscheidet, ist natürlich dann Geschmackssache und/oder an die Anforderungen des Projekts gekoppelt.
https://www.javaworld.com/article/3...ava-se-part-2-creating-soap-web-services.html
https://www.itworld.com/article/321...part-2-creating-soap-web-services.html?page=2
https://www.journaldev.com/9131/soap-webservices-in-java-example-eclipse
https://java2blog.com/soap-web-service-tutorial/
https://medium.com/@swhp/build-soap-web-service-for-millennial-java-developer-2986a0eb579e
http://www.baeldung.com/jax-ws

Ich hab mir die Ergebnisse jetzt nicht im Detail angeschaut, also gut möglich, dass da ein paar unbrauchbare Seiten dabei sind

EDIT: Hier ist ein Vergleich der verfügbaren Technologien: https://www.predic8.de/axis2-cxf-jax-ws-vergleich.htm
JAX-WS ist der offizielle Java-Standard für WebServices. Und gerade von der Benutzung unfassbar einfach.

Ansonsten möchte ich natürlich noch auf Spring verweisen:
https://spring.io/guides/gs/consuming-web-service/

Also für mich stände jetzt Apache cxf noch auf dem Schirm. Aber ich kann nicht ganz erschließen, ob das wieder "veraltet" ist.

Bei solchen Projekten heißt veraltet nicht "schlecht" oder "unbrauchbar". Da steht ja jeweils eine riesige Community hinter und es wird dafür gesorgt, dass die Software weitestgehend fehlerfrei ist und weiterhin auch funktionsfähig bleibt. Dabei wird aber vor allem auf die Funktionsfähigkeit der bereits unterstützten Java Versionen wert gelegt. D.h. Features aus neueren Java Versionen werden dort eher nicht ankommen, sonst müsste man im Zweifelsfall den Support für die alten Java Versionen streichen. Und für die neuen Java Versionen gibt's ja neue Lösungen für das Problem wie z.B. JAX-WS.

Der Punkt ist einfach, dass sich die Sprache Java weiterentwickelt und immer mehr (bessere / einfachere) Möglichkeiten bietet, um Probleme zu lösen. Speziell durch den Einsatz von Annotations, ClassPathScanning und Lambdas kann man sich extrem viel unnötigen Code sparen.

Der JAX-WS Standard und die Implementierungen setzen da von vorne bis hinten drauf. Super bequem und einfach.

Das andere (für mich ausschlaggebende) Problem ist, dass jede Software irgendwann durch neue Software abgelöst wird und die alte irgendwann gar nicht mehr supported wird. Axis entstammt halt einer Zeit, als es direkt im Java Standard keine einfache Möglichkeit für WebServices gab. Die gibt es aber nun seit Jahren. Also gibt es (gerade bei neuen Projekten) keinen vernünftigen Grund mehr auf einen nicht-Standard zu setzen.

Ähnliches Szenario:
Vor Java8 gab's dasselbe Problem mit Date, Calendar und Joda Time. Weil man mit Date und Calendar nicht gerade komfortabel programmieren kann, hat so ziemlich jedes Projekt auf Joda Time gesetzt.
Und nun? Seit Java8 gibt's java.time direkt in Java integriert - quasi ein minimal modifiziertes Joda Time (stammt vom selben Entwickler). Es gibt keinen Grund mehr auf Joda Time zu setzen. Außer man befindet sich in einem Projekt das auf Java 5,6,7 festgenagelt ist.

Und dasselbe gilt quasi für Axis.

Unterm Strich will ich eigentlich damit nur sagen: Macht euch das Leben nicht unnötig schwer, indem ihr auf alte Technologie setzt. Wenn es gleichzeitig ein ebenso gut supportetes aktuelles Projekt gibt, das sich einfacher bedienen lässt / deutlich weniger Code erfordert, dann sollte man das benutzen. Vor allem in Hinblick auf die Unterstützung von neuen/zukünftigen Java Versionen und deren neuen/vereinfachten Sprach-Features.

Ich fand Axis2 schon vor 10 Jahren sehr mühsam... Also sicherlich nichts was ich mir heute noch antun möchte.

@Tockra: Und warum favorisierst Du nun Apache CXF? Ich würde weiterhin an Deiner Stelle den Standard bevorzugen und das ist es eben das annotation-basierte Implementieren direkt mit JDK-Hausmitteln.