EJB --- Eine Modeerscheinung?

[bronks]

Je mehr ich mich mit EJB beschäftige, desto mehr frage ich mich, was für einen Motivation überhaupt dahinter steckt. Eigentlich kann man alles in Handarbeit viel Resourcenschonender gestalten. Die EJBs zu deployen ist jedes mal ein Erlebnis mit 1000 Hürden, welches die Frage nach der Platformunabhängigkeit aufwerfen läßt.

Was würde euch konkret dazu treiben ein Projekt mit EJB umzusetzen? Wo hat EJB, eurer Meinung nach, unschlagbare Vorteile?

 

[bambi]

Wuerde ich nicht sagen. In meinen Projekten verwende ich meistens EJB - und auch natuerlich
etwas "Handarbeit" - es gibt eben keine perfekte Loesung fuer alles gleichzeitig. Oder hab' ich
die einfach nur noch nicht gefunden???
Also EJB ist einfach sehr schnell. Wenn ich einen Datensatz habe, und die dazugehoerigen Daten aus
anderen Tabellen brauche, dann bin ich mit get...() einfach schneller - und 's ist auch einfacher als

select irgendwas
from   table a, table b
where  a.weiisNich = b.weissNich
and    a.nochWas = b.auchNochWas

Ist auch weniger fehleranfaellig, oder? (besonders natuerlich die finder-Methoden sind supi)

 

[KSG9|sebastian]

hibernate > rest

 

[foobar]

Der Vorteil von EJB ist, daß man das darunter liegende RDBMS leicht austauschen kann. Die Nachteile sind:
- viel Overhead(RemoteInterface, HomeInterface etc)
- komplexe Queries lassen sich nicht realisieren, ausser man verteilt das Problem auf mehrere EJB's und kumuliert die Ausgaben.
- sehr langsam

 

[KSG9|sebastian]

benutzt hibernate, in der 3er Version ist es schnell und kann nahezu alles..

 

[bronks]

@foobar:
Genau so sehe ich das auch und frage mich, ob der EJB-Hype eine Vollgasfahrt in die Sackgasse war? Ein RDBMS auszutauschen ist auch so nie das weltbewegende Problem gewesen, wenn man sich an eine so primitive Abfragetechnik gehalten hat, wie es in EJBs umgesetzt wird und natürlich mit Konzept und vorausschauend entwickelt hat.

Gelockt haben mich so Sprüche wie z.B. Der Entwickler muß sich nicht um den DB Zugriff kümmern usw. Da dachte ich fast schon an künstliche Inteligenz. Entpuppt hat es sich als zeitfressendes Monster, welches umständlich zu debuggen ist. Nicht nur, daß man sich um den DB-Zugriff kümmern muß wie sonst auch. Man muß sich um Interfaces kümmern. Die EJBs extra deployen und die ganze zusätzliche Arbeit. Zum Schluß stellt man auch noch heraus, daß jeder Server seine eigenen Deployment Files braucht und alles irgendwie inkompatibel zu sein schein.

Immer wird die verteilte Anwendung hervorgehoben. Warum und wozu das. Ich hab hier aus neugier ein paar schwere Server stehen, aber daß nur, weil ein einzelner Computer dadurch total überfordert ist die riesige Software schnell und stabil zu fahren. 3 Computer mit insgesamt 3 GB RAM machen in diesem Fall das was ein Notebook mit 256 MB, Tomcat und einer etwas solideren Datenbank auch kann.

@KSG9|plak:
Ob ich als SQL-Schnell-Tipper und JDBC-Liebhaber mal dazu komme mir Hibernate anzusehen?

@all:
Es ist doch so, daß sich bei J2EE und den ganzen ApplicationServern eigentlich alles nur um EJB dreht und daß das deren Existenzberechtigung ist; oder liege ich da falsch und es stecken noch andere tolle Techniken hinter der teilwese monströs großen Software?

