L'architettura orientata ai servizi (SOA) è uno stile di progettazione software in cui i servizi vengono forniti agli altri componenti dai componenti dell'applicazione, attraverso un protocollo di comunicazione su una rete.
I servizi Web sono un'implementazione popolare dell'architettura orientata ai servizi.
Quali sono le altre implementazioni dell'architettura orientata ai servizi diversi dai servizi Web?
Prima che i servizi basati su HTTP diventassero predominanti, c'erano molti altri sistemi che fornivano funzioni simili. Nel mondo Windows, quando COM era un modello di componenti diffuso, era normale usare DCOM, un protocollo RPC binario su TCP che permetteva di chiamare metodi su oggetti COM in processi remoti o macchine remote. COM + era un server di applicazioni basato su DCOM, che consente di registrare, eseguire e gestire i servizi. MSMQ era un'altra opzione, un sistema di code asincrone distribuito in cui un'app poteva scrivere su una coda per essere rilevata dal servizio di elaborazione della coda.
Ho usato queste tecnologie e altre per costruire architetture distribuite e orientate ai servizi negli anni '90. Altre opzioni esistevano anche prima. CORBA era simile a COM, meno MS-centrico, e server di applicazioni che eseguono componenti CORBA esistevano per varie piattaforme.
La SOA consiste nel separare le tue applicazioni in domini distinti e indipendenti. È simile al principio Separation of Concerns nella codifica, ma a livello architettonico. E proprio come SoC non si basa su una tecnologia specifica o paradigma come OOP, quindi SOA non si basa su servizi Web o simili meccanismi RPC online. In effetti, i servizi web non sono "un'implementazione di SOA", quanto componenti architettonici che possono essere utilizzati per SOA. Dopo tutto, le stesse tecnologie WS sono spesso utilizzate come back-end per semplici applicazioni client-server.
Un bel po 'di cose che mostrano la loro interfaccia esterna al mondo come un server web che usa altri protocolli diversi per la comunicazione interna.
Per un esempio, Facebook è ovviamente un sito web. Tuttavia, gran parte del monitoraggio interno e tale operazione viene eseguita utilizzando Risparmio . In genere il parsimonia utilizza il proprio protocollo THeader, che gira direttamente su un socket, piuttosto che su HTTP.
Ci sono anche alcuni tipi di casi limite. Il GRPC di Google, ad esempio, è (ovviamente abbastanza, dato il nome) un'implementazione RPC sullo stesso ordine generale di Thrift. Tuttavia, normalmente usa HTTP / 2 per il suo protocollo di comunicazione sottostante. Non è molto simile a un tipico sito Web, ma suppongo che dal momento che utilizza HTTP / 2, c'è almeno spazio per argomento che potrebbe essere considerato un servizio web.
Non ho mai capito che SOA abbia effettivamente bisogno di coinvolgere i servizi web (quindi l'articolo di Wikipedia è un po 'fuorviante dal mio punto di vista). SOA riguarda il modo in cui si integra il sistema nella propria applicazione. E l'utilizzo di servizi Web o protocolli di rete di qualsiasi tipo è un dettaglio di implementazione. La logica di ciascun servizio non dovrebbe sapere come vengono fatte le connessioni e solo sui confini che è necessario conoscere. Pertanto, chi deve dire che i propri servizi non possono comunicare tra loro scrivendo e leggendo i file? O utilizzando l'input / output standard?
Ho visto un paio di risposte che indicano altre opzioni rispetto ai servizi web (o che collegano direttamente allo stesso articolo di Wikipedia), e quelle sono buone se si pensa ai protocolli di rete.
Ma ancora, dettagli di implementazione. Ci sono opzioni che non si basano sulla rete (comunque sono inefficienti o ridicole)
I servizi Web sono ora la forma di servizio più importante in SOA, ma quando sono stato introdotto per la prima volta al concetto abbiamo utilizzato tre livelli di servizi: -
Servizi tecnici - ad es. Procedure memorizzate in un database Oracle progettato per svolgere attività molto piccole e non particolarmente facili per l'utente finale, ad esempio la conversione di una chiave comprensibile dall'utente nella chiave primaria interna del database. Questi servizi sono ampiamente utilizzati dai sistemi interni e dai servizi di livello superiore.
Servizi aziendali : livello superiore ma ancora troppo basso per essere compreso da parti esterne. Generalmente creato orchestrando diversi servizi tecnici per produrre un output utile, ad es. prendendo un PK interno e restituendo un blocco XML contenente dati sul record a cui fa riferimento il PK. O prendendo un documento di riferimento e tirando un PDF del documento dal sistema di gestione dei documenti. Questi servizi sono ampiamente utilizzati dai sistemi interni e dai servizi di livello superiore.
Servizi Externed Exposed (solitamente Servizi Web) : un servizio utile per le parti esterne. per esempio. Un servizio che accetta una chiave comprensibile per l'utente e restituisce un PDF del documento che ha creato il record (realizzato orchestrando tutti i servizi descritti in precedenza).
Leggi altre domande sui tag web-services soa