Wann braucht man JBoss?

[miketech]

Hi zusammen,

ich hab mal eine ganz simple Frage:

Wann genau brauche ich überhaupt sowas wie JBoss?


JBoss ist ja so ein riesen Monster. In den meisten Projekten ist das doch absolut zu hoch gegriffen, oder? Was sind denn Beispielprojekte, wo sich so ein Riese lohnt? Irgendwas, damit ich mir mal ein Bild davon machen kann.

Bei mir benötigt JBoss jede Menge Speicher. Es muss ja irgendeinen Anwendungsfall geben, wo sich das lohnt

Gruß

Mike

 

[foobar]

Im Gegensatz zum Sun One Applicationserver ist JBoss wirklich ressourcenschonend. Ausserdem kannst du den JBoss auch apspecken indem du nur noch die SAR's lädst die auch wirklich benötigt werden.

 

[RaoulDuke]

JBoss ist ein J2EE Applikations Server. Den kannst du z.B. benutzen wenn du mit EJBs arbeiten willst. Das kann ein Tomcat z.B. erstmal nicht.

 

[HLX]

JBoss...ein Monstrum...dass ich nicht lache! Sieh dir mal Websphere oder den Oracle App Server an. Das sind monstren.

JBoss ist eine "schlanker" frei verfügbarer J2EE-Application-Server. Er eignet sich herrlich zum testen von J2EE-Applikationen (EJB etc.).

Wenn du allerdings nur Servlets/JSP machst reicht natürlich auch ein Tomcat. :wink:

EDIT: oh, RaoulDuke und foobar waren schneller...

 

[miketech]

Hi,

ok Ich weiß dass JBoss ein Applikationsserver ist. Aber es gibt ja auch OpenEJB, wenn ich EJBs benötige. Ich suche nur ein Anwendungsbeispiel, wann ich auf einen Applikationsserver zurückgreife, was ich nicht mit OpenEJB und Tomcat usw. machen kann.

Gruß

Mike

 

[foobar]

Tomcat ist ein Servletcontainer und kein Applicationserver .d.h. du kannst im Tomcat Webapplikationen deployen (Servlets, JSP, etc). J2EE ist aber wesentlich mehr als nur ein paar Servlets. Such mal nach J2EE oder lies dir die Beiträge wie Wikipedia durch.

 

[miketech]

Hi,

jaja das hab ich ja alles schon gemacht. Nur wann braucht man den ganzen Kram denn? Dass ich Clustering brauche ist klar, wenn ich so speicherhungrige Software einsetze

Was mir auch nicht klar ist: Es heißt ASP.NET ist Gegenspieler zu J2EE. Aber für mich ist ASP.NET nur JSF und von mir aus auch Apache Axis. Der ganze andere Krempel ist doch in ASP.NET gar nicht vorhanden.

Gruß

Mike

 

[foobar]

Hier wird schon mal grob erklärt wofür man die einzelnen APis benötigt: http://de.wikipedia.org/wiki/J2EE

 

[miketech]

Hi,

jo ich hab jetzt auch angefangen JBoss @ Work zu lesen. Ein wie ich finde sehr gutes Buch. Es wird Stück um Stück eine Anwendung entwickelt und man sieht, wann sich was lohnt.

Bis jetzt bin ich aber nur soweit, dass noch alles mit Tomcat und Hibernate geht. In meinem Buch kam dann eine Liste, wann sich EJBs überhaupt lohnen und da weiß ich nicht, was dafür Praxisbeispiele sind. Es geht halt zum Beispiel darum, dass man EJBs nur benötigt, wenn man auf eine Datenbank schreibend zugreift, wegen Transaktionen. Ja hm, toll

Gibt es JavaMail und JMS auch außerhalb von JBoss, oder ist das nur mit JBoss möglich?

Ansonsten alles sehr interessant. In dem Buch wird mir auch häufig von EJBs abgeraten Nur, wenn ichs wirklich benötige soll ichs nehmen. Ist nur schwer einzuschätzen finde ich.

Gruß

Mike

 

[bronks]

