Cos'è l'architettura orientata ai servizi?

L'architettura orientata ai servizi (SOA) è emersa nella prima parte di questo secolo come evoluzione del calcolo distribuito. Prima della SOA, i servizi erano intesi come il risultato finale del processo di sviluppo dell'applicazione. In SOA, l'applicazione stessa è composta da servizi. I servizi possono essere forniti singolarmente o combinati come componenti in un servizio composito più ampio.

I servizi interagiscono in rete utilizzando un protocollo come REST o SOAP (Simple Object Access Protocol). I servizi sono liberamente accoppiati , il che significa che l'interfaccia del servizio è indipendente dall'implementazione sottostante. Gli sviluppatori o gli integratori di sistemi possono comporre uno o più servizi in un'applicazione senza necessariamente sapere come viene implementato ogni servizio.

Questo articolo è una panoramica di Java SOA e delle caratteristiche chiave di un'architettura orientata ai servizi implementata utilizzando servizi Web basati su SOAP. Inoltre confronterò brevemente SOA e microservizi e discuterò la differenza tra i servizi Web basati su RESTful e SOAP in Java.

SOA e servizi web

SOA e servizi web sono spesso confusi, ma non sono la stessa cosa. SOA è un'architettura che consente agli sviluppatori di combinare più servizi applicativi in ​​un servizio composito più ampio. SOA può essere implementato utilizzando servizi Web basati su SOAP o API REST, o talvolta una combinazione di entrambi. È importante capire che in SOA un servizio è una qualsiasi risorsa disponibile in remoto in grado di rispondere alle richieste. Un servizio web viene implementato utilizzando protocolli specifici.

Perché l'architettura orientata ai servizi?

SOA affronta tre sfide aziendali comuni:

  • Rispondi rapidamente ai cambiamenti aziendali.
  • Sfrutta gli investimenti infrastrutturali esistenti.
  • Supportare nuovi canali di interazione con clienti, partner e fornitori.

L'infrastruttura aziendale è eterogenea tra sistemi operativi, applicazioni, software di sistema e infrastruttura applicativa. Di conseguenza, molti sistemi aziendali sono costituiti da applicazioni complesse e incoerenti che forniscono una gamma di servizi interdipendenti. Le applicazioni esistenti che eseguono i processi aziendali correnti sono fondamentali, quindi iniziare da zero o modificarle è una proposta delicata. Ma le aziende devono essere in grado di modificare ed espandere l'infrastruttura tecnica per soddisfare le esigenze aziendali.

SOA e microservizi

Microservices è uno stile architettonico evoluto da SOA. Entrambe sono architetture distribuite ed entrambe offrono un paradigma disaccoppiato. Mentre l'architettura orientata ai servizi è più pesante sull'infrastruttura, i microservizi offrono uno stile di sviluppo più flessibile e leggero. Ci sono vantaggi e svantaggi per entrambi ed entrambi sono ampiamente utilizzati. In generale, la SOA viene implementata o mantenuta più frequentemente da imprese consolidate che dispongono delle risorse per supportare più formalità. I microservizi spesso si rivolgono a organizzazioni nuove o in crescita che richiedono agilità.

Rispetto a un'architettura monolitica, la natura liberamente accoppiata di SOA rende relativamente semplice collegare nuovi servizi o aggiornare i servizi esistenti per nuovi requisiti aziendali. Fornisce inoltre la possibilità di rendere i servizi fruibili attraverso diversi canali e di esporre le applicazioni legacy come servizi, salvaguardando così gli investimenti infrastrutturali.

Poiché sono accoppiati in modo lasco, i componenti SOA possono essere modificati con un impatto minimo su altri componenti. I componenti possono anche essere aggiunti all'architettura in modo standardizzato e possono essere ridimensionati per affrontare il carico.

Ad esempio, si consideri come un'impresa potrebbe utilizzare una serie di applicazioni esistenti per creare una nuova applicazione composita della catena di fornitura. Sebbene le applicazioni esistenti siano eterogenee e distribuite su vari sistemi, la loro funzionalità è esposta e accessibile tramite interfacce standard.

Matthew Tyson

Caratteristiche chiave della SOA

SOA può essere semplice come un singolo componente che consuma servizi forniti da un altro componente o sofisticato come una gamma di componenti che interagiscono tramite un bus di servizi aziendali come ESB di MuleSoft. Indipendentemente dalla scala, la chiave per un'implementazione SOA di successo è utilizzare la minor complessità possibile per raggiungere i propri obiettivi. La tua prima e ultima domanda dovrebbe sempre essere: questo design soddisfa le nostre esigenze aziendali?

Indipendentemente dalla scala o dalla complessità, il modello di un'architettura orientata ai servizi è più o meno lo stesso:

  • I fornitori di servizi espongono gli endpoint e descrivono le azioni disponibili su ogni endpoint.
  • I consumatori di servizi emettono richieste e consumano risposte.
  • I fornitori di servizi generano messaggi per gestire le richieste.

Implementazione di un'architettura orientata ai servizi

