EJB Enterprise Java Beans

[kossy]

Hallo !

habe mal eine Frage zu den EJB (Version 2.0 oder 2.1, noch nicht 3.0 !). Es wird immer davon gesprochen, dass man die EJB´s lokal, und nicht entfernt aufrufen soll. Warum ist das so? Meine Vermutung wäre, aufgrund möglicher Inkonsistenzen der Daten beim entfernten Aufruf und größeren Administrationsaufwand, der die Anwendung verlangsamen würde. Grundsätzlich kann man glaube ich ja EJB´s entfernt aufrufen, aber ich habe gehört, dass man dies eher lokal vollziehen sollte, also auf der gleiche Maschine und noch nicht mal in unterschiedlichen JVM´s bzw. Rechnerknoten.

 

[maki]

Es wird immer davon gesprochen, dass man die EJB´s lokal, und nicht entfernt aufrufen soll. Warum ist das so?

Was für EJBs?

Meinst wohl EJB2.x EntityBeans, oder?

IMHO sollte man die gar nicht verwenden.

 

[kossy]

Tschuldigung ! Ich meinte natürlich auch die Entity-Beans und nicht Session Beans oder so.

 

[maki]

Warum man sie nicht remote aufrufen sollte:
EntityBeans haben feingranulare Schnittstellen.
Jeder getter/setter Aufruf würde eine Netzwerkverbindung zur Folge haben, langsam, und wenn deine ENtityBean viele getter/setter hat, wären das viele langsame aufrufe.

Stattdessen EntitBeans nur über SessionBeans aufrufen welche alle benötigten Daten auf einmal übers Netz schieben in sog. TransferObjects.

Aber EJB2.x EntityBeans sollte man wirklich vermeiden, geht auch schon vor EJB3, man nehme POJOs.

 

[kossy]

EntityBeans haben feingranulare Schnittstellen.

Könntest du das vielleicht etwas näher erläutern?

Stattdessen EntitBeans nur über SessionBeans aufrufen welche alle benötigten Daten auf einmal übers Netz schieben in sog. TransferObjects.

Wie genau darf ich mir einen solchen Aufruf einer EntityBean über eine SessionBeans vorstellen? Gibt es eine Alternative dazu bzw. was ist der gängigste Weg?

Aber EJB2.x EntityBeans sollte man wirklich vermeiden, geht auch schon vor EJB3, man nehme POJOs.

Ich weiß, leider kaue ich diese Thema derzeit nur "theoretisch" in meiner Hochschule durch und der Prof hat auch schon mal davon gesprochen, POJOs zu nehmen. Praxisbeispiele habe ich aber kaum zu dem Thema gesehen. Ist bestimmt nicht gerade sehr förderlich fürs Verständnis.

Ich habe mir noch ein Buch vom o´reilly Verlag bestellt, ich glaube das hieß EJB 2.0 oder so. Ich hoffe, dass mir das weiterhelfen wird.

 

[foobar]

Wie genau darf ich mir einen solchen Aufruf einer EntityBean über eine SessionBeans vorstellen? Gibt es eine Alternative dazu bzw. was ist der gängigste Weg?

Das Pattern heisst Session Facade: http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html

Könntest du das vielleicht etwas näher erläutern?

Eine Entity Bean stellt eine Entität in deiner Domäne dar z.b. eine Rechnung einen Auftrag etc. Diese Bean hat dann für jede Property einen Getter und Setter, wenn du jetzt per Remote eine EntityBean ansprichst und auf die einzelnen Getter zugreift, wird jedesmal ein einzelnder remotezugriff durchgeführt. Das ist nicht das was man will. Deshalb werden EntityBeans nur lokal verwendet und die Services über eine SessionBean zur Verfügung gestellt.

 

[kossy]

Ok vielen Dank, nun sind die Dinge etwas besser verständlich !

Es hat sich zwischenzeitlich noch Fragen zu einem anderen Thema ergeben, was aber auch die reine Kommunikation betrifft

Bei Java Message Service (JMS), handelt es sich um asynchrone Kommunikation, allerdings habe ich hier in einem Fachbuch gelesen, dass es egal ist, ob ich prozedual oder objektorientiert programmiere. Ich frage mich warum das so ist und kann mir diese Frage auch nirgends beantworten. Gerade SOA soll sich die Vorteile einer Message Queing zu nutze machen und nie entfernte Aufrufe realisieren.