... Bis jetzt bin ich aber nur soweit, dass noch alles mit Tomcat und Hibernate geht. In meinem Buch kam dann eine Liste, wann sich EJBs überhaupt lohnen und da weiß ich nicht, was dafür Praxisbeispiele sind. Es geht halt zum Beispiel darum, dass man EJBs nur benötigt, wenn man auf eine Datenbank schreibend zugreift, wegen Transaktionen. Ja hm, toll
...
Ansonsten alles sehr interessant. In dem Buch wird mir auch häufig von EJBs abgeraten Nur, wenn ichs wirklich benötige soll ichs nehmen. Ist nur schwer einzuschätzen finde ich.

Auch nur ein kleines Adressbuch, ein Projektmanager ... bla, bla ... und zu allem Überfluss auch mein Vokabeltrainer laufen Client/Server auf einem AS mit EJB und Swing-FrontEnd.

EJB ist eine Spec. Hibernate ist eine von vielen Persistenzmaschinen auf die man EJB draufsetzen kann.

Keine Frage: EJB setzt Maßstäbe. Den JBösslern wäre es nur recht, wenn die leute nur auf dem nackten Hibernate aufsetzen ...

 

[miketech]

Hi,

laut meinem Buch ist EJB aber nicht immer zu empfehlen, wenn man es nicht defintiv braucht. Du hast ein externes Frontend in Swing, ich glaube in solchen Fällen empfiehlt das Buch auch EJB. Aber theoretisch kann ich das ja auch über Apache Axis machen, oder?

Ah, aber Du verbindest Deine Logik mit z.B. Webservices oder? Geht das dann nicht sogar in die Richtung, was JBoss mit Seam versucht zu schaffen?

Benutzt EJB 2.x oder 3.0? Mein Buch verwendet noch 2.x und das soll ja noch recht übel sein

Gruß

Mike

 

[bronks]

laut meinem Buch ist EJB aber nicht immer zu empfehlen, wenn man es nicht defintiv braucht.

Das hört sich an, wie wenn man sich soweit wie es nur geht vor EJB drücken sollte. Ich meine, daß es keinen Grund gibt EJB nicht zu verwenden, wenn sich die Action auf dem Server abspielen soll.

Du hast ein externes Frontend in Swing, ich glaube in solchen Fällen empfiehlt das Buch auch EJB. Aber theoretisch kann ich das ja auch über Apache Axis machen, oder?

Dem Frontend ist das relativ egal und dem Frontendentwickler genauso. EJB spielt auf dem Server und da kann man mit vielen techniken verbinden.

Ah, aber Du verbindest Deine Logik mit z.B. Webservices oder? Geht das dann nicht sogar in die Richtung, was JBoss mit Seam versucht zu schaffen?

Über Seam habe ich mich nicht informiert, da es speziell nur JBoss betrifft, aber ich geh mit RMI drauf.

Benutzt EJB 2.x oder 3.0? Mein Buch verwendet noch 2.x und das soll ja noch recht übel sein

EJB2 und ich finde es nicht übel? Warum sollte es überhaupt übel sein? EJB3 wird sicher mehr Kompatibilität bieten, aber es ist wieder eine Umstellung.

 

[miketech]

laut meinem Buch ist EJB aber nicht immer zu empfehlen, wenn man es nicht defintiv braucht.

Das hört sich an, wie wenn man sich soweit wie es nur geht vor EJB drücken sollte. Ich meine, daß es keinen Grund gibt EJB nicht zu verwenden, wenn sich die Action auf dem Server abspielen soll.

So in etwa ist das in dem Buch beschrieben, ja. Also ich denke mir das halt noch so: Wenn Du für z.B. ein Adressbuch oder ähnliches einen JBoss startest hast Du doch gewaltigen Overhead oder? Also bei mir benötigt JBoss schon einiges an Ram, was ja dann nicht unbedingt sein muss. Für kleine Projekte ist das daher wohl etwas heftig, oder?

Du hast ein externes Frontend in Swing, ich glaube in solchen Fällen empfiehlt das Buch auch EJB. Aber theoretisch kann ich das ja auch über Apache Axis machen, oder?

Dem Frontend ist das relativ egal und dem Frontendentwickler genauso. EJB spielt auf dem Server und da kann man mit vielen techniken verbinden.

