L'architettura orientata ai servizi richiede il principio di robustezza?

Penso che tu stia confondendo il principio di robustezza e la robustezza nei sistemi distribuiti .

Il principio di robustezza dice:

Be liberal in what you accept, and conservative in what you send.

Se si applica il principio di robustezza, è molto difficile fornire una descrizione chiara e accurata di ciò che l'applicazione accetterà. In altre parole, sarà più difficile e la tua applicazione più complicata e più difficile da mantenere. Ancora peggio è quando i clienti iniziano a supporre che l'input "cattivo ma accettato" sia un input "buono". Penso che un buon esempio del principio di robustezza andato male sia le prime versioni di HTML e la sua interpretazione da parte dei browser web. Non consiglierei di applicare questo principio a meno che tu non sappia davvero cosa stai facendo.

Tuttavia, la robustezza nei sistemi distribuiti, come discusso nell'articolo di Jeff e nei commenti sottostanti, significa che ci si aspetta un fallimento e si progettano di conseguenza, facendo cose come:

• fornire più server nel caso in cui uno si spenga
• man mano che i servizi falliscono, altri servizi che dipendono da essi subiscono un degrado graduale

Per rispondere alla domanda originale: sì, penso che questo tipo di robustezza sia (o dovrebbe essere) necessaria nei sistemi orientati ai servizi.

Penso che tu debba sbagliare sul lato della robustezza.

Considera questo: in questo momento tutti gli sviluppatori coinvolti possono ricordare il sistema come un insieme integrato. Tuttavia, se l'approccio SOA è effettivamente utile, si dovrebbe finire con diversi servizi che possono essere utilizzati in modi nuovi. Utilizzato dai nuovi utenti che non conoscono la cronologia, o ancora meglio dagli utenti esterni, che sarebbero molto delusi se non ricevessero un servizio ragionevole, cancellassero i messaggi di errore e analizzassero facilmente le risposte. Il principio di minimo stupore dovrebbe guidarti qui.

Nota bene: alcune aziende fanno sì che SOA sia conforme alle parole d'ordine. O forse solo un componente deve essere esposto e scala. O leggono che Amazon lo fa in questo modo. Costruire ciascun componente come un servizio solido e autonomo può essere una perdita di tempo.

Ci saranno sempre componenti che richiedono servizi secondari x, yez per fare un lavoro utile. Potresti non fare alcun favore a nessuno se cerca di combattere con dipendenze mancanti. A volte fallire è meglio che catturare tutto al limite del servizio e nascondere i problemi.