Application Server

[MQue]

Hallo,

was würdet ihr für einen Application Server verwenden bei einer freien Auswahl?
Ich benötige eine Datenbankanbindung, hab eine Geschäftslogik und die Darstellungsschicht sollte noch offen gelassen werden, z.B.: soll die Darstellungsschicht mit JSP, HTML, AJAX realisiert werden können, es sollte aber auch möglich sein, einen eigenen Client (z.B.: Rich Client mit Eclipse) zu schreiben und mit diesem auf Daten des Applikationsserver zuzugreifen.
Wäre Euch dankbar für eine Empfehlung, funktioniert das alles mit Tomcat oder brauch ich die Referenzimplementierung Glassfish dazu?)

lg

 

[maki]

Wenn ich die Wahl hätte würde das mit der OSGi Version von TC (kostenpflichtig) machen

 

[MQue]

Wenn ich die Wahl hätte würde das mit der OSGi Version von TC (kostenpflichtig) machen

das Problem ist, ich hab mit OSGi noch nichts gemacht, ich weiß nur, dass es in Eclipse verwendet wird um die Plugins (Bundles) einzuhängen, komme aber aus der NetBeans- Ecke, da wirds mit Modulen und den Lookups realisiert (eine Analogie ist aber nicht abzustreiten)

Weißt Du vielleicht, ob es mit Tomcat möglich ist, mit einem Client (Plain Old Java Desktop Application) direkt auf die Geschäftslogik des Tomcat zuzugreifen ohne die Präsentationsschicht zu verwenden.

Mir ist momentan nur die "normale" Möglichkeit bekannt, mit einem Browser über die Präsentatiosschicht (ein Servlet (doGet, doPost)) auf den Server bzw. die Dienste des Servers zuzugreifen,

Wäre Dir sehr dankbar für Tipps in diese Richtung,
lg

 

[byte]

Weißt Du vielleicht, ob es mit Tomcat möglich ist, mit einem Client (Plain Old Java Desktop Application) direkt auf die Geschäftslogik des Tomcat zuzugreifen ohne die Präsentationsschicht zu verwenden.

Das geht mit dem Spring Framework sehr komfortabel. Du legst ein "Servlet Projekt" an, dort implementierst Du Deine Services (Schnittstelle zwischen Client und Server) als POJOs. Die Services könnten über DAOs mit einer DB kommunizieren.

Diese Services kannst Du dann über einfache Servlets verfügbar machen. Das funktioniert so, dass du ein DispatcherServlet in der web.xml definierst, dass alle Aufrufe an die entsprechenden Service-Objekte delegiert. Das konfigurierst Du dann entsprechend mit Spring.

Seitens des Rich Clients kannst Du dann mit Hilfe von Apache HttpClient mit dem Server kommunizieren. Das lässt sich mit ein paar Zeilen Code konfigurieren (siehe Spring HTTPInvoker).


Es ist ohne weiteres möglich, parallel dazu einen Webclient zu schreiben, wo mit Hilfe der o.g. Services z.B. JSPs oder dergleichen generiert werden.

 

[maki]

Weißt Du vielleicht, ob es mit Tomcat möglich ist, mit einem Client (Plain Old Java Desktop Application) direkt auf die Geschäftslogik des Tomcat zuzugreifen ohne die Präsentationsschicht zu verwenden.

Klar, machen auch viele, tfa hatte mal was erwähnt, denke es war mit Spring Remoting, RMI etc. gehen natürlich auch, mittlerweile geht das sogar mit EJBs (OpenEJB).

 

[MQue]

Vielen Dank, dann stürz ich mich mal rein, eine Frage stellt sich jetzt noch, ob mich dabei der Tomcat 6.0 Unterstützt (bei Spring, RMI, Datenbankanbindung, EJB)?
lg

 

[Noctarius]

Ich würde auch einen Tomcat mit Spring nutzen. Auf der Basis läuft ein relativ großes, älteres System mit größerem Zugriffsvolumen.

Wenn du allerdings etwas Zeit aufbringen magst und dich z.B. eh in Spring einarbeiten möchtest wäre es vllt doch nicht falsch direkt nach ServiceMix oder SpringDM (die zwei OSGi Server mit Spring Unterstützung) zu schauen, da auch bei Tomcat überlegt wird eventuell demnächst nach OSGi zu schauen

 

