[*] Discussione su possibili architetture per applicazioni medio grosse

[lupoxxx87]

Originariamente inviato da nuovoUtente86

Questo non è del tutto vero, in quanto l' efficienza dei un sistema rispetto ad un altro, dipende esclusivamente dal tipo di protocollo utilizzato sul trasporto stesso.
Un socket, in fondo, individua una qudrupla di indirizzamento, per cui una volta instaurata la connessione, se il mio protocollo è ben studiato, potrei ridurre al minimo il transito di dati, non utili, sulla rete (riducendo il costo solo al carico elaborativo, per gli host, di mantenera persistente la connessione).
Del resto anche i soap devono poggiare su protocolli di livello applicazione (come HTTP) che a loro volta non fanno altro che sfruttare, in maniera trasparente, il concetto di socket.

era quello che cercavo di far capire....
usare un socket e un protocollo di trasmissione ad hoc per una rete dove lo scambio di dati è fitto (server-client) ed uno scambio soap per delle comunicazioni sporadiche, come quella con il web service.

e comunque, tutto quello che comunica usando tcp sfrutta un socket... (quella che dicevi tu come quadrupla)
quello che intendevo io è adattare una propria socket+protocollo alle proprie necessità...
se i terminali client non sono molti si può anche pensare a udp se la rete è strutturata a dovere

[nuovoUtente86]

perdonami ma tu scrivi questo:

un socket è come una connessione persistente su cui viaggiano oggetti...per questo non è efficace su un ws remoto.

con il soap tu mandi un oggetto o una richiesta e ottieni una risposta, senza usufruire della banda quando non stai trasferendo

