Service-oriented architecture

Da Wikipedia, l'enciclopedia libera.

Nell'ambito dell'informatica, con la locuzione inglese di Service-Oriented Architecture (SOA) si indica generalmente un'architettura software adatta a supportare l'uso di servizi Web per garantire l'interoperabilità tra diversi sistemi così da consentire l'utilizzo delle singole applicazioni come componenti del processo di business e soddisfare le richieste degli utenti in modo integrato e trasparente.

Elementi di una SOA, di Dirk Krafzig, Karl Banke, e Dirk Slama. Enterprise SOA. Prentice Hall, 2005

Definizioni di SOA[modifica | modifica sorgente]

Una SOA è progettata per il collegamento a richiesta di risorse computazionali (principalmente applicazioni e dati), per ottenere un dato risultato per gli utenti, che possono essere utenti finali o altri servizi. L'OASIS (Organizzazione per lo sviluppo di standard sull'informazione strutturata) definisce la SOA così:

Un paradigma per l'organizzazione e l'utilizzo delle risorse distribuite che possono essere sotto il controllo di domini di proprietà differenti. Fornisce un mezzo uniforme per offrire, scoprire, interagire ed usare le capacità di produrre gli effetti voluti consistentemente con presupposti e aspettative misurabili.

Anche se esistono molteplici definizioni di SOA, solo il gruppo OASIS ha prodotto una definizione formale applicabile profondamente sia alla tecnologia che ai domini aziendali.

Elenco definizioni[modifica | modifica sorgente]

Sebbene molte definizioni di SOA si limitino alla tecnologia o solo ai Web services, questo aspetto è predominante per i fornitori di tecnologia. Nel 2003 questi parlavano di Web services, e nel 2006 di Motori di Processo.

Descrizione[modifica | modifica sorgente]

Nell'ambito di un'architettura SOA è quindi possibile modificare, in maniera relativamente più semplice, le modalità di interazione tra i servizi, oppure la combinazione nella quale i servizi vengono utilizzati nel processo, così come risulta più agevole aggiungere nuovi servizi e modificare i processi per rispondere alle specifiche esigenze di business: il processo di business non è più vincolato da una specifica piattaforma o da un'applicazione ma può essere considerato come un componente di un processo più ampio e quindi riutilizzato o modificato.

L'architettura orientata ai servizi è particolarmente adatta per le aziende che presentano una discreta complessità di processi e applicazioni, dal momento che agevola l'interazione tra le diverse realtà aziendali; permette quindi alle attività di business di sviluppare processi efficienti sia internamente che esternamente, e parallelamente ne aumenta la flessibilità e l'adattabilità.

Benché molte aziende offrano prodotti che possono formare la base di una SOA va sottolineato che la SOA non è un prodotto.

Non è affatto vero che un'architettura orientata ai servizi non sia legata ad una specifica tecnologia. Chi dice che può essere realizzata usando una vasta gamma di tecnologie, comprese REST, RPC, DCOM, CORBA, MOM, DDS non ha chiaro il vero valore e l'intrinseco significato delle SOA: nessuna di queste tecnologie è infatti capace di implementare entità che descrivano se stesse come è possibile fare usando i Web service mediante il linguaggio di definizione dei servizi WSDL. Infatti applicazioni di test che a run-time capiscano la semantica di un servizio e lo invochino senza "conoscere" nulla del servizio stesso "a priori", non esistono per nessuna delle tecnologie citate.[senza fonte] La chiave sta nella totale assenza di business logic sul client SOA il quale è totalmente agnostico rispetto alla piattaforma di implementazione, riguardo ai protocolli, al binding, al tipo di dati, alle policy con cui il servizio produrrà l'informazione richiesta. Tutto a beneficio dell'indipendenza dei servizi, che possono essere chiamati per eseguire i propri compiti in un modo standard, senza che il servizio abbia conoscenza dell'applicazione chiamante e senza che l'applicazione abbia conoscenza, o necessiti di averne, del servizio che effettivamente eseguirà l'operazione.

