ciao Cosimo,
cosimo.cinefra ha scritto:
mi domando a cosa possano servire le più recenti soluzioni in termini di servizi web se poi non è possibile progettare un deployment distribuito anche geograficamente
Sì, le tecnologie che rendono possibile il deployment distribuito ci sono. Tuttavia, ogni soluzione va esaminata in base al contesto.
Se ogni tua azienda cliente avesse il proprio ufficio costruito sopra la dorsale, e disponesse di 4Mb di banda simmetrica dedicata, allora forse ti avrei consigliato di creare un WCF Data Service per esporre il loro database nel web. Se il loro firewall non avesse consentito di esporre il servizio, avresti comunque potuto consumarlo da remoto per mezzo della funzionalità di Relay del Service Bus di Azure.
http://azure.microsoft.com/it-it/documentation/articles/service-bus-dotnet-how-to-use-relay/Nonostante ti abbia descritto una situazione ideale, siamo comunque dovuti ricorrere a due tecnologie: un servizio WCF e il bus relay di Azure. Lo abbiamo fatto non per il puro gusto di usarle, ma per risolvere due problemi:
- Il database non deve essere esposto a rischi, e perciò lo proteggiamo dietro un servizio WCF, che si occupa anche di autenticare gli utenti ed attuare delle logiche di business.
- Se l'hardware o il contratto di connettività dell'azienda cliente non consentono di esporre una macchina su un indirizzo IP pubblico, dobbiamo avvalerci di un servizio come il Relay del Service Bus di Azure, altrimenti non riusciremmo a collegarci.
Ricorrere a queste due tecnologie ha aggiunto complessità (e costi) al sistema. Prima di procedere, dovremmo valutare se esistono soluzioni più semplici.
Adesso consideriamo il caso reale: non tutte le aziende dispongono di una connessione HDSL con banda dedicata. Anzi, a volte si collegano con una ADSL residenziale. L'ultimo miglio è in rame, e la centralina nelle ore di punta è satura di traffico. A volte possono verificarsi dei disservizi che impediscono agli impiegati di collegarsi ad internet per lunghe ore, perché manca una seconda linea per la
fault tolerance.
Per me questo è un terreno abbastanza accidentato. Non mi azzarderei a costruire un'applicazione - ospitata presso la mia struttura - che
dipenda da un database servito su un collegamento poco affidabile come quello. Chissà con quali latenze di rete, per giunta. Rischierei di rovinare l'immagine del mio servizio, perché quando
miodominio.com non risponde, il cliente penserebbe che il problema sia mio. "A noi tutti gli altri siti internet funzionano", risponderebbero. Invece il problema era che la notte prima gli si era spento il database server per mancanza di corrente.
Se il database fosse un SQL Azure ospitato presso i datacenter di Microsoft, allora la situazione sarebbe diversa perché avrei la certezza che il servizio è affidabile e in mano ad esperti, e che il
Service Level Agreement mi promette un uptime del 99,95%. Anche il client ovviamente dovrà dotarsi di una connettività adeguata (e la banda in download è più economica di quella in upload) ma, se non lo facesse, la causa del problema sarebbe subito evidente: lentezza o disservizi riguarderebbero ogni altro sito o servizio online.
Quindi, anche se è certamente possibile esporre il db sul web, io ti direi che subiresti inutilmente i problemi di connettività del cliente. Se l'applicazione è ospitata da te, puoi anche mettere un avviso grosso così quando il db non è raggiungibile ma sta di fatto che gli impiegati non potranno lavorare finché il problema non viene risolto (e chiameranno te per dargli assistenza).
Se l'applicazione è dal cliente, invece, la connessione ad internet non sarà necessaria e per lo meno quelli che si trovano in rete locale potranno lavorare anche durante i disservizi.
cosimo.cinefra ha scritto:
In particolare mi riferisco a Asp.net Web Api, qual è il loro effettivo scenario di utilizzo ?
ASP.NET WebAPI lo usi quando vuoi realizzare una API RESTful, consumata o da una tua applicazione o dalle applicazioni web di terzi. E' molto interoperabile, quindi può essere consumata da qualsiasi linguaggio o dispositivo in grado di inviare richieste HTTP. Trovi un'introduzione in questo articolo di Andrea Colaci.
http://www.aspitalia.com/articoli/asp.net-mvc/scrivere-servizi-rest-asp.net-web-api.aspxSe sei soltanto tu a controllare sia il client che il servizio (entrambi .NET), ti consiglierei di usare WCF, che ti permetterebbe anche di scambiare dati con un protocollo binario, più efficiente.
Ad ogni modo, WebAPI o WCF non ti risolvono il problema di connettività cui abbiamo parlato, perché le questioni legate alla rete sono ad un livello più basso nello stack.
cosimo.cinefra ha scritto:
vorrei superare le problematiche di installazione inevitabili vista la varietà delle macchine\reti\configurazioni
Ripropongo IISExpress. Le piattaforme supportate sono da XP a Windows 8. E' probabile che vada bene la stessa macchina in cui il gestionale è stato installato. Se il cliente vuole acquistare o dispone già di una versione di Windows server 2008 o superiore, allora andrà anche meglio e tu potrai cavartela con un
deploy package da consegnare all'amministratore.
cosimo.cinefra ha scritto:
Inoltre vorrei avere sotto controllo l'applicazione per poterla aggiornare facilmente senza collegarmi in teleassistenza dal cliente.
Per esempio, puoi farlo così:
http://haacked.com/archive/2011/01/15/building-a-self-updating-site-using-nuget.aspxLe difficoltà che hai citato, prese singolarmente, non sono abbastanza preoccupanti da dover giustificare lo spostamento dell'applicazione web presso altri provider. O sposti anche il database, e ti metti a fare
software-as-a-service, oppure lasci tutto dov'è (secondo me).
Senti anche altri pareri, soprattutto quello di un consulente dato che stai prendendo delle decisioni che riguardano il tuo business. A me interesserebbe sapere cosa ne pensa un amministratore di sistema (io sono uno sviluppatore).
ciao,
Moreno
Modificato da BrightSoul il 04 novembre 2014 20.10 -