[MQue]

Ich würde auch einen Tomcat mit Spring nutzen. Auf der Basis läuft ein relativ großes, älteres System mit größerem Zugriffsvolumen.

Aber Tomcat macht's nicht mit EJB? oder täusch ich mich da, würde die EJB nicht sofort programmieren aber wenn in weiterer Folge Erweiterungen bei der Businesslogik anstehen, wäre es sehr hilfreich, modulare Komponenten zu der Applikation dazuzu- deployen,

 

[maki]

Mit OpenEJB kann man auhc in Tomcat EJBs haben, die Frage ist: Willst du EJBs, oder willst du OSGi?

Am flexibelsten bleibst du aber mit POJOs & SPring imho, geht beides auch auf einem AppServer.

 

[e9926044]

Mit OpenEJB kann man auhc in Tomcat EJBs haben, die Frage ist: Willst du EJBs, oder willst du OSGi?

Am flexibelsten bleibst du aber mit POJOs & SPring imho, geht beides auch auf einem AppServer.

Wisst ihr vielleicht ein (gutes) Tutorial, um mit Spring so schnell wie möglich produktiv zu werden?
Dankeschön,
lg

 

[maki]

Die Spring Doku ist sehr gut imho, allerdings musst du schon wissen wohin die Reise gehen soll, den Spring ist ein ganzes Ökosystem, nicht nur ein Framework.

Was genau interessiert dich denn, e9926044?

 

[MQue]

Hallo nochmal,

wenn ich jetzt Spring und OSGi verwende, wird das wahrscheinlich nur mit Eclipse gehen, da ja Netbean weit und breit nicht mit OSGi umgehen kann, oder täusch ich mich da?

lg

 

[byte]

Equinox ist die OSGi Implementierung von Eclipse und wird afaik auch von Spring Dynamic Modules verwendet. KA obs überhaupt noch ne andere OSGi Implementierung gibt, die weit verbreitet ist.
Inwiefern Netbeans Equinox unterstützt, kann ich nicht sagen. Ich denke mal, um Eclipse wirst Du nicht drum herum kommen, wenn Du Equinox benutzen willst. Ist aber ja nicht so wild. Interessanter ist die Frage, welche Server Plattform Du verwenden willst, die OSGi-fähig ist!?
Der Spring DM Server steht unter GPL.

 

[Noctarius]

Equinox ist die OSGi Implementierung von Eclipse und wird afaik auch von Spring Dynamic Modules verwendet. KA obs überhaupt noch ne andere OSGi Implementierung gibt, die weit verbreitet ist.
Inwiefern Netbeans Equinox unterstützt, kann ich nicht sagen. Ich denke mal, um Eclipse wirst Du nicht drum herum kommen, wenn Du Equinox benutzen willst. Ist aber ja nicht so wild. Interessanter ist die Frage, welche Server Plattform Du verwenden willst, die OSGi-fähig ist!?
Der Spring DM Server steht unter GPL.

Apache Felix im ServiceMix und vielen anderen Projekten

 

[MQue]

Apache Felix im ServiceMix und vielen anderen Projekten

Ok, vielen Dank erst mal, ich fasse mal zusammen, mal schaun ob ich das richtig verstanden habe,
Ich programmiere mit Eclipse auf einen Apache Felix (Server?) im ServiceMix, welcher Equinox (also OSGi) verwendet.
Kann man das so sagen?

Was wäre da dann der Unterschied zu einer Glassfish- Implementierung, welchen ich mit EJB bestücke bzw. einen Einsatz von Spring?

Ich versuche gerade mir einen Weg durch den Framework- Jungle zu suchen und das Beste (für mich) herauszubekommen bzgl der schnellen Erlernbarkeit (hab bis jetzt vorwiegend mit NetBeans gearbeitet).
Wäre Euch sehr dankbar für Tipps,

lg

 

[byte]

Das Thema OSGi ist imo recht komplex, vor allem wenn man eine Integration mit anderen Frameworks haben will. Es gibt immer wieder mehr oder weniger fiese Pitfalls, grade wenn man Libraries oder Frameworks in den OSGi Container integriert. Erst letztens saß ich wieder an einem Problem mit AspectJ, dass sich am Ende auf ein ClassLoader Problem mit nem Bundle zurückführen lies.
Wir benutzen OSGi nur auf dem Richclient und nicht auf dem Server. Dort benutzen wir einfach Tomcat + Spring + Hibernate und fahren sehr gut damit.

 

