Come dice la domanda: Quando si implementa "SOA", si tratta di un concetto destinato alla comunicazione tra sistemi su una rete o è inteso come un concetto che opera all'interno del linguaggio come modello?
L'architettura orientata ai servizi è un'architettura , quindi la risposta non è né.
Non è un modello di progettazione all'interno di un linguaggio perché governa le decisioni molto, molto al di fuori della progettazione del programma - in particolare, come tutti i dati aziendali sono organizzati in servizi, che ha uno stretto rapporto con la struttura organizzativa. Persino alcuni concetti tecnici come la messaggistica fire-and-forget sono generalmente indipendenti dalla lingua.
E non è specificamente correlato alla comunicazione tra i sistemi su una rete perché potresti implementare un intero SOA in un singolo processo, se lo desideri. Il metodo preferito di interazione del servizio in una SOA è in-process e dati o messaggi dovrebbero solo superare i limiti del processo quando è necessario ridimensionarlo. Anche in questo caso, SOA si occupa della logica piuttosto che della implementazione fisica . Se si dispone di un "servizio di fatturazione", l'architettura non dice nulla su dove si trova quel servizio, e parti di esso potrebbero infatti trovarsi in diversi endpoint fisici.
SOA si presta bene ai sistemi distribuiti perché di alcuni degli altri vincoli tecnici che tende ad imporre, come l'asincronia e l'accoppiamento lento. I sistemi distribuiti generalmente si comportano meglio quando trattano la rete come una rete (cioè non dipendono dalla bassa latenza / larghezza di banda elevata) e quando i componenti possono funzionare tutti autonomamente. Ma questo è un risultato di SOA, non il suo obiettivo.
Un SOA è molto semplicemente l'opposto di un modello di dati canonici; in altre parole, ogni servizio è come una piccola dittatura che protegge i suoi dati ferocemente e non condividerà nulla con nessun altro servizio tranne quello di cui ha assolutamente bisogno per funzionare. Puoi implementarlo in qualsiasi linguaggio di programmazione e con (quasi) qualsiasi infrastruttura fisica.
Se lo usi in una lingua come pattern, non avrai bisogno di alcune delle funzionalità di SOA:
Quindi, se vuoi semplicemente avere un contratto pulito tra i componenti, puoi anche farlo senza SOA. Scrivi invece un documento di design.
Se si sospetta che sarà necessario sostituire alcuni componenti con componenti di terze parti in un secondo momento, SOA è una soluzione valida. Tuttavia, a causa dell'impatto sulle prestazioni della serializzazione / deserializzazione XML, potrebbe essere necessario prendere in considerazione l'utilizzo di un'opzione di scelta rapida per la comunicazione interna. Ciò può essere fatto all'interno di un wrapper che utilizza la scorciatoia per interni e SOA per le comunicazioni esterne.
In SOA la logica aziendale è suddivisa in componenti logici in cui ogni componente è esposto come un servizio. Quindi perché è un concetto architettonico. È comune che questi componenti vengano distribuiti su più dispositivi fisici, ma non deve essere così. Potresti avere più servizi in esecuzione su una singola macchina.
SOA consente la scalabilità orizzontale, al contrario della scalabilità verticale (maggiore potenza del cavallo). SOA viene spesso applicato quando si lavora con applicazioni aziendali. Immagina una grande organizzazione con più applicazioni indipendenti scritte in vari linguaggi di programmazione. Per consentire a queste applicazioni di comunicare tra loro (integrare), potresti voler esporre le loro funzionalità tramite i servizi.
In Internet sono disponibili diversi standard di servizio: link
I framework di sviluppo come .NET nascondono la complessità di questi standard offrendo strumenti come servizi web ASMX e WCF ( link )
Per riassumere, sarebbe molto difficile integrare le applicazioni aziendali se non esistessero standard e framework che ho menzionato sopra.
Leggi altre domande sui tag design-patterns soa