JBoss ja oder nein?

Derzeit beschäftigt mich die Frage, ob man nun für die Webentwicklung mit Java nurn Web-Server nehmen sollte, oder diesen lieber in ne Application Server, wie zb. JBoss integrieren sollte. Ich wurde oft in irgendwelchen Literaturen drauf aufmerksam, dass man dies als Quasi-Standard nimmt und nicht nur ein Servlet-Container ala Tomcat, Jetty etc. nutzt.
Nur was ich nciht richtig verstehe ist eigentlich der sinn des Ganzen. Was bringt mir ein Application Server fürn Vorteil gegenüber normalen Servlet Containern? JNDI zb. ist auch im Tomcat verfügbar. JMX soll toll sein, wenn man wüsste, wozu man dies nützen könnte (ich weiß es net ).
Also kann mir einer sagen, was es denn für einen Vorteil gegenüber der abgespeckten Version hat und ob sich dies überhaupt für ein Browsergame lohnt, so ein Monsterpaket im Hintergrund zu haben? Ok das schöne am JBoss ist natürlich das Hot-Deploy, was aber sicher nicht ein Grund für mich ist, dass ich sowas drunter schalte. Für mich hat so ein Application Server im ersten Blick nurn Performanceverlust zur Folge, weil man ja noch mehr Zeugs im Hintergrund aktiv hat, was auch irgendwo Speicher und dementsprechend Leistung kostet. Auch wurde in einem Hibernate-Buch schon fast von JBoss geschwärmt. Gibts da denn erkennbare Unterschiede, ob ich Hibernate in nem Container ala. Tomcat laufen lasse, oder dies in nen Application Server integriere? Und EJB3 wollte ich eigentlich auch nicht nutzen, da dies ja nicht gerade das Performanteste sein soll.
Könnt ihr mir Vor- und Nachteile nennen?

Ich habe mir nur mal zeitweise die Möglichkeiten von derartigen Rundumpaketen angeschaut und ich würde dringend davon abraten, diese zu verwenden. Produkte wie JBoss sind eindeutig für den Einsatz in Geschäftsapplikationen gedacht, nicht für den Einsatz als Spieleplattform. Für deine Zwecke (obwohl ich nicht weiß, welche Art von Spiel du entwickeln willst), reicht ein Jetty oder ein Tomcat vollkommen aus. Irgendwelche großen Security- und Rollensysteme, Message-Services, SOAP-Unterstützung und was es nicht alles gibt bringt einem vorallem eines: Unmengen von Overhead.
Also ist meine Meinung...kann sein, dass das ein "gelernter" anders sieht

JBoss wird dir vermutlich gar nichts nutzen, solange Du kein EJB, JMS oder ähnliches nutzen willst. Und als "Servlet-Container" nutzt JBoss ja auch nichts anderes als Tomcat, wobei es sich dabei scheinbar um eine angepasste Version handelt.

Naja ich würde ja ein Teil von EJB auch nutzen. Aber nur die Annotation, um Hibernate die Metadaten zu geben.
Wie siehts so mit Caching und Clustering aus? Ich hab mich mit dem Zeugs noch net auseinander gesetzt, aber kann das auch schon nen Container? Auch schreiben die hier in der Hibernate-Lektüre, dass Hibernate die Transaction-Engine von JBoss nutzt und nicht das JDBC-Zeugs, was nicht so sicher sein soll (???).
Mein Problem ist nun, ob ich nun EJB oder Hibernate nutzen soll (im Endeffekt nehmen se sich ja nicht wirklich viel, was die Arbeitsweise angeht) oder lieber ganz auf den Application Server zu verzichten. Ok im Endeffekt könnte man am Ende eh probieren, ob es sich lohnen würde.
Naja JMS find ich bei ner normalen Webapplikation nicht wirklich zwingend oder erforderlich. Vielleicht hab ich mir gerade ne eigene Struktur im Kopf gebildet und lasse dann solche Sachen nicht zu. Ich lasse mich aber gerne belehren
Jo das der nichts anderes als Tomcat nutzt (ok mein JBoss läuft derzeit mit Jetty, was ja aber ne Entscheidung eines jeden selbst ist), aber es geht ja auch eher um das Zeugs, was halt eben nicht die Servlets betrifft. Da gibts ja auch noch ne Menge hinten dran, was man da noch in einer Application hat.