[MQue]

Das Thema OSGi ist imo recht komplex, vor allem wenn man eine Integration mit anderen Frameworks haben will.
Wir benutzen OSGi nur auf dem Richclient und nicht auf dem Server. Dort benutzen wir einfach Tomcat + Spring + Hibernate und fahren sehr gut damit.

Tomcat + Spring + Hibernate kommt mir mittlerweile auch schon sehr Sympatisch vor, mit Hibernate hab ich schon gearbeitet (dürfte kein Problem sein), Tomcat ist mir auch sehr gut bekannt (meine ganzen EE - Projekte hab ich mit Eclipse und Tomcat realisiert -> einfache Servlets, JSP und HTML), die einzige Unbekannte für mich ist Spring,
wird also wahrscheinlich in diese Richtung gehen, ich hoffe ich bereues es nicht, die Verantwortlichen haben mir da freie Hand bei der Auswahl gegeben, wollen aber wahrscheinlich so schnell wie möglich Resultate sehen, das werden aufregende Wochen,

lg

 

[byte]

tfa hat in einem seiner Blogs hier im Board ein kleines Spring Tutorial. Das kannst Du Dir ja mal angucken. Ansonsten ist die Spring Doku sehr gut (wenn auch umfangreich). Es gibt aber auch haufenweise Tutorials im Netz und das Spring Forum ist auch sehr gut besucht. Lohnen tut sich das allemal. Du wirst die Java Welt danach mit anderen Augen sehen.

 

[Noctarius]

Ok, vielen Dank erst mal, ich fasse mal zusammen, mal schaun ob ich das richtig verstanden habe,
Ich programmiere mit Eclipse auf einen Apache Felix (Server?) im ServiceMix, welcher Equinox (also OSGi) verwendet.
Kann man das so sagen?

Ganz einfach: Nein

Es gibt mehrere OSGi Implementierungen der Frameworkspezifikation, die bekanntesten sind eben Apache Felix, Eclipse Equinox und Knopflerfish. ServiceMix, Spring DM Server, JBoss und Andere Server benutzen solch eine OSGI Implementierung als Basis um darauf OSGi-Bundles (ne spezielle Art von JAR-Files) auszuführen und damit Services, Klassen, Funktionen, usw anzubieten.

Eclipse selber ist eine RCP (Rich Client Platform) welche als Grundlage OSGi verwendet. Eclipse selber baut dabei auf Equinox auf. ServiceMix andererseits z.B. baut auf Apache Felix auf.

Der Vorteil an der OSGi Spezifikation (wenn man sich an die Grundlagen hält und keine Equinox-Erweiterungen nutzt) ist, dass ein OSGi-Bundle welches auf Equinox läuft auch auf Felix oder Knopflerfish funktioniert.

Damit kannst du mit Eclipse sehr einfach Bundles entwickeln und dann auf einem externen Server benutzen.

Für mich hat sich folgende Kombination als am einfachsten herausgestellt (für Webanwendungen und -plugins):
Eclipse -> Maven (Eclipse Plugin) -> Archetype Spring-OSGi-Bundle -> ServiceMix mit Spring DynamicModules Unterstützung

Hier mögen die Meinungen aber auseinander gehen. Ich finde Spring hat eine tolle OSGi Extention (wenn auch manchmal etwas fehlt, ist halt erst Version 1.0.2) und ist generell sehr gut dokumentiert und verständlich. Abgesehen davon gibt es zu Spring genug Bücher und für mich immer noch der größte Vorteil: Ich arbeite hauptsächlich mit POJOs und DI

 

[maki]

Sehe das so wie Noctarius, mit SpringDM wird das ganze sehr einfach (und Intergrationstests zB. auch ), da reicht auch ein nacktes Equinox mit den entsprechenden Bundles um die App laufen zu lassen, es muss kein SpringDM Server sein.
Soweit ich weiss, ist Equinox bisher die umfassendste OSGi Implementierung.

 

[Noctarius]

