Carmelo Saffioti's Blog: Service Oriented Architecture

Nell'ambito dell'informatica, con la locuzione inglese di Service-Oriented Architecture (SOA) si indica un'architettura software atta a supportare l'uso di servizi Web per soddisfare le richieste degli utenti così da consentire l'utilizzo delle singole applicazioni come componenti del processo di business.

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

Indice

Definizioni di SOA

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'utilizzazione 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.

Il concetto di SOA (WebServices e non solo ) deriva dalla riconsiderazione delle strutture aziendali: organizzazioni rizomatiche che fonda le sue radici nella cultura biologica. L'evoluzione delle infrastrutture di comunicazione, che ormai sono pervasive consente di pensare l'interconnessione tra soggetti economici, come le aziende, come un processo dinamico, non fissato una volta per tutte.

Elenco definizioni

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

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 si presenta 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 permettendo, al contempo, alle attività di business di sviluppare processi efficienti, sia internamente che esternamente ed aumentarne 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 services 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. La chiave sta nella totale assenza di business logic sul client SOA il quale è totalmente agnostico rispetto alla piattaforma di implementazione, riguardo i protocolli, il binding, il tipo di dati, le policy con cui il servizio produrrà l'informazione richiesta Service Level Agreement (SLA). 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, 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

Aspetti dello sviluppo della SOA

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

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, Pearson, 2006. ISBN 0-13-987-0471-768

Jason Bloomberg; Ronald Schmelzer. Service- orient or Be Doomed. Hoboken, New Yersey, 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

Kunal Mittal. Requirements process for SOA projects, Part 1 of 3: Capturing requirements for an SOA application - Initial requirements to build out your SOA (HTML). IBM Developerworks, 2006
Tony Shan; Hua, Winnie. A Service-Oriented Solution Framework for Internet Banking (PDF). International Journal of Web Services Research, Vol. 3, Issue 1, pp 29-48, 2006
Tony Shan; Hua, Winnie. Solution Architecture for N-Tier Applications (PDF). In Proc. of the 3rd IEEE International Conference on Services Computing (SCC 2006), pp. 349-356, 2006
Steve Jones. Toward an acceptable definition of service (PDF). IEEE Software, 2005
Eric Pulier; Hugh Taylor. Understanding Enterprise SOA. Greenwich, Manning Publications, 2005. ISBN 1-932394-59-1

OASIS SOA Reference Model Technical Committee. A Reference Model for Service Oriented Architecture. (PDF). OASIS, 2006
Various authors. The Emergence of Grid and Service-Oriented IT: An Industry Vision for Business Success (Paperback). , 2006.

Hiroshi Wada; Suzuki, Junichi. A Service-Oriented Design Framework for Secure Network Applications (PDF). In Proc. of the 30th IEEE International Conference on Computer Software and Applications Conference (COMPSAC 2006), 2006
Hiroshi Wada; Suzuki, Junichi. A Model-Driven Development Framework for Non-Functional Aspects in Service Oriented Grids (PDF). In Proc. of 2nd IEEE International Conference on Autonomic and Autonomous Systems (ICAS 2006), 2006