Was ist ein EJB-Experte? Es werden viele Leute mit EJB-Wissen gesucht. Warum? Ist der EJB-Experte eine aussterbende Rasse, die jetzt noch zur Rettung von mißratenen Entwicklungen herangezogen wird, wie es vor dem Jahr 2000 der AS/400-Experte? Oder ist der EJB-Experte der, der die Zukunft beherrschen wird?

 

[KSG9|sebastian]

Bei uns in der Firma sind grade IBMler, die machen alles mit Hibernate.

 

[Bleiglanz]

würde sagen dass das ganze eine grosse Zukunft hat

a) Nebenläufigkeit automatisch (echte arbeitserleichterung für den Progger)

b) Transaktionen automatisch (auch eine arbeiteserleichterung)

das kriegt man aber alles auch ohne EJB gebacken, keine Frage. IMHO ist das ganze J2EE Zeugs nur dann wirklich ein Muss, wenn man verteilte Transaktionen über mehrere DBs spannen will

[transactionbeginn]
insert in oracle
update in db2
delete in ms-sqlserver
[transactionende]

sowas kriegt man von Hand nicht mehr so leicht gebacken, da können J2EE Server ziemlich viel Entwicklungszeit einsparen. Und das M$ Konkurrenzprodukt (MTS bzw. COM+) ist so übel, dass J2EE praktisch eine alleinstellung auf dem markt hat

für eine stinkige homepage mit gästebuch auf mysql-basis ist EJB natürlich absolut ungeeignet

P.S. sinnvoll arbeiten kann man praktisch eh nur mit Codegeneratoren, sonst schmiert man bei Projekten mit 50 DB-Tabellen sofort ab

P.P.S. die Query-Language ist tatsächlich ein schlechter Witz, auch bei EJB-Einsatz kommt man um gelegentlichen JDBC nicht herum

 

[Oskar]

Bei uns in der Firma sind grade IBMler, die machen alles mit Hibernate.

Ich dachte die sollten ihr eigenes Produkt vertreiben (Websphere) naja sie werden schon wissen warum nicht ....

Ansonsten warte ich aktuell auf EJB 3.0 mal schaun was da dann alles anders ( besser !?) wird.

 

[KSG9|sebastian]

Lol natürlich verwenden sie WebSphere, aber irgendwie braucht man ne Verbindung zu der Datenbank bei nem Intranet für > 5000 Mitarbeiter

 

[Thomas Darimont]

Hallo!

Ich hab auch schon einiges mit EJB gemacht und muss sagen, dass die ganze Komplexität die ein EJB Ansatz verlangt
mittlerweile wirklich nur noch mit Codegeneratoren ala XDoclet oder auf Velocity-Basis zu handeln ist. Was meiner Meinung nach EJB trotzdem noch Wertvoll macht ist wie "einfach" man damit verteilte Dienstkomponenten entwickeln kann. Man sagt ja auch das das wirklich schlechte an EJB eigentlich nur die Persistenzschicht wäre (CMP und BMP EntityBeans) unter anderem auch deswegen, weil gerade dafür die "Komplexesten" Containerabhänigen Deploymentdeskriptoren notwendig sind. Mit den normalen SessionBeans (Stateless) und MessageDrivenBeans hat man im allgemeinen nicht so sehr die Probleme.

Btw. zur Sache das man bei Verwendung von EJB zur Performancesteigerung teilweise bei "größeren" Batch-Aktionen auf händisches JDBC setzen muss. Diese Tatsache findet sich auch in Form eines DesignPatterns wieder (Fast Lane Reader). Diese Vorgehensweise ist nicht nur bei der Verwendung von EJB sondern auch bei Hibernate ratsam. Selbst die "Hibernate-Experten" aus dem Buch "Hibernate in Action" sagen das Hibernate nicht für "Massendatenverarbeitung" entworfen wurde. Somit ist dieser Umstand IMHO nicht an die Technologie EJB gebunden sondern davon unabhänig.

Btw2. Hibernate 2. ist auch schon "schnell" obwohl solche Aussagen immer als rein Subjektiv anzusehen sind und stark vom Anwendungsgebiet abhängen....

