Ich versuche zu verstehen, was der Zweck ist und warum wir die unterschiedlichen Kundenansichten in EJB benötigen. Könnte jemand versuchen zu erklären?
Ich versuche zu verstehen, was der Zweck ist und warum wir die unterschiedlichen Kundenansichten in EJB benötigen. Könnte jemand versuchen zu erklären?
Antworten:
Remote-Client-Ansicht
Wenn sich Ihr EJB und seine Clients in einer verteilten Umgebung befinden, bedeutet dies, dass sich EJBs und Clients auf separaten virtuellen Java-Maschinen befinden. Beispiel: Auf einem WebSphere Application Server gehostete EJBs und Servlets, die auf einem Tomcat-Server gehostete EJB-APIs verwenden.
Lokale Client-Ansicht
Nur wenn garantiert ist, dass andere Enterprise-Beans oder Clients die Bean nur innerhalb einer einzelnen JVM adressieren. Beispiel: EJBs sowie die Servlets, die auf demselben WebSphere-Server bereitgestellt werden.
No-Interface-Ansicht
Entspricht fast der lokalen Client-Ansicht, es gibt jedoch Unterschiede. Ihre Bean-Klasse ist in diesem Fall nicht erforderlich, um Client-Ansichtsschnittstellen zu implementieren. Alle öffentlichen Methoden der Bean-Klasse werden dem Aufrufer automatisch zur Verfügung gestellt. Die Ansicht ohne Schnittstelle erhält immer eine EJB-Referenz - genau wie lokale oder entfernte Ansichten - entweder durch Injektion oder JNDI-Suche. Der Java-Typ der EJB-Referenz ist jedoch eher der Bean-Klassentyp als der Typ einer lokalen Schnittstelle. Dies ist eine Annehmlichkeit, die als Teil von Java EE6 eingeführt wurde.
Unterschied zwischen lokaler Client-Ansicht und Ansicht ohne Schnittstelle
Bei einer Ansicht ohne Schnittstelle müssen der Client und die Ziel-Bean in derselben Anwendung (EAR) gepackt sein. Bei lokaler Ansicht kann der Client in einer anderen Anwendung als der Unternehmensanwendung gepackt werden. Dies bietet mehr Flexibilität bei der Feinkörnung Ihrer Komponenten.
Abhängig von Ihrem API-Verwendungsszenario können Sie die lokale Clientansicht im Vergleich zur Ansicht ohne Schnittstelle verwenden. Es ist sehr wahrscheinlich, dass die Ansicht ohne Benutzeroberfläche in zukünftigen Spezifikationen flexible Funktionen erhält.
Grund
In der Vergangenheit oder auf andere Weise sollte ein Client, der EJB-Dienste nutzen möchte, die Bean auf dem Container "nachschlagen" (mit bestimmten Anfangskontexten). Dies lag daran, dass alle Aufrufe über eine spezielle EJB-Referenz (Proxy) erfolgen, die vom Container bereitgestellt wird. Auf diese Weise kann der Container alle zusätzlichen Bean-Services wie Pooling, Container-verwaltete Transaktionen usw. bereitstellen. Daher kann ein Client eine EJB nicht explizit mit dem newOperator instanziieren . Die Client-Ansicht wird über bestimmte Schnittstellen bereitgestellt, auf die der Client Zugriff haben würde. Die Proxy-Realisierung auf der Serverseite erfolgt basierend auf diesen Schnittstellen. Wie oben erwähnt, werden unterschiedliche Clientansichten definiert, um unterschiedliche Bereitstellungsszenarien zu berücksichtigen.
newSie eine neue Instanz. Das ist alles. Diese neue Instanz wird vom Container nicht "unterstützt", was das Pooling, das Festlegen des Kontexts usw. betrifft. Sie werden selbst ausgeführt.
Gemäß Abschnitt 3.2.2 von EJB 3.1 Spezifikation:
Der Zugriff auf eine Enterprise-Bean über die lokale Clientansicht muss nur für lokale Clients unterstützt werden, die in derselben Anwendung wie die Enterprise-Bean gepackt sind, die die lokale Clientansicht bereitstellt. Konforme Implementierungen dieser Spezifikation unterstützen optional den Zugriff auf die lokale Clientansicht einer Enterprise-Bean von einem lokalen Client, der in einer anderen Anwendung gepackt ist. Die Konfigurationsanforderungen für den anwendungsübergreifenden Zugriff auf die lokale Clientansicht sind herstellerspezifisch und liegen außerhalb des Geltungsbereichs dieser Spezifikation. Anwendungen, die auf den anwendungsübergreifenden Zugriff auf die lokale Clientansicht angewiesen sind, sind nicht portierbar.
Die Ansicht ohne Schnittstelle ist nur eine praktische Funktion, mit der eine Bean eine lokale Clientansicht verfügbar machen kann, ohne eine separate Schnittstelle deklarieren zu müssen.