Ja, das hatte ich mir fast gedacht, denn prinzipiell dürfte es einem Server ja egal sein woher er sein HTTP Request bekommt (egal ob Browser oder sonst was) solange, das Request korrekt aufgebaut ist, oder? Andere Client Server Architekturen kommunizieren ja auch über HTTP.
Falls ihr wirklich Client / Server macht, solltet ihr euch das Transportprotokoll gut überlegen. HTTP ist gut und verlässlich aber auch recht langsam. Denkbar wären z.B. auch RMI (sauschnell, aber evtl Portprobleme, je nachdem auf welchen Maschinen eure CLients laufen - Stichwort: beim Kunden, oder bei euch), Hessian, Burlap usw.
Dazu fallen mir nur zwei Sachen ein: "Nicht meine Idee" und "Buzzword-Bingo".
Gut, das kenn ich auch. Allerdings sollte man auf sowas keine Architekturentscheidungen aufbauen.
Das mit dem Server könnte durchaus noch relevant sein (unabhängig von der Transaktionaliät), da zudem der Gedanke im Raum steht aus dem Fat-Client einen Thin-Client zu machen und die einen Großteil der Logik in den Server zu verlagern.
Das macht je nach Anwendung Sinn. Allerdings kommt dann das Thema "Performance über die Leitung" zum tragen. Zu viele feingranulare Calls killen jede Performance, so dass man meist recht grobe Aufrufe macht. Dann bist du aber fast wieder bei einer Webanwendung. Desweiteren sollte man dann nen gutes Cachingkonzept haben.
Aber wie würd ich dann ohne Beans etc mit einem Tomcat Transaktionalität erreichen können? Hast du ein paar Stichworte oder was anderes für mich, dass mir da weiterhelfen könnte?
Wie ich ja schon sagte, hat Transaktionalität ja grundsätzlich erstmal nichts mit der Plattform zu tun. Das Connection Interface bietet ja erstmal alles was du brauchst um Transaktionen zu fahren. Da der geneigte Javaentwickler allerdings ungern auf Händen und Knien durch den Schlamm kriecht, gibt es da Frameworks bzw. Standards. EJB bringt sowas als Dienst mit - das hattest du ja schon erwähnt. Allerdings braucht nicht jede Javaanwendung (im Grunde genommen brauchen ihn vielleich 10% der Javaanwendungen) einen Applicationserver, den EJB vorraussetzt (genau genommen ja nur einen EJB container, aber den gibt es fast nur innerhalb eines AS).
Die Alternative ist halt der Einsatz von Spring und dessen Transaktionsabstraktion. Damit kannst du auf verschiedene Arten und Weisen Transaktionalität KONFIGURIEREN. Zum einen gibt es (sehr stark vereinfacht) die Möglichkeit zu sagen: Alle Methoden der Klassen aus dem package foo.bar die mit *Service enden sollen Transaktional sein. Alle Methoden, die mit get* anfangen sollen zusätzlich das ReadOnly Flag bekommen. Damit brauchst du nichtmal den Geschäftscode anfassen, vorrausgesetzt, es lässt sich mit endlchem Aufwand so ein "Pattern" ermitteln. Wenn man allerdings nicht mit dieser Art Transaktionssteuerung gerechnet hat, geht das oft nicht.
Die andere Variante das mit Spring zu konfigurieren sind Annotations. @Transactional an die Methoden, die Transaktional sein sollen und der Laden läuft (ein wenig Infrastruktursetup (DataSource, TransactionManager)) kommt natürlich noch dazu.
Der Clou an der Sache ist, dass dieses Konfigurationsmodell unabhängig von der Plattform ist - sprich, du wirfst das Projekt als WAR in nen Tomcat und es tut. Du wirfst das Projekt als EAR in einen JBoss und es tut.
Nähere Informationen zum Transaktionshandling mit Spring gibt es
hier. Ich hab dir unten noch den Beispielcode einer Springdemo angehängt die ich hier vor kurzem gehalten hab. Ein Server mit verschiedenen Clients die über RMI kommunizieren (wobei das Protokoll recht leicht austauschbar ist). Zur Verdeutlichung der Transaktionalität findest du in SpringServer ein transactions.xml. Das ist der komplette Konfigurationscode für den Server.
Gruß
Ollie