Zur Frage was ein EJB Experte ist... hmmm...
Ein EJB Experte ist für mich jemand, der sich mit der EJB Spezifikations-Reihe von 1.0 - 2.1 auskennt und 1-2 Applikationsserver Konfigurieren (*Beans, Datenquellen, Transaktionsmanager, JMS-Queues/Topics,Mail, etc.) und damit umgehen (Deployment, Administration) kann. Weiterhin muss sich dieser jemand zwingen sehr gut im sonstigen J2EE Bereich gut auskennen (JDBC,JNDI,JMS,JTA,JCA,JAAS,JMX,Java Mail, Servlets, JSP...) zusätzlich sollten noch gute Kenntnisse mit XML und RMI und/ oder Corba vorhanden sein. Ansonsten sollte dieser "Experte" die meisten bewährten EJB Design Patterns kennen und anwenden können. Ein zusätzliches Schmankerl wäre noch wenn er auch Ahnung von Methodiken zur Performanzverbesserung bzw. Aufstellung von Systemmetriken hätte. Unverzichtbar sind jedoch auf jeden Fall auch Kenntnisse in der Praktischen Anwendung und vor allem der Entwicklung von EJB's (Codegeneratoren, Konfiguration der Entwicklungsumgebung, Erfährung mit Client-Komponenten etc.).... und, und, und...

Just my 2 Cents,

Gruß Tom

 

[Michael]

Ansonsten warte ich aktuell auf EJB 3.0 mal schaun was da dann alles anders ( besser !?) wird.

EJB 3.0 wird eine große Erleichterung für alle EJB-Entwickler sein. Keine Deployment-Deskriptoren schreiben zu müssen und die Informationen für das EJB-Deployment als Attribute im EJB-Code einbetten zu können ist an sich schon ein Traum. Durch die Verwendung von Attributen bei Entitiy-Beans werden sich wahrscheinlich mehr Entwickler an diese Art von O/R Mapper herantrauen.

Mein Zukunfstraum ist jedenfalls Attribut-OP auch mit Portels (wegfall von portlet.xml) und JSP (wegfall von web.xml) einsetzten zu können, aber bis dahin werden noch einige Jahre ins Land ziehen... vor allem bis zur Toolunterstützung.

 

[Bleiglanz]

Für mich ist das eher ein Alptraum

Mir graust schon vor den Annotationswahnsinnigen (wer jemals mit XDoclet mehr als 5 EJBs verwaltet hat weiss wovon ich rede)

Die völlige Abschaffung der ejb-jar.xml ist nicht direkt das was ich mir wünsche (ist immerhin eine zentrale Stelle für "Konfiguration der Anwendung"); auch wenns z.Zt. extrem nervig ist...

wenn das jetzt alles in den Annotations in zig Quelltextfiles abgelegt wird, dann wird das wohl sowas wie "Spaghetti Konfiguration"

 

[bronks]

Ich hab mich ein bissl schlau gemacht was man von EJB 3.0 so alles erwarten kann.

Sehe ich das richtig? Plattformunabhängigkeit auch auf dem AS? Endlich kann ich meine EJBs auf allen AS deployen welche EJB3.0 unterstützen ohne tagelang in irgendwelchen XMLs herumgraben zu müssen?

 

[Bleiglanz]

Ich hab mich ein bissl schlau gemacht was man von EJB 3.0 so alles erwarten kann.

Sehe ich das richtig? Plattformunabhängigkeit auch auf dem AS? Endlich kann ich meine EJBs auf allen AS deployen welche EJB3.0 unterstützen ohne tagelang in irgendwelchen XMLs herumgraben zu müssen?

Das glaub ich nie und nimmer, bin schon gespannt welche herstellerspezifischen Annotations sich die Anbieter von Appservern einfallen lassen werden....

BTW ist der ganze Annotationszirkus de facto der Abschied vom Komponentenmodell der EJBs (war ja mal so gedacht: kompilieren -> kofigurieren -> einspielen); wenn jetzt alles im sourcecode steht, dann wird wohl die Deployer-Rolle eingestampft

wann und wo man in Zukunft einen physikalischen JNDI Namen für eine EJB festlegen soll ist mir ein Rätsel