Ho uno script Python su una scatola che voglio chiamare da un server Java, attraverso la rete. So che posso avviare un server sul lato Python e quindi collegarmi ad esso dal sito Java, ma sto cercando di vedere se c'è un modo per evitare il sovraccarico di eseguire un server sul lato Python. C'è un altro modo per farlo?
Bene, in parole povere, senza un server, il lato Python non sarà in grado di ricevere messaggi di rete in arrivo. (In alternativa, se il lato Python è in grado di ricevere messaggi di rete, allora deve esserci un server coinvolto.)
Ci sono alcune opzioni che hai qui.
Incorporare un semplice server personalizzato nell'applicazione Python . Questo server può essere qualcosa che scrivi tu stesso, in base ai socket di rete e al tuo protocollo personalizzato. Ci vuole un po 'di lavoro, ma puoi adattare il protocollo alle tue esatte esigenze e tralasciare tutto il sovraccarico che viene fornito con protocolli più generici, motivo per cui sceglierei questa strada solo se le prestazioni sono critiche e il sovraccarico della rete sarà importante fattore. Se il server Python è connesso a Internet (pubblico), firewall per impedire l'accesso al proprio server personalizzato dall'esterno. Inoltre, poiché la tua applicazione sarà di lunga durata, devi assicurarti di avere una buona gestione degli errori, in modo che possa essere ripristinata ogni volta che qualcosa va storto. Avvolgilo in un ciclo di script di shell (esegui server - sleep - repeat) se vuoi esserne sicuro.
Incorporare un server HTTP nell'applicazione Python . Ci sono alcune librerie che puoi usare per questo, quindi l'overhead di programmazione e test sarà molto inferiore rispetto al protocollo personalizzato. Dal momento che è HTTP, però, avrai un po 'più di overhead e sarai legato al paradigma request / response, che probabilmente sta bene considerando che il server Java avvia la connessione. Proprio come il protocollo personalizzato, questa soluzione ha bisogno di protezione - o firewall, oppure ascoltarla solo su localhost e metterla dietro un proxy inverso.
Implementa il protocollo CGI e gira dietro un "vero" web server . CGI è davvero facile da implementare, ma avrai bisogno di un server web per guidarlo. Inoltre, poiché CGI riavvia il programma per ogni richiesta, dovrai progettarlo per evitare lunghi tempi di avvio. Al rialzo, non dovrai trafficare con le librerie HTTP, i socket di rete e preoccuparti di molti dei problemi di sicurezza correlati: tieni il server host sicuro e non fai niente di stupido all'interno del tuo CGI, e lo farai va bene.
Usa ssh . Ciò non richiede assolutamente alcuno sforzo in più sulla parte Python e probabilmente (non sono un esperto di Java, quindi non lo so davvero) non c'è molto da fare anche sul lato Java; dovrai però creare e impostare una chiave ssh adatta sul lato Java, e dargli accesso sul lato Python. Devi renderlo una chiave ssh senza passphrase, altrimenti il server non sarà in grado di usarlo senza l'intervento umano; questo a sua volta significa che probabilmente desideri un utente dedicato proprio per questo scopo sul lato Python e blocca tale utente fino ai requisiti assoluti.
Utilizza una sorta di libreria delle code dei messaggi . Ho usato ZeroMQ in passato, che è disponibile per tutti i linguaggi di programmazione popolari, ma ce ne sono altri. Continuerai ad implementare un protocollo personalizzato, ma la parte di trasporto di esso viene gestita per te in modo abbastanza efficiente. Questo approccio è particolarmente adatto quando hai bisogno di canali di comunicazione affidabili ed efficienti e non puoi permetterti di riavviare lo script per ogni richiesta. Anche in questo caso, devi prendere tutti gli arresti anomali per assicurarti che si riprenda.
Comunicazione tramite un dispositivo di archiviazione persistente condiviso . Questo può essere un database, un filesystem condiviso, memcache o forse un server che espone una sorta di API di archiviazione persistente. Ciò richiede il polling sulla parte Python, quindi potrebbe non essere la soluzione più efficiente, oltre a dover prestare attenzione alle condizioni di gara e ad altri problemi legati alla temporizzazione. È un'ottima soluzione se si dispone di grandi quantità di dati da elaborare per messaggio, e (a condizione che l'elaborazione sia progettata per essere atomica) sopravviverà vicino a ogni possibile scenario di arresto senza perdita di dati.
Una scelta completamente ortogonale è come apparirà l'API (a livello di messaggio). Per il caso SSH, la questione è già chiara: stai solo passando alcune opzioni da riga di comando al tuo script, non c'è molta scelta lì. Per il resto, tuttavia, il corpo del messaggio può utilizzare qualsiasi formato tu voglia: JSON, XML, testo normale, SOAP, lo chiami. Quale è più sensato dipende dal tipo di dati necessari per alimentare il tuo script.
Esegui lighttpd e mettici un aggancio per creare un file. Avere un lavoro cron verificare se quel file esiste ogni intervallo. Se lo fa, fai un'azione (s), quindi eliminalo.
Avviare un piccolo server (svilupparlo da solo) scritto in Java sulla scatola python non dovrebbe avere troppo overhead, se non si vuole fare questo, allora non c'è un vero modo nativo in Java per farlo .
Alcune opzioni però:
Se si dispone già di un server Web in esecuzione sulla scatola, creare uno script CGI che esegua il programma desiderato. Quando la java box effettua una connessione HTTP all'URL, viene eseguito lo script python.
Utilizza una shell remota e connettici ad essa, ad es. System.exec("rsh remotebox progname");
Utilizza una shell sicura (come sopra), ad es. System.exec("ssh remotebox progname");
In passato usavamo script su vari box avendo un chron job (o Scheduled Task su Windows) che verifica ogni minuto la data su un file in una cartella condivisa. Se la data è cambiata, esegui lo script. Altrimenti, esci e torna di nuovo in un minuto. Davvero low-tech.