Also die Transaktionen in EJB sind die Pest. Transaktionen werden auf Methodenbasis in den Session-Beans gehandhabt. Sprich in der default-Einstellung macht jede Methode eine Transaktion auf. Das kann man zwar steuern, aber der Scope bleibt auf Methodenebene. Und das hat ein paar sehr unangenehme Nebenwirkungen. Eine Transaktion wird commited, wenn die Methode verlassen wird. Dies sorgt in aller Regel dafür, dass die Exception erst in der View-Schicht abgefangen werden kann. Total dämlich.
Was JMS betrifft, gebe ich Dir recht, dass es im BG Bereich vermutlich wenig Anwendungsfälle dafür gibt. Ausser man möchte Unzulänglichkeiten von EJB ausgleichen. So ist es in EJB z.B. nicht erlaubt java.io zu verwenden. Wenn man das braucht, z.B. für Logging, muss man Mechanismen des Containers nutzen, und ist damit abhängig vom AppServer und kann nicht mehr so leicht wechseln, oder man löst so etwas über JMS.
Was an EJB wirklich schon ist, sind die Callback und Interception Mechanismen, die man bei BGs vermutlich gut gebrauchen kann und ein schöne Anwendungsarchitektur ermöglichen.

Original von AgmemonWas an EJB wirklich schon ist, sind die Callback und Interception Mechanismen, die man bei BGs vermutlich gut gebrauchen kann und ein schöne Anwendungsarchitektur ermöglichen.

Das bekommt man aber auch selbst ganz gut hin
EJB halte ich aber wirklich für nicht geeignet, wenn man ein Spiel entwickeln will. Viel zu Aufwändig, viel zu schwergewichtig. Und ich glaube nicht, dass mein Bild da ganz falsch ist.

Lass die Finger von JBoss
Das Ding ist wirklich der ultimative Overhead fuer BG's.
Von Hibernate und JBoss als "Dreamteam" wird uebrigens geschwaermt, weil beide Produkte der gleichen Firma gehoeren und entsprechend verheiratet wurden

Gut ihr beruhigt mich. Ich hatte schon gedacht ich hab irgendwas verpasst und muss noch schnell auf den Zug aufspringen
Hmm ok das die von der gleichen Firma sind hab ich garnicht mitbekommen. Das erklärt dann einiges.

Ich würde inzwischen auch von Hibernate dringend abraten. Mein Spiel basiert darauf, und während ich anfangs total begeistert ware, stellt sich jetzt eher Ernüchterung ein. Eine SQL-Datenbank für ein Spiel zu verwenden stellt ja eigentlich an sich schon Vergewaltigung dar (zumindest wenn das Spiel etwas komplexer ist). Wenn man dann noch Hibernate verwendet und nicht unmengen von Zeit in die Optimierung steckt, dann kann man den Queries bei der Ausführung zusehen. Also rein von der Performance her ist Hibernate eher am unteren Ende der Fahnenstange angesiedelt. Was ich derzeit konstant im Auge behalte sind Objekt-Datenbanken, insbesondere db4o. Hab mal einige kurze Tests geschrieben und die Performance ist schon klasse. Aber ist es eine ganz andere Programmier- und Arbeitsweise.

Vorneweg: Ich habe keine Ahnung.
Aber.. was ist das schlimme an einer SQL-Datenbank? Und werden die Queries bei Hibernate nicht optimiert und die Objekte selber nicht gecached? Wird daraus nicht auch ein Geschwindigkeitsvorteil? Weil, rein theoretisch (ohne diese Dinger) ist Hibernate und Co (anderer Sprachen) auf jeden Fall ein Performancedefizit, dafür muss man sich aber nichtmal eine Logfile angucken. Da reicht doch (Informatiker)-Menschenverstand.