Apache Felix bietet auch vollen OSGI Spec Nur die vielen zusätzlichen Möglichkeiten von Equinox fehlen, die man der Portabilität wegen, nicht umbedingt einsetzen sollte. Außer man baut definitiv für Eclipse

edit: Hier noch eine sehr schöne Grundlagenerklärung zu OSGi: OSGi ? Wikipedia

 

[maki]

Was ist mit Fragements unter Felix?
Vor 6 Monaten wurden diese noch nicht unterstützt

 

[Noctarius]

Müssten entweder schon gehen oder mit dem nächsten Release kommen. Hatte zumind. neulich noch was darüber gelesen dass daran gearbeitet wurde. Ich persönlich hab sie noch nicht eingesetzt, daher weiß ich es nicht genau

 

[maki]

Sehr nützlich, zB. für die Logging konfig. oder auch Internationaliserung.

 

[Noctarius]

Kannst im ServiceMix (dank SpringDM) auch über OSGi-Compendium Namespace machen

 

[MQue]

OK, ich hab mir das Spring angesehen (kurz überflogen und ein paar kleine Referenzimplementierungen gemacht) und bin überzeugt von diesem Teil,

Meine Frage wäre jetzt, wie kann ich das Spring- Framework in meiner Tomcat- Implementierung verwenden? Muss ich da einfach nur die jars in mein JavaEE- Projekt kopieren und dann funkts. oder muss ich dem Tomcat da auch noch was sagen?

Vielen Dank,
lg

 

[maki]

Deine Webapp braucht die jars, sonst nix.

 

[Noctarius]

Ich bin Verfechter der Doppelstrategie @Autowire Annotation und dann by-interface-type binden lassen (zumind. da wo es Sinn macht, weil man nur eine Instanz haben mag), Rest per XML DI

 

[byte]

OK, ich hab mir das Spring angesehen (kurz überflogen und ein paar kleine Referenzimplementierungen gemacht) und bin überzeugt von diesem Teil,

Meine Frage wäre jetzt, wie kann ich das Spring- Framework in meiner Tomcat- Implementierung verwenden? Muss ich da einfach nur die jars in mein JavaEE- Projekt kopieren und dann funkts. oder muss ich dem Tomcat da auch noch was sagen?

Vielen Dank,
lg

Einfach die Jars ins WEB-INF/lib Verzeichnis. Du musst dann halt sehen, dass Du einen WebApplicationContext konfigurierst, der einmal aufgebaut wird, wenn die Webanwendung gestartet wird.

 

[MQue]

Hallo nochmal,

hab noch ne blöde frage zu Spring, soweit klappt alles sehr gut, ich brauche jetzt noch eine Datenbankanbindung (am besten mit iBatis oder Hibernate),
in Spring sind ja jetzt schon ein paar jars dabei wie z.B.:

org.springframework.jdbc-3.0.0.M3.jar
org.springframework.jdbc-sources-3.0.0.M3.jar
org.springframework.orm-3.0.0.M3.jar
org.springframework.orm-sources-3.0.0.M3.jar

das hat aber jetzt noch nichts mit iBatis oder Hibernate zu tun, oder?
die jars muss ich wahrscheinlich separat einbinden, ich frage mich jetzt nur, was Spring zu meiner Datenbankanbindung beitragen kann???

vielen Dank,
lg

 

[Noctarius]

5.1 Hibernate und Spring: Auszug aus Kapitel 5 Integration anderer Technologien aus dem Buch Hibernate
kurze Leseprobe

The Spring series, Part 2: When Hibernate meets Spring

Spring macht hauptsächlich das DI für Hibernate Klassen

 

[maki]

Nebenbei

..3.0.0.M3...

nur für den Fall, aber in einem Prod. Projekt sollte man keine Milestone jars verwenden, Schnittstellen etc. können sich schnell ändern.

 

[byte]

Hallo nochmal,

hab noch ne blöde frage zu Spring, soweit klappt alles sehr gut, ich brauche jetzt noch eine Datenbankanbindung (am besten mit iBatis oder Hibernate),
in Spring sind ja jetzt schon ein paar jars dabei wie z.B.:

org.springframework.jdbc-3.0.0.M3.jar
org.springframework.jdbc-sources-3.0.0.M3.jar
org.springframework.orm-3.0.0.M3.jar
org.springframework.orm-sources-3.0.0.M3.jar