Ich vermute mal, dass liegt daran, dass der Empfänger erst bei Bedarf seine Informationen holt. Ich glaube man benutzt nicht entfernte Aufrufe, weil sonst zuviel Traffic auf der Leitung wäre.

Warum benutzt man für RMI vorwiegend das CORBA Protokoll IIOP und nicht das Java Protokoll JRMP ein?

Ich vermute, weil es so möglich ist, nicht nur Javasysteme miteinander zu koppeln, sondern auch hetrogene Systeme ! Stichwort Interoperabilität.

 

[foobar]

Bei Java Message Service (JMS), handelt es sich um asynchrone Kommunikation, allerdings habe ich hier in einem Fachbuch gelesen, dass es egal ist, ob ich prozedual oder objektorientiert programmiere.

Den Zusammenhang verstehe ich nicht. JMS hat nichts mit OOP oder prozeduraler Programmierung zu tun. JMS wird dann verwendet, wenn der Client nicht auf die Abarbeitung einer Anfrge warten kann oder will. Dadurch lassen sich auch verteilte Systeme koppeln.

Warum benutzt man für RMI vorwiegend das CORBA Protokoll IIOP und nicht das Java Protokoll JRMP ein?

Ich vermute, weil es so möglich ist, nicht nur Javasysteme miteinander zu koppeln, sondern auch hetrogene Systeme ! Stichwort Interoperabilität.

RMI nutzt man nur dann wenn Clients und Server in Java implementiert sind und man keine Interoperabilität braucht. Denn Webservices bringen eine Menge Overhead den man nicht immer in Kauf nehmen will, wenn es nur darum geht die Geschäftslogik zentral zu hinterlegen.

 

[kossy]

Und wann genau macht es wirklich Sinn RPC einzusetzen?

 

[foobar]

RMI ist doch RPC(Remote Procedure Call)

 

[kossy]

also ist nur der Unterscheid das RPC prozedual arbeitet und rmi eher für objekte geeignet ist?

 

[kossy]

Ich muss nochmal nachhaken. Warum ist RPC auch gleichzeitig RMI ? Also soweit ich weiß ist RPC (die Idee entfernte Prozeduren aufrufen zu können) der Vorgänger von RMI (die Idee entfernte Methoden für bestimmte Objektidentitäten aufrufen zu können).

Also wenn ich nun von einer Objektarchitektur und der Kommunikation von einzelnen Objekten untereinander spreche, dann benötige ich RMI Verfahren für die Kommunikation und nicht RPC, weil ich keine statischen Prozeduren aufrufen will.

Ist das so korrekt, kann das vielleicht jemand beantworten?

 

[foobar]

RMI ist der Überbegriff für alle entfernten Methodenaufrufe, ob das jetzt prozedural oder oo ist spielt dabei keine Rolle. RMI ist eine konkrete Implementierung dieser Architektur oder Verfahrens für Java.

Wikipedia

Java RMI stellt einen RPC-Mechanismus für Java bereit.
http://de.wikipedia.org/wiki/Remote_Procedure_Call

Ist ja auch egal wie man das jetzt nennt, hauptsache es funzt ;-)

 

[kossy]

Ist ja auch egal wie man das jetzt nennt, hauptsache es funzt ;-)

Grundsätzlich hast Du recht, aber leider muss ich im Rahmen meines Studiums solche Dinge ganz genau definieren und trennen können. Leider reiten die Profs. gerade auf solchen Dinge herum und wollen es ganz genau wissen :x

Nochmal kurz was anderes. Wird der Namensdienst RMi registry eigentlich von dem Komponentenmodel (bzw. EJB Container) implizit bereits gestellt? Oder wird der Namensdienst irgendwo anders bereitsgestellt?

 

[foobar]

Ja, JNDI ist Teil von Jee http://de.wikipedia.org/wiki/JEE

Grundsätzlich hast Du recht, aber leider muss ich im Rahmen meines Studiums solche Dinge ganz genau definieren und trennen können. Leider reiten die Profs. gerade auf solchen Dinge herum und wollen es ganz genau wissen

Verstehe. Laut Wikipedia ist RMI eine RPC implementierung. Eine Differenzierung zwischen oo und prozedural ist mir in diesem Bereich nicht bekannt.
Bei Soap wird bei den Services zwischen dem Stype RPC und Document LIteral unterschieden aber bei RMI gibt es nur entfernte Methodenaufrufe.

 

[kossy]

Ich habe nochmal eine theoretische Frage aus einer Vorlesung, bei deren Beantwortung ich mich schwer tue.

Hier die Frage:

