✔ wer kann mir eine erklärung liefern zu unterschieden zwischen java beans und ejb
- Themenstarter Looky
- Beginndatum
Thomas Darimont
Erfahrenes Mitglied
Hallo,
JavaBeans und EJB sind beides Komponentenmodelle.
JavaBeans sind ganz normale java Klassen die bestimmten Konventionen folgen (die in entsprechenden Spezifikationen definiert sind: ) ebenso EJBs.
JavaBeans waren führer dazu gedacht als Grundlage für grafische Steuerelement Komponenten verwendet zu werden.
Da die properties Accessor / Mutator (get/set) Methoden bestimmten Konventionen folgen mussten konnte man
in einem UI Editor die entsprechenden Eigenschaftsattribute identifizieren die dann der UI-Entwickler
über den GUI-Editor anpassen konnte.
EJBs waren dafür gedacht Serverseitige Geschäftskomponenten / Dienste / Entitäten zu modellieren.
Da hier die Anfoderungen um einiges Umfangreicher ausfallen (Lebenszyklusverwaltung, Security, TransactionHandling,
u.U. Verteilung etc.) ist die EJB Spezifikation auch um einiges Umfangreicher als die JavaBeans Spec.
JavaBeans brauchen keine besondere Umgebung um verwendet werden zu können,
EJBs hingegen benötigen einen Container (EJB Container).
Dieser Container verwaltet u.a. den Lebenszyklus
(create,destory, etc..) dieser Objekte und kümmert sich um weitere Belange wie Security, Transaction Handling etc..
Weiterhin gibts unterschiediche Ausprägungen von EJBs nämlich (Container Managed / Bean Managed) EntityBeans,
((Remote | local) | (Stateful | Stateless)) SessionBeans und MessageDrivenBeans.
Wobei heute in EJB 3.0 die Entitybeans / SessionBeans / MessageDrivenBeans quasi durch normale Javabeans abgelöst worden sind.
Die man um entsprechende Annotations erweitert um die entsprechende EJB Ausprägung festzulegen.
wobei man dann die Persistenz über JPA (oder eine andere Persistenztechnologie) handled.
Weiterhin ist von der hohen Komplexität der frühreren EJB Versionen 1.x/2.x nicht mehr viel zu spüren.
Gruß Tom
JavaBeans und EJB sind beides Komponentenmodelle.
JavaBeans sind ganz normale java Klassen die bestimmten Konventionen folgen (die in entsprechenden Spezifikationen definiert sind: ) ebenso EJBs.
JavaBeans waren führer dazu gedacht als Grundlage für grafische Steuerelement Komponenten verwendet zu werden.
Da die properties Accessor / Mutator (get/set) Methoden bestimmten Konventionen folgen mussten konnte man
in einem UI Editor die entsprechenden Eigenschaftsattribute identifizieren die dann der UI-Entwickler
über den GUI-Editor anpassen konnte.
EJBs waren dafür gedacht Serverseitige Geschäftskomponenten / Dienste / Entitäten zu modellieren.
Da hier die Anfoderungen um einiges Umfangreicher ausfallen (Lebenszyklusverwaltung, Security, TransactionHandling,
u.U. Verteilung etc.) ist die EJB Spezifikation auch um einiges Umfangreicher als die JavaBeans Spec.
JavaBeans brauchen keine besondere Umgebung um verwendet werden zu können,
EJBs hingegen benötigen einen Container (EJB Container).
Dieser Container verwaltet u.a. den Lebenszyklus
(create,destory, etc..) dieser Objekte und kümmert sich um weitere Belange wie Security, Transaction Handling etc..
Weiterhin gibts unterschiediche Ausprägungen von EJBs nämlich (Container Managed / Bean Managed) EntityBeans,
((Remote | local) | (Stateful | Stateless)) SessionBeans und MessageDrivenBeans.
Wobei heute in EJB 3.0 die Entitybeans / SessionBeans / MessageDrivenBeans quasi durch normale Javabeans abgelöst worden sind.
Die man um entsprechende Annotations erweitert um die entsprechende EJB Ausprägung festzulegen.
wobei man dann die Persistenz über JPA (oder eine andere Persistenztechnologie) handled.
Weiterhin ist von der hohen Komplexität der frühreren EJB Versionen 1.x/2.x nicht mehr viel zu spüren.
Gruß Tom
Looky
Erfahrenes Mitglied
mhm.
ok, ein bean spezifiziert sich dadurch, dass es unter anderem einen parameterlosen konstruktor, private membervarisablen und getter und setter methoden hat.
benutzt wird das teil dafür, um daten z.b. in einem db zu schreiben usw.
soweit richtig?
hast du dann vielleicht mal ein klitzekleines code beispiel, an dem ich den direkten unterschied zwischen einem ejb und einem bean erkenne?
mir ist der unterschied nämlich trotz deiner sicherlich guter erklärung noch nicht ganz klar.
danke
chriz
ok, ein bean spezifiziert sich dadurch, dass es unter anderem einen parameterlosen konstruktor, private membervarisablen und getter und setter methoden hat.
benutzt wird das teil dafür, um daten z.b. in einem db zu schreiben usw.
soweit richtig?
hast du dann vielleicht mal ein klitzekleines code beispiel, an dem ich den direkten unterschied zwischen einem ejb und einem bean erkenne?
mir ist der unterschied nämlich trotz deiner sicherlich guter erklärung noch nicht ganz klar.
danke
chriz
Oliver Gierke
Erfahrenes Mitglied
Vielleicht kurz zusammengefasst:
JavaBean
- Properties werden durch Getter und Setter veröffentlicht (Namingconvention)
(Den Parameterlosen Konstruktor würde ich nicht unbedingt dazuzählen)
EJB
- Klasse die in einen Container deployt wird, der den Lebenszykklus (erzeugen, zerstören von Instanzen der Klasse) regelt
Eine EJB wird seit Version 3 der Spezifikation über Annotationen zu einer gemacht, vorher musste man bestimme Interfaces Implementieren. Normale JavaBeans findest du quasi überall, da sich das Pattern als ein sehr Grundsätzliches eingebürgert hat.
Das Problem am Begriff Bean ist halt, dass er arg überladen ist (Spring benutzt ihn ja auch in einer leicht abgänderten Semantik). D.h. ohne Kontext ist das schwer zu deuten.
Gruß
Ollie
JavaBean
- Properties werden durch Getter und Setter veröffentlicht (Namingconvention)
(Den Parameterlosen Konstruktor würde ich nicht unbedingt dazuzählen)
EJB
- Klasse die in einen Container deployt wird, der den Lebenszykklus (erzeugen, zerstören von Instanzen der Klasse) regelt
Eine EJB wird seit Version 3 der Spezifikation über Annotationen zu einer gemacht, vorher musste man bestimme Interfaces Implementieren. Normale JavaBeans findest du quasi überall, da sich das Pattern als ein sehr Grundsätzliches eingebürgert hat.
Das Problem am Begriff Bean ist halt, dass er arg überladen ist (Spring benutzt ihn ja auch in einer leicht abgänderten Semantik). D.h. ohne Kontext ist das schwer zu deuten.
Gruß
Ollie
Oliver Gierke
Erfahrenes Mitglied
Ich glaub so bös war es nicht gemeint. Es geht einfach darum, dass die Posts leicht lesbar sein sollen um mehr leute zum Antworten zu bringen. Und für Hinweise in diese Richtung sind Mods da. Das hier:
wahr auch eher ein Griff ins Klo IMHO. Das hier ist ein Forum das von Wissen und Unwissen lebt. Wenn du nur "kompetente" Antworten willst, senden dir einige Leute hier gern einen Supportvertrag zu - gegen Entgeld versteht sich
. Das hier ist ein Forum was eben von freiwilliger Mitarbeit lebt, kein Expertenpool an dem man sich nach belieben bedienen kann. Nur so als Hinweis.Dennoch freue ich mich, geholfen haben zu können. =) Sind denn noch Unklarheiten offen?
Gruß
Ollie
Looky
Erfahrenes Mitglied
Moin,
auch ich helfe gerne, wie du in einigen Posts sicher feststellen wirst. Nichts desto trotz finde ich eine Regel zur Groß und Kleinschreibung.. Naja, irgendwie typisch deutsch. Ich für meinen Teil finde auch nicht das das zur besseren Lesbarkeit beiträgt.
Und normalerweise, wenn ich mal eine Frage habe, dann schreibe ich diesen "Griff ins Klo" sicher nicht. Nur in diesem Moment war es dringend, das ich in kurzer Zeit qualitativ hochwertige Antworten bekomme. Und dabei hätte mir eine "Könnte sein das..." Antwort nicht geholfen.
Christian:suspekt:
auch ich helfe gerne, wie du in einigen Posts sicher feststellen wirst. Nichts desto trotz finde ich eine Regel zur Groß und Kleinschreibung.. Naja, irgendwie typisch deutsch. Ich für meinen Teil finde auch nicht das das zur besseren Lesbarkeit beiträgt.
Und normalerweise, wenn ich mal eine Frage habe, dann schreibe ich diesen "Griff ins Klo" sicher nicht. Nur in diesem Moment war es dringend, das ich in kurzer Zeit qualitativ hochwertige Antworten bekomme. Und dabei hätte mir eine "Könnte sein das..." Antwort nicht geholfen.
Christian:suspekt:
Oliver Gierke
Erfahrenes Mitglied
Sehr gut, willkommen im Forum!
Ich könnte auch mit reiner Kleinschreibung leben, aber hier ist es halt wie mit Codeconventions im Team: es ist relevant, worauf sich das Team einigt, nicht, was der ein oder andere schöner fänd.Das ist okay, allerdings ist dann ein Forum halt nicht die richtige Anlaufstelle. Wenn das jeder machen würde, würden sich Newbies nie mehr trauen auch nur irgendwas zu posten. Und ehrlich gesagt ist ein Forum kein Last-Minute-Rettungsanker.
Nur meine 0,02€... Back to topic?
Gruß
Ollie
