SOA, Java EE e organizzazione dei dati

Se vuoi che questi servizi siano veramente indipendenti, diversi schemi o database diversi sono un approccio migliore secondo me. In futuro è possibile spostare questi servizi su diversi servizi applicativi o suddividere il database in server diversi.

Ma non sono sicuro che una partizione a livello di servizio (REST o SOAP suppongo) sia comoda per lo sviluppo indipendente / facile. È possibile creare la partizione a livello di libreria (diverso .jar per ogni squadra), ogni squadra può lavorare in uno di questi file .jar che espone alcuni clases (un'interfaccia) per gli altri. Hai la stessa indipendenza di sviluppo senza la complessità della distribuzione che hai con diversi servizi.

Con la partizione di servizi, se una modifica non modifica il contratto di servizio con altri servizi o applicazioni, è possibile distribuire / testare solo questo servizio, ma se il servizio modifica questo contratto è necessario modificare / distribuire / verificare tutti i client di questi servizi, sembra facile ma può facilmente trasformarsi in un incubo o in una dipendenza.

A mio parere una partizione a livello di servizio è ok quando viene eseguita per esigenze di distribuzione, dividi il sistema in piccoli pezzi indipendenti implementabili perché in questo modo puoi avere un server dedicato ad alcuni pezzi (un sottosistema con un carico pesante per esempio) o magari replicare lo stesso pezzo in molti server, di solito questo è necessario per motivi di scalabilità. Ma per ragioni di sviluppo, a mio parere, una partizione a livello di libreria è più semplice (io cerco la facilità di sviluppo)

Stai ristrutturando l'architettura dell'applicazione da un monolite ad un approccio più modulare:

At the company I work for, we're currently splitting up our monolith solution into a number of small services (SOA).

Ma perché contare ancora su un server delle applicazioni?

Many of the services are small, so we'd like to deploy a number of these services on the same application server, JBoss 7.1 in this case.

Ci sono altre opzioni oggi disponibili:

• Spring Boot
• Dropwizard
• Vert.x
• Riproduci - come autonomo ecc.

Ogni servizio gestirà la propria connessione DB.

Per lo scenario indicato:

Opterei per il caso con un servizio - un'origine dati - uno schema. Ciò ti offre flessibilità: se ristrutturerai la tua architettura in futuro, potresti spostare facilmente schemi completi su server diversi (inclusi i servizi di risposta). Supponiamo che tu stia sviluppando in un e-commerce -scenario, le parti possibili erano:

• login-infrastrutture
• dati cliente (ad es. indirizzo)
• di ordine-data
• dati per le informazioni di archiviazione (posizione di archiviazione)
• catalogo prodotti ...

Queste sono tutte preoccupazioni diverse nel senso di SoC , che potrebbero essere suddivise.

A seconda della tua crescita, potrebbe essere necessario implementare una infrastruttura di accesso separata.

D'altra parte:

Poiché non conosco la tua attività, né la tua attuale architettura, c'è YAGNI e Ottimizzazione della velocità . Potrebbe essere possibile che tu rifatti il tuo modello corrente in un caso d'uso, il che non accadrà mai (ad esempio, non tutti e-commerce-shop è il prossimo Amazon ).

Analizzando la tua architettura (monolitica), una possibile ristrutturazione dovrebbe emergere da sola. Sai meglio, quali sottosistemi sono usati come.

Qui una buona lettura.

Non sono un esperto di SOA, ma penso che tu stia cercando una soluzione più leggera. In ogni caso, vedi link

Se stai dividendo solo un'applicazione, ti suggerisco di studiare la piattaforma OSGI.

Nel SOA "classico" viene utilizzato un modello di dati canonico link , o almeno è un pattern ampiamente utilizzato.

Non ricevo il problema relativo al prefisso degli oggetti DB. Nel modello di dati canonico si utilizzano schemi xsd per i tipi di dati e si possono inserire in diversi spazi dei nomi xml.