Per implementare SOA si inizia con l'architettura del servizio di base, quindi si fornisce l'infrastruttura, ovvero i protocolli e altri strumenti che consentono la comunicazione e l'interoperabilità. La Figura 2 mostra un diagramma di una tipica architettura di servizio.

Matthew Tyson

In questo diagramma, tre consumatori richiamano i servizi inviando messaggi a un bus di servizi aziendali, che trasforma e instrada i messaggi a un'implementazione del servizio appropriata. Un motore di regole aziendali incorpora le regole aziendali in un servizio o tra i servizi. Un livello di gestione dei servizi gestisce attività come il controllo, la fatturazione e la registrazione.

I componenti in questa architettura sono accoppiati in modo lasco, quindi possono essere sostituiti o aggiornati con un impatto relativamente minimo sull'applicazione nel suo insieme. Ciò offre all'azienda la flessibilità di aggiungere o aggiornare i processi aziendali secondo necessità. Nella maggior parte dei casi, le modifiche ai singoli servizi non dovrebbero influire notevolmente su altri servizi.

Servizi web SOAP vs RESTful

È possibile adottare lo stile SOA e implementarlo con REST, ad esempio utilizzando l'API JAX-RS o Spring Boot Actuator, ma questa discussione non rientra nell'ambito di questo articolo. Vedere "SOAP vs REST vs JSON" per un utile confronto tra i servizi web SOAP e RESTful. C'è anche una certa sovrapposizione tra i servizi Web RESTful e lo stile più leggero associato ai microservizi.

Servizi Web basati su SOAP

I servizi Web implementati utilizzando SOAP sono ancora più rigidi di un'implementazione di servizi Web o microservizi RESTful, ma molto più flessibili rispetto ai primi giorni di SOA. Qui esamineremo solo i protocolli di alto livello richiesti per i servizi Web basati su SOAP.

SOAP, WSDL e XSD

SOAP, WSDL e XSD sono l'infrastruttura fondamentale di un'implementazione di un servizio Web basata su SOAP. WSDL viene utilizzato per descrivere il servizio e SOAP è il livello di trasporto per l'invio di messaggi tra consumatori e fornitori di servizi. I servizi comunicano con messaggi definiti formalmente utilizzando XML Schema (XSD). Puoi pensare a WSDL come all'interfaccia del servizio (vagamente analoga a un'interfaccia Java). L'implementazione viene eseguita in classi Java e la comunicazione attraverso la rete avviene tramite SOAP. Funzionalmente, un consumatore cercherebbe un servizio, otterrebbe il WSDL per quel servizio, quindi richiamerebbe il servizio utilizzando SOAP.

Sicurezza del servizio Web

La specifica WS-I Basic Profile 2.0 riguarda la sicurezza dei messaggi. Questa specifica si concentra sullo scambio di credenziali, sull'integrità dei messaggi e sulla riservatezza dei messaggi.

Rilevamento del servizio Web

Una volta che la pietra angolare della scoperta dei servizi web, UDDI (descrizione universale, definizione e integrazione) è passato alla storia. Oggi è comune esporre un servizio Web basato su SOAP come faresti con qualsiasi altro servizio, tramite un URL dell'endpoint. A titolo di esempio, è possibile utilizzare il JAX-WS Servizio Endpoint interfaccia e le sue @WebServicee @WebMethodle annotazioni.

Creazione e distribuzione di servizi Web

Gli sviluppatori Java hanno diverse opzioni per creare e distribuire servizi web basati su SOAP, inclusi Apache Axis2 e Spring-WS; tuttavia, lo standard Java è JAX-WS, l'API Java per i servizi Web XML. L'idea principale alla base di JAX-WS è creare classi Java e annotarle per creare gli artefatti richiesti. Sotto il cofano, JAX-WS utilizza diversi pacchetti Java, tra cui JAXB, una libreria per scopi generali per l'associazione di classi Java a XML.

JAX-WS nasconde allo sviluppatore la complessità ei protocolli sottostanti, semplificando così il processo di definizione e distribuzione dei servizi SOAP basati su Java. I moderni IDE Java come Eclipse includono il supporto completo per lo sviluppo di servizi web JAX-WS. La specifica JAX-WS è stata selezionata anche per lo sviluppo in corso a Jakarta EE.

Conclusione

L'architettura orientata ai servizi implementata con servizi Web basati su SOAP richiede definizioni di servizi più rigide e formali rispetto ai servizi Web o ai microservizi RESTful. Tuttavia, alcune organizzazioni più grandi continuano a favorire lo stile più formale applicato da SOAP. Anche molti sistemi legacy su larga scala sono basati su SOAP e alcuni sistemi B2B e interni scelgono servizi Web basati su SOAP per i loro contratti API più formalmente definiti. Che tu stia sviluppando o gestendo un sistema aziendale su larga scala, comprendere il modello SOA ed essere in grado di valutare le tue opzioni per l'implementazione ti servirà bene nella tua carriera di programmazione.

Questa storia, "Cos'è l'architettura orientata ai servizi?" è stato originariamente pubblicato da JavaWorld.