EJB 3.0 bereits verwenden/verwendbar oder 2.1?

J

janw

Mitglied
Hallo,

sollte man schon EJB der Version 3.0 verwenden oder erstmal bei 2.1 bleiben? Der JBoss 4.0.3 SP1 unterstützt 3.0 ja schon. Tut er dies bereits zuverlässig oder gibts da einige Macken?
Immerhin ist die Spezifikation ja erst (oder schon?) ein "Proposed Final Draft".

Das, was ich über EJB 3.0 gelesen habe, gefiel mir jedenfalls, deswegen denke ich daran.

Gruß
Jan
 
Hallo!

Na ja, ich würde im moment noch kein EJB 3.0 für neue kritische Projekte verwenden.
Auch wenn die JSR 220 (http://www.jcp.org/en/jsr/detail?id=220) mittlerweile ein ' Proposed Final Draft' kann es da immernoch kleine Änderungen geben für die die Container Provider wieder ein wenig Zeit brauchen um diese zu Adaptieren siehe: http://www.jcp.org/en/procedures/jcp2 . Das ist zwar recht unwahrscheinlich, aber ich persönlich hätte dich ein wenig Bauchschmerzen damit. Weiterhin ist das verfügbare KnowHow in EJB 3.0 noch nicht sehr weit gesäht. Auch gibt es noch recht wenig Design Patterns bzw. Best Practices die sich speziell um EJB 3.0 drehen.

EJB 2.1 würde ich nur dann verwenden wenn unbedingt notwendig ist: Die J2EE Entwickler Community hat mittlerweile erkannt, dass die Verwendung von EJB sehr viele Nachteile hat (schwer zu testen, sehr Aufwendig, hohe Hardwareanforderungen, Container Spezifische Erweiterungen, etc...) und für die meisten Projekte viel sehr viel unnötigen Overhead beschert, was den Erfolg des gesamten Projektes riskieren kann.

Meine Empfehlung wäre für neue Projekte eine Architektur zu wählen die eine Kombination aus einem LightweightContainer (Spring, Pico / NanoContainer, Excalibur, etc) und einer PersistenzFramework (Hibernate, eine JDO Implementierung, TopLink, etc) bildet. Damit geht die Entwicklung relativ leicht füßig von der Hand (einfaches testen, geringer Resourcen Verbrauch, kein Application Server notwendig). Weiterhin sind die neueren Versionen einiger Persistenz Frameworks wie Hibernate und TopLink
von der API her recht ähnlich zu dem, was auch EJB 3.0 bietet, so dass eine spätere Portierung relativ leicht möglich ist.

Ob ihr nun EJB 3.0 / 2.1 oder doch was anderes verwendet hängt im Grunde genommen von eurer Risikofreudigkeit ab...
Ich würde für eine Spring/Hibernate Kombo plädieren :)

Gruß Tom
 
Hi!

Deine favorisierte lightweight-Kombination klingt interessant, sollte ich mich auch im hinblick auf EJB 3.0 befassen (v.a. mit Hibernate), ist aber in unserer Gruppe leider nicht zu integrieren, weil zuviel EJB 2.x wissen vorhanden ist.

Danke & Gruß
Jan
 
Hallo!

Der Roadmap unter: http://opensource2.atlassian.com/pr...sian.jira.plugin.system.project:roadmap-panel
haben die Spring Jungs noch ein paar Dinge zu erledigen bevor die 2.0 final wird. Aber bis zur 2.0 M2 ist ja nicht mehr weit ;-)

Ich werde EJB3 erstmals im Rahmen einer Produktentwicklung im Q2 2006 einsetzen und mich speziell mit Message Driven Beans und JMS auseinandersetzen, es sei denn Spring 2 ist schneller
Zum Vergrößern anklicken....

Hast du dir schon mal jencks angeschaut?
http://jencks.org/
Springmanaged MessageDriven Pojos können einem das Leben mit JMS ganz schön einfach machen ;-)

Gruß Tom
 
