2012-03-20 20 views
10

Jakie są opcje uzyskania komunikacji o małym opóźnieniu między dwiema wojnami toczącymi się w tym samym moście-kontenerze?Komunikacja między procesami między wojnami w tym samym pojemniku

Po prostu muszę połączyć się z usługą w jednej wojnie z drugiej strony, ale nie stać mnie na nazywanie jej usługą internetową.

Ponieważ są one uruchomione w tej samej maszynie JVM, mam nadzieję, że nie będę używać RMI/JMS itp., Ale nie wiem, jakie mam inne opcje?

Przyjrzałem się komunikacji między serwletami, ale ponieważ bezpośrednie wywołanie metody jest deprecated, który nie wydaje się być właściwym wyborem?

Znalazłem także kyronet, ale czy istnieją lepsze rozwiązania, ponieważ jest to w tej samej maszynie JVM?

To, czego szukam, to coś podobnego do Apache Camel VM Component (seda między aplikacjami webowymi), ale ponieważ tylko jedna z aplikacji używa Camela, nie jest to opcja.

Wiem, że muszę podzielić się DTO, pomiędzy wojnami, ale proszę nie sugerować ciągnąc usługę pod wspólną bibliotekę, jeśli to była opcja nie byłaby tym pytaniem :)

Edytuj:

Osadzanie kontenera EJB prawdopodobnie nie jest opcją.

Odpowiedz

5

Zarejestruj interfejsy z JNDI i uczyń je globalnymi, aby "inny" serwlet mógł je pobrać z repozytorium.

Sprawdź this

(uwaga: zrezygnowaliśmy JNDI na rzecz własnej implementacji rejestru ale zaczniemy rejestru i Jetty programowo w tej samej JVM)

+0

Dzięki za odpowiedź! Dlaczego zrezygnowałeś z pomocy JNDI Jetty? Czy zaimplementowałeś własny menedżer NamingManager, ale nadal korzystasz z interfejsu API kontekstowego lub czy upuściłeś JNDI razem?Czy możesz wskazać mi jakiś zasób opisujący jak problematycznie zarejestrować go w Jetty? Och, i wreszcie, czy obiekty przekazywane przez to rozwiązanie są przekazywane przez referencje lub serializowane? – ebaxt

+0

Mijamy "odwołanie", więc wystąpienia obiektów są bezpośrednio adresowalne. JNDI jest w porządku: spróbuj tego linku, aby uzyskać informacje [link] (http://docs.codehaus.org/display/JETTY/JNDI). Powód, dla którego go odrzuciliśmy, był dwojaki: chcieliśmy większej elastyczności (wiele rejestrów ze stałymi interfejsami, funkcjonalności zapytań, rejestrację w czasie wykonywania) i bardziej szczupłego pakietu (JNDI ma charakter ogólny i zapewnia funkcjonalność, której nie potrzebujemy). Wdrożenie rejestru wymaga właściwego obchodzenia się z stylem webapp, co może nie być łatwe. –

+0

Niesamowite, wielkie dzięki! – ebaxt

2

Ekspozycja usługi jako EJB z interfejsem lokalnym byłaby jedną z opcji. Standard nie gwarantuje, że zostanie to zaimplementowane jako bezpośrednie połączenie podczas wykonywania aplikacji, ale apparently most app servers implement it that way. Do uruchomienia w Jetty, musisz użyć wbudowanego kontenera EJB, takiego jak OpenEJB, JBoss embeddable lub Spring's Pitchfork.

+0

Dziękujemy! Ponieważ mamy duże wdrożenie SOA oparte na niestandardowym opakowaniu embedded-jetty, nie zakładam, że kontener EJB będzie latał z moim menedżerem. – ebaxt

+0

@ebaxt: Podejrzewam, że całkowicie zależy od etykiety "EJB" i jej złej reputacji sprzed 10 lat. Jeśli nie pojawi się żadne inne proste rozwiązanie, warto spróbować. –

+0

Tak, prawdopodobnie masz rację w obu punktach;) – ebaxt

1

Możliwe jest „komunikować się” między dwoma kolokacja aplikacji internetowych za pomocą ServletContext.getContext (String uriPath) i RequestDispatchers (lub nawet detektory ServletContext).

Sugerowana przez Reynders peer (http://www.coderanch.com/t/222608/Web-Services/java/communicate-war-files)

Poniżej znajduje się przykładowy kod roboczy próbowałem :)

public void doGet(HttpServletRequest Prequest, HttpServletResponse Presponse) 
    throws IOException, ServletException { 

    ServletContext sc = getServletContext().getContext("/war2"); 
    RequestDispatcher rd = sc.getRequestDispatcher("/LoginHandler?UserId=DummyUser"); 
    rd.forward(Prequest, Presponse); 
} /* End of doGet */