Original von Lunikon
Was ich derzeit konstant im Auge behalte sind Objekt-Datenbanken, insbesondere db4o. Hab mal einige kurze Tests geschrieben und die Performance ist schon klasse. Aber ist es eine ganz andere Programmier- und Arbeitsweise.

db4o wäre optimal, wenn es nicht unter GPL steht und somit nicht wirklich für ein Spiel, was nicht Open Source sein will, geeignet ist. Deswegen bin ich ja gerade bei Hibernate, weil ich kein Bock hab mir meine DAOs selber zu schreiben, weil es halt bei einem komplexen Spiel, schonmal ne Lebensaufgabe werden kann.

Aber.. was ist das schlimme an einer SQL-Datenbank?
Für Java-Applikationen ists schon nicht das Wahre. Man muss ja die Objekte immer in ne relationale Form bringen. Nachteil einer Objektdatenbank ala db4o ist aber, dass man die Daten nicht in anderen Programmen nutzen kann, wenn es nicht Java ist.
edit: heir mal nen Performancevergleich: polepos.sourceforge.net/results/PolePosition.pdf
Natürlich nicht allgemeingültig und HSQLDB ist ja meiner Meinung nach für ein Projekt, wie ein Spiel nicht geeignet. Ich würds eher für ein portables Systrem nutzen.

Da steht aber auf der Seite, das HSQLDB fast immer gut abschneidet - wenn das schon der Test(h)ersteller schreibt..
Das es da soviel anderes gibt, war mir noch gar nicht bewusst. Hatte eigentlich Hibernate für ne schöne Sache gehalten, selber damit aber noch nichts getan.
Problem wäre aber definitiv, das man sich dann auf Java festgenagelt hat, man kann dann keine "fremden" Sprachen verwenden, oder?

Ich weiß nun nicht, obs für HSQLDB nen Connector allgemeinen Connector für andere Sprachen gibt, aber die DB wird sicher meist in Java-Projekten genutzt, weil se ja selber in Java geschrieben ist (db4o geht auch nur noch in .NET)
Also ich sehe gerade es gibt auch für C# nen Framework, die an HSQLDB verbinden kann, aber es gibt auch so nen Nachbau.
Zu den Testergebnissen: Ich glaub dieser ganzen Sache noch nicht. Vielleicht bin ich dann auch einfach zuviel von dem derzeitigen DB-Gedanke geblendet. Aber ich sehe es nicht so als sinnvoll an, dass ein DBMS seine Tabellen komplett in den Speicher pumpt und dann dort damit arbeitet. Ich könnt mich nun auch Irren, aber normale "bekannte" DBMS hauen nicht alles in den Speicher, sondern laden auch mal Sachen nach.
Ich hoffe es kommt in nächster Zukunft mal ne alternative zu db4o, wo man sich net auf eine Lizens festnageln muss. Objektdatenbanken gibts noch net wirklich viele - leider.
Aber seien wir mal ehrlich. Ob man im Hintergrund, was der User ja nicht mitbekommen wird, eine Datenbank nutzt, die unter GPL steht, sollte doch wohl nicht so schnell auffallen. Ich find nun zwar den Preis nicht mehr für ne kommerzielle db4o Lizens, aber die war auch nciht gerade locker zu bezahlen

Ach nochn Nachtrag zu db4o: Der wirkliche Vorteil dieses System ist in meinen Augen die native Query-Engine. Eine Anfrage an den Server zu schreiben, indem man die verwendete Programmiersprache nimmt, ist für mich ein imminenser Vorteil....wenn die DB nicht unter GPL laufen würde.
edit: typo -.-

Original von Lunikon
Was ich derzeit konstant im Auge behalte sind Objekt-Datenbanken, insbesondere db4o.

