[*] Discussione su possibili architetture per applicazioni medio grosse [Archivio]

omniteo790

13-04-2010, 09:01

Apro questo topic per poter fare esprimere a tutti le loro idee riguardo a delle possibili architetture software specificando ovviamente l'ambito e lo scopo dell'applicazione.
Essendo uscito dall'università poco tempo fa e non essendo ancora imbattuto in progetti di grosse dimensioni sono curioso di sentire il parere di esperti.

Per esempio se volessi realizzare un'applicazione gestionale con un numero di utenti elevato cosa consigliereste?
Io ho pensato a queste possibile alternative:

1) Applicazione Web.
* CLIENT: BROWSER
* SERVER: Servlet/Jsp oppure Asp.net o altro
2)
* CLIENT: Applicazioni DESKTOP: (framework .net o java o ?) oppure Browser in base alle esigenze (Ad esempio FLEX)
* SERVER: SOAP Web services che espongono una serie di funzionalità e fungono da Businnes Logic e da interfaccia verso il Database

3)
* CLIENT: Applicazioni DESKTOP: (framework .net o java)
* SERVER: Solo Database e la logica per interrograre il DB risiede del Client

La seconda soluzione mi sembra la più scalabile anche nell'ottica che in sistema debba comunicare con altri sistemi differenti.
Forse un possibili problema potrebbero essere le performace del SOAP?
Ad esempio se uno dovesse scegliere la secoda sarebbe sbagliato utilizzare Java lato server per creare i Web service e il framework .net lato Windows?
Scrivete pure i vostri pareri o delle altre possibili alternative.

lupoxxx87

13-04-2010, 10:33

penso che dovresti essere più chiaro su cosa vuoi realizzare...
(o forse sono io tordo che non lo capisco)

un'applicazione gestionale....per cosa? gestionale per aziende ? tipo i software zucchetti ?

con un numero di utenti elevato...nel senso che distribuisci su larga scala o che molti utenti accedono contemporaneamente ? perchè nel secondo caso perdo il legame con l'idea che mi ero fatto di software gestionale :p

tomminno

13-04-2010, 10:59

Insomma sei partito con l'idea di rifare l'ennesimo gestionale?
Un grande gestionale è un misto dei primi 2 punti.
Avrai a che fare sia con web site sia con webservice e magari qualche applicativo desktop che comunque si interfaccia con i webservice.
Ma è tutto molto molto complesso. Infatti non funzionano

Non funzionano perchè ogni azienda ha le sue esigenze e nessun gestionale è adeguatamente adattabile alle specifiche casistiche (si magari SAP spendendo qualche milione di euro in consulenze gli fai fare quello che vuoi...)

zakmckraken

13-04-2010, 12:03

Ciao!
Dipende dall'obiettivo, dovessi fare qualcosa che deve girare su architetture eterogenee, o con particolari requisiti di accessibilita' userei la
1)
* CLIENT: BROWSER
* SERVER: Servlet/Jsp oppure Asp.net o altro
Nel caso di esigenze particolari come x esempio lavorare offline e sincronizzazione quando possibile, fornendo solo eventualmente la parte browser, userei la
2)
* CLIENT: Applicazioni DESKTOP: (framework .net o java o ?) oppure Browser in base alle esigenze (Ad esempio FLEX)
* SERVER: SOAP Web services che espongono una serie di funzionalità e fungono da Business Logic e da interfaccia verso il Database
La 3 francamente non la prenderei in considerazione, ma dipende sempre anche da che cosa vuole il cliente

e..
...si magari SAP spendendo qualche milione di euro in consulenze gli fai fare quello che vuoi...)
Tutto sommato preferirei qualcosa di fatto bene secondo le mie esigenze che sganciare $$$$$$$$$ a sap :P Anche se visto come viene gestito attualmente lo sviluppo software forse e meglio esternalizzare e lavarsene le mani!!
Con pm+analisti+sviluppatori vari validi farei anche un nuovo progetto!!

Zak

tomminno

13-04-2010, 12:13

Tutto sommato preferirei qualcosa di fatto bene secondo le mie esigenze che sganciare $$$$$$$$$ a sap :P Anche se visto come viene gestito attualmente lo sviluppo software forse e meglio esternalizzare e lavarsene le mani!!
Con pm+analisti+sviluppatori vari validi farei anche un nuovo progetto!!

Zak

Pensa un pò ti fai fare un gestionale più o meno custom, poi l'azienda a cui ti eri rivolto fallisce e...
Oppure mutate esigenze di business ti obbligano a cambiare fornitore del software per limiti intrinseci del gestionale e ovviamente il nuovo ti costringe alla modifica di tutte le procedure che ovviamente erano tarate per far funzionare l'azienda con il vecchio gestionale.
Ho visto personalmente entrambe le casistiche.
Oltretutto il gesitonale perfettamente custom è una pura utopia, sarà sempre un lieve adattamento di un software già esistente all'esigenze del cliente.

Non che bisogna per forza finire nelle mani di SAP (credo che non si parta da meno di 500.000 euro solo per macchine e software, senza assistenza), però per lo meno pagando puoi sempre trovare qualcuno che ci sappia mettere le mani. Con un gestionale custom questo non succede.