Achso. Ich meine mich gelesen zu haben, dass es insbesondere praktisch ist das in JBoss zu machen, weil ich EJBs direkt mit Webservices verbinden kann. Aber soweit bin ich in meinem Buch noch nicht gekommen.

Ah, aber Du verbindest Deine Logik mit z.B. Webservices oder? Geht das dann nicht sogar in die Richtung, was JBoss mit Seam versucht zu schaffen?

Über Seam habe ich mich nicht informiert, da es speziell nur JBoss betrifft, aber ich geh mit RMI drauf.

Ok

Benutzt EJB 2.x oder 3.0? Mein Buch verwendet noch 2.x und das soll ja noch recht übel sein

EJB2 und ich finde es nicht übel? Warum sollte es überhaupt übel sein? EJB3 wird sicher mehr Kompatibilität bieten, aber es ist wieder eine Umstellung.

Naja, bisher kann ich ja nur das Wiedergeben, was ich gehört habe. Eigene Erfahrungen habe ich ja noch keine und bisher wurde EJB 2.x als sehr komplex dargestellt.

In EJB3 wurden ja die XDoclets durch Annotations ersetzt. Ist das noch woanders passiert? Oder hat XDoclet bei der Entwicklung von J2EE immer noch eine sehr entscheidende Bedeutung? Vermutlich ist das nur bei EJBs der Fall gewesen. Von weiteren Änderungen in der Hinsicht habe ich noch nichts gehört.

Keine Frage: EJB setzt Maßstäbe. Den JBösslern wäre es nur recht, wenn die leute nur auf dem nackten Hibernate aufsetzen ...

Wie ist das denn eigentlich zu verstehen?

Gruß

Mike

 

[puddah]

Ich denke man sollte diese Münze von beiden Seiten betrachten. Wie jede andere Technologie auch hat die EJB Spezifikation ihre vorteile und Nachteile. Pauschal zu behaupten, dass eine Lösung immer auf EJB's beruhen sollte kann nur falsch sein. miketech hat völlig recht, wenn er sagt, dass eine so kleine und popelige Anwendung wie ein Adressbuch nicht auf EJB's (auf einem JBoss deployt, um beim Thema zu bleiben) basieren sollte. Das würde über das Ziel hinnaus schießen. Gerade bei sehr komplexen Buisinessanwendungen zeigen die EJB's ihren Vorteil. Hier kann durch den Komponenten Ansatz leicht zusätzliche Funktionalität hinzugefügt werden. Allerdings sollte man die älteren EJB Versionen auch hier vorsichtig nutzen (Stichwort: n+1 SQL Statements).

 

[bronks]

... miketech hat völlig recht, wenn er sagt, dass eine so kleine und popelige Anwendung wie ein Adressbuch nicht auf EJB's (auf einem JBoss deployt, um beim Thema zu bleiben) basieren sollte. Das würde über das Ziel hinnaus schießen.

Warum übers Ziel hinaus? Wo liegt das Problem?

 

[puddah]

Für ein Adressbuch benötigt man keine Verteilung von Komponenten, keine komplexen Transaktionen und keine Abstraktion von EIS Backends. Also frage ich einmal anders herum: Wieso sollte ich in einem solchen Fall ein System einsetzten, dass mir einen Haufen Funktionalität bietet, die ich garnicht brauche? Würde eine kleine Stand Alone Anwendung in diesem Fall nicht völlig ausreichen?

 

[miketech]

Hi,

nun habe ich mein JBoss At Work Buch nahezu durchgelesen und kann wieder was von mir geben

In dem Buch wird beschrieben, wie man z.B. die Business Logik als EJB implementiert und dann via Weboberfläche darauf zugreift. Der Vorteil ist, dass sie dann ohne Probleme auch via Webservices auf die Logik zugreifen konnten.

Wenn man nun das Adressbuch auf dem Server hat und dazu ein Webfrontend und z.B. eine Swing-Anwendung macht das ja Sinn, oder?

Ich weiß nicht, wie man es noch machen kann. Ich fand das Prinzip nur recht einleuchtend, dass man ein Modul (EJB) hat, welches von mehreren anderen Modulen (Web + Webservice) angesprochen werden kann.

