[Java] Architettura distribuita

Allora: siccome c'è da migliorare le performance di un'applicazione in Java "composita" spalmandola su più server avrei bisogno di capire come fare una cosa.

Riassumendo questa applicazione al momento è dotata di una web-app come frontend grazie alla quale gli utenti caricando file vari (pdf, excel ecc) tramite un Wizard.

Caricati i file viene considerato "chiuso" un pacchetto. Questo pacchetto di file deve essere lavorato (spezzare il pdf in pagine, estrarre i testi ecc.) e alla fine viene generato un unico file zip.

La lavorazione è piuttosto onerosa e deve poter avvenire per N pacchetti in simultanea per N clienti.

Al momento web-app e applicazione che lavora i pacchetti si parlano tramite code JMS ma risiedono sulla stessa macchina quindi filesystem comune.

La volontà è di ennuplicare l'applicazione che genera questi pacchetti su più macchine separate dalla web-app per velocizzare il tutto.

Se la web-app che sta sul server A salva i pacchetti sul filesystem di A e manda un messaggio di lavorazione al primo "consumer" libero che magari sta sul server B, C, D ecc (non si può sapere a priori), come faccio a trasferire i file dal filesystem di A sul filesystem di B oppure C oppure D ecc. in modo sicuro e rapido?

I file del pacchetto da lavorare dovrebbero essere spostati così da essere lavorati ed infine il pacchetto zip magari rimandato inditro al filesystem di A (front-end) che rimane come repository unico dei file sorgenti e dei pacchetti finiti mentre appunto i "semilavorati" vengono smandruppati di volta in volta sugli altri vari nodi.

Tnx.

[shinya]

Boh, ci sono 1000 soluzioni...
Che ne dici se:
1) la web app prende i file, li mette su filesystem, e dice ad un processo "broker" che è stato caricato qualcosa (terrei la logica di parlare con i consumer separata dalla web app).
2) metti su un sftp che esponga i file da elaborare (o un un qualche network filesystem, non so la topologia della rete, se le macchine fanno parte della stessa rete o se sono su internet; il punto è avere un qualcosa che esponga i file e si occupi di cifrare i file in transito).
3) il broker "interroga" i consumer disponibili (qui vedi te: se riesci a riutilizzare JMS va bene, altrimenti puoi modificare i consumer e il broker in modo che espongano un'interfaccia http, per dire, e definire un protocollo sopra questo in modo che ci possa parlare via post request; se usi java, con jetty si fa in fretta)
4) i consumer rispondono, e il broker indica i file da elaborare al consumer più scarico.
5) il broker scelto si recupera i file da sftp
6) quando ha finito li ricarica via sftp (o quello che hai scelto) al filesystem originale.

Ti fa cagare?

Molto probabilmente c'è una soluzione più semplice e che richieda meno modifiche al codice esistente, ma così a braccio questo è quello che mi viene in mente.

[cdimauro]

Io usavo e userei Ice.

Ho tenuto anche un talk alla PyCon4. C'è ancora il video, e ti può essere utile per farti un'idea.
Uso Python come linguaggio, ma ovviamente sia i server che i client puoi realizzarli con uno qualunque di quelli supportati.

La cosa interessante è che puoi, ad esempio, implementare velocemente i server in Python, e poi magari reimplementarli in Java, C#, o anche C++, se hai bisogno di maggiori prestazioni.

Originariamente inviato da shinya

Boh, ci sono 1000 soluzioni...
Che ne dici se:
1) la web app prende i file, li mette su filesystem, e dice ad un processo "broker" che è stato caricato qualcosa (terrei la logica di parlare con i consumer separata dalla web app).
2) metti su un sftp che esponga i file da elaborare (o un un qualche network filesystem, non so la topologia della rete, se le macchine fanno parte della stessa rete o se sono su internet; il punto è avere un qualcosa che esponga i file e si occupi di cifrare i file in transito).
3) il broker "interroga" i consumer disponibili (qui vedi te: se riesci a riutilizzare JMS va bene, altrimenti puoi modificare i consumer e il broker in modo che espongano un'interfaccia http, per dire, e definire un protocollo sopra questo in modo che ci possa parlare via post request; se usi java, con jetty si fa in fretta)
4) i consumer rispondono, e il broker indica i file da elaborare al consumer più scarico.
5) il broker scelto si recupera i file da sftp
6) quando ha finito li ricarica via sftp (o quello che hai scelto) al filesystem originale.

Ti fa cagare?

Molto probabilmente c'è una soluzione più semplice e che richieda meno modifiche al codice esistente, ma così a braccio questo è quello che mi viene in mente.

Non capisco cosa intendi per: "terrei la logica di parlare con i consumer separata dalla web app"

Come detto la web-app già ora è solo un'interfaccia che mette un messaggio in coda quando c'è da lavorare un pacchetto. Di fatto la web-app è il PRODUCER.

Dall'altra parte c'è 1 CONSUMER, che dovrebbero diventare N COSUMER che scodano i messaggi che di volta in volta arrivano nella coda stabilita.

Come Message Provider stiamo utilizzando ActiveMQ.

Le macchine dovrebbero far parte della stessa rete e come server usiamo Windows.

[shinya]

Originariamente inviato da Sgurbat

Non capisco cosa intendi per: "terrei la logica di parlare con i consumer separata dalla web app"

Come detto la web-app già ora è solo un'interfaccia che mette un messaggio in coda quando c'è da lavorare un pacchetto. Di fatto la web-app è il PRODUCER.

Dall'altra parte c'è 1 CONSUMER, che dovrebbero diventare N COSUMER che scodano i messaggi che di volta in volta arrivano nella coda stabilita.

Sì, quello che dicevo io era di lasciare la web app inalterata e aggiungere un pezzo che prende i messaggi dalla coda e decide quale consumer dovrà processare l'elaborazione. Dato che, da quanto ho capito, ti serve una logica per decidere quale degli N consumer dovrà occuparsi di una data elaborazione, io non la metterei nella web app, tutto qua. Ma forse questo era superfluo dirlo, ma non conoscendo bene l'architettura attuale l'ho specificato.

[cdimauro]

Se il costo del lavoro del consumer è all'incirca lo stesso, forse potrebbe bastare un semplice round-robin per sceglierne uno.