zakmckraken

13-04-2010, 12:22

Non che bisogna per forza finire nelle mani di SAP (credo che non si parta da meno di 500.000 euro solo per macchine e software, senza assistenza), però per lo meno pagando puoi sempre trovare qualcuno che ci sappia mettere le mani. Con un gestionale custom questo non succede.

Nota che ho detto "Con pm+analisti+sviluppatori vari validi". Questo implica che ci sia una analisi, che ci sia documentazione comprensibile, che il software sia scritto bene! :P Altrimenti costa sicuramente meno, anche come tempo sfruttare soluzioni gia'presenti, e accettabilmente solide!
Certo che se tutto viene fatto come l'ultimo progetto "enterprAis" a cui ho partecipato in cui viene seguita la metodologia "spaghetti".. manco il Dio dei Programmatori riesce a capirci qualcosa senza un aiuto divino!

(tutto imho)

omniteo790

13-04-2010, 12:25

Sinceramente non ho nessun progetto da realizzare, però voglio solo capire le possibili architetture.

Comunque se per esempio volessi realizzare un software aziendale generico (che permetta di gestire delle informazioni aziendali/prodotti e che lo si voglia realizzare completamente custom) e che abbia un numero elevato di utenti contemporaneamente consessi come lo organizzareste?

Ad esempio se il front-end utente dovesse essere un'applicazione desktop come organizzereste il back-end?

Partendo dal presupposto che non si voglia incorporare nessuna logica di businnes nei client

Ad esempio all'univeristà mi avevano fatto studiare in ambito java RMI per realizzare applicazioni client/server ma forse oggi non ha più molto visto il continuo sviluppo dei web services.

lupoxxx87

13-04-2010, 12:50

omniteo790

13-04-2010, 13:03

io strutturerei così :

WEB SERVICE CENTRALE
|
|
(WEB) SERVER AZIENDALE --- DATABASE
/|\
/ | \
CLIENT AZIENDALI

in modo da avere sul server aziendale, o web server a seconda di come si realizza, l'accesso al database, altre funzionalità di connessione (se salta la connessione durante un operazione, etc...), i moduli per il prelievo di dati sensibili (cambio di valute in tempo reale, connessione con banche blablabla) in connessione con il ws, mentre i client non forniscono altro che un amichevole interfaccia di accesso ai dati :p

Ok perfetto, quindi esporresti tramite il (WEB) SERVER AZIENDALE un numero di servizi SOAP che i diversi client potrebbero invocare?
In confronto a tecnologie "like RMI" questa soluzione forse è meno efficiente ma secondo me è la più scalabile nell'ottica di un domani di dover intefacciare il proprio sistema con altri software.

E nell'ottica di introdurre anche client web realizzeresti un'architettura di questo genere?

APP SERVER (es: jsp) <--> (WEB - SOAP) SERVER AZIENDALE<->DATABASE
/|\--------------------------------- /|\
/ | \--------------------------------/ | \
CLIENT AZIENDALI (browser) CLIENT AZIENDALI (desktop)

lupoxxx87

13-04-2010, 13:18

Ok perfetto, quindi esporresti tramite il (WEB) SERVER AZIENDALE un numero di servizi SOAP che i diversi client potrebbero invocare?
In confronto a tecnologie "like RMI" questa soluzione forse è meno efficiente ma secondo me è la più scalabile nell'ottica di un domani di dover intefacciare il proprio sistema con altri software.

E nell'ottica di introdurre anche client web realizzeresti un'architettura di questo genere?

a mio parere client desktop + server e client browser + web server sono trattabili allo stesso modo, ma non contemporaneamente.
personalmente preferisco la soluzione dell'applicativo desktop perchè i browser, oggi come oggi, pur di fornire funzionalità aggiuntive, appesantiscono di molto il servizio.

se poi nell'architettura della parte aziendale, strutturi l'applicazione su pattern proxy, va a finire che ottieni una struttura molto simile a una RMI su rete interna.
il fatto che sia solo il server aziendale ad interfacciarsi all'esterno garantisce un leggero vantaggio in fatto di velocità ed efficienza di traffico.

riguardo all'interfacciamento server-web service....io credo che la maggior funzionalità la si ottenga inserendo tutte le funzioni principali (gestione magazzino, patrimonio, etc) sul server, e la comunicazione con il web service, attraverso SOAP o altri metodi, utilizzarla solo per aggiornare i dati (conti bancari, valute, disposizioni...)

tutto questo ovviamente è una mia opinione e non pretendo che sia la migliore. è solo la struttura che utilizzerei io per gestire una cosa così

omniteo790

13-04-2010, 14:04

a mio parere client desktop + server e client browser + web server sono trattabili allo stesso modo, ma non contemporaneamente.
personalmente preferisco la soluzione dell'applicativo desktop perchè i browser, oggi come oggi, pur di fornire funzionalità aggiuntive, appesantiscono di molto il servizio.

