Web Service Frameworks

[nickiquickie]

Hallo!

Ich bin auf der Suche nach einer (wenn überhaupt möglich! ) vollständigen Liste der aktuell existierenden Web Service Frameworks, die in Java geschrieben sind.
Einige habe ich schon gefunden:

• Axis1.x
• Axis2
• CXF
• Metro
• Spring Web Services
• JBoss Web Services
• WSIT (Web Services Interoperability Technology)
• WSIF (Web Service Invocation Framework)
• WS02 Web Service Framework for Java
• ActiveSOAP
• Hessian
• Otego Web Services Frame Work

Kennt ihr noch welche? Was ist mit IBM oder Oracle oder BEA? Bieten die nichts eigenes an?

mfg, nickiquickie

 

[Oliver Gierke]

Reichen die dir nicht? Ich finde die Entscheidungsfindung schon so schwer genug, auch wenn viele von den genannten schon aus div. Gründen für mich ausfielen. Desweiteren solltest du genauer abgrenzen. SOAP und REST (Metro) sind z.B. extrem verschiedene Ansätze mit unterschiedlichem Overhead, Komplexität, Möglichkeiten. Hessian als WebService Framework zu bezeichnen halte ich für etwas zu weit gesprungen, da es eigentlich ein separates Metaprotokoll (wie SOAP) ist.

Es gibt im Übrigen mit JAX-WS ein Bestreben, einen Standard anzubieten, der von verschiedenen Vendors implementiert werden können.

Im Allgemeinen macht es auch Sinn, vorher zu überlegen was man will und dann etwas zu suchen, was passt. Und nicht erst zu schauen, was es alles gibt. Fachlichkeit vor Technik ist das Stichwort. Wenn du z.B. weißt du musst nur über HTTP kommunizieren und der Kommunikationsoverhead soll möglichst klein bleiben, würde ich eher die REST Frameworks in Betracht ziehen als "schwere" SOAP Varianten. Wenn es denn SOAP sein soll, dann bevorzuge ich im Allgemeinen Frameworks, die einen dokumentenorientierten Ansatz fahren (Spring WebServices).

Gruß
Ollie

 

[nickiquickie]

Danke für Deine Antwort, Ollie!

Reichen die dir nicht?

Doch, das sind mehr als genug.

Ich finde die Entscheidungsfindung schon so schwer genug, auch wenn viele von den genannten schon aus div. Gründen für mich ausfielen.

Die Entscheidung ist schon für Axis2 und Metro gefallen. (Die werde ich weiter untersuchen) Ich versuche nur herauszufinden, ob ich noch ein "großes", "populäres" Framework übersehen habe. Wie zum Beispiel eins von IBM oder von BEA oder oder oder? Ich habe keines, was relevant sein könnte, entdecken können und habe gedacht ich frag hier einfach mal.

Desweiteren solltest du genauer abgrenzen. SOAP und REST (Metro) sind z.B. extrem verschiedene Ansätze mit unterschiedlichem Overhead, Komplexität, Möglichkeiten. Hessian als WebService Framework zu bezeichnen halte ich für etwas zu weit gesprungen, da es eigentlich ein separates Metaprotokoll (wie SOAP) ist.

Von den größeren Frameworks (Axis2, CXF, Metro, JBossWS, SpringWS) können die meisten SOAP und REST. Teilweise zwar nur als POX und nicht das wirkliche REST. Aber Axis2 und Metro bieten wirklich RESTful Web Service Entwicklung an.

Es gibt im Übrigen mit JAX-WS ein Bestreben, einen Standard anzubieten, der von verschiedenen Vendors implementiert werden können.

Ja, der auch von Metro und JBoss verwendet wird. Sogar Axis2 hat schon damit angefangen JAX-WS zu unterstützen. Es wird aber noch ein bisschen dauern, bis er vollständig integriert ist.

Im Allgemeinen macht es auch Sinn, vorher zu überlegen was man will und dann etwas zu suchen, was passt. Und nicht erst zu schauen, was es alles gibt.

Mit geht es wirklich erstmal darum, was es alles an Frameworks zur Entwicklung von Web Services gibt. Jedoch sind bis auf die ersten fünf aus der Liste keine Frameworks dabei, die ich näher anschauen will. Ich denke es gibt noch eine Menge kleinere Frameworks, wie auch Hessian, die nicht wirklich ein Framework sind, sondern eher ein eigenes Protokoll. Die kleineren interessieren mich nicht weiter.

Was ist mit kommerziellen Produkten? Kennst Du da vielleicht was?
Ich weiß, dass es auf Basis von CXF eine kommerzielle Implementierung gibt, aber Oracle oder IBM müssten doch ähnlich wie JBoss etwas anbieten, oder?

mfg, nickiquickie

 

[Oliver Gierke]

Selbst wenn sie es täten. Der Platzhirsch im Bereich SOAP heißt auf jeden Fall Axis(2). Hierfür bevorzuge ich aber den saubereren Ansatz von Spring WebServices - kein unnötiges generieren von Quellcode, dynamische WSDL, keine Probleme mit Attachments (besonders bei der Crosskommunikation mit einem .NET basierten WebService macht Axis gut Probleme).

