Jak w pytaniu mam dwa interfejsy:
@Remote
package a.b
public interface A {} // ziarno ejb
@Remote
public interface B {} // ejb client
Czy to że są w różnych pakietach przeszkadza w czymś ?
Uczę się dopiero EJB i mam problemy ze zrozumieniem jak to dziala pod spodem.
Jedno z drugim nie ma nic wspólnego. Równie dobrze możesz przecież w swojej aplikacji "konsumować" zdalne serwisy wystawione przez zupełnie kogoś innego.
Ale jeśli miałbym coś zasugerować to zostawiłbym EJB ;] Bo praktyka pokazuje że do "własnych" zależności stosuje sie CDI a jeśli już się wystawia jakieś zdalne zależności to jako Webservices a nie jako EJB.
EJB najcześćiej w zasadzie służy do tego aby mieć domyślną transakcję zarządzanę przez kontener, timery itp. Zdalne EJB służą do rozpraszania na wiele różnych kontenerów (serwerów aplikacyjnych) w małym projekcie to tylko skomplikowanie życia i spadek wydajności (serializacja). Do prostego API dostępnego na zewnątrz polecam JAX-RS (które może być EJB, jeśli chcesz aby było to w transakcji). Polecam zostać przy EJB (transakcyjność), ale używać CDI jako DI. Dla CDI nie ma znaczenia czy wstrzykuje EJB czy obiekt CDI. Wreszcie DI w JEE zostało ujednolicone.
@margor90 a czy czasem JEE7 nie rozwiązuje tego problemu z tranzakcjami?
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on CDI managed beans
za http://docs.oracle.com/javaee/7/api/javax/transaction/Transactional.html
Zgapili rozwiązanie ze Springa gdzie było to możliwe już od jakiegoś czasu ;)
Jestem świadomy istnienia @Transactional w CDI. Jeszcze nie korzystałem. To troszkę wygląda na kolejną możliwość rozwiązania tego samego problemu. Zasadnicza różnica między EJB, a CDI to w tej chwili - wydaje mi się - pule obiektów. Oraz oddzielny wątek na transakcję w EJB. Nie wiem jak to w przypadku @Transactional CDI. Faktem jest, że JEE staje się coraz lżejsze i bardziej modułowe. Czasy ciężkich serwerów aplikacyjnych do małych aplikacji dobiegają końca.
Dużą zaletą EJB jest jeszcze asynchroniczne wywołanie metod (fire and forget) w full profile. Z drugiej strony dodali w JEE 7 Managed Executor Service (@Resource pobierany z serwera).
Z ciekawostek mam zamiar wypróbować Payara micro to może być taki Spring Boot na JEE7:
http://www.payara.co.uk/introducing_payara_micro
Warto wspomnieć, że w JEE7 nawet odchodzi się od intefejsów (w JEE5 konieczność imlementacji interfejsu @local/@Remote, w JEE 6 adnotacja @LocalBean, a teraz jest to domyślnie zdaje się, samo @stateless):
http://www.adam-bien.com/roller/abien/entry/injecting_an_executorservice_with_java
Prostota wygrywa i dobrze.
Zdalne interfejsy muszą znajdować się w tych samych pakietach po obu stronach, przynajmniej w Glassfiszu