se poi nell'architettura della parte aziendale, strutturi l'applicazione su pattern proxy, va a finire che ottieni una struttura molto simile a una RMI su rete interna.
il fatto che sia solo il server aziendale ad interfacciarsi all'esterno garantisce un leggero vantaggio in fatto di velocità ed efficienza di traffico.

riguardo all'interfacciamento server-web service....io credo che la maggior funzionalità la si ottenga inserendo tutte le funzioni principali (gestione magazzino, patrimonio, etc) sul server, e la comunicazione con il web service, attraverso SOAP o altri metodi, utilizzarla solo per aggiornare i dati (conti bancari, valute, disposizioni...)

tutto questo ovviamente è una mia opinione e non pretendo che sia la migliore. è solo la struttura che utilizzerei io per gestire una cosa così

Scusa ma forse non ho capito bene io. Tralasciamo per un attimo l'interfacciamento verso l'esterno delle rete aziendale. Ma da quallo che ho capito tu intendi come server aziendare una serie di funzionalità esposte a Web services SOAP o altro?

(SOAP) SERVER AZIENDALE <-----------------> DATABASE
/|\
/ | \
CLIENT AZIENDALI

lupoxxx87

13-04-2010, 14:15

per me il server aziendale è dove risiede effettivamente il programma gestionale.
i client non fanno altro che instaurare una socket con questo e comunicare i cambiamenti di dati etc etc...
se vuoi vederla così, sul client c'è soltanto la GUI per comunicare con il server.

in un sw gestionale ogni cambiamento/modifica/inserimento deve essere comunicato in tempo reale, quindi è bene che il sw stesso sia uno solo, e i client accedono al server e comunicano cosa cambiare, in modo che gli altri client possano vederlo in tempo reale

omniteo790

13-04-2010, 14:29

lupoxxx87

13-04-2010, 14:46

il soap lo usi quando comunichi con un web service, per cui non sai cosa ti arriva, il socket quando hai server-client ben progettati e sai come deve avvenire la comunicazione

omniteo790

13-04-2010, 14:59

il soap lo usi quando comunichi con un web service, per cui non sai cosa ti arriva, il socket quando hai server-client ben progettati e sai come deve avvenire la comunicazione

Ok. Però se i web service li progetto io dovrei ottenere lo stesso risultato del socket. La soluzione socket mi sembra più efficiente ma meno scalabile non trovi?

lupoxxx87

13-04-2010, 15:18

omniteo790

13-04-2010, 15:28

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

Mi sa che non ci intendiamo :-). Non farei una chiamata socket su un web service. I socket non li userei proprio. Esporrei in un server una serie di funzionalità tramite web service soap e li invocherei tramite chiamate SOAP/http attraverso i client. Per esempio con .net è possibile fare questo in modo automatico conoscendo solamente il wsdl di un servizio esistente.

tomminno

13-04-2010, 15:37

Ok. Però se i web service li progetto io dovrei ottenere lo stesso risultato del socket. La soluzione socket mi sembra più efficiente ma meno scalabile non trovi?

Ovvio. Se usi i socket devi pensare ad un protocollo di comunicazione (con relativo parser) e reinventare la ruota per la miliardesima volta, con tutti i bug del caso e problemi di scalabilità che possono presentarsi lungo lo sviluppo.

Potresti anche usare alternative come ICE che già implementano meccanismi affidabili per la gestione distribuita di oggetti con binding per C++/C#/Java.

Ovviamente devi pensare che in un'azienda non esiste una sola piattaforma e un solo linguaggio (sono ancora vivi e vegeti VB6 e ASP...), specialmente se di una certa dimensione.
Perchè sicuramente verranno sviluppati sistemi di interfacciamento interno verso il gestionale, quindi è d'obbligo rimanere quanto più negli standard possibile.

omniteo790

13-04-2010, 16:11

Ovvio. Se usi i socket devi pensare ad un protocollo di comunicazione (con relativo parser) e reinventare la ruota per la miliardesima volta, con tutti i bug del caso e problemi di scalabilità che possono presentarsi lungo lo sviluppo.

Potresti anche usare alternative come ICE che già implementano meccanismi affidabili per la gestione distribuita di oggetti con binding per C++/C#/Java.

Ovviamente devi pensare che in un'azienda non esiste una sola piattaforma e un solo linguaggio (sono ancora vivi e vegeti VB6 e ASP...), specialmente se di una certa dimensione.
Perchè sicuramente verranno sviluppati sistemi di interfacciamento interno verso il gestionale, quindi è d'obbligo rimanere quanto più negli standard possibile.

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

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? Oppure è meglio uniformare le tecnologie? Con la possibilità futura di realizzare inoltre client web (tecnologia a scelta grazie a beckend SOAP)?

nuovoUtente86

13-04-2010, 16:40

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

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.

lupoxxx87

13-04-2010, 16:57

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

13-04-2010, 17:15

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

13-04-2010, 17:22

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

13-04-2010, 17:57

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

13-04-2010, 19:32

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

14-04-2010, 10:26

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.

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

14-04-2010, 11:06

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

14-04-2010, 11:35

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

14-04-2010, 12:24

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

14-04-2010, 13:07

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

14-04-2010, 13:16

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

14-04-2010, 14:21

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

14-04-2010, 15:30

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.