Devo utilizzare una singola piattaforma per servizi comuni o modularizzarli?

4

Sto progettando una suite di applicazioni web che hanno le stesse funzionalità di base. Cioè, tutti sapranno come creare e operare sui widget. Le differenze saranno nel pubblico di destinazione e in che modo un utente interagirà con un widget. Essenzialmente, se queste applicazioni fossero sviluppate in modo indipendente, ci sarebbe molto di sforzi duplicati.

Per semplificare questo ho pensato a due soluzioni. Vorrei tutti i tuoi commenti sui pro e contro per ciascuna soluzione e che preferiresti.

  1. "Piattaforma" - L'idea è che ci sia un livello di servizio indipendente, un servizio web. Non sarebbe un servizio web, ma semplicemente un back-end per tutte le applicazioni. La piattaforma parlerebbe con le applicazioni tramite la messaggistica o la serializzazione degli oggetti.

    Vorrei scrivere la piattaforma con Java, ma l'intenzione sarebbe che le applicazioni potessero essere scritte con qualsiasi framework web come Rails, Django, Flex o semplicemente qualcosa in Java.

    La piattaforma dovrebbe astrarre il database, quindi tutte le interazioni con il back-end verrebbero effettuate tramite la piattaforma. Un potenziale problema con questo è che l'aggiornamento della piattaforma comporterà la rimozione di tutte le applicazioni. Ma almeno tutte le applicazioni saranno coerenti per quanto riguarda il back-end.

    Mi piace come questo viene tagliato orizzontalmente e che l'applicazione deve solo concentrarsi sul front-end, piuttosto che preoccuparsi di come organizzare il back-end.

  2. "Moduli" - L'idea è che scrivo tutto con Java e sviluppi moduli che possano vivere nei loro barattoli. Ogni modulo rappresenterebbe un modulo Guice e ogni applicazione includerebbe solo i moduli che desiderava e crea i propri iniettori.

    Questo approccio renderebbe ciascuna applicazione completamente indipendente l'una dall'altra, oltre a condividere un database comune. Quindi, teoricamente, sarebbe molto più semplice implementare un'applicazione in un ambiente diverso senza preoccuparsi della piattaforma. Sarei bloccato in un ambiente linguistico, Java. Anche se JRuby e Jython sarebbero disponibili. Quindi forse non è un problema.

    Inoltre, prevedo che è più semplice personalizzare un'applicazione senza eseguire la piattaforma. L'unico problema è che se aggiorno un modulo, vorrei ridistribuire ogni applicazione usando quel modulo. Ciò sarebbe facile con l'integrazione continua, però.

Grazie per il tuo tempo.

Riguardo alla risposta di Gary, ho deciso di adottare un approccio ibrido.

Svilupperò una piattaforma, che sarà il punto di accesso per le applicazioni web a dati e servizi. Quindi modulerò la piattaforma, ma tutti i moduli rimarranno sotto un unico repository con un POM padre. Mentre potrei semplicemente tenerli tutti in un solo JAR, vorrei che la separazione del classpath per scopi di sviluppo, per far pensare me / altri prima di richiedere a un modulo di dipendere da un altro.

    
posta Jeremy Heiler 11.12.2010 - 17:11
fonte

1 risposta

3

Piattaforma

Mi piace l'idea dell'approccio alla piattaforma, ma ci sono un paio di punti che menzioni che mi danno motivo di preoccupazione.

Perché non rendere il back-end del tutto stateless e RESTful? Sai, avere un sacco di servizi Web che forniscono il necessario JSON o XML per guidare i client front-end. Questi client potrebbero essere scritti in qualsiasi lingua che ti piace, purché possano consumare / produrre la necessaria rappresentazione intermedia. Implementare i servizi web RESTful in questi giorni è banale con implementazioni JAX-RS come RESTEasy solo una dipendenza da Maven.

Avere la piattaforma fuori dal database è una buona pratica semplicemente perché vuoi che il tuo cliente e i tuoi servizi siano il più indipendenti l'uno dall'altro.

Hai detto che gli aggiornamenti alla piattaforma significherebbero abbattere l'intero sistema. Perché? Se sei serio su questo, avrai i tuoi cluster live e failover in esecuzione in parallelo. Si aggiorna il proprio cluster di fail-over e si esegue la suite di test di verifica su di esso per assicurarsi che sia in esecuzione. Quindi si cambia il bilanciamento del carico per utilizzare il cluster di fail-over anziché quello live (il live sta diventando fail-over). Se la tua piattaforma è veramente priva di stato, le operazioni dei tuoi clienti saranno ininterrotte poiché il DNS dei tuoi servizi rimane lo stesso.

Eviterei di usare la serializzazione di oggetti Java (ad es. RMI) solo a causa delle restrizioni API binarie che potresti incontrare se decidessi di aggiornare gli oggetti.

Moduli

La condivisione di codice comune tra i moduli è banale con un sistema di compilazione come Maven (o Ivy se non puoi lasciare Ant). Avere un linguaggio back-end comune ridurrà anche la curva di apprendimento per i nuovi sviluppatori. Inoltre avrai senza dubbio una vasta collezione di classi base template per supportare le funzioni comuni nei diversi livelli back-end (DAO, DTO, BO ecc.). (Questo vale anche per l'approccio alla piattaforma).

Dato che ciascun modulo è separato e indipendente l'uno dall'altro è possibile che se gli sviluppatori non comunicano in modo efficace, la duplicazione del codice si verificherà probabilmente all'interno dei moduli. Inoltre, i bug verranno corretti in un modulo, ma persi in un altro. Ciò è particolarmente vero se stai creando più varianti di un modulo per gestire diversi client.

Ovviamente, l'iniezione di dipendenza e una buona progettazione contribuiranno notevolmente a mitigarlo, ma potresti trovare la soluzione più complessa rispetto a quella che potresti fare se segui il percorso della piattaforma.

    
risposta data 11.12.2010 - 23:59
fonte

Leggi altre domande sui tag