Begründen Sie warum in manchen Anwendungsszenarien die Interaktion der Komponenten auf der Grundlage des Message Queuing gegenüber dem entfernten Aufruf die bessere Wahl darstellt?

Ich vermute, dass es manchmal erwünscht ist, die Komponenten bzw. Sender und Empfänger zu entkoppeln, umso die Geschwindigkeit meiner verteilten Anwendung zu erhöhen. Würde ich alles mit RMI und RPC machen wollen, wäre der administrative, technische Aufwand zu groß und geht auf Kosten der Geschwindigkeit.

Der Vorteil bei Nachrichtenorientierter Kommuniikation ist ja das Ausnutzen einer asynchronen Verbindung. Der Sender muss nicht auf eine Bestätigung vom Empfänger warten. Das ist optional !

Kann man das so stehen lassen? Was könnte ich noch ergänzen?

Vielen Dank !
MFG

 

[foobar]

Ja, würde ich auch so sagen. Der Sender muß nicht auf das Ende einer Longrunningoperation warten.

 

[kossy]

Hallo !

Ich habe nochmal eine Frage. Es geht um die Entity Beans und die Datenbank, in denen die Attributwerte der Entity Bean in Feldern gespeichert werden soll.

Ist es möglich, dass irgendeine Entity Bean in einer entfernten Datenbank ihre Werte abspeichern kann? Also die Datenbank könnte auf einem anderen Rechner aktiv sein, als die Entity Bean. Ist dieser Weg vielleicht sogar üblich?

Muss eigentlich immer ein identisches Datenbankprodukt verwendet werden (z.B. Oracle oder MySQL). Oder reicht es einfach aus, auf allen in Frage kommenden Datenbank ein realtionales DB Schema x-beliebiger Hersteller laufen zu lassen?

Kann es sich auch um eine verteilte Datenbank handeln? (Falls es so etwas gibt)

Danke schön...

 

[foobar]

Ist es möglich, dass irgendeine Entity Bean in einer entfernten Datenbank ihre Werte abspeichern kann? Also die Datenbank könnte auf einem anderen Rechner aktiv sein, als die Entity Bean. Ist dieser Weg vielleicht sogar üblich?

Ja, das ist theoretisch durch verschiedene persitentunits möglich. Aber nur eine Entity aus einer entfernten DB zu laden ist wohl eher unüblich. Ausser diese Entity enthält Daten, die sich nicht oft ändern wie irgendwelche Paramter der Anwendung.

Muss eigentlich immer ein identisches Datenbankprodukt verwendet werden (z.B. Oracle oder MySQL). Oder reicht es einfach aus, auf allen in Frage kommenden Datenbank ein realtionales DB Schema x-beliebiger Hersteller laufen zu lassen?

Öhm, JPA ist DB unabhängig. Du kannst deine DB theoretisch jeder Zeit austauschen und JPA kann auch zur Laufzeit dein DB-Schema anpassen oder neu erstellen falls nicht vorhanden.

Kann es sich auch um eine verteilte Datenbank handeln? (Falls es so etwas gibt)

Ja, sowas nennt man Clustering. Damit kann man entweder eine DB replizieren d.h. es gibt einen Master und mehrere Nodes an die Anfragen weiter geleitet werden.
Man kann aber auch nur eine einzelne Tabelle aus einer anderen DB verwenden. Das wird z.b. von Mysql und Informix Online unterstützt.

 

[kossy]

Öhm, JPA ist DB unabhängig. Du kannst deine DB theoretisch jeder Zeit austauschen und JPA kann auch zur Laufzeit dein DB-Schema anpassen oder neu erstellen falls nicht vorhanden.

Vielen Dank erstmal, was genau meinst du mit JPA? In dem Zusammenhang mit Entity Beans hat sich noch eine weitere Frage ergeben. Die sogenannten Callbackmethoden (ejbLoad(), ejbStore() usw.) werden ja implizit durch den EJB Container aufgerufen. Kann eigentlich eine entfernte Clientanwendung irgendwie an diese Callbackmethoden herankommen bzw. sie aufrufen? Oder ist das gänzlich unterbunden durch die EJB Container Architektur. Falls das funktionieren sollte, wird dass dann im Deployment Deskriptor festgelegt?

MFG und Danke

 

[foobar]

EJBs sind normale Pojos. Wenn die Callbackmethoden public sind, kann theoretische jeder darauf zugreifen.

JPA ist die Java Persistence API. Diese API wird von EntityBeans zur Persistierung verwendet.

 

[kossy]