Vor jeder Art von SOAP Framework finde ich REST im einiges sportlicher, da näher am Architekturkonzept von HTTP, sprich, es liegt "sauberer" im Protokoll. hier gibt es noch einige andere Frameworks RESTlet, ReasEasy, Jersey (JAX-RS Referenzimplementierung). Bisher habe ich da aber noch keins gefunden, was sich elegant in eine Springapp einfügt.

in den gängigen neueren Applicationserver findet man meist proprietäre Implementierungen von JAX-WS. Ich würde jedoch bei der Auswahl des Frameworks auch darauf achten, wie groß die Verbreitung ist. Support kann man mittlerweile auch für OpenSource Projekte kaufen. Und der läuft oft besser als bei manch großem Namen.

Gruß
Ollie

 

[nickiquickie]

Selbst wenn sie es täten. Der Platzhirsch im Bereich SOAP heißt auf jeden Fall Axis(2). Hierfür bevorzuge ich aber den saubereren Ansatz von Spring WebServices - kein unnötiges generieren von Quellcode, dynamische WSDL, keine Probleme mit Attachments (besonders bei der Crosskommunikation mit einem .NET basierten WebService macht Axis gut Probleme).

Was meinst Du mit "den sauberen Ansatz von Spring Web Services"? Innerhalb von Axis1 oder 2? Mit der Spring-Integration in Axis? Kannst Du innerhalb Axis2 Spring Web Services direkt ansprechen?

Vor jeder Art von SOAP Framework finde ich REST im einiges sportlicher, da näher am Architekturkonzept von HTTP, sprich, es liegt "sauberer" im Protokoll. hier gibt es noch einige andere Frameworks RESTlet, ReasEasy, Jersey (JAX-RS Referenzimplementierung). Bisher habe ich da aber noch keins gefunden, was sich elegant in eine Springapp einfügt.

In erster Linie geht´s bei meinem Projekt um SOAP. Es ist natürlich ein Vorteil für das Framework, wenn es REST beherrscht, aber es ist nicht zwingend nötig.
Danke für die Tipps mit den REST-Frameworks und besonders der Wink mit dem Zaunpfahl, dass es eine Referenzimplementierung für RESTful Web Services gibt. Da bin ich bis jetzt noch nicht drüber gestolpert. Die werd ich mir aber auch mal genauer anschauen.

Danke für Deinen Tipps. Das mit der proprietären Unterstützung in den Applicationservern war genau das was ich gesucht habe. Jetzt kann ich diese "komischen" Frameworks der Applicationserver-Anbieter auch einordnen. Proprietär ist da das richtige Wort.

mfg, nickiquickie

 

[Thomas Darimont]

Hallo,

schau mal hier:
http://java-source.net/open-source/web-services-tools
http://wiki.apache.org/ws/StackComparison


Gruß Tom

 

[nickiquickie]

http://java-source.net/open-source/web-services-tools

Super Übersicht. Danke!

[

http://wiki.apache.org/ws/StackComparison

Die hier kenne ich schon. Ist auch sehr hilfreich.

mfg, nickiquickie

 

[Oliver Gierke]

Was meinst Du mit "den sauberen Ansatz von Spring Web Services"? Innerhalb von Axis1 oder 2? Mit der Spring-Integration in Axis? Kannst Du innerhalb Axis2 Spring Web Services direkt ansprechen?

Ich halte halt einfach den Ansatz von Axis (egal in welcher Version) für grundfalsch. Bei Axis gehst du her und generierst dir aus JavaInterfaces Klassen WSDLs usw. Das zieht natürlich viele Implementierungsdetails und Spezifika mit in das ja eigentlich Sprachneutrale Interface, das ein WebService haben soll. Die Probleme mit .NET hab ich ja schon angesprochen, den Umgang mit Attachments ebenso. Desweiteren sollten WebServices eigentlich Dokumentgetrieben sein und nicht besseres RPC.

Spring WebServices geht genau diesen Weg. Man definiert eine sprachneutrale Austauschdatenspezifikaton in XSD - fertig. Das WSDL erzeugt das Framework dynamisch. D.h. weniger Artefakte zu verwalten, editieren usw.Auch die Endpointimplementierung ist vom Konzept her dem Controllermodell aus SpringMVC sehr ähnlich. Für eine Anwendung die eh schon auf Spring basiert ist Konsistenz ein positiver Nebeneffekt.

Gruß
Ollie

 

[nickiquickie]

Bei Axis gehst du her und generierst dir aus JavaInterfaces Klassen WSDLs usw.

Das ist ja nur der eine Weg: Code-First! Die Frameworks (Axis2, Metro, CXF) bieten ja, genau wie SpringWS, noch den Contract-First-Ansatz: xsd erstellen bzw. kombinieren und in das WSDL einfließen lassen. Anschließend den Code für unterschiedliche Sprachen (Java, C, C++) aus der WSDL generieren.

Ansonsten kann ich Dir nur zustimmen: Konsistenz und Modell des SpringMVC sind eindeutige Vorteile des Spring WS-Frameworks.

mfg, nickiquickie