das hat aber jetzt noch nichts mit iBatis oder Hibernate zu tun, oder?
die jars muss ich wahrscheinlich separat einbinden, ich frage mich jetzt nur, was Spring zu meiner Datenbankanbindung beitragen kann???

vielen Dank,
lg

Spring bietet Dir deklaratives Transaktions-Handling. Du kannst eine Transaktionsklammer um eine Methode legen, z.B. durch einfaches annotieren mit @Transactional (alternativ auch per XML). Ausserdem hat Spring eine eigene Exception Hierarchie (siehe DataAccessException). Exceptions aus dem ORM können auf diese Exceptions gemappt werden, was z.B. im Falle von Hibernate definitiv sehr sinnvoll ist, denn Hibernate Exceptions sind nicht selten sehr nichtssagend. Die DataAccessExceptions hingegen sind idR sehr aufschlussreich.

In älteren Hibernate Versionen hat Spring noch mehr abgenommen. Früher konnte Hibernate die Session noch nicht selbstständig an die Transaktion binden. Das hatte Spring dann übernommen (Stichwort HibernateTemplate). Seit Hibernate 3.2 kann Hibernate das aber selbst, deshalb kann man direkt mit der Hibernate Session arbeiten, statt den Umweg übers HibernateTemplate zu gehen.

 

[MQue]

5.1 Hibernate und Spring: Auszug aus Kapitel 5 Integration anderer Technologien aus dem Buch Hibernate
kurze Leseprobe

The Spring series, Part 2: When Hibernate meets Spring

Spring macht hauptsächlich das DI für Hibernate Klassen

den 2. Link hätte ich schon durchgemacht bis "and Cloudscape before continuing. After downloading C..." -> das Cloudscape - den Link gibts nämlich nicht mehr.
vielen Dank,
lg

 

[MQue]

Morgen,

hätte noch eine Frage zu Spring, ich habe momentan 5 Anbindungen (also 5 Klassen ohne darüberliegendes Interface) von externen Geräten (Steuerungen) an mein Programm (Seriell, TCP, DDE, Modbus, OPC).
Ich brauche aber nicht für jeden Kunden alle 5 sondern nur z.B.: TCP (werd ich am öftesten benötigen),
Ich habs momentan (ohne Spring sondern eine ganz normale Java- Applikation) so realisiert, das ich in einer Konfig- Datei einfach reinschreib, welche Verbindung ich benötige (z.B.: tcp) und erzeuge mir dann eben ein Objekt dieser Klasse, den anderen Code für die serielle, DDE, Modbus, OPC - Schnittstelle brauche ich z.B.: für diese konkrete Anwendung nicht, dieser Code ist in meiner jetzigen Realisierung aber auch dabei -> also toter Code

kann ich es mit Spring irgendwie lösen, das ich meine Anwendung starte und dann die Module, die ich brauche wie z.B.: TCP, irgendwie in meine Applikation hineinwerfe?
Ist das möglich oder wie könnte ich es elegant realisieren, dass in einer Applkation nur der Code drinnen ist, der wirklich benötigt wird?

lg

 

[Noctarius]

Eine Propertiesdatei benutzen, die Module da eintragen und ob sie aktiviert werden sollen oder nicht und dann mit Dependency Injection die "Instanzen" der Module in deine Anwendung injecten lassen.

 

[MQue]

Eine Propertiesdatei benutzen, die Module da eintragen und ob sie aktiviert werden sollen oder nicht und dann mit Dependency Injection die "Instanzen" der Module in deine Anwendung injecten lassen.

Das heißt aber auch, dass der Code in meiner Anwendung drinnen bleiben muss auch von den Schnittstellen, die ich nicht benötige, oder ? Gebe es in diese Richtung vielleicht auch eine Möglichkeit, wie ich gemeint habe, einfach Komponenten ins Programm werfen?

Vielen Dank,
lg

 

[maki]

Das heißt aber auch, dass der Code in meiner Anwendung drinnen bleiben muss auch von den Schnittstellen, die ich nicht benötige, oder ? Gebe es in diese Richtung vielleicht auch eine Möglichkeit, wie ich gemeint habe, einfach Komponenten ins Programm werfen?

Sagt dir der Begriff "Application Context" schon etwas?
Du definierst doch deine Beans, da kannst du dann auch welche weglassen die du nicht brauchst...

