Scambio dati tra portali

[jeck]

Non complicarti la vita, lascia stare l'open base dir. Cambiare password e username su due file è una banalità. E risolve efficacemente il tuo problema.

no infatti, l'open base dir l'ho proprio scartato a priori.
Quindi secondo te anche per altri tipi di implementazione (sempre scambio dati e memorizzazioni nel db dell'altro portale) mi conviene fare in due file separati?
per esempio, ora i due portali danno 2 differenti servizi, ma gli utenti iscritti sono gli stessi, quindi quando si iscrive un utente su un portale in automatico deve finire nell'altro. Ci sono 2 database distinti, quindi ho creato un webservice che permette di spedire i dati da un portale all'altro e fare la memorizzazione. In questo caso le modifiche o nuove integrazioni allo script le ho fatte su un solo file, invece come dici te le avrei dovute fare su due file differenti, con la conseguenza di poter dimenticare qualcosa e commettere più errori.

[W Thunderbird]

no infatti, l'open base dir l'ho proprio scartato a priori.
Quindi secondo te anche per altri tipi di implementazione (sempre scambio dati e memorizzazioni nel db dell'altro portale) mi conviene fare in due file separati?
per esempio, ora i due portali danno 2 differenti servizi, ma gli utenti iscritti sono gli stessi, quindi quando si iscrive un utente su un portale in automatico deve finire nell'altro. Ci sono 2 database distinti, quindi ho creato un webservice che permette di spedire i dati da un portale all'altro e fare la memorizzazione. In questo caso le modifiche o nuove integrazioni allo script le ho fatte su un solo file, invece come dici te le avrei dovute fare su due file differenti, con la conseguenza di poter dimenticare qualcosa e commettere più errori.

Io finora ho fatto così, mi trovo comodo, i file hanno direttive comuni alle applicazioni, ne modifico uno in locale e poi lo spedisco via ftp nelle cartelle delle applicazioni che servono. D'altronde se stanno sulla stessa macchina.. perchè aumentare il carico con un webservice di scambio dati ?
Cmq sono curioso, perchè non mi ci sono mai cimentato, con cosa hai creato il webservice di scambio dati ?

[jeck]

Io finora ho fatto così, mi trovo comodo, i file hanno direttive comuni alle applicazioni, ne modifico uno in locale e poi lo spedisco via ftp nelle cartelle delle applicazioni che servono. D'altronde se stanno sulla stessa macchina.. perchè aumentare il carico con un webservice di scambio dati ?
Cmq sono curioso, perchè non mi ci sono mai cimentato, con cosa hai creato il webservice di scambio dati ?

ad esclusione del file di configurazione che modificare quello non è un problema, ma la mia preoccupazione è se cambia le esigenze del progetto, che potrei cambiare lo stesso codice su due file differenti per avere lo stesso risultato, io vorrei evitare questo, o meglio cercare di ridurlo al minimo.

Immagina l'iscrizione utente, si trova in entrambi i portali e se fatta nel portale principale deve finire anche nel secondario, e non viceversa. Quindi immaginando che l'utente si iscrive al principale, li ho 2 script identici (o quasi) che fanno la stessa operazione, una dal portale principale e l'altra dal portale secondario. Nel caso cambiano i dati da raccogliere per l'iscrizione,devo modificare 2 script, uno presente nel portale principale e l'altro nel secondario. Invece con webservice, socket xml o altro, ho un solo script che si occupa della memorizzazione, quindi le integrazioni vengono fatte in un solo script, con la conseguenza riduzione di errori. Forse è una mia ossessione, ma come logica mi sembra corretta.

Il webservice l'ho fatto in php e xml. un portale genera un xml con i dati che mi interessa, e li spedisce ad un file php esterno, tale file elabora il file xml con i dati e i comandi da eseguire, i comandi sono i vari metodi della classe. Al termine delle operazioni il file php restituisce un file xml con l'esito delle operazioni.

[W Thunderbird]

Premesso che "webservice" mi pare esagerato, la tua logica è corretta (Io uso chiamare webservice i programmi che godono di vita propria, che in php non si possono fare, ma è una cosa mia.. ). Devi aspettarti però che piccole modifiche ai rispettivi siti li dovrai comunque fare in caso di cambiamenti.

Lo script php non gode di vita propria, lo devi avviare tu con una richiesta.
Dato che mi sembra di capire che i dati da passare da un portale all'altro sono poca roba, mi sembra inutile l'uso del file.
L'uso di file xml o altri standard basati su file (anche inventati di sana pianta) è tipico dell'elaborazione in due tempi. Io mando il file, il webservice (che gode di vita propria), quando può elabora il file e mi restituisce un file con i risultati delle operazioni che io ricevo quando ho tempo.
Se è tutto in tempo reale, come php è obbligato a fare, a quale pro doversi scambiare file e non direttamente i dati ?
Ridurresti la complessità e la memoria utilizzata.

[jeck]

Premesso che "webservice" mi pare esagerato, la tua logica è corretta (Io uso chiamare webservice i programmi che godono di vita propria, che in php non si possono fare, ma è una cosa mia.. ). Devi aspettarti però che piccole modifiche ai rispettivi siti li dovrai comunque fare in caso di cambiamenti.

Lo script php non gode di vita propria, lo devi avviare tu con una richiesta.
Dato che mi sembra di capire che i dati da passare da un portale all'altro sono poca roba, mi sembra inutile l'uso del file.
L'uso di file xml o altri standard basati su file (anche inventati di sana pianta) è tipico dell'elaborazione in due tempi. Io mando il file, e il webservice, quando può elabora il file e mi restituisce un file con i risultati delle operazioni che io ricevo quando ho tempo.
Se è tutto in tempo reale, come php è obbligato a fare, a quale pro doversi scambiare file e non direttamente i dati ?
Ridurresti la complessità e la memoria utilizzata.

si tutti vero, io impropriamente chiamo webservice, ma in realtà sono script php che ricevono dati xml, elaborano il contenuto e restituiscono dati xml, ovviamente come dici te, tutto in tempo reale. Le piccole modifice vanno sicuramente fatte, considerando che si passano i dati, il portale principale dovrà raccogliere le nuove integrazioni, e il secondario dovrà elaborarle, qundi qualcosa va modificato in entrambi, ma modificare l'intero script di memorizzazione mi sembrava troppo, come confermi te.

non ricorco perché ho scelto di utilizzare tale sistema, è passto oltre un anno, visto ora che devo fare nuove integrazioni mi chiedo se la soluzione adottata sia la migliore o se ci sono strade alternative migliori, in sicurezza e rapidità.

sopra ho scritto di scambio file, ma in realtà non è corretto, è un mio errore, scambio dati, un file php genera intestazioni e contenuti che poi spedisco all'altro file, non genero file che poi l'altro script elebora, mi sono espresso proprio male.

la tua soluzione quale sarebbe?

[W Thunderbird]

La mia soluzione sarebbe la più "semplice" possibile.. usa curl..
Se sono sulla stessa macchina, tra l'altro, possono comunicare a livello locale (il celeberrimo localhost), non serve chissà quale sicurezza.

[jeck]

La mia soluzione sarebbe la più "semplice" possibile.. usa curl..
Se sono sulla stessa macchina, tra l'altro, possono comunicare a livello locale (il celeberrimo localhost), non serve chissà quale sicurezza.

vero! non ci avevo minimamente pensato. sono sulla stessa macchina, su un VPS.

grazie mille!