[*] Discussione su possibili architetture per applicazioni medio grosse

[omniteo790]

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]

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

[tomminno]

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]

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..
...

Originariamente inviato da tomminno

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]

Originariamente inviato da zakmckraken

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]

Originariamente inviato da tomminno

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]

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]

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

[omniteo790]

Originariamente inviato da lupoxxx87

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

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]

Originariamente inviato da omniteo790

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]

Originariamente inviato da lupoxxx87

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]

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]

Originariamente inviato da lupoxxx87

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

Ok l'idea è quella che ho io solo che quello che mi preme capire è se è meglio fare una comunicazione tramite socket oppure tramite SOAP. Sarebbe sbagliato esporre servizio SOAP al posto di funzionalità tramite SOCKET?

[lupoxxx87]

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]

Originariamente inviato da lupoxxx87

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]

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

[omniteo790]

Originariamente inviato da lupoxxx87

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]

Originariamente inviato da omniteo790

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]

Originariamente inviato da tomminno

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]

Originariamente inviato da lupoxxx87

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.