 |
Architettura SOA |
 Approfondimento
Anonymous "Elementi costituenti dell'architettura SOA.
La SOA ha l'obiettivo di fornire un'architettura di riferimento orientata alla fruzione remota ed integrata di servizi.
All'interno della SOA sono presenti tre elementi principali:
-) Service Provider;
-) Service Requestor;
-) Service Registry.
Il Service Provider realizza ed offre un servizio, utilizzando
l'operazione di publish. Le caratteristiche del servizio realizzato
sono memorizzate all'interno di un registry accessibile pubblicamente.
Il Service Provider accetta delle request e risponde con delle
primitive di response.
Il Service Requestor rappresenta un potenziale utente che richiede un
servizio, utilizza la primitiva di find per interagire con il Service
Directory ed ottenere il servizio più adatto ai propri obiettivi. Una
volta individuato si collega al Service Provider corrispondente (bind)
ed inizia a fruire del particolare servizio.
Il Service Registry (definito anche Directory o Service Broker) si
occupa della gestione del registro dei servizi archiviando le
pubblicazione dei servizi e permettendo la ricerca di un servizio sulla
base delle caratteristiche con le quali è stato definito e memorizzato.
Naturalmente, il Service Registry può seguire politiche di controllo
degli accessi sulle interrogazioni in modo da limitare la visibilità
sui servizi inseriti.
La SOA definisce, quindi, "chi fa che cosa" all'interno di una serie di
interazioni in cui il servizio ricopre il ruolo principale. Va notato
che i tre attori interessati possono essere distribuiti sul territorio
e possono utilizzare piattaforme tecnologiche differenti, con l'unico
vincolo però di dover utilizzare tutti e tre un canale trasmissivo
comune. Rimanendo sul mezzo trasmissivo, questo risulta essere un
parametro dell'architettura, quindi l'approccio adottato dalle SOA ha
il vantaggio di potersi integrare con diversi ambienti quali la
telefonia mobile, il Web, o paradossalmente anche la posta ordinaria,
permettendo in tal modo di realizzare applicazioni multicanale,
fruibili cioè attraverso diversi dispositivi.
Partendo da questa considerazione si può dire che un'architettura per
e-Service è un'istanza di una SOA dove il mezzo di comunicazione è di
tipo elettronico, mentre una architettura per Web Service è un'istanza
di una SOA dove il mezzo di comunicazione considerato
è il Web.
La SOA è implementata utilizzando le seguenti tecnologie principali:
-) SOAP, Simple Object Access Protocol;
-) WSDL, Web Service Definition Language;
-) UDDI, Universal Description, Discovery and Integration.
SOAP è un protocollo, basato su XML (eXtensible Markup Language) e HTTP
(Hyper Text Transfer Protocol), in grado di fare interagire componenti
remoti attraverso il Web. Nonostante uno dei primi scopi di SOAP sia
stato quello di supportare l'RPC (Remote Procedure Call) sul Web,
questo protocollo è stato studiato anche per avere usi
che possono comprendere una interazione di tipo asincrono e,
quindi, basata su messaggi. In SOAP la specifica delle chiamate viene
descritta in XML, mentre l'HTTP è il protocollo di trasporto
utilizzato. Questa ultima caratteristica pone SOAP in una posizione
privilegiata rispetto ad altri meccanismi di invocazione presenti
in standard di computazione distribuita quale
COM+, Java RMI e CORBA, in quanto questi ultimi mostrano dei limiti
nell'uso del Web durante la comunicazione visto che i loro
messaggi vengono spesso bloccati dai
firewall.
WSDL è lo standard in XML per la definizione completa dei servizi, sia
in termini di parametri che di tipologia di connessione/request
accettata e
comportamento.
È di fondamentale importanza, quindi, avere a disposizione una
piattaforma in grado di reperire Web Service sulla base di diverse
tipologie di ricerca. UDDI è un progetto nato per questo scopo e
iniziato da un gruppo di compagnie del mondo IT quali Microsoft, IBM e
Ariba e al quale ora aderiscono circa 300 aziende.
Riguardo alla sua architettura UDDI prevede la creazione di un ambiente
distribuito peer-to-peer in cui i vari nodi, che contengono una parte
dei servizi disponibili, possano interoperare tra di loro allo scopo di
soddisfare le richieste di pubblicazione e ricerca di
servizi.
L'UDDI Business Registry è ulteriormente suddiviso in:
-) Service Type Registry: contenente un insieme di dati in grado di
descrivere e localizzare le tipologie di servizio. Tali informazioni
sono organizzate secondo una struttura detta
tModel;
-) Business Registry: contenente informazioni sulle aziende che
forniscono servizi e si sono registrate al nodo. Ogni entry di questo
registry è detta businessEntity;
La libreria API UDDI è di utilità per l'accesso, la ricerca e la manutenzione dei servizi registrati.
Un particolare oggetto di studio correlato alla SOA è il BPEL4WS
(Business Process Execution Language for Web Service), il quale
definisce un linguaggio di composizione tra servizi.
L'esigenza di coordinare in modo automatico attività svolte da attori
diversi per il raggiungimento di un obiettivo comune quale, per
esempio, l'approvazione di una richiesta, la concessione di un prestito
e il rimborso di danni ad un assicurato è caratteristica di processi
con un elevato numero di istanze, regole di esecuzione precise e
ripetibili.
Le classiche applicazioni software per il
supporto di flussi di lavoro con queste caratteristiche sono i sistemi
di gestione di workflow (WfMS, WorkFlow Management Systems),
che consentono la gestione contemporanea di un
numero, anche elevato, di istanze di processi seguendo schemi di
processo predefiniti.
L'affermarsi dei Web Service rende naturale l'estensione dei concetti
alla base dei sistemi di gestione di workflow anche per coordinare
servizi in rete forniti da più organizzazioni. In questo ambito,
l'obiettivo principale è quello di comporre più servizi forniti da
fornitori diversi al fine di creare nuovi servizi a valore aggiunto.
Tale composizione richiede però la definizione di standard per
modellare le interazioni tra i servizi. La letteratura
propone due principali approcci al coordinamento dei
servizi in rete, che vengono denominati orchestrazione e coreografia.
Nell'orchestrazione, si fa riferimento ad un processo di business che
può interagire con altri servizi, interni od esterni.
L'interazione avviene tramite messaggi
scambiati tra i servizi. L'orchestrazione presuppone il controllo sul
processo da parte di una sola organizzazione e consente di gestire
processi in esecuzione anche di lunga durata.
La coreografia indica, invece, un approccio più collaborativo, in cui
ogni partecipante descrive il proprio ruolo nell'interazione e il
compito del sistema di coreografia è principalmente quello di tenere
traccia delle interazioni avvenute tra le parti.
BPEL4WS (o BPEL, in breve) è un linguaggio, nato grazie
all'esperienza maturata sulla base di XLANG, una proposta di
Microsoft, e WSFL (Web Service Flow Language), si colloca come la
principale proposta per l'orchestrazione di Web Service, che può essere
vista come una naturale evoluzione di modelli e sistemi per la gestione
del workflow.
Una delle particolarità di BPEL è la sua visione ricorsiva di
composizione di Web Service. Infatti, Il processo definito come insieme
di Web Service collaboranti, può essere esso stesso un Web Service.
Questo nuovo servizio a valore aggiunto, così creato, sarà visibile
all'esterno come un servizio semplice di cui è definita l'interfaccia
WSDL.
Riferimenti:
-) http://uddi.microsoft.com UDDI Business Registry attivo
-) http://uddi.ibm.com UDDI Business Registry attivo
-) http://uddi.sap.com UDDI Business Registry attivo
-) http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ Business Process Execution Language for Web Services
-) http://www.w3.org/TR/wsdl Web Services Description Language (WSDL)
-) http://www.uddi.org/ UDDI
-) http://www.wfmc.org WfMC, Workflow Management Coalition
"
|
|
|
|
| |
Links Correlati |  |
Punteggio articolo | |
Punteggio medio: 0
Voti: 0
| |
Opzioni | |
|