Dank dir, ich kenne bereits nur David Jencks - vom hörensagen ...

Sieht nach einer feinen alternative aus, werde mich gleich ransetzen um ein paar proof-of-concepts zu machen, zumal ich bereits in wepapps ziemlich viel spring nutze.

Ich muss aber auch sagen das EJB3 - zumindest die Implementierung in Jboss-4.0.3EJB - auf den ersten blick ziemlich unkompliziert zu handlen ist.
 
Hallo Tom,

nochmals vielen Dank für den Tipp, hat auf anhieb geklappt!
Hast du Erfahrung mit Jencks & Spring im Produktivbetrieb?

p.s. Deloyment auf JBoss, Geronimo und JONAS problemlos, Mock testing vom feinsten - ich liebe Spring!
 
Entschuldige meine neugier, aber was stellst du mit jencks an? in welcher umgebung hast du die anwendung bereitgestellt?

Ich werde jedenfalls ziemlich fette XML-Nachrichten asynchron verarbeiten müssen, da kann ein Paket schon 25-40 MB umfassen.

Mich würde interessieren ob es dort bei Jencks-Spring Stolpersteine gibt bzw. ob das Teil stabil lüppt.
 
Hallo!

Entschuldige meine neugier, aber was stellst du mit jencks an? in welcher umgebung hast du die anwendung bereitgestellt?

Ich werde jedenfalls ziemlich fette XML-Nachrichten asynchron verarbeiten müssen, da kann ein Paket schon 25-40 MB umfassen.

Mich würde interessieren ob es dort bei Jencks-Spring Stolpersteine gibt bzw. ob das Teil stabil lüppt.
Zum Vergrößern anklicken....
In meiner alten Firma hab ich mal angefangen einen JMS basierten PrintService zu implementieren.
Diesen entwickle ich nun privat weiter... basierent auf Spring 1.2.6 , Jencks 1.1.1, JBoss 4.x, JBoss MQ / ActiveMQ.
Das ganze läuft innerhalb eines Tomcats 5.x innerhalb des JBoss. (Läuft aber auch in einem Standalone Tomcat)

Also deine XML Nachrichten sind ja wirklich sehr groß....
Ich würde diese nicht über JMS übertragen, man stelle sich vor, dass diese /riesen/ Messages in einer MessageQueue im Speicher oder
in einer Datenbank gehalten werden...nicht wirklich prickelnd. Okay das FileSystem wäre auch noch eine Möglichkeit, aber damit hat (IMHO) zum Beispiel JBossMQ unter JBoss 4.x so seine Probleme... (FileSystem Persistenz für JMS Messages gibts da nämlich nicht mehr (war zumindest in JBoss 4.0.2 so)). Statt dessen würde ich nur "Meta-Messages" mit einer Art kurzen Zusammenfassung der Daten übertragen. Diese enthalten dann u.a. auch Informationen darüber, wie der Consumer an die Daten kommen kann (z.Bsp. FTP Kennung, oder Daten zur Verwendung eines optimierten Stream Protokolls).
Der Consumer kann dann diese Zusammenfassung auswerten und dann entscheiden ob er dieses Packet haben will. Möchte er es verarbeiten, so kann er das Packet mit den Bereitgestellten Informationen beziehen.

Ein anderer Ansatz bestünde daraus, die Verarbeitungslogik zu den Daten zu verlegen, um den teuren Datentransport zu sparen. Ganz nach dem Motto von Ted "Effective Enterprise Java" Neward:
"If we can't bring the data to the code, bring the code to the data" ;-)

(Wenn die Daten sowieso auf der selben Maschine liegen
braucht man ja egentlich nur das FileHandle des entsprechenden XML Files hin und her zureichen).

Mich würde interessieren ob es dort bei Jencks-Spring Stolpersteine gibt bzw. ob das Teil stabil lüppt.
Zum Vergrößern anklicken....
Also bei mir läufts ohne Probleme... aber schau doch selbst in der Mailingliste nach.

Gruß Tom
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück