Zastanawiam się, dlaczego potrzebujemy oddzielnych interfejsów zdalnych i lokalnych dla komponentów bean sesji EJB 3.0. Sądzę, że przez większość czasu obaj określiliby tę samą umowę. Dlaczego nie mogę mieć wspólnego interfejsu i w moim Beanie powinienem móc powiedzieć, że chcę, aby ten komponent był dostępny zdalnie i/lub lokalnie.Dlaczego potrzebujemy oddzielnych interfejsów zdalnych i lokalnych dla ziaren sesji EJB 3.0
dzięki Vikas
Nie zgadzam się, że w czasie projektowania zdalne i lokalne powinny być traktowane jako trywialnie inter-changeable.
Po pierwsze, w zdalnym wywołaniu występują koszty ogólne, więc przy projektowaniu interfejsów zdalnych należy uważnie rozważyć, czy masz odpowiednią szczegółowość i parametry. Przypomnienie: będzie to stosunkowo kosztowne. jest pomocny jako projektant.
Ponadto, biorąc pod uwagę, że parametry zdalnego interfejsu są przekazywane wartością, a parametry lokalnego interfejsu są przekazywane przez odniesienie, istnieją zasadnicze różnice semantyczne między tymi dwoma przypadkami, dlatego możesz wybrać zaprojektowanie obu interfejsów w różny sposób.
Pojęcie "przezroczystości lokalizacji" to niebezpieczny anty-wzór. Twój projekt absolutnie musi wiedzieć, czy wykonuje połączenie lokalne czy zdalne, z wielu powodów (obsługa błędów i wydajność są najbardziej oczywiste).
Zdalne interfejsy EJB różnią się od ich lokalnych odpowiedników, ponieważ sygnatura wyjątku musi być inna, aby uwzględnić błędy związane z siecią, które mogą wystąpić tylko w zdalnym wywołaniu. Siodłanie bagażu zdalnie sterowanego do interfejsu lokalnego (tak jak w przypadku EJB 1) sprawia, że kod jest okropny. EJB 2 wprowadził oddzielne lokalne interfejsy, aby uprościć programowanie EJB, które zawsze były lokalne.
Myślę, że pytanie brzmi, dlaczego nie mogę wybrać tego, gdy deklaruję zastrzyk? –
To co mówi specyfikacja EJB:
Wybór pomiędzy lokalnym i zdalnym modelu programowania jest decyzja projektowa, że dostawca Bean sprawia przy opracowywaniu fasola przedsiębiorstwa.
Chociaż możliwe jest zapewnienie zarówno zdalnego widoku klienta, jak i lokalnego klienta dla komponentu EJB, bardziej typowo tylko jeden lub drugi będzie dostarczony.
Więc pisząc fasoli myśleć o tym, kim jest klient, to jest bardzo prawdopodobne, że lokalny klient będzie potrzebował tych samych metod, a nawet tego samego fasoli że zdalny jeden.
Dobrym powodem jest to, że uzyskujesz dostęp do EJB poprzez jego interfejs. W ten sposób przekazujesz parametr po wartości, gdy używasz zdalnego interfejsu i przez odniesienie, gdy używasz lokalnego interfejsu. I czy wiesz, dlaczego to zachowanie? ma to sens: może chcesz, aby aplikacja zdalna uzyskiwała dostęp do obiektu biznesowego, a przekazywanie przez odniesienie zmniejsza opóźnienie sieci. Pamiętaj: zdalny dostęp to proces przekształcania obiektu w strumień bajtów - marshaling - i proces przekształcania strumienia bajtów w obiekt - niemaganie. Ten dodatkowy krok - Marshaling i unmarshaling - spowalnia działanie aplikacji.
'... ponieważ przekazywanie według wartości zmniejsza opóźnienie sieci. Wyobrażam sobie, że pisałeś to zbyt szybko, ponieważ jest po prostu odwrotnie: przekazuj ** referencje ** redukuje sieć _traffic_ (drobny szczegół) :) –
@ ᴠɪɴᴄᴇɴᴛ Dziękuję! –
wierzę, że gdy potrzebuje Twoja firma wszystkie metody w lokalnej muszą być również narażone na klientów zdalnych, a następnie
ten podejście może być pracą wokół osiągnięcia @Local & @Remote do tego samego interfejsu. Dostęp do tej samej metody można uzyskać lokalnie, jeśli jest to wymagane i zdalnie, jeśli jest to wymagane, bez żadnych dodatkowych kosztów.
To jest moja myśl. Ktoś daj mi znać swoje myśli, aby to potwierdzić.
To interesujący pomysł, czy dowiedziałeś się, że twój pomysł jest poprawny?To w rzeczywistości nie generuje kosztów ogólnych. Mam podobne pytania na ten temat: http://stackoverflow.com/questions/6361937/application-client-access-ejb-on-glassfish-via-a-remote-interface-can-i-do-it-vi. Miałem nadzieję, że możesz tu przedstawić pewne myśli. tyvm –
Klienci uzyskują dostęp do sesji lub komponentu bean obiektu za pośrednictwem interfejsów komponentu bean. Kontener EJB generuje implementacje interfejsu w celu wymuszenia i zarządzania tym zachowaniem, działając jako kanał komunikacji między klientem i komponentem bean. W wersjach przed specyfikacją EJB 2.0 wszystkie komponenty zostały zdefiniowane i zaimplementowane jako rozproszone, zdalne komponenty. W rezultacie dwa interfejsy wymagane od komponentów bean zostały określone jako interfejs macierzysty (który ogólnie definiuje metody cyklu życia) i interfejs zdalny (który ogólnie definiuje funkcjonalne metody biznesowe).
Internally, J2EE uses the Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) to enable remote, distributed method calls and applications. While this approach provides many benefits, it also generates a large amount of overhead, with a corresponding performance hit as stubs are referenced, parameters go through the marshaling process, and objects are tossed around the network.
Considerations of performance, practicality, and typical usage in the field resulted in the introduction of local interfaces in the EJB 2.0 specification. As noted, prior terminology referred to the home interface and the remote interface; at this point, depending on which approach is used, local interface and local home interface or remote interface and remote home interface are better terms. Either of the local home or remote home interfaces is referred to as the home interface; either of the local or remote interfaces is referred to as the component interface. This tutorial refers to the interfaces in these terms and uses these conventions for names.
When using J2EE technologies, it is normal to focus on distributed, or remote, beans, but you should keep the local option in mind, when applicable. It may be surprising to learn that a bean can have local interfaces, remote interfaces, or both. However, the client must write to a specific (that is, local or remote) interface. There are some issues to keep in mind when using local interfaces:
Ziarna muszą przebiegać w tej samej maszynie wirtualnej - w końcu są lokalne. Parametry są wysyłane przez odniesienie, a nie przez kopiowanie, tak jak w przypadku zdalnych interfejsów i obiektów. Jeśli zignorujesz to rozróżnienie i nie zapiszesz odpowiednich kodów, mogą wystąpić nieoczekiwane efekty uboczne. Zwykle na decyzję o użyciu dostępu lokalnego lub zdalnego wpływa:
Typ klienta - Jeśli zawsze oczekujesz, że klient będzie komponentem sieci Web lub innym komponentem, wybierz dostęp zdalny.
Niezależnie od tego, czy ziarna są ściśle lub luźno połączone - jeśli ziarna są od siebie nawzajem i często wchodzą w interakcje, należy rozważyć dostęp lokalny.
Skalowalność - dostęp zdalny jest z natury skalowalny i powinien być stosowany, jeśli ważna jest skalowalność. Po pojawieniu się lokalnych interfejsów w specyfikacji EJB 2.0, większość źródeł zaleca, aby komponenty bean obiektów prawie zawsze opierały się na dostępie lokalnym. Dzięki lokalnym interfejsom większość problemów związanych z wydajnością w zakresie dostępu do danych o bardzo drobnym dostępie znika. Jeśli klient jest zdalny, standardowy wzorzec projektu powoduje, że klient używa zdalnego interfejsu do uzyskiwania dostępu do komponentu bean sesji, który następnie działa jako łącznik z komponentem bean obiektu. Sesja sesji komunikuje się z komponentem bean obiektu za pośrednictwem interfejsu lokalnego (z punktu widzenia wzorca, ta technika nazywa się fasadą sesji i może być faktycznie używana w kontekście zdalnym lub lokalnym).
Ładny tekst, z tym że komponenty bean sesji nie komunikują się z komponentami bean obiektu. Nazwy mogą być nieco mylące, ale w dzisiejszych czasach społeczność społecznościowa sesji z podmiotem zarządzającym podmiotami (JPA). –
Zgadzam się, że w wielu przypadkach może będę musiał zaprojektować różne interfejsy dla tych dwóch, ale w przypadkach, w których mam ten sam interfejs dla tych dwóch, powinienem być w stanie opisywać je za pomocą zarówno lokalnego, jak i zdalnego. Zaletą tego jest to, że mój klient nie musi się martwić o to, czy jest to wywołanie lokalne czy zdalne (z wyjątkiem sytuacji, gdy określa nazwę jndi). Otrzyma ten sam interfejs w obu przypadkach, dzięki czemu będzie mógł traktować oba z nich jednakowo. –
Cóż, na dobre i na złe, autorzy specyfikacji nie zgodzili się, że taka "lokalna/zdalna niezależność" jest pożądana. Osobiście zgadzam się z autorami specyfikacji na ten temat. – djna