# Application Server



## MQue (23. Jun 2009)

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 (23. Jun 2009)

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


----------



## MQue (23. Jun 2009)

maki hat gesagt.:


> 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 (23. Jun 2009)

Michael1234 hat gesagt.:


> 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 (23. Jun 2009)

> 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 (23. Jun 2009)

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 (23. Jun 2009)

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 (23. Jun 2009)

Noctarius hat gesagt.:


> 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 (23. Jun 2009)

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 (23. Jun 2009)

maki hat gesagt.:


> 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 (23. Jun 2009)

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 (23. Jun 2009)

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 (23. Jun 2009)

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 (23. Jun 2009)

byto hat gesagt.:


> 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 (24. Jun 2009)

Noctarius hat gesagt.:


> 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 (24. Jun 2009)

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 (24. Jun 2009)

byto hat gesagt.:


> 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 (24. Jun 2009)

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 (24. Jun 2009)

Michael1234 hat gesagt.:


> 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 (24. Jun 2009)

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 (24. Jun 2009)

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 (24. Jun 2009)

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


----------



## Noctarius (24. Jun 2009)

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 (24. Jun 2009)

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


----------



## Noctarius (24. Jun 2009)

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


----------



## MQue (25. Jun 2009)

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 (25. Jun 2009)

Deine Webapp braucht die jars, sonst nix.


----------



## Noctarius (25. Jun 2009)

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 (25. Jun 2009)

Michael1234 hat gesagt.:


> 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?
> 
> ...



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 (25. Jun 2009)

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 (25. Jun 2009)

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 (25. Jun 2009)

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 (25. Jun 2009)

Michael1234 hat gesagt.:


> 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.:
> ...



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 (25. Jun 2009)

Noctarius hat gesagt.:


> 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
> ...



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 (26. Jun 2009)

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 (26. Jun 2009)

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 (26. Jun 2009)

Noctarius hat gesagt.:


> 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 (26. Jun 2009)

> 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 (14. Jul 2009)

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 (14. Jul 2009)

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 (14. Jul 2009)

byto hat gesagt.:


> 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.
> 
> ...



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 (14. Jul 2009)

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 (14. Jul 2009)

ARadauer hat gesagt.:


> 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.



Noctarius hat gesagt.:


> 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 (14. Jul 2009)

byto hat gesagt.:


> 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.



byto hat gesagt.:


> 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 (14. Jul 2009)

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 (14. Jul 2009)

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


----------



## byte (14. Jul 2009)

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 (14. Jul 2009)

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 (14. Jul 2009)

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 (14. Jul 2009)

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


----------



## ARadauer (14. Jul 2009)

hab ich das richtig verstanden, dass wenn ich spring remoting einsetze und http-invoker oder hessian verwenden weill, dass ich dann einen servlet container auf der server seite brauche, bei rmi kann ich mir den sparen, oder?


----------



## byte (14. Jul 2009)

Noctarius hat gesagt.:


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



Du schreibst einen Webservice. Dieser Webservice liefert Daten, z.B. ein Objekt A. Dieses Objekt A hat eine Referenz auf ein Objekt B, das wiederum eine Rückreferenz auf das A-Objekt hat (also eine zyklische Referenzierung). Beim Serialisieren nach XML (das Format ist ja in der WSDL beschrieben) knallts nun, weil CXF diesen Zyklus nicht auflösen kann. Zumindest habe ich bisher keine Lösung dafür gefunden. Wenn jemand weiss, wie es geht, immer her damit. 



ARadauer hat gesagt.:


> hab ich das richtig verstanden, dass wenn ich spring remoting einsetze und http-invoker oder hessian verwenden weill, dass ich dann einen servlet container auf der server seite brauche, bei rmi kann ich mir den sparen, oder?



Du hast es richtig verstanden. Wenn Du keinen Servlet Container benutzen willst, dann kannst Du ohne weiteres Spring Remoting mit RMI benutzen. Dann ist Dein Server im Grunde nur eine Main Methode, die den Spring ApplicationContext initialisiert. Spring startet daraufhin (völlig transparent) die RMI Registry und stellt somit die Spring Beans als Remote Services über RMI bereit.


----------



## Noctarius (14. Jul 2009)

byto hat gesagt.:


> Du schreibst einen Webservice. Dieser Webservice liefert Daten, z.B. ein Objekt A. Dieses Objekt A hat eine Referenz auf ein Objekt B, das wiederum eine Rückreferenz auf das A-Objekt hat (also eine zyklische Referenzierung). Beim Serialisieren nach XML (das Format ist ja in der WSDL beschrieben) knallts nun, weil CXF diesen Zyklus nicht auflösen kann. Zumindest habe ich bisher keine Lösung dafür gefunden. Wenn jemand weiss, wie es geht, immer her damit.



Ok dann hatte ich doch verstanden was du meinst  Aber den Fall brauchte ich trotzdem noch nicht, da bei SOAP normal TransferObjects "serialisiert" werden, eben anders als bei RMI Techniken (wozu auch HTTP-Invoker gehört).