Wenn man z.B. keine Webservices benötigt und die Anwendung nicht auf mehrere Rechner verteilen möchte kann man die Logik auch im Servlet unterbringen und sich die EJBs sparen. D.h. dann könnte man auch mit Tomcat arbeiten. Ich weiß nur nicht, wie speicherhungrig Tomcat im Vergleich zu PHP oder so ist.

Gruß

Mike

 

[bronks]

... Würde eine kleine Stand Alone Anwendung in diesem Fall nicht völlig ausreichen?

Na wirklich SUPER! So eine Antwort in einem Board welches "Enterprise Java" heißt. Enterprise ist halt mal Client/Server. Entweder man zieht es enterprisemäßig durch und lutscht dabei den gesamten Patternkatalog von unten nach oben durch oder man bleibt auf etwas Halbem sitzen.

 

[bronks]

... In dem Buch wird beschrieben, wie man z.B. die Business Logik als EJB implementiert und dann via Weboberfläche darauf zugreift. Der Vorteil ist, dass sie dann ohne Probleme auch via Webservices auf die Logik zugreifen konnten.

Wenn man nun das Adressbuch auf dem Server hat und dazu ein Webfrontend und z.B. eine Swing-Anwendung macht das ja Sinn, oder? ...

Es reicht schon, wenn von der SwingGui 2 User an dem Adressbuch arbeiten wollen. Bei EJB laufen Transaktionen automatisch und die Isolation paßt auch, wenn man sich darüber vorher Gedanken gemacht hat. Das ist eine Arbeitserleichterung, die man von EJB geschenkt bekommt.

 

[miketech]

... In dem Buch wird beschrieben, wie man z.B. die Business Logik als EJB implementiert und dann via Weboberfläche darauf zugreift. Der Vorteil ist, dass sie dann ohne Probleme auch via Webservices auf die Logik zugreifen konnten.

Wenn man nun das Adressbuch auf dem Server hat und dazu ein Webfrontend und z.B. eine Swing-Anwendung macht das ja Sinn, oder? ...

Es reicht schon, wenn von der SwingGui 2 User an dem Adressbuch arbeiten wollen. Bei EJB laufen Transaktionen automatisch und die Isolation paßt auch, wenn man sich darüber vorher Gedanken gemacht hat. Das ist eine Arbeitserleichterung, die man von EJB geschenkt bekommt.

Ja, das hab ich auch gelesen. Hatte nicht gedacht, dass das hier auch eine Anforderung an das Adressbuch ist.

Aber das geht ja noch ohne EJBs ganz prima, zumindest was ich bisher gelesen habe. Also das war mir im Buch nicht ganz klar:

Zunächst hat man die Transaktionen manuell eingerichtet. Also jede Datenbank-Operation wurde als Transaktion umgesetzt. Später wurde das ganze zu einem EJB umgebaut, wodurch die manuelle Transaktionskontrolle wegfallen konnte, weil sich JBoss selbst darum kümmert.

Wo genau ist hier der Unterschied: Ist das noch dasselbe, wie vorher? Abgesehen davon, dass ich Code gespart habe, was ja schon nett ist. Oder bietet mir das noch weitere Vorteile, die mit manueller Transaktionskontrolle gar nicht möglich wären?

Gruß

Mike

 

[puddah]

Wo genau ist hier der Unterschied: Ist das noch dasselbe, wie vorher? Abgesehen davon, dass ich Code gespart habe, was ja schon nett ist. Oder bietet mir das noch weitere Vorteile, die mit manueller Transaktionskontrolle gar nicht möglich wären?

So weit ich weiss sind managed transactions genau die selben wie die manuellen via JTA. Der Vorteil ist einfach, dass du die Transaktionen deklarativ angibst und deinen Code nicht mit dem für die Transaktionskontrolle mischen musst.

Na wirklich SUPER! So eine Antwort in einem Board welches "Enterprise Java" heißt. Enterprise ist halt mal Client/Server. Entweder man zieht es enterprisemäßig durch und lutscht dabei den gesamten Patternkatalog von unten nach oben durch oder man bleibt auf etwas Halbem sitzen.

Dann habe ich das ganze hier wohl falsch verstanden. Ich dachte hier geht es um eine generelle Diskussion um die Vor und Nachteile von EJB's bzw Applicationservern und wann man diese einsetzen sollte.

 

