Próbuję zrozumieć, jaki jest cel i dlaczego potrzebujemy różnych poglądów klientów w EJB. Czy ktoś mógłby spróbować wyjaśnić?
Próbuję zrozumieć, jaki jest cel i dlaczego potrzebujemy różnych poglądów klientów w EJB. Czy ktoś mógłby spróbować wyjaśnić?
Odpowiedzi:
Widok klienta zdalnego
Gdy EJB i jego klienci będą w środowisku rozproszonym - co oznacza, że EJB i klienci będą rezydować na oddzielnych maszynach wirtualnych Java. Przykład: komponenty EJB hostowane na serwerze WebSphere Application Server i serwlety korzystające z interfejsów API EJB hostowanych na serwerze Tomcat.
Widok klienta lokalnego
Tylko wtedy, gdy jest zagwarantowane, że inne korporacyjne komponenty bean lub klienci będą adresować komponent bean tylko w ramach jednej maszyny JVM. Przykład: komponenty EJB oraz serwlety wdrożone na tym samym serwerze WebSphere.
Widok bez interfejsu
Jest prawie taki sam jak widok klienta lokalnego, ale istnieją różnice. Twoja klasa bean nie jest wymagana do implementacji interfejsów widoku klienta w tym przypadku. Wszystkie metody publiczne klasy bean są automatycznie ujawniane wywołującemu. widok bez interfejsu zawsze uzyskuje odniesienie EJB - tak jak widoki lokalne lub zdalne - albo poprzez wstrzyknięcie, albo wyszukiwanie JNDI; ale typ Java odwołania EJB jest typem klasy bean, a nie typem interfejsu lokalnego. Jest to udogodnienie wprowadzone w ramach Java EE6.
Różnica między widokiem klienta lokalnego a widokiem bez interfejsu
W przypadku widoku bez interfejsu klient i docelowy komponent bean muszą być spakowane w tej samej aplikacji (EAR). W przypadku widoku lokalnego klient może być spakowany w osobnej aplikacji niż aplikacja korporacyjna. Daje to więc większą elastyczność w zakresie drobnoziarnistości komponentów.
Możesz użyć lokalnego widoku klienta lub widoku bez interfejsu w zależności od scenariusza użycia interfejsu API. Jest bardzo prawdopodobne, że widok bez interfejsu otrzyma elastyczne funkcje w przyszłych specyfikacjach.
Powód
Historycznie lub w inny sposób, klient, który chciał korzystać z usług EJB, miał „wyszukać” ziarno w kontenerze (w pewnych początkowych kontekstach). Wynika to z faktu, że wszystkie wywołania są wykonywane za pośrednictwem specjalnego odniesienia EJB (proxy) udostępnionego przez kontener. Pozwala to kontenerowi na dostarczanie wszystkich dodatkowych usług bean, takich jak pule, transakcje zarządzane przez kontener itp. Tak więc klient nie może jawnie utworzyć instancji EJB z newoperatorem. Widok klienta jest udostępniany za pośrednictwem określonych interfejsów, do których klient miałby dostęp. Realizacja proxy po stronie serwera odbywa się w oparciu o te interfejsy. Różne widoki klienta są zdefiniowane w celu dostosowania do różnych scenariuszy wdrażania, jak wspomniano powyżej.
newotrzymasz nową instancję. To wszystko. Ta nowa instancja nie będzie miała żadnego „wsparcia” ze strony kontenera w zakresie tworzenia puli, ustawiania kontekstu itp. Uruchamiasz się samodzielnie.
Zgodnie z sekcją 3.2.2 specyfikacji EJB 3.1:
Dostęp do komponentu bean przedsiębiorstwa za pośrednictwem widoku klienta lokalnego musi być obsługiwany tylko w przypadku klientów lokalnych spakowanych w ramach tej samej aplikacji, co komponent bean przedsiębiorstwa udostępniający widok klienta lokalnego. Zgodne implementacje tej specyfikacji mogą opcjonalnie obsługiwać dostęp do lokalnego widoku klienta komponentu bean przedsiębiorstwa z lokalnego klienta spakowanego w innej aplikacji. Wymagania konfiguracyjne dotyczące dostępu między aplikacjami do widoku lokalnego klienta są specyficzne dla dostawcy i nie wchodzą w zakres tej specyfikacji. Aplikacje korzystające z dostępu między aplikacjami do widoku lokalnego klienta są nieprzenośne.
Widok bez interfejsu to tylko wygodna funkcja, która umożliwia komponentowi bean udostępnianie lokalnego widoku klienta bez konieczności deklarowania oddzielnego interfejsu.