Come implementare accoppiamento lasco con un'architettura SOA

Question

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

sto lavorando a ridisegnare alcuni sistemi legacy al lavoro ora e vorrei costruirlo con più di un'architettura SOA di quanto non abbia attualmente. Usiamo questi servizi in circa 5 dei nostri siti web e uno dei maggiori problemi che abbiamo ora con il nostro sistema legacy è che quasi sempre quando facciamo correzioni di bug o aggiornamenti dobbiamo ri-distribuire i nostri 5 siti web che possono essere un abbastanza lungo processo.

Il mio obiettivo è quello di rendere le interfacce tra servizi liberamente accoppiati in modo che le modifiche possano essere apportate senza dover ridistribuire tutti i servizi e i siti Web dipendenti.

Ho bisogno della possibilità di estendere un'interfaccia di servizio già esistente senza rompere o aggiornare nessuna delle sue dipendenze. Qualcuno di voi ha riscontrato questo problema prima? come l'hai risolto?

Answer 1

Suggerisco di guardare uno stile di servizi diverso da quello che forse hai fatto finora. Considera servizi che collaborano tra loro usando eventi, piuttosto che richiesta/risposta. Ho usato questo approccio per molti anni con clienti in vari settori verticali con un grande successo. Ho scritto un po 'su questi argomenti 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/

Speranza che aiuta.

Answer 2

Quello che stai chiedendo non è un argomento facile. Ci sono molti modi in cui puoi fare in modo che la tua architettura orientata ai servizi si allenti liberamente.

Suggerisco di dare un'occhiata a Thomas Erl's SOA book series. Spiega tutto in modo abbastanza chiaro e approfondito.

Answer 3

Ci sono un paio di approcci che puoi adottare. La nostra architettura SOA coinvolge messaggi XML inviati da e verso i servizi. Un modo per ottenere ciò che descrivi è evitare l'uso di una libreria di bind di dati nel nostro schema XML e utilizzare un parser XML generico per ottenere solo i nodi di dati che vuoi ignorare a coloro che non ti interessano. In questo modo il servizio può aggiungere nuovi nodi aggiuntivi al messaggio senza rompere nessuno che lo sta usando. Solitamente lo facciamo solo quando abbiamo bisogno di una o due informazioni da una struttura di schema più grande.

In alternativa, l'altra soluzione (preferita) che usiamo è il controllo delle versioni. Una versione di un servizio aderisce a un particolare schema/interfaccia. Quando lo schema cambia (ad esempio, l'interfaccia viene estesa o modificata), creiamo una nuova versione del servizio. In qualsiasi momento potremmo avere 2 o 3 versioni in movimento in qualsiasi momento. Con il passare del tempo, dismettiamo e quindi rimuoviamo le versioni precedenti, mentre alla fine migriamo il codice dipendente nelle versioni più recenti. In questo modo coloro che dipendono dal servizio possono continuare a utilizzare la versione esistente del servizio mentre alcune particolari dipendenze possono "aggiornare" la nuova versione. Quali versioni di un servizio sono chiamate sono definite in un file di configurazione per il codice dipendente. Si noti che non è solo lo schema che ottiene la versione, ma anche tutto il codice di implementazione sottostante.

Spero che questo aiuti.

Answer 4

Esistono alcune pratiche comuni per ottenere un accoppiamento lento per i servizi.

1. Usa 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 (sfuso in, stretto out)

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

Answer 5

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

• Ubicazione del sistema chiamato (il suo indirizzo fisico): La vostra applicazione utilizzare URL diretti per l'accesso sistemi o è l'applicazione disaccoppiata tramite un livello di astrazione che è responsabile per mantenere le connessioni tra i sistemi? Il registro servizi e il paradigma del gruppo di servizi utilizzato in SAP NetWeaver CE sono buoni esempi di come potrebbe essere un'astrazione di questo tipo. L'uso di un bus di servizio aziendale (ESB) è un altro esempio. Il punto è che l'applicazione non dovrebbe codificare l'indirizzo fisico del sistema chiamato per poter essere considerato liberamente accoppiato.

• Numero di ricevitori: L'applicazione specificare quali sistemi sono i ricevitori di una chiamata di servizio? Un composito liberamente accoppiato non specificherà particolari sistemi ma lascerà il recapito dei suoi messaggi a un livello di implementazione del contratto di servizio. Un'applicazione accoppiata strettamente chiamerà esplicitamente i sistemi di ricezione nell'ordine ; un'applicazione liberamente accoppiata chiama semplicemente l'interfaccia di servizio e consente al livello di implementazione del contratto di servizio di occuparsi dei dettagli della consegna dei messaggi ai sistemi corretti.

• Disponibilità di sistemi: La vostra applicazione richiede che tutti i sistemi che ci si connette ad essere installato e funzionante per tutto il tempo? Ovviamente, questo è un requisito molto difficile specialmente se si si desidera connettersi a sistemi esterni che non sono sotto il vostro controllo. Se la risposta è che tutti i sistemi devono essere sempre in esecuzione, l'applicazione è strettamente accoppiata a questo proposito.

• Formato dati: L'applicazione riutilizzare i formati dei dati forniti dai i sistemi back-end o stai usando un sistema di tipo di dati canonica che è indipendente dai sistemi di tipo utilizzati nelle chiamate applicazioni? Se si riutilizza i tipi di dati dei sistemi backend , è probabile che si debba lottare con le conversioni dei tipi di dati nell'applicazione e questo non è un approccio molto approssimativamente accoppiato.

• Tempo di risposta: L'applicazione richiede sistemi di chiamata a rispondere entro un certo periodo di tempo o è accettabile per l'applicazione a ricevere una risposta minuti, ore, o addirittura giorni più tardi?