Gianni Messina

In un’organizzazione, la funzionalità di autenticazione degli utenti è fondamentale per diversi processi. La sicurezza delle informazioni e dei dati sensibili è un aspetto cruciale per qualsiasi organizzazione che desideri proteggere le proprie risorse e mantenere un ambiente lavorativo affidabile.

L’autenticazione degli utenti, svolge un ruolo di primo piano nel garantire che solo le persone autorizzate possano accedere alle risorse e ai sistemi aziendali.

Invece di riscrivere il codice di autenticazione per tutti i processi aziendali, è possibile creare un unico servizio di autenticazione e riutilizzarlo per tutte le applicazioni.

Allo stesso modo, la maggior parte dei sistemi di un’organizzazione sanitaria, come i sistemi di gestione dei pazienti e i sistemi di cartelle cliniche elettroniche (EHR), devono registrare i pazienti. Questi sistemi possono ricorrere a un unico servizio comune per eseguire la registrazione del paziente.

Quali sono i vantaggi dell’architettura orientata ai servizi?

L’architettura orientata ai servizi (SOA) presenta numerosi vantaggi rispetto alle tradizionali architetture monolitiche in cui tutti i processi vengono eseguiti come una singola unità. Alcuni dei principali vantaggi della SOA includono quanto segue:

Time-to-market ridotto

Gli sviluppatori riutilizzano i servizi in diversi processi aziendali per risparmiare tempo e costi. Possono assemblare applicazioni molto più velocemente con la SOA che scrivendo codici ed eseguendo integrazioni da zero.

Manutenzione efficiente

È più facile creare, aggiornare ed eseguire il debug di piccoli servizi rispetto ai blocchi di codice di grandi dimensioni nelle applicazioni monolitiche. La modifica di qualsiasi servizio in una SOA non influisce sulla funzionalità complessiva del processo aziendale.

Maggiore adattabilità

La SOA è più adattabile ai progressi tecnologici. È possibile modernizzare le applicazioni in modo efficiente ed economico. Ad esempio, le organizzazioni sanitarie possono utilizzare la funzionalità dei vecchi sistemi di cartelle cliniche elettroniche nelle nuove applicazioni basate su cloud.

Quali sono i principi base dell’architettura orientata ai servizi?

Non esistono linee guida standard ben definite per l’implementazione dell’architettura orientata ai servizi (SOA). Tuttavia, alcuni principi base sono comuni a tutte le implementazioni SOA.

Interoperabilità

Ciascun servizio in SOA include documenti descrittivi che specificano la funzionalità del servizio e i relativi termini e condizioni. Qualsiasi sistema client può eseguire un servizio, indipendentemente dalla piattaforma o dal linguaggio di programmazione sottostante. Ad esempio, i processi aziendali possono utilizzare servizi scritti sia in C# che in Python. Poiché non esistono interazioni dirette, le modifiche in un servizio non influiscono sugli altri componenti che utilizzano il servizio.

Accoppiamento debole

I servizi in SOA dovrebbero essere accoppiati debolmente, con la minor dipendenza possibile da risorse esterne come modelli di dati o sistemi informativi. Dovrebbero anche essere indipendenti senza mantenere alcuna informazione da sessioni o transazioni passate. In questo modo, se si modifica un servizio, non avrà un impatto significativo sulle applicazioni client e sugli altri servizi che utilizzano il servizio.

Astrazione

I client o gli utenti del servizio in SOA non devono conoscere la logica del codice del servizio o i dettagli di implementazione. Per loro, i servizi dovrebbero apparire come una scatola nera. I clienti ottengono le informazioni richieste su ciò che fa il servizio e su come utilizzarlo tramite contratti di servizio e altri documenti di descrizione del servizio.

Granularità

I servizi in SOA dovrebbero avere una dimensione e un ambito appropriati, idealmente racchiudendo una discreta
funzione aziendale per servizio. Gli sviluppatori possono quindi utilizzare più servizi per creare un servizio composito per l’esecuzione di operazioni complesse.

