Mit dem client jar EJB-3-und design-patterns
Ich bin neu in EJB 3 und ziemlich verwirrt mit einige Zweifel, die Google nicht bieten eine zufrieden stellende Antwort.
Ich versuche zu schaffen, einen Rahmen mit einigen Basis-Klassen und einige utility-Methoden, die meine anderen Anwendungen verwenden können. Alle Anwendungen werden auf dem gleichen server bereitgestellt.
Wenn ich versuche, erstellen Sie ein neues EJB-3.0-Projekt in eclipse, fragt es, wenn ich will erstellen Sie eine client-jar-Datei auch. Welchen Zweck hat dieses client-jar-Datei dienen? Meine ejbmodule ist nun als Teil der EAR-Datei. Also brauche ich wirklich dieses client-jar?
Brauche ich zum erstellen von lokalen und remote-Schnittstellen? Oder einfach nur remote-interfaces zu tun?
Entschied ich mich zu halten, alle Schnittstellen in einem Projekt namens " projCommon und die bean-Definitionen in projApps. Die remote-Schnittstellen, die die bean-Klassen implementieren, sind in projCommon. So projApps ist abhängig von projCommon.
Plane ich die Verwendung einer delegate-Methode definiert, in projCommon berufen sich auf die bean-Klassen. Das bedeutet, dass projCommon ist auch abhängig von projApps, rt? Und führen zu einer zirkulären Abhängigkeit.
Wie genau sind die EJB ' s direkt eingespritzt?
Wäre wirklich hilfreich, wenn Sie uns freundlicherweise eine Erklärung zu meine Zweifel.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Eines EJB-client-JAR-Datei ist ein optionaler JAR-Datei enthält alle class-Dateien, die ein client-Programm nutzen muss der client-Ansicht der enterprise beans, die enthalten sind in der EJB-JAR-Datei. Wenn Sie sich entscheiden, nicht zum erstellen eines client-JAR-Datei für ein EJB-Modul werden alle client-interface-Klassen werden in der EJB-JAR-Datei
Sie tun nicht wirklich brauchen, die EJB-Client-es ist nur einfacher, Verpackungen zu verwenden, die EJBs aus client.
Wenn alle Ihre EJBs in derselben EAR-Datei dann können Sie die Nutzung von lokalen Schnittstellen, wenn nicht müssen Sie die remote-interfaces. Lokale Schnittstellen sind effizienter zu gestalten, sind die Abrufe durchgeführt werden Referenz.
Einige Container (z.B. WebSphere) optimiert diese zur Laufzeit für Sie und rufen automatisch die lokalen Schnittstellen, wenn es möglich ist.
Ich würde immer meine Projekte, organisiert von funktionalen Bereichen. Lokale Anrufe innerhalb der funktionalen Bereiche und remote-diejenigen, die außerhalb der funktionalen Bereiche, Diese können Sie später teilen Sie die Funktionalität bereitgestellt werden, die auf verschiedenen Servern zu skalieren. Es hält auch den code mehr modular. Auch dies vermeidet zirkuläre Abhängigkeiten.
Wie es funktioniert ist egal, Das wird getan, indem der Behälter. Der ganze Punkt von J2EE ist zu Abstrakt aus der wie.
Als pro http://www.developer.com/print.php/3650661:
EJB-3-Container bieten die Einrichtungen zu injizieren verschiedene Arten von Ressourcen in stateless session beans. In der Regel, um Anwender-tasks oder Prozess-Anforderungen von client-Anwendungen, die business-Methoden in der session-bean erfordern eine oder mehrere Arten von Ressourcen. Diese Ressourcen können von anderen session beans, Datenquellen, oder message queues.
Den Ressourcen, die stateless session-bean ist, versucht die injiziert werden können, mithilfe von Annotationen oder deployment-Deskriptoren. Ressourcen können erworben werden durch annotation von Instanz-Variablen oder die annotation der setter-Methoden.
Sehen hier für mehr details. Hoffe, dass dies helfen.