Avrai solo servizi autonomi

Question

Uno dei principi di SOA è: "I servizi sono autonomi". Ho 2 servizi. Il servizio A dipende dal servizio B. Il servizio A non può servire i clienti a meno che il servizio B non sia attivo e in esecuzione. Violo il principio qui?

O se autonomo deve significare "disaccoppiato", posso soddisfare il principio se ho un fail-safe (ad esempio un'altra istanza del servizio B in esecuzione altrove a cui è collegata se l'istanza primaria non è attiva)? Questo può soddisfare i miei requisiti di disponibilità, ma non sono sicuro di come questo possa ridurre la mia dipendenza. Sì, il fail-safe potrebbe anche essere il servizio C di terze parti e in questo caso migliorerò la mia autonomia.

O il principio significa semplicemente che i servizi devono essere progettati come "fifedoms" con interfacce ben definite per ottenere i dati in & amp; su. Tuttavia, alcuni guru sembrano pensare che sia necessario archiviare anche questi dati ricevuti internamente per ridurre la dipendenza e mantenere la propria autonomia ...

È un errore se dovessi trattare i servizi come componenti con la messaggistica? :)

Pensieri?

Answer 1

Vedi questo post su Tenets SOA . Vedi anche The Fractal Constellation of Autonomous Services .

" I servizi devono essere distribuiti, gestiti e sottoposti a versione indipendentemente da altri servizi e / o applicazioni che dipendono da essi. & Quot;

Autonomia non significa isolato o completamente autonomo.

Invece, potresti avere una "costellazione" di due servizi. Sì, dipendono l'uno dall'altro. No, A non si interrompe quando B viene spostato o aggiornato. Né A si interrompe quando vengono cambiati gli interni non di interfaccia di B.

Allo stesso modo - dal punto di vista di B - e l'aggiornamento agli interni di A non si sovrappone ai cambiamenti nell'interfaccia e negli interni di B.

Le API si evolvono indipendentemente. Lo schema, i messaggi e le implementazioni sono indipendenti. Capita semplicemente di riferirsi l'un l'altro.

" Il servizio A non può servire i clienti a meno che il servizio B non sia attivo e in esecuzione " - non preoccuparti. Anche il servizio A non può servire i client se è inattivo. Il servizio inattivo è un problema. Non importa se è B (da cui dipende A) o A. La dipendenza non ha nulla a che fare con A o B che sono affidabili o disponibili.

Sì, i servizi hanno interfacce ben definite e indipendenti. La implementazione di A dipende da B, ma l'interfaccia no.

---

Modifica.

" alcuni guru sembrano pensare che sia necessario archiviare anche questi dati che ricevi internamente per ridurre la dipendenza e mantenere la tua autonomia ... "

Non riesco a vedere il punto. Se A dipende da B e l'algoritmo di B cambia, la copia di A dei dati di B è - beh - vecchia. Dipende da di solito significa una relazione attiva, funzionante, aggiornata alla transazione.

Il problema è che B può essere lento, il che rende A lento, il che rende l'applicazione che utilizza A lento. È un peccato. Ma questa non è una richiesta per infrangere le regole di autonomia e avere A mantenere una cache segreta di vecchi dati da B.

Answer 2

La tua autonomia è solo migliorata con un servizio di backup. Cosa succede se entrambi i servizi B e C si disattivano? Quindi il servizio diminuisce. Puoi migliorare ulteriormente la tua autonomia (e le tue prestazioni) memorizzando nella cache i risultati dei servizi esterni. In questo modo, se B e C diminuiscono, puoi comunque servire alcuni dei tuoi clienti con risultati memorizzati nella cache. Fintanto che fai affidamento su servizi di terze parti, tuttavia, non otterrai mai un'autonomia del 100%.