Quali sono i componenti dell’architettura orientata ai servizi?

Ci sono quattro componenti principali nell’architettura orientata ai servizi (SOA).

Servizio

I servizi sono gli elementi costitutivi di base della SOA. Possono essere privati, cioè disponibili solo per gli utenti interni di un’organizzazione, o pubblici, cioè accessibili a tutti via Internet. Individualmente, ciascun servizio ha tre caratteristiche principali.

Implementazione di servizi
L’implementazione di servizi è il codice che costruisce la logica per eseguire la specifica funzione del servizio, come l’autenticazione dell’utente o il calcolo della fattura.

Contratto di servizi

Il contratto di servizi definisce la natura del servizio e i termini e le condizioni associati, come i prerequisiti per l’utilizzo del servizio, il costo del servizio e la qualità del servizio fornito.

Interfaccia di servizi

In SOA, altri servizi o sistemi comunicano con un servizio attraverso la sua interfaccia di servizi. L’interfaccia definisce come richiamare il servizio per eseguire attività o scambiare dati. Riduce le dipendenze tra i servizi e il richiedente di servizi. Ad esempio, anche gli utenti con poca o nessuna comprensione della logica del codice sottostante possono utilizzare un servizio tramite la sua interfaccia.

Fornitore di servizi

Il fornitore di servizi crea, mantiene e fornisce uno o più servizi che altri possono utilizzare. Le organizzazioni possono creare i propri servizi o acquistarli da fornitori di servizi terzi.

Utente di servizi

L’utente di servizi richiede al fornitore di servizi di eseguire un servizio specifico. Può essere un intero sistema, un’applicazione o un altro servizio. Il contratto di servizi specifica le regole che il fornitore e l’utente di servizi devono seguire quando interagiscono tra loro. I fornitori e gli utenti di servizi possono appartenere a diversi dipartimenti, organizzazioni e persino settori.

Registro di servizi

Un registro di servizi, o repository di servizi, è una directory accessibile in rete di servizi disponibili. Memorizza i documenti di descrizione del servizio dei fornitori di servizi. I documenti descrittivi contengono informazioni sul servizio e su come comunicare con esso. Gli utenti di servizi possono facilmente individuare i servizi di cui hanno bisogno utilizzando il registro di servizi.

Come funziona l’architettura orientata ai servizi?

Nell’architettura orientata ai servizi (SOA), i servizi funzionano in modo indipendente e forniscono funzionalità o scambi di dati ai propri utenti. L’utente richiede informazioni e invia i dati di input al servizio. Il servizio elabora i dati, esegue l’attività e invia una risposta. Ad esempio, se un’applicazione utilizza un servizio di autorizzazione, fornisce al servizio il nome utente e la password. Il servizio verifica il nome utente e la password e restituisce una risposta appropriata.

Protocolli di comunicazione

I servizi comunicano utilizzando regole stabilite che determinano la trasmissione dei dati su una rete. Queste regole sono chiamate protocolli di comunicazione. Alcuni protocolli standard per implementare la SOA includono quanto segue:

• Simple Object Access Protocol (SOAP)
• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Servizio messaggi Java (JMS)

Cos’è un ESB nell’architettura orientata ai servizi?

Un bus di servizio aziendale (ESB) è un software che è possibile utilizzare durante la comunicazione con un sistema che dispone di più servizi. Stabilisce la comunicazione tra servizi e utenti di servizi, indipendentemente dalla tecnologia.  

Vantaggi di un ESB

Un ESB fornisce capacità di comunicazione e trasformazione attraverso un’interfaccia di servizi riutilizzabile. Puoi pensare a un ESB come a un servizio centralizzato che instrada le richieste di servizi al servizio appropriato. Inoltre, trasforma la richiesta in un formato accettabile per la piattaforma sottostante e il linguaggio di programmazione del servizio.

