Un'architettura orientata ai servizi (SOA) è un modello architettonico nella progettazione di software per computer in cui i componenti dell'applicazione forniscono servizi ad altri componenti tramite un protocollo di comunicazione, tipicamente su una rete. I principi dell'orientamento al servizio sono indipendenti da qualsiasi prodotto, fornitore o tecnologia.
SOA semplifica il funzionamento reciproco dei componenti software su varie reti.
I servizi web che sono costruiti secondo l'architettura SOA tendono a rendere il servizio web più indipendente. I servizi web stessi possono scambiare dati tra loro e, a causa dei principi di base su cui sono creati, non necessitano di alcun tipo di interazione umana e inoltre non necessitano di modifiche al codice. Assicura che i servizi web su una rete possano interagire tra loro senza problemi.
SOA si basa su alcuni principi chiave che sono menzionati di seguito
- Contratto di servizio standardizzato : i servizi aderiscono a una descrizione del servizio. Un servizio deve avere una sorta di descrizione che descriva di cosa tratta. Ciò rende più semplice per le applicazioni client capire cosa fa il servizio.
- Accoppiamento allentato : minore dipendenza l'uno dall'altro. Questa è una delle caratteristiche principali dei servizi web che afferma semplicemente che dovrebbe esserci la minore dipendenza possibile tra i servizi web e il client che richiama il servizio web. Pertanto, se la funzionalità del servizio cambia in qualsiasi momento, non dovrebbe interrompere l'applicazione client o interromperne il funzionamento.
- Astrazione dei servizi: i servizi nascondono la logica che incapsulano dal mondo esterno. Il servizio non dovrebbe esporre come esegue la sua funzionalità; dovrebbe solo dire all'applicazione client cosa fa e non come lo fa.
- Riusabilità dei servizi : la logica è suddivisa in servizi con l'intento di massimizzare il riutilizzo. In qualsiasi azienda di sviluppo la riutilizzabilità è un argomento importante perché ovviamente non si vorrebbe spendere tempo e fatica per costruire lo stesso codice più e più volte su più applicazioni che lo richiedono. Quindi, una volta che il codice per un servizio Web è stato scritto, dovrebbe essere in grado di funzionare con vari tipi di applicazioni.
- Autonomia del servizio : i servizi dovrebbero avere il controllo sulla logica che incapsulano. Il servizio sa tutto sulle funzionalità che offre e quindi dovrebbe anche avere il controllo completo sul codice che contiene.
- Apolidia del servizio : idealmente, i servizi dovrebbero essere apolidi. Ciò significa che i servizi non dovrebbero nascondere le informazioni da uno stato all'altro. Questo dovrebbe essere fatto dall'applicazione client. Un esempio può essere un ordine effettuato su un sito di shopping. Ora puoi avere un servizio web che ti dà il prezzo di un particolare articolo. Ma se gli articoli vengono aggiunti a un carrello e la pagina web naviga fino alla pagina in cui effettui il pagamento, la responsabilità del prezzo dell'articolo da trasferire alla pagina di pagamento non dovrebbe essere a carico del servizio web. Invece, deve essere fatto dall'applicazione web.
- Rilevabilità dei servizi: è possibile rilevare i servizi (di solito in un registro dei servizi). Lo abbiamo già visto nel concetto dell'UDDI, che esegue un registro che può contenere informazioni sul servizio web.
- Componibilità dei servizi: i servizi suddividono i grandi problemi in piccoli problemi. Non si dovrebbe mai incorporare tutte le funzionalità di un'applicazione in un unico servizio, ma piuttosto suddividere il servizio in moduli, ciascuno con una funzionalità aziendale separata.
- Interoperabilità dei servizi: i servizi devono utilizzare standard che consentano a diversi abbonati di utilizzare il servizio. Nei servizi Web, vengono utilizzati standard come XML e la comunicazione su HTTP per garantire che sia conforme a questo principio.