Wenn die Callbackmethoden public sind, kann theoretische jeder darauf zugreifen.

Ok aber würde das denn auch Sinn machen und nicht vielleicht sogar Gefahren mit sich bringen (unerlaubte Zugriffe von x-beliebigen Clients, Datenintegrität könnte gefährdet werden, unerlaubte Datenbankzugriffe).

Im Zusammenhang mit Entity Beans wird immer wieder EJBHome- und EJBObject-Objekte ins Spiel gebracht. Diese sind doch konkrete Klassen, die aber eher technische Dinge umsetzen und sich auf die Home und Remoteschnittstellen einer bestimmten Entitybean beziehen oder?

 

[ps]

> JPA ist die Java Persistence API. Diese API wird von EntityBeans zur Persistierung verwendet.

Die gabs bei EJB2.x doch noch garnicht...

 

[foobar]

> JPA ist die Java Persistence API. Diese API wird von EntityBeans zur Persistierung verwendet.

Die gabs bei EJB2.x doch noch garnicht...

Achja es geht hier ja um Ejb2, Sorry

 

[kossy]

Ist Java RMI eigentlich ein Komponentenmodel? Oder sind RMI Registry usw. nur spezielle Klassen einer Middleware?

 

[foobar]

RMI dient nur dazu entfernte Methoden aufzurufen wie der Name ja schon vermuten lässt *g*
Als Komponentenmodell würde ich das nicht bezeichnen.

 

[byte]

Sag Deinem Prof mal, dass seine Vorlesungsinhalte lange überholt sind. :roll:

EJB 2 ist der letzte Scheiss und seit Jahren veraltet. Selbst als es aktuell war, wurde es von vielen links liegen gelassen, weil höchst unpraktikabel.

 

[kossy]

Ich glaube, dass weiß er selbst, vielleicht nutzt er die EJB 2.0 noch, um so besser die theoretischen Zusammenhänge erklären zu können?! Ich kenne nun die EJB 3.0 nicht (oder auch POJO's heißen die nun glaube ich), aber vielleicht kann er anhand dieser die Zusammenhänge weniger gut erklären!?

 

[byte]

POJO: http://de.wikipedia.org/wiki/Plain_Old_Java_Object

Auch ich habe damals EJB 2 gelernt in der Uni (damals gabs JEE 5 noch nicht). Die theoretischen Zusammenhänge lernt man da imo aber nicht besser, weil man durch viel zu viel technische Details verwirrt wird. Es mag durchaus richtig sein, dass EJB 2 das Verständis besser fördern könnte, wie ein EJB Container intern arbeitet, aber das wird in solchen Vorlesungen sicherlich nicht vermittelt. Ausserdem ist es wohl eher nur von peripherem Interesse, wenn man damit arbeiten möchte.

Andererseits hats auch was für sich: Du hast Dein Aha-Erlebnis noch vor Dir, wenn Du Dich irgendwann mit EJB 3 beschäftigst und siehst, dass es auch einfach geht.

 

[Guest]

Ich muss euch nochmal kurz etwas zu Instanzen-Pooling fragen. In EJB 2.0 (also der veralteten Version) werden doch nur zustandslose Sessionbeans und Message Driven Beans gepoolt oder? Mein Prof. hat in einer Vorlesung behauptet, dass die Entity Beans und zustandsbehaftete Sessionsbeans nicht gepoolt werden.

Da sich mein Prof. leider oft sehr missverständlich ausdrückt, frage ich lieber hier nochmal bei euch nach. Stimm das? Ich bin ziemlich sicher, dass auch Entity Beans gepoolt werden.

Es geht mir nur um den einfachen Standard und nicht um irgendwelche x-beliebigen Herstellerimplementierungen. Klar ist, dass jeder Hersteller das auch unterschiedlich handhaben kann.

Danke euch !

 

[Guest]

Mit poolen meine ich, dass Instanzenpooling. Hoffe, ich hatte mich klar genug ausgedrückt.

 

[kossy]

War die Frage vielleicht zu undeutlich? Also mit Instanzenpooling meine ich, dass die Instanzen der Beanklassen (welcher letztenendes auch alle nötigen Geschäfts- und Callbackmethoden implementieren) schon vorab zu einer gewissen Anzahl erzeugt werden und dann einfach dem EJB Object hinzugefügt werden, sobald der Client über das EJB Home Objekt die create Methode aufruft.

 

[foobar]

Stateful SessionBeans werden auf keinen Fall gepoolt wie das bei EntityBeans aussah weiß ich auch nicht.