[miketech]

Wo genau ist hier der Unterschied: Ist das noch dasselbe, wie vorher? Abgesehen davon, dass ich Code gespart habe, was ja schon nett ist. Oder bietet mir das noch weitere Vorteile, die mit manueller Transaktionskontrolle gar nicht möglich wären?

So weit ich weiss sind managed transactions genau die selben wie die manuellen via JTA. Der Vorteil ist einfach, dass du die Transaktionen deklarativ angibst und deinen Code nicht mit dem für die Transaktionskontrolle mischen musst.

Ok danke.

Na wirklich SUPER! So eine Antwort in einem Board welches "Enterprise Java" heißt. Enterprise ist halt mal Client/Server. Entweder man zieht es enterprisemäßig durch und lutscht dabei den gesamten Patternkatalog von unten nach oben durch oder man bleibt auf etwas Halbem sitzen.

Dann habe ich das ganze hier wohl falsch verstanden. Ich dachte hier geht es um eine generelle Diskussion um die Vor und Nachteile von EJB's bzw Applicationservern und wann man diese einsetzen sollte.

Nene, das passt schon auch Ich freu mich über alle Meinungen hierzu.

Hat denn jemand Erfahrungen mit Tomcat, oder JBoss bzgl. Performance? Läuft das auf einer Kiste wie z.B. 2 GHz mit 512 MB RAM so, dass man das vernünftig nutzen kann für ein Projekt? Oder muss ich dafür mehr Hardware zur Verfügung stellen? Also die Seiten sollten schon genauso schnell dargestellt werden können, wie z.B. bei PHP u.ä.

Gruß

Mike

 

[tec1]

Ich arbeite in einer recht großen Firma (ca. 140 Leute), die Webanwendungen wie diverse Onlinebankenportale, große Shops für Telekommunikationsanbieter und diverse andere Dinge entwickelt. Wir verwenden überhaupt keine EJBs, es geht alles mit struts oder jsf sowie spring und hibernate. Der Tomcat ist bei uns auch der "Applicationsserver" der Wahl, JBoss wird nicht verwendet. EJB's wurden vor einiger Zeit getestet und für ungeeignet befunden, ob sich das mit EJB 3 ändert wird man sehen, wir sind jedenfalls mit Spring und Hibernate sehr zufrieden.

 

[miketech]

Hi,

hm dafür kenn ich nun Struts zu wenig, aber offensichtlich ist das Framework durchaus ausreichend, um solche komplexen Anwendungen aufzusetzen. Transaktionen und was sonst noch so anfällt wird dann wahrscheinlich innerhalb des Frameworks abgewickelt, so dass man auf EJBs verzichten kann. Kann das sein?

Gruß

Mike

 

[Gast]

Struts und JSf sind Webframeworks, das hat mit EJB nihts zu tun. Ejb kannst du eher mit Hibernate und Spring vergleichen.

 

[puddah]

Mit der neuen Persistence API sind die EJB's (genauer gesagt die Entity Beans) sehr Hibernate like. Im Grunde genommen ist EJB3 nur eine allgemeinere Spezifikation der Technik, die bei Hibernate eingesetzt wird. Das ist allein schon daran zu erkennen, dass die EJB3 Implementierung von JBoss direkt auf Hibernate aufsetzt. Ansich ne tolle Sache auf jeden Fall schöner als die 2.1 Version.

 

[bronks]

Mit der neuen Persistence API sind die EJB's (genauer gesagt die Entity Beans) sehr Hibernate like. Im Grunde genommen ist EJB3 nur eine allgemeinere Spezifikation der Technik, die bei Hibernate eingesetzt wird. Das ist allein schon daran zu erkennen, dass die EJB3 Implementierung von JBoss direkt auf Hibernate aufsetzt. Ansich ne tolle Sache auf jeden Fall schöner als die 2.1 Version.

Aha ... Hibernate ... Der aufmerksame Beobachter dieser Entwicklungen wird Dir erklären, daß Oracle die Vorgabe gespendet hat.

 

[puddah]

Das kann gut sein... Aber was hat das damit zu tun, dass sich Hibernate und EJB3 Persistence ähnlich sind?

 