Quali sono i limiti nell’implementazione dell’architettura orientata ai servizi?

Scalabilità limitata

La scalabilità del sistema ha un impatto significativo quando i servizi condividono molte risorse e devono coordinarsi per eseguire la loro funzionalità. 

Interdipendenze crescenti

I sistemi di architettura orientata ai servizi (SOA) possono diventare più complessi nel tempo e sviluppare diverse interdipendenze tra i servizi. Può essere difficile modificarli o eseguirne il debug se diversi servizi si chiamano a vicenda in un ciclo. Anche le risorse condivise, come i database centralizzati, possono rallentare il sistema.

Singolo punto di errore

Per le implementazioni SOA con un ESB, l’ESB crea un singolo punto di errore. È un servizio centralizzato che va contro l’idea di decentralizzazione sostenuta dalla SOA. Clienti e servizi non possono comunicare tra loro se l’ESB si interrompe.

Cosa sono i microservizi?

L’architettura dei microservizi è costituita da componenti software molto piccoli e completamente indipendenti, chiamati microservizi, che si specializzano e si concentrano su un’unica attività. I microservizi comunicano tramite le API, che sono regole create dagli sviluppatori per consentire ad altri sistemi software di comunicare con il loro microservizio.

Lo stile architettonico dei microservizi è più adatto ai moderni ambienti di cloud computing. Spesso operano in container, unità software indipendenti che impacchettano il codice con tutte le sue dipendenze.

Vantaggi dei microservizi

I microservizi sono scalabili in modo indipendente, veloci, portatili e indipendenti dalla piattaforma (caratteristiche native del cloud). Sono anche disaccoppiati, il che significa che non hanno dipendenze limitate da altri microservizi. Per raggiungere questo obiettivo, i microservizi hanno accesso locale a tutti i dati di cui hanno bisogno invece dell’accesso remoto ai dati centralizzati a cui accedono e utilizzano anche altri sistemi. Ciò crea una duplicazione dei dati che i microservizi compensano in termini di prestazioni e agilità.

SOA rispetto ai microservizi

L’architettura dei microservizi è un’evoluzione dello stile architettonico delle SOA. I microservizi affrontano le carenze della SOA per rendere il software più compatibile con i moderni ambienti aziendali basati su cloud. Sono granulari e favoriscono la duplicazione dei dati rispetto alla condivisione dei dati. Ciò li rende completamente indipendenti con i propri protocolli di comunicazione che vengono esposti tramite API leggere. È essenzialmente compito degli utenti utilizzare il microservizio tramite la sua API, eliminando così la necessità di un ESB centralizzato.

In che modo AWS contribuisce a implementare i microservizi?

AWS è un ottimo luogo in cui costruire applicazioni moderne tramite pattern di architettura modulari, modelli operativi serverless e processi di sviluppo agili. Offre la piattaforma più completa per la creazione di microservizi a disponibilità elevata per alimentare applicazioni moderne di qualsiasi portata e scala. Ad esempio, è possibile fare quanto segue:

• Creare, isolare ed eseguire microservizi sicuri in container gestiti per semplificare le operazioni e ridurre i costi di gestione.
• Utilizzare AWS Lambda per eseguire i microservizi senza eseguire il provisioning e la gestione dei server.
• Scegliere tra 15 database AWS dedicati relazionali e non relazionali per supportare l’architettura di microservizi.
• Monitorare e controllare facilmente i microservizi in esecuzione in AWS con AWS App Mesh.
• Monitorare e risolvere le complesse interazioni dei microservizi con AWS X-Ray.

I microservizi in AWS permettono di innovare più velocemente, limitare i rischi, accelerare il time-to-market e ridurre il costo totale di proprietà. Inizia a utilizzare SOA e microservizi in AWS creando un account AWS oggi stesso.

Pagine: Page 1 Page 2

Featured