Come implementare allentato accoppiamento con una SOA Architettura

Question

Ho fatto un sacco di ricerca ultimamente su SOA e ESB del ecc

Sto lavorando a ridisegnare alcuni sistemi legacy al lavoro ora e vorrei costruire con più di un'architettura SOA di quanto non sia attualmente. Usiamo questi servizi in circa 5 dei nostri siti web e uno dei più grandi problemi che abbiamo in questo momento con il nostro sistema legacy è che quasi tutto il tempo in cui facciamo correzioni di bug o aggiornamenti abbiamo bisogno di ri-distribuire i nostri 5 siti web che possono essere un tempo abbastanza processo che richiede tempo.

Il mio obiettivo è quello di rendere le interfacce tra i servizi loosely coupled modo che le modifiche possono essere fatte senza dover re-implementare tutti i servizi dipendenti e siti web.

Ho bisogno della capacità di estendere un'interfaccia servizio già esistente senza rompere o aggiornare alcuna delle sue dipendenze. Qualcuno di voi incontrato questo problema prima? Come hai fatto a risolverlo?

Answer 1

Suggerisco guardando un diverso stile di servizi rispetto forse hai fatto finora. Prendere in considerazione i servizi che collaborano tra loro eventi utilizzando, invece di richiesta / risposta. Sto usando questo metodo per molti anni con clienti in vari mercati verticali, con un grande successo. Ho scritto un po 'su questi temi negli ultimi 4 anni. Qui è un posto dove si può iniziare:

http: // www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/

La speranza che aiuta.

Answer 2

Ci sono un paio di approcci si può prendere. La nostra architettura SOA comporta messaggi XML inviati da e per i servizi. Un modo per ottenere ciò che si descrive è evitando l'uso di una libreria associazione di dati al nostro schema XML e utilizzare un parser XML generico per ottenere solo i nodi di dati che si desidera ignorando quelli che non si sono interessati. In questo modo il servizio può aggiungere ulteriori nuovi nodi al messaggio senza rompere chiunque attualmente utilizzarlo. Noi di solito facciamo solo quando abbiamo bisogno di solo uno o due pezzi di informazioni da una struttura dello schema più grande.

In alternativa, l'altra soluzione (preferito) usiamo viene versioni. Una versione di un servizio aderisce ad un particolare schema / interfaccia. Quando le modifiche dello schema (per esempio l'interfaccia è esteso o modificato), creiamo una nuova versione del servizio. In qualsiasi momento possiamo avere 2 o 3 versioni in movimento in qualsiasi momento. Nel tempo, abbiamo deprecano e quindi rimuovere le versioni precedenti, mentre alla fine la migrazione codice dipendente su versioni più recenti. In questo modo coloro che dipendono dal servizio possono continuare ad utilizzare la versione esistente del servizio, mentre alcuni particolari dipendenza può 'upgrade' alla nuova versione. Quali versioni di un servizio sono chiamati sono definiti in un file di configurazione per il codice dipendente. Si noti che non è solo lo schema che viene di versione, ma tutto il codice implementazione sottostante pure.

Spero che questo aiuti.

Answer 3

Quello che stai chiedendo non è un argomento facile. Ci sono molti modi si può andare su come rendere il vostro Service Oriented Architecture debolmente accoppiati.

Suggerisco di check-out di Thomas Erl SOA serie di libri . Si spiega tutto abbastanza chiaramente e in modo approfondito.

Answer 4

Ci sono alcuni pratices comuni per raggiungere accoppiamento lasco per i servizi.

1. Utilizzare doc stile / letterale di servizi web, pensare in dati (formato filo), invece di RPC, evitare di dati dello schema-base vincolante.

2. rispettare rigorosamente il contratto per l'invio di dati, ma mantenere alcune ipotesi l'elaborazione di dati in arrivo, XPath è un buon strumento per questo (sciolto in, stretto out)

3. Usa ESB e di evitare qualsiasi puntare direttamente al punto di comunicazione tra i servizi.

Answer 5

Ecco una lista di controllo di massima per valutare se il vostro SOA implementa accoppiamento lasco:

• posizione del sistema chiamato (il suo indirizzo fisico): La tua applicazione utilizzano URL diretto agli impianti accesso o la applicazione disaccoppiato tramite un livello di astrazione che è responsabile per mantenere i collegamenti tra i sistemi? Il Registro Servizi e il paradigma gruppo di servizio utilizzato in SAP NetWeaver CE sono buone esempi di ciò che una tale astrazione potrebbe essere simile. l'utilizzo di un enterprise service bus (ESB) è un altro esempio. Il punto è che l'applicazione non dovrebbe codificare l'indirizzo fisico della chiamato sistema al fine di allineare essere considerato debolmente accoppiati.

• Numero di ricevitori: L'applicazione specificare quali sistemi sono i ricevitori di una chiamata di servizio? Un composito ad accoppiamento no specificare particolari sistemi, ma lascerà la consegna del suo messaggi a un livello di attuazione del contratto di servizio. Un ermeticamente applicazione accoppiato sarà esplicitamente chiamare il sistema ricevente in ordine; un'applicazione accoppiamento lasco fa semplicemente chiamate al interfaccia di servizio e consente l'implementazione contratto di servizio strato di prendersi cura dei dettagli dei messaggi consegna a destra sistemi.

• Disponibilità di sistemi: La vostra applicazione richiede che tutte le sistemi che ci si connette ad essere installato e funzionante per tutto il tempo? Ovviamente, questo è un requisito molto difficile, soprattutto se si vogliono collegarsi a sistemi esterni che non sono sotto il vostro controllo. Se la risposta è che tutti i sistemi devono essere in esecuzione tutto il tempo, il applicazione è strettamente accoppiato al riguardo.

• Formato dei dati: L'applicazione riutilizzare i formati di dati fornito da i sistemi di back-end o stai usando un sistema di tipo di dati canonica che è indipendente dei sistemi di tipo utilizzati nella chiamata applicazioni? Se si sta riutilizzando i tipi di dati di back-end sistemi, probabilmente devono lottare con le conversioni dei tipi di dati in la vostra applicazione, e questo non è un approccio molto debolmente accoppiati.

• Tempo di risposta: L'applicazione richiede chiamati sistemi di rispondere entro un dato periodo o è accettabile per l'applicazione di ricevere una risposta minuti, ore, o addirittura giorni dopo?