2012-03-20 9 views
10

Quali opzioni ci sono per ottenere comunicazioni a bassa latenza tra due guerre in esecuzione nello stesso jetty-container?Comunicazione in corso tra guerre nello stesso contenitore

Fondamentalmente ho bisogno di chiamare un servizio in una guerra dall'altra, ma non posso permettermi il sovraccarico di chiamarlo come servizio web.

Poiché sono in esecuzione nella stessa JVM, spero di evitare l'utilizzo di RMI/JMS ecc., Ma non so quali altre opzioni sono disponibili?

Ho esaminato la comunicazione tra i servlet, ma poiché l'invocazione diretta del metodo è deprecated, non sembra essere la scelta giusta?

Ho trovato anche kyronet, ma ci sono soluzioni migliori poiché questo è nella stessa JVM?

Quello che sto cercando è qualcosa come Apache Camel VM Component (seda tra le applicazioni web), ma dal momento che solo una delle applicazioni utilizza Camel per questo non è un'opzione.

So che potrebbe essere necessario condividere alcuni DTO tra le due guerre, ma per favore non suggerisco tirando il servizio in una libreria condivisa, se questo era un'opzione non sarei questa domanda :)

Modifica:

Anche l'incorporazione di un contenitore EJB non è un'opzione.

risposta

5

Registrare le interfacce con JNDI e renderle globali in modo che il servlet 'altro' possa recuperarle dal repository.

check this

(nota: abbiamo rinunciato JNDI a favore della nostra implementazione proprio registro, ma iniziamo il Registro di sistema e Jetty di programmazione nella stessa JVM)

+0

Grazie per la tua risposta! Perché hai rinunciato al supporto JNDI di Jetty? Quindi hai implementato il tuo NamingManager, ma continui a utilizzare l'API Context o hai eliminato JNDI tutti insieme?Potresti indicarmi qualche risorsa che descrive come registrarla in modo problematico con Jetty? Oh, e infine, gli oggetti trasferiti attraverso questa soluzione sono passati per riferimento o serializzati? – ebaxt

+0

Passiamo per "riferimento" in modo che le istanze degli oggetti siano direttamente indirizzabili. JNDI va bene: prova questo link per alcune informazioni [collegamento] (http://docs.codehaus.org/display/JETTY/JNDI). Il motivo per cui lo abbiamo abbandonato è stato duplice: volevamo più flessibilità (registri multipli con interfacce fisse, funzionalità di query, registrazione runtime) e un pacchetto più snello (JNDI è generico e fornisce funzionalità che non sono necessarie). L'implementazione del tuo registro richiede che tu gestisca correttamente la vita Webapp, che potrebbe non essere facile. –

+0

Impressionante, grazie mille! – ebaxt

2

L'esposizione del servizio come EJB con interfaccia locale sarebbe un'opzione. Lo standard non garantisce che questo verrà implementato come una chiamata diretta quando eseguito attraverso diverse applicazioni, ma apparently most app servers implement it that way. Per la corsa in Jetty, devi utilizzare un contenitore EJB integrabile come OpenEJB, JBoss embeddable o Spring's Pitchfork.

+0

Grazie! Dal momento che abbiamo una grande distribuzione SOA basata su un wrapper embedded-jetty personalizzato, non ho intenzione di far volare un container EJB con il mio manager. – ebaxt

+0

@ebaxt: Sospetto che tutto dipenda dall'etichetta "EJB" e dalla sua cattiva reputazione di 10 anni fa. Se non viene trovata un'altra soluzione semplice, potrebbe valere la pena provarlo. –

+0

Sì, probabilmente hai ragione su entrambi i punti;) – ebaxt

1

E 'possibile "comunicare" tra due applicazioni web co-localizzate utilizzando ServletContext.getContext (String uriPath) e RequestDispatchers (o anche i listener di ServletContext).

suggerito da Reynders Peer (http://www.coderanch.com/t/222608/Web-Services/java/communicate-war-files)

seguito è riportato il codice di lavoro di esempio ho provato :)

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 */