il che non è vero nella misura in cui qualunque sia il protocollo applicatico utilizzato (che evidentemente può fare la differenza prestazionale), a parità di trasporto (e livelli sottostanti) ha il medesimo comportamento (giusto per fare un esempio terra terra, sia che si utilizzi un Servizio basato su http, sia che si sparino una serie di Object java su uno stream TCP, avrò comuqnue l' utilizzo di banda solo quando effettivamente trasmetto). Ovviamente sarà un' attenta analisi dei requisiti e delle entità in gioco a far optare per una soluzione rispetto ad un' altra, ma non si può dire a prescindere o a priori che una sia meno efficiente o performante rispetto ad un' altra.

[tomminno]

Originariamente inviato da omniteo790

Quindi sei concorde con me che un'architettura con server (servizi soap) e client è migliore e scalabile?

Direi che al momento è la strada più battuta.

Parlando di tecnologie cosa suggeriresti? E' sbagliato pensare a java lato server side in modo tale da poter utilizzare server linux e .net come client desktop in modo tale da realizzare interfaccie standard in modo veloce?

Personalmente ho avuto molte rogne a far comunicare client .NET con ws in Java specilamente quando si vanno ad usare tutte le funzionalità degli standard WS-* (una volta mi è capitata pure una vecchia versione di Axis che generava il wsdl sbagliato e non validato dal .NET ma il fornitore del servizio non aveva nessuna intenzione di porvi rimedio).

Per quanto riguarda gli applicativi desktop in ambito aziendale sono problematici da gestire, gli update comportano una politica di aggiornamento globalizzata con il rischio che ci sia sempre qualcuno con un client non aggiornato che possa combinare danni.

Oppure è meglio uniformare le tecnologie? Con la possibilità futura di realizzare inoltre client web (tecnologia a scelta grazie a beckend SOAP)?

In ambito aziendale client web tutta la vita.

[omniteo790]

Originariamente inviato da tomminno

In ambito aziendale client web tutta la vita.

Per la manutenzione dei client ti do ragione. Ma se l'intera azienda avesse un disco condiviso da dove lanciare il o i client aziendali (exe sebza installare ) i problemi sarebbero risolti senza dover installare nulla. (Soluzione forse un po bruttina). Comunque ho capito quello che dici e lo condivido. L'unico problema è quando ci si trova di fronte a delle funzionalità più complicate che necessitano di una potenza e dei privilegi maggiori sulla macchina dell'utente. In questo caso occorre inevitabilmente utilizzare Client desktop no?

[tomminno]

Originariamente inviato da omniteo790

Per la manutenzione dei client ti do ragione. Ma se l'intera azienda avesse un disco condiviso da dove lanciare il o i client aziendali (exe sebza installare ) i problemi sarebbero risolti senza dover installare nulla. (Soluzione forse un po bruttina).

Intanto dovresti avere un eseguibile per ogni possibile piattaforma aziendale.
Esecuzione in locale di un file remoto? Si va incontro a tanti di quei problemi (a partire dai permessi) che secondo me non ne vale la pena. Oltretutto se nessuno utilizza questa soluzione un motivo deve esserci.

Comunque ho capito quello che dici e lo condivido. L'unico problema è quando ci si trova di fronte a delle funzionalità più complicate che necessitano di una potenza e dei privilegi maggiori sulla macchina dell'utente. In questo caso occorre inevitabilmente utilizzare Client desktop no?

Quali sarebbero questi funzionalità complicate?
E per quale motivo un software gestionale aziendale dovrebbe richiedere dei privilegi maggiori sulla macchina utente?
Stiamo sempre parlando di un software aziendale non di un software per il calcolo distribuito.

[omniteo790]

Originariamente inviato da tomminno

Intanto dovresti avere un eseguibile per ogni possibile piattaforma aziendale.
Esecuzione in locale di un file remoto? Si va incontro a tanti di quei problemi (a partire dai permessi) che secondo me non ne vale la pena. Oltretutto se nessuno utilizza questa soluzione un motivo deve esserci.

Ah ok...non cercerò di documentarmi un po e osservare i prossibili problemi.

Originariamente inviato da tomminno

Quali sarebbero questi funzionalità complicate?
E per quale motivo un software gestionale aziendale dovrebbe richiedere dei privilegi maggiori sulla macchina utente?
Stiamo sempre parlando di un software aziendale non di un software per il calcolo distribuito.

Bhe se per esempio devo creare dei file sul pc dell'utente oppure lanciare qualche programma/exe esterno non potrei con i privilegi del browser a meno di non usare applet.

[tomminno]

Originariamente inviato da omniteo790

Bhe se per esempio devo creare dei file sul pc dell'utente

Se devi "scrivere" semplicemente fai scaricare il file generato sul server.

oppure lanciare qualche programma/exe esterno non potrei con i privilegi del browser a meno di non usare applet.

Personalmente non ho mai visto una cosa simile a livello aziendale nè tantomeno ricevuto richieste in tal senso. Tutto ruota intorno al web e ad operazioni centralizzate.
Specialmente perchè all'interno dell'azienda non tutti hanno gli stessi software, nemmeno la stessa versione di Office, figuriamoci il resto (sistemi operativi differenti in primis).

Alla fine se lanci un programma sul computer utente significa che questo deve eseguire operazioni su quel computer, ma che utilità può avere a livello aziendale? L'utente può benissimo avviarlo da solo il programma, dopotutto deve comunque interagirci. Per lanciare procedure automatiche esistono le policy di dominio che solo al di fuori dello scopo di un gestionale.
Alla fine l'utilità sarebbe quella di avere un link per aprire un programma locale no?

[omniteo790]

Originariamente inviato da tomminno

Se devi "scrivere" semplicemente fai scaricare il file generato sul server.



Personalmente non ho mai visto una cosa simile a livello aziendale nè tantomeno ricevuto richieste in tal senso. Tutto ruota intorno al web e ad operazioni centralizzate.
Specialmente perchè all'interno dell'azienda non tutti hanno gli stessi software, nemmeno la stessa versione di Office, figuriamoci il resto (sistemi operativi differenti in primis).

Alla fine se lanci un programma sul computer utente significa che questo deve eseguire operazioni su quel computer, ma che utilità può avere a livello aziendale? L'utente può benissimo avviarlo da solo il programma, dopotutto deve comunque interagirci. Per lanciare procedure automatiche esistono le policy di dominio che solo al di fuori dello scopo di un gestionale.
Alla fine l'utilità sarebbe quella di avere un link per aprire un programma locale no?

Si forse l'unico esempio che mi viene in mente è quello che un possibile software possa accedere a informazioni centralizzare e doverle poi trasferire tramite rs232 ad un macchinario collegato al pc locare. In questo caso però si sarebbe costretti a realizzare App desktop.

Cmq per tutto il restro del software forse è meglio come dici tu rimanere in ambito Web. Forse l'unico problema è che la "user experience" di utenti che hanno sempre utilizzato un'applicazione desktop rispetto a quella web è differente. Per il resto è solo una questione di tempistiche di sviluppo del software. Realizzare un applicazione desktop è in alcuni casi più veloce che realizzarne una Web graficamente accattivante. Però questa mia opinione è opinabile

[tomminno]

Originariamente inviato da omniteo790

Si forse l'unico esempio che mi viene in mente è quello che un possibile software possa accedere a informazioni centralizzare e doverle poi trasferire tramite rs232 ad un macchinario collegato al pc locare. In questo caso però si sarebbe costretti a realizzare App desktop.

Difficilmente questa casistica si ripete per centinaia di computer di un'azienda.
Oltretutto è talmente specifica che un gestionale neanche la contempla: magari per sviluppare tale software è necessario avere a disposizione il macchinario, conoscere il protocollo e magari avere tutti gli strumenti hardware e software di sviluppo, che non sono ovviamente in dotazione ad un'azienda che fa gestionali.

Cmq per tutto il restro del software forse è meglio come dici tu rimanere in ambito Web. Forse l'unico problema è che la "user experience" di utenti che hanno sempre utilizzato un'applicazione desktop rispetto a quella web è differente. Per il resto è solo una questione di tempistiche di sviluppo del software. Realizzare un applicazione desktop è in alcuni casi più veloce che realizzarne una Web graficamente accattivante. Però questa mia opinione è opinabile

Finchè non devi realizzare lo stesso software per almeno 3 sistemi operativi...
E no, non ho ancora visto un applicativo Java che si potesse definire "graficamente accattivamente" (che non significa ovviamente che non esistano). Vallo a raccontare agli utenti mac della user experience di un software java.
Oltretutto oggi tutti hanno sono abituati ad usare il web, mentre adattarsi ad un nuovo software desktop richiede più tempo.

[omniteo790]

Originariamente inviato da tomminno

Finchè non devi realizzare lo stesso software per almeno 3 sistemi operativi...
E no, non ho ancora visto un applicativo Java che si potesse definire "graficamente accattivamente" (che non significa ovviamente che non esistano). Vallo a raccontare agli utenti mac della user experience di un software java.
Oltretutto oggi tutti hanno sono abituati ad usare il web, mentre adattarsi ad un nuovo software desktop richiede più tempo.

Sul fatto che è difficile creare app desktop java accattivanti ti do ragione, intendevo con tecnologie .net (piuttosto facili da realizzare) ma ovviamente solo in ambito Windows.

Comunque rimanendo in ambito Web secondo te sarebbe una scelta azzardata utilizzare per la parte di presentazione tecnologie come Flex? e come backend scegliere le Servlet (ed eventualmente introducendo un ulteriore strato tipo EJB o Web services - non saprei quale è meglio)? oppure andresti su tecnologie asp.net? questo però capisco che dipenda molto dalla tipologia di server che una azienda possiede

[marco.r]

Originariamente inviato da tomminno

Difficilmente questa casistica si ripete per centinaia di computer di un'azienda.
Oltretutto è talmente specifica che un gestionale neanche la contempla: magari per sviluppare tale software è necessario avere a disposizione il macchinario, conoscere il protocollo e magari avere tutti gli strumenti hardware e software di sviluppo, che non sono ovviamente in dotazione ad un'azienda che fa gestionali.

Esempi real-life che ho visto io:
identificazione dell'utente all'interno del programma tramite lettore di impronte digitali, acquisizione di documenti cartacei dal banco, e in generale tutti quei casi in cui occorre effettuare l'immissione di dati in forma "non convenzionale" per cui il browser non basta. Si puo' ovviare in qualche modo (activex ad esempio) ma non è banalissimo.

[tomminno]

Originariamente inviato da marco.r

Esempi real-life che ho visto io:
identificazione dell'utente all'interno del programma tramite lettore di impronte digitali,

Generalmente è l'accesso al computer che viene gestito da policy di dominio (eventuali eToken o accessi con impronte digitali).
Più facilmente si utilizzano ancora i cari vecchi username e password (magari di dominio) per accessi particolari via web.
Comunque in qualche caso particolare potrebbe essere richiesto tale tipo di autenticazione, ma proprio per tutti i dipendenti dell'azienda?

acquisizione di documenti cartacei dal banco, e in generale tutti quei casi in cui occorre effettuare l'immissione di dati in forma "non convenzionale" per cui il browser non basta. Si puo' ovviare in qualche modo (activex ad esempio) ma non è banalissimo.

Utilizzo di scanner e upload di relativo file pdf? Per lo meno dove lavoro l'acquisizione di documenti cartacei avviene così, poi alcuni vengono elaborati centralmente per l'estrazione dei dati.

[marco.r]

Originariamente inviato da tomminno

Generalmente è l'accesso al computer che viene gestito da policy di dominio (eventuali eToken o accessi con impronte digitali).
Più facilmente si utilizzano ancora i cari vecchi username e password (magari di dominio) per accessi particolari via web.
Comunque in qualche caso particolare potrebbe essere richiesto tale tipo di autenticazione, ma proprio per tutti i dipendenti dell'azienda?



Utilizzo di scanner e upload di relativo file pdf? Per lo meno dove lavoro l'acquisizione di documenti cartacei avviene così, poi alcuni vengono elaborati centralmente per l'estrazione dei dati.

Nel caso che ho visto io si trattava della parte di vendita al banco di un negozio, dove meno tempo l'operatore perde meglio e'. Tra acquisire un pdf con il relativo upload e avere una procedura integrata che fa acquisizione ocr, eventuale riacquisizione e correzione dei dati immessi ne passa, soprattutto se hai un cliente scalpitante davanti.
In particolare nel caso che ho visto io gli operatori non avevano una postazione fissa ma condividevano un certo numero di terminali, per cui si dovevano autenticare ad ogni vendita e anche qui usare un sistema di autenticazione piu' rapido aiuta.
Si tratta magari di un contesto specifico, ma direi non troppo raro. Una soluzione può anche essere quella di lasciare il programma "via web" affiancandogli delle piccole applicazioni specifiche che facciano l'input in modo diverso, ma la magia del "tutto via web e zero fatica deployment" viene un po' meno.

[omniteo790]

Vi ringrazio per le opinioni che mi avete dato.

Ma ora spostando la discussione sulle tecnologie. Qual'è la vostra esperienza in merito sia in ambito Web che Desktop. Java, .net etc.