Habe ich mir auch schon angesehen. Ist wunderbar, aber die Lizenz fuer nicht GPL-Software liegt bei min. 199 Dollar
Willst du Replikation oder gar Netzwerkfaehifkeit (lassen sich beide aber recht einfach manuell realisieren), geht der Preis auf ueber 1.300 Dollar pro Lizenz. Hatte vor Wochen mal ne Anfrage gestellt und nen Angebot von denen bekommen.
Verwendest du db4o musst du dein Spiel veroeffentlichen oder zahlen. Ein Geheimhalten der DB im Hintergrund und damit Unlizenziertes Nutzen der Software kann dich mehr kosten als du auf dem Konto hast. Mal ganz davon abgesehen, dass sowas unterste Schublade ist. So teuer sind die Lizenzen jetzt auch wieder nicht: das neue Office kostest mehr!
Und ja, Objektdatenbanken sind natuerlich besser als Wrapper. Wobei Oracle TopLink recht flott unterwegs ist (im Vergleich zu Hibernate).

Ich hab ja nicht gesagt, dass man es machen soll Sonst würd ich ja schon db4o nutzen Na ok 199 Dollar (Sarkasmus: Da kann man nur hoffen, dass die Immoblilienkrise nochn bissl den Dollar schwächt) ist net die Welt, aber da bekommt man net die Lizens für die Client-Server-Struktur mit oder? Oder zählt das mit in diese Netzwerkfähigkeit rein?

Nee, das is ne eigene Lizenz bzw. eine Erweiterung. Allerdings kannst du dir das auch selbst basteln, hast eben bloss keinen direkten Zugriff auf die Datenbank, sondern musst dir deinen eigenen schreiben und die Daten selbst uebers Netz schicken.
Wer braucht aber schon sowas? Durch Kopieren der (normalerweise) .yap Datei, hast du den gesamten Datenbestand bei dir und kannst lokal arbeiten.

Also ich verstehe diese GPL-Panik nicht. Es besteht ja kein Zwang, das BG ebenfalls unter die GPL zu stellen:
www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
www.gnu.org/licenses/gpl-faq.html#UnreleasedMods
Was die Datenbankfrage betrifft:
Hier herrscht mittlerweile eine Architekturvielfalt, dass man ganz genau gucken sollte, was man macht. Ich habe schon vor bestimmt 10 Jahren mit einer Objektdatenbank gearbeitet. Die hieß Poet oder so ähnlich und war Schweine teurer. Und schon damals hieß es, dass Objektdatenbanken die Zukunft sind. Pustekuchen. Und vor 5 Jahren ging es dann los mit XML-Datenbanken, die die Offenbarung bringen sollten. Da wurde aber auch nichts draus. Relationale Datenbanken und der SQL-Standard sind immer noch der Status Quo und werden es noch lange bleiben.
Wichtig ist bei der Wahl der Datenbank ist, sich anzusehen, für welchen Einsatzzweck sie entwickelt wurden.
Hat man die richtige Datenbank gefunden muss man gucken, welches O/R-Mapping oder O/R-Wrapping für den Anwendungszweck geeignet ist. Ich habe Erfahrung mit EJB/Hibernate, JDO und ActiveRecord und kann sagen, dass es da schon deutliche Unterschiede gibt. Der Auffälligste in meinen Augen ist die zugrunde liegende Sprache. Nämlich ob sie Typisiert ist oder nicht.
So erlebt man bei EJB/Hibernate nämlich schnell, dass man für jedes ResultSet einer Abfrage, die über ein normales SELECT hinaus geht, eine eigene Value-Klasse. Hat man also eine Abfrage, die z.B. SQL-Funktionen, wie count, min, max, usw. verwendet, muss man eine neue Klasse schreiben um das Ergebnis aufzunehmen. Bei dynamisch typisierten Sprachen, wie Ruby mit ActiveRecord, braucht man dies nicht.
Und der dritte Punkt, der im meinen Augen wichtig ist, ist zu sehen, in wie fern ein Caching möglich ist. EJB hält die EntityBeans z.B. in einem Objekt-Pool vor. Oder man setzt auf Lösungen, wie memcached, um einen "echten" Cache vor der Datenbank zu haben.Dazu kommen dann noch sachen, wie "partial Caching" und "page caching" bei denen man bei bestimmten Daten nur sporadisch auf die Datenbank zugreifen muss.
In unserem Projekt setzen wir auf eine MySQL Datenbank mit InnoDB Tabellen, ActiveRecord als O/R Wrapping, nutzen partial und page Caching überall wo es möglich ist und werden später noch memcached vor die Datenbank schalten.