----------



## byte (15. Jul 2009)

Jo hast Recht, Webservices sind nur für flache Objekte geeignet. Bei tiefen Objektgraphen wirds grottenlangsam.
Aber genau da liegt das Problem für mich, grade wenn man Richclients entwickelt. Wenn ich z.B. eine Baumstruktur im Client darstellen will, dann muss ich einen Objektgraphen/-baum übertragen. Oder ich müsste mir eine flache Struktur aus TransferObjects konstruieren, aus der ich dann auf dem Client wieder die Baumstruktur rekonstruieren könnte. Du kannst es drehen wie Du willst, aber Webservices sind hier einfach extrem lästig.

Die Dinger sind gut, wenn man über Sprachgrenzen hinweg Daten austauschen will. Für alles weitere bevorzuge ich serialisierte Binärdaten.


----------



## Noctarius (15. Jul 2009)

Also wir nutzen einen REST Service (Ausgabe als JSON Datenstruktur) für die Kommunikation unseres Frontends (in ExtJS) mit dem Backend. Wir haben zwar Baumstrukturen die wir darstellen, allerdings sind dies eher Informationen zu einer einzelnen Person, ergo nicht Tonnen an Daten.

Aber ich kann mir vorstellen was du meinst. Wir haben eine Schnittstelle implementiert (des XSD-Schemas der Arbeitsagentur) und wenn ich 200 Stellen auf einmal übertragen (bzw vorher exportieren will) hat das System richtig richtig zu rödeln bis die XML Struktur mit JAXB aufgebaut ist


----------



## ARadauer (15. Jul 2009)

ich hack mich hier nochmal ein... hat jemand von euch schon mal über spring remting mit rmi einen callback realisert?
also ich geb dem server ein objekt mit, der server ruft von diesem objekt eine methode auf und der code läuft dann am client... ginge das? bzw wie ginge das ;-)


----------



## Noctarius (15. Jul 2009)

Mit Spring Remoting noch nicht gemacht aber mit RMI im Allgemeinen:

Je Seite ein Server-Interface:
Client: IClientSideRemote::callback(Object foo)
Server: IServerSideRemote::myMethod(Object bar, IClientSideRemote callback) { ...; callback.callback(foo); }

Dürfte unter Spring halt ähnlich aussehen

edit: hab gerade das hier gefunden, vielleicht ist das was für dich (als Alternative) Sanjiv Jivan's Blog


----------



## byte (15. Jul 2009)

ARadauer hat gesagt.:


> ich hack mich hier nochmal ein... hat jemand von euch schon mal über spring remting mit rmi einen callback realisert?
> also ich geb dem server ein objekt mit, der server ruft von diesem objekt eine methode auf und der code läuft dann am client... ginge das? bzw wie ginge das ;-)



Darüber hat tfa einen Blog Eintrag geschrieben: http://www.java-forum.org/blogs/tfa...g-remoting-mit-remote-methode-invocation.html

Edit Achso Callbacks... hab ich noch nicht gemacht, halte ich aber auch für fragwürdig. Du musst dafür Remote Class Loading verwenden, was bzgl. Sicherheit sehr fragwürdig ist.


----------



## tfa (15. Jul 2009)

Danke für die Werbung, aber ARadauer möchte Callbacks, und davon schreibe ich nichts.
Würde mich aber auch interessieren, wie das funktioniert.


----------



## Noctarius (15. Jul 2009)

byto hat gesagt.:


> Darüber hat tfa einen Blog Eintrag geschrieben: http://www.java-forum.org/blogs/tfa...g-remoting-mit-remote-methode-invocation.html
> 
> Edit Achso Callbacks... hab ich noch nicht gemacht, halte ich aber auch für fragwürdig. Du musst dafür Remote Class Loading verwenden, was bzgl. Sicherheit sehr fragwürdig ist.



Nicht zwangsweise wenn beide Klassen die selbe SerialVersionId besitzen sollte das Callback auch sauber serialisiert / deserialisiert werden können.

ps: Hab den beitrag oben nacheditiert


----------



## ARadauer (15. Jul 2009)

Noctarius hat gesagt.:


> edit: hab gerade das hier gefunden, vielleicht ist das was für dich (als Alternative) Sanjiv Jivan's Blog



lingo? ach ich weiß nicht, noch eine framework? ich möcht mich jetzt nicht zu weit in unbeaknnte gebiete begeben...

den blog eintrag von tfa hab ich schon mal gesehen, aber ich habs vorher schon mal getestet, ich hab dieses Spring und Hibernate buch. da wird das auch ganz nett erklärt...

anscheinend sind callbacks über spring remoting nicht gang und gäbe... mal schaun ob es sich trotzdem realiseren lässt


----------



## Noctarius (15. Jul 2009)

lingo scheint praktisch nur eine Implementierung für Spring Remote zu sein, genau wie RMI


----------