Lässt sich doch gut konfigurieren mit Ant oder Maven2, ausserdem bietet doch Spring selbst schon Unterstützung für verschiedene Konfigurationen.

 

[ARadauer]

ich kann ja mit spring in einer swing anwendung, einfach spring beans als service über rmi einbinden. Diese Services können dann in meinen mit Daos über Hibernate auf die Datenbank gehen.

Bin gerade dabei, dass ich sowas plane. Welchen Vorteil oder welche Funktion hat in so einer Konfiguration noch ein Tomcat Server?

 

[Noctarius]

Mit RMI meinst du vermutlich Spring Remoting?

"Diese Services können dann in meinen mit Daos über Hibernate auf die Datenbank gehen." <- Den Satz versteh ich Deutsch-Technisch nicht xD

"Welchen Vorteil oder welche Funktion hat in so einer Konfiguration noch ein Tomcat Server? " <- Auf Client- oder auf Serverseite?

Was genau hast du denn vor?

 

[ARadauer]

Das geht mit dem Spring Framework sehr komfortabel. Du legst ein "Servlet Projekt" an, dort implementierst Du Deine Services (Schnittstelle zwischen Client und Server) als POJOs. Die Services könnten über DAOs mit einer DB kommunizieren.

Diese Services kannst Du dann über einfache Servlets verfügbar machen. Das funktioniert so, dass du ein DispatcherServlet in der web.xml definierst, dass alle Aufrufe an die entsprechenden Service-Objekte delegiert. Das konfigurierst Du dann entsprechend mit Spring.

Seitens des Rich Clients kannst Du dann mit Hilfe von Apache HttpClient mit dem Server kommunizieren. Das lässt sich mit ein paar Zeilen Code konfigurieren (siehe Spring HTTPInvoker).


Es ist ohne weiteres möglich, parallel dazu einen Webclient zu schreiben, wo mit Hilfe der o.g. Services z.B. JSPs oder dergleichen generiert werden.