> Also ich verstehe diese GPL-Panik nicht. Es besteht ja kein Zwang, das BG ebenfalls unter die GPL zu stellen:
Beispiel MySQL:
Der C#-MySQL-Connector steht unter der GPL [für den PHP-MySQL-Connector gibt es AFAIK eine Ausnahme]. Möchte man diesen nun in einem BG nutzen (muss man wohl, wenn man MySQL nutzen möchte), so muss man das BG auch _bei Weitergabe_ unter der GPL stellen.
Es sei denn man lädt diesen Connector dynamisch ein und ist in der Lage mit weiteren Connectoren (Microsoft SQL, PostgresSQL, etc) umzugehen.
Gerade bei db4o ist eine ähnlicher Connector schwer zu finden, so dass das eigene Projekt schon als abhängige Softwarekomponente zählt und damit _bei Weitergabe_ unter der GPL fällt.
Daher habe ich entschieden auf keinen Fall GPL-Komponenten zu nutzen, da ich meine Komponenten lizenzieren möchte, wie ich es für richtig halte. Die Möglichkeit zur binären Weitergabe möchte ich mir nicht verbauen.

Also seh ich das richtig, dass wenn ich mein Projekt nicht weitergeben will (ist bestimmt wieder Definition, was darunter zählt) keine Lizens brauche? Oder zählt schon eine Weitergabe, wenn ich es von meinem lokalen Rechner auf einen Server im Internet kopiere?

> Oder zählt schon eine Weitergabe, wenn ich es von meinem lokalen Rechner auf einen Server im Internet kopiere?
Ja, das zählt aber nicht wirklich als 'Weitergabe'. Aber du brauchst nur den Sourcecode bzw die GPL-'Freigabe' an denjenigen zu geben, dem du die Binärdateien bzw den Sourcecode gibst. Also dir.
Wenn _nur du_ dein Projekt mit db4o nutzt, dann bist du nicht davon betroffen und kannst es mit der GPL-Lizenz einsetzen.
Die GPL greift erst bei der Weitergabe an andere Personen.

Kurz zur Lizenz: Ich sehe da auch kein Problem. Ich habe nicht vor, die Software meines BGs zu verkaufen/weiterzugeben, sondern werde sie immer auf den eigenen Server betreiben. Wenn ich sie je weiter gebe, dann habe ich damit ja auch Einnahmen (wäre blöd wenn nicht) und kann dann auch die Kosten für eine Lizenz in die Kalkulation einbeziehen. Trotzdem habe ich vor, rein um das Projekt zu unterstützen, eine Lizenz zu erwerben, sobald meine Spiele kommerziell an den Start gehen.
Was die Wahl der Datenbank betrifft: Stimme da meinen Vorrednern absolut zu. Man muss eben schauen, was man entwickelt und was dafür am besten geeignet ist. Ich sehe die Heimat der relationalen Datenbanken eigentlich eher bei den Geschäftsanwendungen wo eben auch Dinge wichtig sind wie Anwendungsunabhängiger Zugriff auf die Daten oder sowas. Bei einem Spiel wäre sicherlich das effizienteste, einfach alle Daten im Speicher zu haben. Aber diese Daten muss man dann trotzdem sicher speichern. Und da das bei komplexen und großen Objektgrpahen alles andere als einfach ist, wird man so schnell nicht ohne Datenbank auskommen. Hier sehe ich dann eben eher die Objektdatenbank als geeignet an.