Unterschied EJB und JavaBeans?

Status
Nicht offen für weitere Antworten.
F

frager

Gast
hallo, wo genau ist der unterschied bei den beiden sachen?

vielen dank :)
 

SnooP

Top Contributor
die beiden Artikel sind da aber auch etwas seltsam imho... - für mich ist ne JavaBean nichts anders als ein normales Java Objekt, das einzige was eine JavaBean haben muss nach Definition sind die Attribute, auf die man per get und set-Methoden zugreifen kann... - das wars auch schonn... - ich hab JavaBeans schon für andere Sachen als GUI verwendet, wie im Artikel sugeriert wurde... z.B. kann man innerhalb von EJBs (bei Entity Beans) die JavaBeans verwenden, um Daten zu transportieren, da diese von dem Container einfach in eine andere Datenstruktur umgewandelt werden können: BeanMapping (Corba - CDR? ... bzw. auch xml-complex-types).

EJBs sind dann aufgemotzte Java-Komponenten, die innerhalb eines Containers (Application-Servers) bestimmte Geschäftslogiken umsetzen können (siehe auch 3-Tier-Architecture).
 

byte

Top Contributor
SnooP hat gesagt.:
ich hab JavaBeans schon für andere Sachen als GUI verwendet, wie im Artikel sugeriert wurde... z.B. kann man innerhalb von EJBs (bei Entity Beans) die JavaBeans verwenden, um Daten zu transportieren


Das steht doch so oder ähnlich auch im Artikel:

JavaBeans (...) werden in der Softwareentwicklung als Container zur Datenübertragung verwendet und bilden die Grundlage für Enterprise Java Beans. Ursprünglich waren Java-Beans für „visuelles Programmieren“ gedacht (...)
 

SnooP

Top Contributor
naja... aber mir ist nicht ganz klar, warum sie die Grundlage für EJBs bilden sollen. Ich glaube sowas fördert eher die Verwirrung um diese beiden Begriffe. Für mich hat ne EJB jetzt nix mit ner normalen Bean zu tun - außer halt die Namensähnlichkeit ;)
 

byte

Top Contributor
Ja da hast Du recht. Sie hätten lieber als erstes schreiben sollen, dass JavaBeans und Enterprise Java Beans etwas grundlegend unterschiedliches sind. Diese Namensähnlichkeit verursacht halt Verwirrung...
 

Bleiglanz

Gesperrter Benutzer
Gemeinsamkeit: die 4 Buchstaben B e a n

Unterschiede:

JavaBeans kennt jeder, sind stinknormale Java-Klassen mit zwei besonderheiten:

a) parameterloser Konstruktor
b) getter und setter Schema für sogenannte Properties

Man kann sie einfach so in eigenen Programmen einsetzen

EJBs kennt man nicht so ohne weiteres (viele brauchen sie auch nicht), sind Software-Komponenten bestehend aus (z.Zt. mehreren) Java Objekten, XML-Beschreibungsdateien,...; man kann damit nicht ad hoc arbeiten, sondern braucht eine Laufzeitumgebung ("Applicationserver") in den man diese Komponenten hineinpackt ("deployed") und der regelt dann das ganze.

Man schreib als Programmierer NIE sowas wie new MeineBean(); das ist verboten (nur der Container darf EJBs erzeugen)

usw. usf.
 
F

frager

Gast
hallo, aha. also normale beans kann ich also selber schreiben und wenn die klasse dann setter und getter methoden hat, ists ne java bean, richtig? was jetzt die ejb angeht, hab ich mir das auch so ähnlich gedacht. sie bilden eine art 'framework', damit der entwickler sich nur noch um die geschäftslogik kümmern muss (objektverteilung, persistenz) werden durch die ejb erledigt (durch die xml deskriptoren). es sei denn, man macht BMP (bean managed persistence). kann man das so stehen lassen? ach ja, für die ejb braucht man dann also noch einen j2ee fähigen server wie websphere , oder?

gruß
frager
 
F

frager

Gast
nochmal ich,

@snoop: was meinst du mit 3 schichtenarchitektur? präsentation, anwendung und persistent, oder client server, datenbank?

gruß :)
 

SnooP

Top Contributor
jo im Prinzip schonn - ... Client-Tier, App-Server-Tier, Dataserver-Tier .. wobei das heutzutage auch schon wieder weitergestuft wird, eher in Richtung 4-Tier:
Client-Tier: Webbrowser
Presentation-Tier: Webserver
Applicationserver-Tier: Applicationserver, Container (z.B. JBoss mit der Möglichkeit des Einstellens von EJBs...) - auch Business-Logic
Persistence-Tier: Irgendein Mechanismus, der aus den Datenmodellen aus der "Business-Schicht" eine persistente Form macht, also z.B. eine Datenbank.. diese kann dabei schon direkt durch den Container in der vorigen Schicht bedient werden, wie bei den Entity-Beans... d.h. die Art und Weise der Speicherung ist für den Entwickler mehr oder weniger verdeckt... so will man das ja am besten auch haben... dann kann man das Speichermodell auch mal ändern.
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen

Ähnliche Java Themen


Oben