[bronks]

Das kann gut sein... Aber was hat das damit zu tun, dass sich Hibernate und EJB3 Persistence ähnlich sind?

Mit der neuen Persistence API sind die EJB's (genauer gesagt die Entity Beans) sehr Toplink like. Im Grunde genommen ist EJB3 nur eine allgemeinere Spezifikation der Technik, die bei Toplink eingesetzt wird. Das ist allein schon daran zu erkennen, dass die EJB3 Implementierung von Oracle und die Referenzimplementierung von SUN direkt auf Toplink aufsetzen. Ansich ne tolle Sache icon_smile.gif , aber schade daß die Grenze zwischen Client und Server dadurch total verschwommen ist, welche bei 2.1 knallhart gezogen war.

 

[puddah]

Mit der neuen Persistence API sind die EJB's (genauer gesagt die Entity Beans) sehr Toplink like. Im Grunde genommen ist EJB3 nur eine allgemeinere Spezifikation der Technik, die bei Toplink eingesetzt wird. Das ist allein schon daran zu erkennen, dass die EJB3 Implementierung von Oracle und die Referenzimplementierung von SUN direkt auf Toplink aufsetzen.

Gut dann sind TopLink und Hibernate und EJB3 sich ähnlich... Gut zu wissen. O/R-Mapper scheinen ja richtig im Trend zu liegen.

Ansich ne tolle Sache icon_smile.gif , aber schade daß die Grenze zwischen Client und Server dadurch total verschwommen ist, welche bei 2.1 knallhart gezogen war.

Da kann ich dir jetzt nicht ganz folgen. Wie meinst du das? Die Persistence API beschreibt einen O/R Mapping Mechanismus, wo steht das mit dem CLient im zusammenhang?

 

[bronks]

... Da kann ich dir jetzt nicht ganz folgen. Wie meinst du das? Die Persistence API beschreibt einen O/R Mapping Mechanismus, wo steht das mit dem CLient im zusammenhang?

EJB sind keine O/R Mapper. Der Zusammenhang steht sogar in dem knapp gefassten Wikipediaartikel zu EJB drin.

 

[puddah]

EJB sind keine O/R Mapper

Was dann?

Der Zusammenhang steht sogar in dem knapp gefassten Wikipediaartikel zu EJB drin.

Hab mal kurz den Artikel überfolgen. Meinst du detached Objects bringen die unsaubere Trennung?

 

[Echnaton]

java persistence api ist teil der ejb3 spezifikation
die persistence provider sind dann hibernate oder toplink
toplink ist im glassfish enthalten. die sind für ejb3 die referenzimplementierung. hibernate ist "nur" kompatibel (ich weiß aber nicht wie weit...) und jboss 4.0.5 unterstützt ejb3 auch noch nicht komplett (ich weiß nicht wie weit genau...)
ejb3 ist vergleichbar mit corba oder .net remoting (so weit ich mich mit den anderen beschäftigt habe, sind ejbs beiden techniken überlegen). ejb3 bedeutet vor allem: verteilte objekte, wiederverwendbarkeit, skalierbarkeit und mit hilfe der jpa und dem persistence provider außerdem leichtes o/r mapping über die entity beans.
was mit "grenzen verschwimmen" gemeint sein kann, weiß ich auch nicht, aber ich kenne 2.1 nicht und bin noch relativ neu bei ejb3.

 

[bronks]

@Echnaton:
An EJB3 ist nicht nur neu, daß Annotations verwendet werden und das ganze dadurch deutlich anders aussieht. Im inneren findet man eine ganz neue Technik, welche anders angewendet werden will und noch ganz anders kann, als die alte. Die Grenzen verschwimmen dadurch, daß man Logik und Objekte, welche der Server beeinhalten soll auch einfach in den Client stecken kann ohne, daß es von aussen jemand merkt. Man kann Sachen machen, die mit 2.1 überhaupt nicht funktioniert hätten und wenn, dann mit sehr schlechter Performance. Der sehr positive effekt der verschwommenen Grenzen ist, daß TOs vollständig entfallen können.

 

[Guest]

Wann braucht man JBoss?

Wenn BEA ausfällt. Muuhhaaa. :bae: [/quote]