SOA può anche essere vista come uno stile dell'architettura dei sistemi informatici che permetta la creazione delle applicazioni sviluppate, combinando servizi debolmente accoppiati e interoperabilità degli stessi. Questi servizi interoperano secondo una definizione formale, detta protocollo o contratto, come per i WSDL indipendente dalla piattaforma sottostante e dalle tecnologie di sviluppo (come Java, .NET, ecc). I servizi, per esempio, scritti in Java usando la piattaforma Java EE e quelli in C# con .NET possono essere utilizzati dall'applicazione sovrastante. Le applicazioni in esecuzione su una piattaforma possono anche utilizzare servizi in esecuzione su altre, come con i Web services, facilitando quindi la riusabilità.

SOA può supportare l'integrazione e la consolidazione di attività all'interno di complessi sistemi aziendali (sistemi di EAI, ma non specifica o fornisce la metodologia o il framework per documentare capacità e potenzialità dei servizi.

I linguaggi di alto livello come BPEL e le specifiche come WS-CDL e WS-Coordination estendono il concetto di servizio, fornendo un metodo per definire e supportare la coordinazione dei servizi di rifinitura con quelli maggiori, che, di conseguenza, possono essere inclusi in flussi di controllo e processi aziendali implementati con applicazioni composte o portali.

Tecnologie alla base della SOA[modifica | modifica sorgente]

Aspetti dello sviluppo della SOA[modifica | modifica sorgente]

La validità di un'architettura orientata ai servizi (SOA) è conseguenza degli elementi e degli standard su cui si fonda. In particolare vanno considerati i seguenti aspetti:

  • Standard aperti: per poter operare in ambienti multipiattaforma è necessario, o quantomeno consigliabile, utilizzare esclusivamente standard aperti quali XML, WSDL e WS-Security (WSS).
  • Modularità: bisogna trovare il giusto equilibrio tra i servizi erogati da ogni singolo componente, creando un insieme bilanciato di piccoli servizi riutilizzabili per le funzioni comuni e servizi più grandi per processi specifici.
  • Contratti di servizio: WSDL (Web Services Description Language) è la specifica standard per la creazione di contratti di Web Services, un contratto definito avrà come conseguenza servizi più flessibili.
  • ESB (Enterprise Service Bus): La dorsale di pubblicazione dei servizi ed abilitazione delle applicazioni per accedervi. Inoltre include caratteristiche quali adattatori per i sistemi legacy, capacità di orchestrazione dei servizi, autorizzazione e autenticazione lato sicurezza, trasformazione dei dati, supporto per regole di business e capacità di monitorare i service level agreement.

Bibliografia[modifica | modifica sorgente]

  • Douglas K. Barry, Web Services and Service-Oriented Architectures: The Savvy Manager's Guide, San Francisco, Morgan Kaufmann Publishers, 2003. ISBN 1-55860-906-7.
  • Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah, Service-Oriented Architecture Compass - Business Value, Planning and Enterprise Roadmap, Upper Saddle River, IBM Press, 2005. ISBN 0-13-187002-5.
  • Jason Bloomberg, Ronald Schmelzer, Service- orient or Be Doomed, Hoboken, New Jersey, WILEY, 2006. ISBN 0-13-187002-5.
  • Thomas Erl, Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services, Upper Saddle River, Prentice Hall PTR, 2004. ISBN 0-13-142898-5.
  • Thomas Erl, Service-Oriented Architecture: Concepts, Technology, and Design, Upper Saddle River, Prentice Hall PTR, 2005. ISBN 0-13-185858-0.
  • Judith Hurwitz, Robin Bloor, Carol Baroudi, Marcia Kaufman, Service Oriented Architecture for Dummies, Hoboken, Wiley, 2006. ISBN 0-470-05435-2.

Altri progetti[modifica | modifica sorgente]

Collegamenti esterni[modifica | modifica sorgente]

Web Portale Web: accedi alle voci di Wikipedia che trattano di Web