Das hab ich ungefähr vor. Meine Frage (hoffentlich etwas verständlicher : kann ich mir den Tomcat sparen, wenn ich Spring Remoting (RMI) einsetze? bzw welche Vorteile würde mir ein Tomcat bringe?

 

[Noctarius]

Ich würde dir folgende Kombination vorschlagen:
Tomcat -> Spring WS (WebService) -> WebService POJO mit @WebService Annotation -> darauf über Spring Remoting zugreifen

Der Vorteil: Tomcat in Verbindung mit dem Spring WS nimmt dir den gesamten Unterbau ab

 

[byte]

Das hab ich ungefähr vor. Meine Frage (hoffentlich etwas verständlicher : kann ich mir den Tomcat sparen, wenn ich Spring Remoting (RMI) einsetze? bzw welche Vorteile würde mir ein Tomcat bringe?

Es gibt verschiedene Implementierungen für Spring Remoting, u.a. auch eine für RMI. In diesem Fall brauchst Du dann keinen Tomcat. Spring würde dann einfach eine rmiregistry starten, die dann laufen bleibt und auf Anfragen horcht (genauso wie es bei Plain RMI der Fall wäre).
Der Vorteil eines Tomcats wäre, dass Du Kommunikation über HTTP und somit weniger Probleme mit Firewalls hast. Ausserdem kannst Du halt alle Vorteile eines Webcontainers nutzen.

Ich würde dir folgende Kombination vorschlagen:
Tomcat -> Spring WS (WebService) -> WebService POJO mit @WebService Annotation -> darauf über Spring Remoting zugreifen

Der Vorteil: Tomcat in Verbindung mit dem Spring WS nimmt dir den gesamten Unterbau ab

Finde diese Antwort etwas pauschal. Webservices sind wegen des SOAP Marshallings deutlich langsamer als bsp. HTTPInvoker oder auch RMI. Wenn Du eh nur eine Java-to-Java Kommunikation hast, dann wüsste ich nicht, warum man Webservices benutzen sollte.
Hatte kürzlich mal Performance Tests zw. HTTPInovker und Webservices (Apache CXF) gemacht mit einem Objektgraphen der Tiefe 6. Aufrufe des Webservice waren um den Faktor 70 langsamer als Aufrufe über HTTPInvoker. Ausserdem wurde wesentlich mehr Heapspace beansprucht auf beiden Seiten.

 

[Noctarius]

Finde diese Antwort etwas pauschal. Webservices sind wegen des SOAP Marshallings deutlich langsamer als bsp. HTTPInvoker oder auch RMI. Wenn Du eh nur eine Java-to-Java Kommunikation hast, dann wüsste ich nicht, warum man Webservices benutzen sollte.

Weil die Anforderungen immer mit den Möglichkeiten wachsen. Wir sind hier gerade dabei ein, über die Jahre, organisch gewachsenes System von Grund auf neu zu implementieren. Viele Sachen könnten wir uns jetzt sparen wenn wir (bzw. meine Vorgänger) damals nicht nach der selben Art gedacht hätten. Bei Zeit unkritischen Aufgaben würde ich nach Erfahrung immer generischer Arbeiten, schließlich weißt du nie was mal für Systeme angebunden werden müssen. Und ein ESB ist auch nicht immer die Lösung nachträglich.

Hatte kürzlich mal Performance Tests zw. HTTPInovker und Webservices (Apache CXF) gemacht mit einem Objektgraphen der Tiefe 6. Aufrufe des Webservice waren um den Faktor 70 langsamer als Aufrufe über HTTPInvoker. Ausserdem wurde wesentlich mehr Heapspace beansprucht auf beiden Seiten.

HTTPInvoker serealisiert die Objekte auch, nur sind die XML Daten mit mehr Aufwand beim Zusammenbauen verbunden und brauchen unheimlich viel Overhead.

Abgesehen davon ist ein WebService nicht zwangsweise eine SOAP Nachricht. Ein WebService ist grundlegend eine Schnittstelle zum Zugriff auf entfernte Systeme. Auch JMS Kommunikationen können theoretisch als WebService tituliert werden. Und Spring WS bzw CXF brauchen nicht zwangsweise SOAP zur Kommunikation.

Von RMI würde ich grundsätzlich abraten, sobald die Verbindung das traute Heim der Firma verlässt, da die Verbindung unverschlüsselt abläuft und RMI nicht mit Proxysystem klarkommt. Willst du eine RMI Technik einsetzen dann benutze SIMON (tuxedo weist dir den Weg ).

 

[byte]

In diesem Fall gings ja um eine 3-Schicht-Architektur mit Richclient. Mir persönlich wärs da nicht egal, ob ein Servicecall 50ms oder 3000ms dauert.

Aber das schöne bei Spring ist ja, dass man das alles mehr oder weniger konfiguriert. Wir haben in unserem Projekt jetzt Services per HTTPInvoker mit unserem Richclient verbunden. Wenn mal ein weiteres System dazukommt, dass HTTPInvoker nicht versteht (weil es z.b. gar keine Java-Anwendung ist), dann können wir problemlos einen Webservice nachliefern, der die nötigen Daten per SOAP oder was auch immer liefert.

Ich sehe keine Notwendigkeit, perse alles mit Webservices zu machen, nur weil sich Anforderungen ändern können.

 

[Noctarius]

Naja HTTPInvoker ist doch perse auch nur eine Konfiguration einer mit @WebService annotierten Klasse

 

[byte]

Es war schon deutlich mehr Aufwand, das ganze mit Apache CXF zum Laufen zu bekommen als beim reinen HttpInvoker. Aber im Grunde hast Du recht, es ist nur ne Frage der Konfiguration.

Wobei es noch eine Sache gibt, die mit CXF partou nicht laufen wollte, und zwar zyklische Referenzierung (z.B. bei bidirektionalen Parent-Child Referenzen)! Aber ich bin auch kein Experte, was Webservices angeht...

 

[Noctarius]

Puh dazu hätte ich spontan auch keine Idee, da WebServices meist versucht werden stateless zu halten. Übrigens ein weiteres schönes Beispiel für WebServices ohne SOAP ist ein REST-Service

 

[byte]

Die Webservices sind ja Stateless. Die Referenzierung bezieht sich ja auf die zu übertragenden Daten. Apache CXF kommt offenbar beim Marshalling / Unmarshalling nicht mit Zyklen zurecht.

 

[Noctarius]

Hm dann glaub ich versteh ich gerade nicht auf was du hinaus willst Manchmal fehlt doch das Wissen vom Studium