Secure, Reliable, Transacted Web Services: Architettura e composizione

 

Settembre 2003

IBM Corporation Donald F. Ferguson   IBM Fellow e Presidente  IBM Software Group Architecture Board Tony Storey  IBM Fellow

Microsoft Corporation   Brad Lovering  Ingegnere distinto    John Shewchuk  Progettista di servizi Web

Contenuto

1.0 Introduzione
   1.1 Servizi componibili
   1.2 Un esempio di composizione in pratica
2.0 Servizi Web: architettura Service-Oriented
   2.1 I servizi sono descritti dallo schema e dal tipo di contratto non
   2.2 La compatibilità del servizio è superiore alla compatibilità dei tipi
   2.3 L'orientamento del servizio presuppone che le cose cattive possano e accadranno
   2.4 L'orientamento del servizio consente l'associazione flessibile dei servizi
3.0 Specifiche e funzioni del servizio Web
   3.1 Approccio componibile ai servizi Web
   3.2 Nozioni di base - Trasporti e messaggistica
      3.2.1 Transports – HTTP, HTTP/S, SMTP
      3.2.2 Formati di messaggio - XSD
      3.2.3 WS-Addressing
   3.3 Descrizione
      3.3.1 WSDL
      3.3.2 WS-Policy
      3.3.3 Recupero di descrizioni
      3.3.4 WS-MetadataExchange
      3.3.5 UDDI
   3.4 Service Assurances
   3.5 Sicurezza
      3.5.1 WS-Security
      3.5.2 WS-Trust
      3.5.3 WS-SecureConversation
      3.5.4 WS-Federation
   3.6 Messaggistica affidabile
      3.6.1 WS-ReliableMessaging
   3.7 Transazioni
      3.7.1 WS-Coordination
      3.7.2 WS-AtomicTransaction
      3.7.3 WS-BusinessActivity
   3.8 Composizione dei servizi
      3.8.1 BPEL4WS
4.0 Servizi Web in pratica - Esempio
   4.1 Parte 1: Esperienza del cliente
   4.2 Parte 2: L'esperienza fornitore
5.0 Conclusioni
6.0 Riconoscimenti

1.0 Introduzione

Oggi i servizi Web, in particolare i servizi distribuiti che elaborano messaggi SOAP con codifica XML, inviati tramite HTTP e descritti usando WSDL (Web Services Description Language) vengono distribuiti su larga scala. I termini XML, SOAP e HTTP sono attualmente in uso comune e, in molti termini, il loro uso è passato oltre i loro acronimi originali. Per completezza, questi acronimi sono elencati qui: XML- eXtensible Markup Language, SOAP- Simple Object Access Protocol e HTTP- HyperText Transfer Protocol. I servizi Web vengono usati in una vasta gamma di scenari di integrazione delle applicazioni: da semplice, ad hoc, dietro il firewall, condivisione dei dati a vendite al dettaglio Internet su larga scala e trading di valuta. E sempre più servizi Web vengono applicati in scenari di dispositivi mobili, dispositivi e griglie.

I servizi Web forniscono l'interoperabilità tra componenti software che possono comunicare tra aziende diverse e possono risiedere in infrastrutture diverse. Questo risolve uno dei problemi più critici che i clienti, gli sviluppatori di software e i partner affrontano. HTTP e SOAP forniscono l'interoperabilità dei messaggi e delle comunicazioni. WSDL fornisce la descrizione del servizio per supportare l'interoperabilità tra gli strumenti di sviluppo; integra l'interoperabilità delle comunicazioni con la possibilità di scambiare definizioni di interfaccia.

Il set di base di specifiche di servizio Web consente ai clienti e ai fornitori di software di risolvere problemi importanti. Basandosi sul successo, molti sviluppatori e aziende sono pronti per affrontare problemi più difficili con la tecnologia del servizio Web. Il successo dei servizi Web ha portato gli sviluppatori a desiderare ancora più funzionalità dai servizi Web. Poiché l'interoperabilità significativa degli strumenti e delle comunicazioni ha avuto esito positivo, gli sviluppatori si aspettano ora che le funzioni avanzate interoperativino.

Oltre all'interoperabilità dei messaggi di base e allo scambio di interfacce, gli sviluppatori richiedono sempre più che i servizi applicativi di livello superiore interagiscono. Molte applicazioni commerciali vengono eseguite in un ambiente ("middleware" o "sistemi operativi") che forniscono supporto per funzioni come la sicurezza e le transazioni.

IBM, Microsoft e altri membri del settore vengono spesso richiesti per rendere i servizi Web più sicuri, più affidabili e più in grado di supportare le transazioni. Inoltre, viene chiesto di fornire queste funzionalità mantenendo al tempo stesso la semplicità e l'interoperabilità essenziali presenti nei servizi Web oggi.

Questo documento offre una panoramica concisa per il set di specifiche del servizio Web che rispondono a queste esigenze. Per informazioni dettagliate sulle specifiche, vengono forniti riferimenti ai documenti effettivi. Lo scopo principale di questo documento è definire brevemente il valore fornito ai nostri clienti. Viene inoltre descritto come queste specifiche si integrano tra loro per comporre ambienti affidabili per le applicazioni distribuite.

Ci troviamo di fronte a una sfida di progettazione chiave: come si offrono ai servizi Web nuove funzionalità di sicurezza, affidabilità e transazione senza aggiungere più complessità del necessario?

1.1 Servizi componibili

Come abbiamo fatto con SOAP e WSDL, IBM, Microsoft e i nostri partner hanno seguito il principio di progettazione di componibilità nella definizione delle specifiche del servizio Web. L'approccio seguito è basato sul principio di progettazione di componibilità nella definizione delle specifiche del servizio Web. Ogni specifica sviluppata risolve un'esigenza immediata ed è preziosa nel proprio diritto. Ad esempio, gli sviluppatori possono adottare messaggistica affidabile per semplificare lo sviluppo di soluzioni o adottare BPEL4WS per definire le composizioni dei servizi. E mentre ogni specifica è da sola, sono progettati per essere combinati e lavorare tra loro.

Usiamo il termine componibilità per descrivere specifiche indipendenti che possono essere combinate per offrire funzionalità più potenti. I provider del sistema operativo e del middleware possono supportare funzionalità composte, ad esempio i provider possono integrare il supporto di messaggistica affidabile per comunicare BPEL4WS processi. In questo esempio vengono combinate due specifiche indipendenti per semplificare lo sviluppo dei processi di comunicazione eliminando la necessità di gestire gli errori di comunicazione dei messaggi durante la progettazione del processo.

La componibilità consente a consumo incrementale o l'individuazione progressiva di nuovi concetti, strumenti e servizi. Gli sviluppatori devono solo imparare e implementare ciò che è necessario e non più. La complessità della soluzione aumenta solo perché i requisiti del problema aumentano e non sono dovuti alla tecnologia "bloat".

La componibilità ha e continua a essere uno degli obiettivi di progettazione chiave per i servizi Web. Negli ultimi anni abbiamo definito le specifiche di base del servizio Web (SOAP e WSDL) per supportare intrinsecamente la composizione. Una delle caratteristiche fondamentali di un servizio Web è una normale struttura di messaggi in più parti. Questa struttura consente la composizione di nuove funzionalità. È possibile aggiungere nuovi elementi di messaggio che supportano nuovi servizi ai messaggi in modo da non modificare l'elaborazione delle funzionalità esistenti. Ad esempio, è possibile aggiungere in modo indipendente identificatori di transazione e numeri di sequenza di messaggistica affidabili. Le due estensioni non sono in conflitto tra loro e sono compatibili con strutture di messaggi preesistenti.

Figura 1. La componibilità consente di usare gli elementi in base alle esigenze.

La figura 1 mostra un semplice messaggio di servizi Web che contiene elementi per WS-Addressing, WS-Securitye WS-ReliableMessaging. Si noti che gli elementi WS-Addressing, WS-Security e WS-ReliableMessaging sono indipendenti e questi elementi possono essere usati in modo indipendente senza modificare l'elaborazione di altri elementi.

Questa caratteristica consente di definire sicurezza, affidabilità e transazioni in termini di elementi di messaggio componibili.

La nozione di composizione consente anche la creazione di un set specifico di servizi Web componibili ben definiti che supportano sicurezza, affidabilità e così via. Questi servizi ben definiti specificano il comportamento dei servizi necessari per supportare funzionalità di servizio Web di livello superiore. Un esempio è il servizio token sicuro definito in WS-Trust che rilascia e convalida gli elementi di sicurezza nei messaggi.

Inoltre, è importante che i consumer di un servizio siano in grado di determinare le garanzie di servizio supportate e necessarie. I servizi devono documentare i requisiti e il supporto per transazioni, sicurezza, messaggistica affidabile e così via. WS-Policy consente ai servizi Web di aumentare in modo incrementale il file WSDL per documentare le funzioni di transazione, sicurezza e affidabilità supportate o richieste. WSDL e WS-Policy abilitare la composizione per la descrizione dei servizi. Ciò a sua volta consente alle altre parti di comprendere quali elementi del messaggio e servizi di livello superiore usare durante l'interazione con il servizio.

1.2 Un esempio di composizione in pratica

La figura 2 offre una panoramica che illustra la composizione in pratica. Un cliente e un fornitore usano servizi Web per elaborare gli ordini.

Figura 2. Composizione in un sistema di elaborazione degli ordini

Nella compilazione di questi servizi Web gli sviluppatori usano WSDL e i documenti correlati per descrivere l'interfaccia aziendale. Questi documenti WSDL descrivono il set di messaggi che verranno elaborati dai servizi Web del cliente e del fornitore, ad esempio il messaggio SubmitPurchaseOrder (SubmitPO) che passa dal cliente al fornitore. Questa operazione è illustrata nella parte superiore della figura 2. Una volta che le parti principali dell'applicazione sono presenti, gli sviluppatori possono quindi decidere di supportare una funzionalità aggiuntiva, ad esempio qui decidono di effettuare l'elaborazione dell'ordine transazionato. A tale scopo, comporre gli elementi seguenti nella struttura esistente:

• I servizi associano WS-Policy documenti che descrivono il supporto per le transazioni alla descrizione WSDL dei servizi. Si noti che queste istruzioni dei criteri aumentano ma non modificano fondamentalmente la funzionalità aziendale esistente.
• Per supportare l'elaborazione transazionata, i servizi aggiungono un elemento di messaggio aggiuntivo che descrive le transazioni che compongono con , ma non modificano fondamentalmente i messaggi dell'applicazione esistenti.
• Quando il servizio fornitore riceve messaggi che contengono l'elemento transazione, usa queste informazioni per comunicare con un servizio Web designato denominato coordinatore che supporta la funzione di transazione. Anche in questo caso, questo servizio Web aggiuntivo aggiunge semplicemente alla soluzione e non richiede modifiche alla descrizione della funzionalità aziendale esistente.
• Infine, i servizi possono implementare operazioni aggiuntive per supportare l'integrazione con il servizio coordinatore delle transazioni.

Nella figura precedente questi elementi aggiuntivi sono evidenziati.

Il modello è incrementale e componibile perché:

• L'aggiunta delle nuove funzioni può essere eseguita indipendentemente dall'aggiunta di altre funzioni.
• L'aggiunta della funzione non interrompe i messaggi esistenti, la logica di elaborazione dei messaggi o WSDL.

La componibilità è un principio di progettazione sempre più importante, ma l'approccio non è sempre ben compreso. Mentre le specifiche dei singoli servizi Web definiscono il modo in cui singoli elementi e servizi interagiscono, questo white paper è destinato a fornire una panoramica del modo in cui la raccolta di specifiche può essere composta per fornire servizi Web interoperabili più sofisticati.

2.0 Servizi Web: architettura Service-Oriented

Negli ultimi anni abbiamo assistito a un'attività incentrata sullo sviluppo dei servizi Web. Con tutta questa attività è importante tornare indietro e porre la domanda " Perché?" Certamente, i servizi Web non abilitano nuovi tipi di funzionalità di calcolo, dopo che tutti i servizi Web vengono ancora eseguiti nei computer esistenti, eseguendo lo stesso set di istruzioni e accedendo agli stessi dati. Inoltre, i protocolli del servizio Web in molti casi possono effettivamente aumentare il sovraccarico del protocollo per una determinata attività.

Uno dei motivi principali per cui si vede tale interesse nei servizi Web è che i servizi Web sono particolarmente adatti per abilitare un'architettura Service-Oriented (SOA). Quando si usano servizi Web per creare un SOA, le soluzioni sono costituite da raccolte di servizi autonomi, identificati da URL, con interfacce documentate usando WSDL ed elaborando messaggi XML ben definiti. SOA è un complemento naturale agli approcci orientati agli oggetti (OO), procedurali e incentrati sui dati per l'implementazione della soluzione. Infatti, quando si crea un sistema SOA, i singoli servizi vengono in genere costruiti usando una o più di queste tecnologie.

Un'architettura Service-Oriented differisce dai sistemi OO e procedurali in un aspetto chiave: binding. Servizi interagiscono in base quali funzioni di forniscono e come forniscono loro. I sistemi OO e procedurali collegano gli elementi in base al tipo o al nome. Le sezioni seguenti forniscono altri dettagli.

2.1 I servizi sono descritti dallo schema e dal tipo di contratto non

A differenza dei sistemi precedenti, il modello di servizio Web non opera sulla nozione di tipi condivisi che richiedono un'implementazione comune. I servizi interagiscono invece esclusivamente sui contratti (WSDL/BPEL4WS per il comportamento di elaborazione dei messaggi) e sugli schemi (WSDL/XSD per la struttura dei messaggi). Ciò consente al servizio di descrivere la struttura dei messaggi che può inviare e/o ricevere e sequenziare vincoli su questi messaggi. La separazione tra struttura e comportamento e la descrizione esplicita e verificabile del computer di queste caratteristiche semplifica l'integrazione in ambienti eterogenei.

Inoltre, queste informazioni caratterizzano sufficientemente l'interfaccia del servizio in modo che l'integrazione dell'applicazione non richieda un ambiente di esecuzione condiviso per creare la struttura o il comportamento dei messaggi.

Il modello orientato ai servizi presuppone un ambiente completamente distribuito in cui è difficile, se non impossibile, propagare modifiche allo schema e/o al contratto a tutte le parti che hanno rilevato un servizio. L'orientamento del servizio implica che i contratti e lo schema devono rimanere compatibili con le versioni precedenti e che possono contenere informazioni comprese incomplete da particolari sistemi di elaborazione.

Per questo motivo, le tecnologie di contratto e schema progettate per l'uso nelle progettazioni orientate ai servizi consentono una maggiore flessibilità rispetto alle interfacce tradizionali orientate agli oggetti. In particolare, i servizi usano funzionalità come i caratteri jolly degli elementi XML (ad esempio xsd:any), le estensioni dello schema e i blocchi di intestazione SOAP facoltativi per evolvere i servizi in modi che non interrompono le applicazioni distribuite. Queste caratteristiche sono la chiave per la componibilità dei servizi Web.

2.2 La compatibilità del servizio è superiore alla compatibilità dei tipi

Le progettazioni procedurali e orientate agli oggetti equivalgono in genere alla compatibilità dei tipi con la compatibilità semantica. L'orientamento del servizio offre un modello più completo per determinare la compatibilità. La compatibilità strutturale si basa sul contratto (WSDL e facoltativamente BPEL4WS) e sullo schema (XSD) e può essere convalidato. Inoltre, l'avvento di WS-Policy fornisce un'ulteriore analisi automatizzata della compatibilità del controllo dei servizi tra i servizi. Questa operazione viene eseguita in base a asserzioni esplicite di funzionalità e requisiti sotto forma di istruzioni WS-Policy.

Usando WS-Policy, i servizi descrivono le funzionalità e i requisiti di service assurance sotto forma di un'espressione di criteri leggibile dal computer contenente combinazioni di asserzioni. Ciò consente al servizio di selezionarsi tra loro in base a "come" o "con quale qualità" forniscono i loro contratti,

Le asserzioni di criteri sono identificate da nomi stabili e univoci a livello globale il cui significato è coerente nel tempo e nello spazio indipendentemente dal servizio a cui viene applicata l'asserzione. Le asserzioni di criteri possono anche avere parametri che qualificano l'interpretazione esatta dell'asserzione.

2.3 L'orientamento del servizio presuppone che le cose cattive possano e accadranno

Alcuni approcci precedenti alle applicazioni distribuite presupponevano in modo esplicito uno spazio di tipi comune, un modello di esecuzione e un modello di riferimento procedure/oggetto. In sostanza, il modello di programmazione "in memoria" ha definito il modello di sistema distribuito.

L'orientamento del servizio presuppone semplicemente che i servizi vengano eseguiti in modo autonomo e che non esista alcuna nozione di esecuzione locale o di ambiente operativo comune. Per questo motivo, un SOA presuppone esplicitamente che le comunicazioni, la disponibilità e gli errori di tipo siano comuni.

Per mantenere l'integrità del sistema, le progettazioni orientate ai servizi si basano in modo esplicito su un'ampia gamma di tecnologie per gestire le modalità asincrone e parziali degli errori. Le tecniche come la messaggistica asincrona, le transazioni, la messaggistica affidabile e la distribuzione ridondante sono la norma in sistemi orientati ai servizi.

Inoltre, a differenza del modello in memoria, l'orientamento del servizio presuppone che non solo un messaggio in arrivo possa essere in formato non valido, ma anche che possa essere stato trasmesso per scopi dannosi o completamente imprevisti. Di conseguenza, i sistemi orientati ai servizi si proteggono ponendo il carico di prova su tutti i mittenti di messaggi richiedendo alle applicazioni di dimostrare che i diritti richiesti sono stati concessi al mittente. Coerente con la nozione di autonomia del servizio, le architetture orientate ai servizi si basano in genere sulle relazioni di trust gestite dall'amministratore per evitare meccanismi di autenticazione per servizio comuni nelle applicazioni Web classiche.

2.4 L'orientamento del servizio consente l'associazione flessibile dei servizi

Uno dei concetti di base di 'architettura orientata ai servizi (SOA) è l'associazione flessibile dei servizi. I modelli procedurali, componenti e oggetti più tradizionali associano i componenti tramite riferimenti (puntatori) o nomi. Un SOA supporta un'individuazione più dinamica delle istanze del servizio che fornisce l'interfaccia, la semantica e le garanzie di servizio previste dal richiedente.

Nei sistemi procedurali o orientati agli oggetti, un chiamante trova in genere un server in base ai tipi che esporta o a uno spazio dei nomi condiviso. In un sistema SOA i chiamanti possono cercare registri come UDDI per un servizio.

1. Messaggio compatibile con i requisiti del chiamante. La compatibilità può verificarsi tramite WSDL o messaggi corrispondenti da XML Schema noti.
2. Che documenta il supporto per il servizio garantisce che il chiamante richieda. Ad esempio, il chiamante può desiderare determinati approcci alla sicurezza o alle transazioni.

Il binding libero rispetto all'implementazione del servizio che consente implementazioni alternative di comportamento può essere usato per soddisfare una serie di requisiti aziendali. Ad esempio, le implementazioni alternative potrebbero corrispondere a fornitori alternativi in una catena di approvvigionamento, consentendo una risposta più rapida ai cambiamenti delle condizioni di mercato. Analogamente, l'implementazione alternativa potrebbe essere distribuita geograficamente nei data center che abilitano la tolleranza di emergenza.

3.0 Specifiche e funzioni del servizio Web

Questa sezione offre una panoramica delle specifiche del servizio Web.

3.1 Approccio componibile ai servizi Web

Questa sezione descrive brevemente le specifiche del servizio Web disponibili. Viene spiegato il loro valore ai provider di soluzioni, il loro ruolo in un'architettura più ampia e come si complimentano tra loro.

La figura seguente fornisce un raggruppamento generale delle specifiche del servizio Web pubblicate da IBM, Microsoft e altri. Si noti che questa figura non è destinata a implicare una stretta sovrapposizione tra i gruppi; è invece progettato per fornire un'intuizione sulle relazioni tra le aree funzionali. Ad esempio, la sicurezza dei messaggi non richiede Descrizione e analogamente Description è un concetto utile per il tempo di sviluppo per la messaggistica.

Figura 3. Architettura del protocollo di servizi Web interoperabili

3.2 Nozioni di base- Trasporti e messaggistica

Se vi invierò una lettera scritta in francese, ma vi aspettavi una telefonata in inglese, non comunicheremo. L'interoperabilità dei servizi Web presenta lo stesso problema; questo problema viene affrontato fornendo un set comune di trasporti e tecnologie di messaggistica.

Inoltre, per garantire che queste tecnologie siano efficaci in pratica, IBM, Microsoft e altri hanno creato l'organizzazione di interoperabilità dei servizi Web (WS-I). Recentemente il WS-I ha rilasciato un profilo di base che documenta formalmente meccanismi di trasporto e messaggistica dei servizi Web interoperabili.

3.2.1 Trasporti: HTTP, HTTP/S, SMTP

Questo set di specifiche definisce i meccanismi di comunicazione principali per lo spostamento di dati non elaborati tra i servizi Web.

HTTP, HTTP/S e SMTP (Simple Mail Transport Protocol) sono esempi in questo gruppo. Le implementazioni del servizio Web possono supportare anche altri trasporti, ma è fondamentale fornire supporto per protocolli standard e interoperabili.

3.2.2 Formati di messaggio - XSD

Il gruppo successivo di specifiche definisce meccanismi interoperativi per la codifica dei messaggi del servizio Web per il trasporto. I trasporti spostano blocchi di "byte" tra i servizi. Ciò è utile solo se i partecipanti possono convertire i byte in strutture di dati utili elaborate dall'applicazione.

Il gruppo di specifiche di messaggistica definisce come formattare correttamente i messaggi. Le definizioni di XML e XML Schema forniscono il meccanismo per accettare in modo astratto le strutture di messaggi (dati). SOAP definisce la codifica standard per la rappresentazione dei messaggi XML nelle informazioni sui byte scambiate dai servizi sui trasporti.

3.2.3 WS-Addressing

I messaggi e le risposte vanno da qualche parte e provengono da qualche parte. WS-Addressing offre un approccio indipendente dal trasporto interoperabile per identificare mittenti e ricevitori di messaggi. WS-Addressing fornisce anche un approccio più dettagliato per identificare elementi specifici all'interno di un servizio che inviano o devono ricevere un messaggio.

Attualmente la maggior parte dei sistemi che usano servizi Web codificano la destinazione per un messaggio del servizio Web con un URL inserito nel trasporto HTTP. La destinazione della risposta è determinata dall'indirizzo di trasporto restituito. Questo approccio si basa sul modello browser-server di base di HTTP.

Usando l'approccio odierno, le informazioni di origine e di destinazione non fanno parte del messaggio stesso. Questo può causare diversi problemi. Le informazioni possono andare perse se una connessione di trasporto termina (ad esempio, se la risposta richiede molto tempo e si verifica il timeout della connessione) o se il messaggio viene inoltrato da un intermediario, ad esempio un firewall.

WS-Addressing fornisce un meccanismo per inserire la destinazione, l'origine e altre informazioni importanti sull'indirizzo direttamente all'interno del messaggio del servizio Web. In breve, WS-Addressing disaccoppia le informazioni sull'indirizzo da qualsiasi modello di trasporto specifico.

In molti scenari i messaggi sono destinati direttamente a un servizio e le informazioni di indirizzamento nel messaggio possono essere descritte semplicemente usando un URL. Tuttavia, in pratica, spesso si rileva che i messaggi sono destinati a elementi o risorse specifici all'interno di un servizio. Ad esempio, un servizio di coordinamento potrebbe coordinare molte attività diverse. Il coordinatore deve associare la maggior parte dei messaggi in arrivo a un'istanza specifica dell'attività gestita e non al servizio di coordinamento stesso. 

WS-Addressing fornisce un meccanismo semplice ma potente denominato riferimento all'endpoint per indirizzare le entità gestite da un servizio. Sebbene tali informazioni possano essere codificate in modo ad hoc all'interno dell'URL del servizio, i riferimenti all'endpoint forniscono un elemento XML standard che consente a un approccio strutturato di codificare questo indirizzamento con granularità fine.

La combinazione di controllo granulare sull'indirizzamento associato alla codifica indipendente dal trasporto dell'origine e della destinazione dei messaggi consente l'invio dei messaggi del servizio Web in un'ampia gamma di trasporti, tramite intermediari e consente modelli di comunicazione di durata asincrona e estesa.

WS-Addressing consente anche a un mittente di indicare dove deve essere inserita una risposta in modo indipendente dal trasporto. La risposta a un messaggio potrebbe non necessariamente andare al mittente. In HTTP, ad esempio, senza WS-Addressing è impossibile specificare che la risposta deve essere inviata altrove.

Questi miglioramenti al modello di messaggistica consentono l'uso dei servizi Web per supportare molti scenari aziendali. Ad esempio, alcune attività bancarie richiedono una revisione umana per l'approvazione in determinati passaggi. In genere sono presenti molte istanze attive dell'attività in qualsiasi momento. WS-Addressing fornisce un meccanismo generale per associare messaggi in ingresso o in uscita a attività specifiche. Il meccanismo usato dal servizio è trasparente per coloro che usano il servizio tramite un riferimento all'endpoint.

3.3 Descrizione

Le specifiche di trasporto e messaggio consentono ai servizi Web di comunicare tramite messaggi. Ma come fanno i partecipanti a sapere quali sono i messaggi? In che modo un documento del servizio Web o descrive i messaggi inviati e ricevuti? L'uso di un servizio Web richiede una comprensione dei messaggi che il servizio Web utilizzerà e produrrà, ovvero l'interfaccia per il servizio Web. Il gruppo di descrizioni delle specifiche consente a un servizio Web di esprimere l'interfaccia e le funzionalità.

Oltre all'interoperabilità dei messaggi; queste specifiche consentono anche l'interoperabilità degli strumenti di sviluppo . Le specifiche di descrizione forniscono un modello standard che consente a diversi strumenti di fornitori diversi di supportare in modo collaborativo gli sviluppatori. Allo stesso modo in cui i servizi Web isolano i partner dalle scelte di implementazione e infrastruttura, le specifiche di descrizione isolano i partner dalle scelte degli strumenti di sviluppo.

3.3.1 WSDL

I WSDL (Web Services Description Language) e il XML Schema (XSD) sono le specifiche di base di questo gruppo. XML Schema consente agli sviluppatori e ai provider di servizi di definire tipi XML per strutture di dati, ad esempio un ordine di acquisto e messaggi, ad esempio il messaggio CreatePO. WSDL consente a un servizio Web di documentare i messaggi ricevuti e inviati. In altre parole, quali "azioni" o "funzioni" il servizio esegue in termini di messaggi ricevuti e inviati.

WSDL offre supporto per una gamma di modelli di interazione dei messaggi. Supporta messaggi di input unidirezionale che non hanno risposta, richiesta/risposta e un modo invia con o senza risposta. Gli ultimi due modelli consentono a un servizio di specificare altri servizi necessari.

I miglioramenti WSDL proposti forniscono supporto per i protocolli di documentazione e i formati di messaggio supportati da un servizio e l'indirizzo del servizio.

3.3.2 WS-Policy

Le definizioni WSDL e XSD spesso non forniscono informazioni sufficienti per chiamare un servizio Web. WSDL e XSD definiscono la sintassi dell'interfaccia del servizio, ma non esprimono informazioni sul modo in cui il servizio fornisce l'interfaccia o su ciò che il servizio si aspetta dal chiamante. Ad esempio, il servizio richiede la sicurezza o implementa le transazioni?

WS-Policy consente a un servizio di specificare ciò che prevede i chiamanti e il modo in cui implementa l'interfaccia. WS-Policy è fondamentale per ottenere l'interoperabilità al funzionamento funzionale di livello superiore del servizio. Sicurezza, transazioni, messaggistica affidabile e altre specifiche richiedono uno schema WS-Policy concreto. Questi consentono ai servizi di descrivere la garanzia funzionale che si aspettano e forniscono ai chiamanti.

Il framework WS-Policy fornisce un modello di base per la definizione di espressioni di criteri.

WS-Policy supporta una grammatica per l'aggregazione di istruzioni dei criteri e consente la costruzione di set di criteri più flessibili e completi.

WS-PolicyAttachment specifica come associare un set di criteri ai messaggi XML e agli elementi WSDL (operazioni e portType).

Insieme WS-Policy e WS-PolicyAttachment fornire il framework. Le singole specifiche definiscono le istruzioni di criteri e lo schema specifici del dominio.

Infine, @PageWS-PolicyAssertions fornisce un set fondamentale di istruzioni di criteri comuni che possono essere usate per ottenere l'interoperabilità.

3.3.3 Recupero di descrizioni

Xml, XSD, WSDL e WS-Policy supporto per descrivere l'interfaccia e le garanzie di servizio per un servizio. Ma come fanno i potenziali utenti del servizio a trovare queste informazioni?

Attualmente, l'approccio più comune è attraverso scambi di posta elettronica o parola di bocca. È necessario un modello più generico e scalabile. Esistono due opzioni, il servizio può passare direttamente al servizio per ottenere informazioni usando WS-MetadataExchange oppure può scegliere di usare un servizio UDDI che aggrega queste informazioni per più servizi di destinazione.

Gli sviluppatori usano WS-MetadataExchange quando hanno un riferimento a un servizio e devono comprendere cosa fa. Gli sviluppatori usano UDDI quando vogliono trovare un riferimento a un servizio che supporta un set specifico di funzioni.

3.3.4 WS-MetadataExchange

Come descritto in precedenza, i servizi in genere forniscono informazioni come WSDL, WS-Policy e XSD, che descrivono il servizio stesso. La raccolta dei dati si riferisce alle informazioni sul servizio come metadati. La specifica WS-MetadataExchange consente a un servizio di fornire metadati ad altri utenti tramite un'interfaccia dei servizi Web. Dato solo un riferimento a un servizio Web, un potenziale utente può accedere a un set di operazioni WSDL/SOAP per recuperare i metadati che descrivono il servizio. I client possono usare WS-MetadataExchange in fase di progettazione, durante la compilazione dei client o in fase di esecuzione.

3.3.5 UDDI

Spesso è utile raccogliere metadati su una raccolta di servizi e rendere disponibili le informazioni in un modulo ricercabile. Tali servizi di aggregazione dei metadati sono un repository utile in cui le organizzazioni possono pubblicare i servizi forniti, descrivere le interfacce nei servizi e abilitare tassonomie specifiche del dominio dei servizi. La specifica Descrizione universale e interfaccia di individuazione (UDDI) definisce un servizio di aggregazione dei metadati.

Le soluzioni possono eseguire query su UDDI in fase di progettazione per trovare servizi compatibili con i requisiti. Gli sviluppatori possono usare questi servizi nella definizione dei flussi di lavoro BPEL4WS, ad esempio. Le soluzioni possono anche eseguire query su UDDI in fase di esecuzione. In questo scenario, il chiamante "conosce" l'interfaccia necessaria e cerca un servizio che soddisfa i requisiti funzionali o viene fornito da un partner noto.

Si noti che uno dei meccanismi che potrebbero essere usati per popolare un servizio UDDI con metadati consiste nell'acquisire i metadati dai servizi usando WS-MetadataExchange.

3.4 Service Assurances

I servizi Web hanno generato tanto entusiasmo in parte grazie alla loro capacità di colmare sistemi diversi. Gli sviluppatori hanno prodotto molte soluzioni completamente funzionali usando le funzionalità di base del trasporto, della messaggistica e della descrizione. Tuttavia, per essere accettati dagli sviluppatori che creano soluzioni di integrazione più potenti, i servizi Web devono fornire funzionalità per garantire lo stesso livello di garanzie di servizio fornite da soluzioni middleware più tradizionali. Non è sufficiente scambiare semplicemente messaggi. Le applicazioni e i servizi risiedono in middleware e sistemi che forniscono funzioni di alto livello preziose, ad esempio sicurezza, affidabilità e operazioni transazionate. I servizi Web devono fornire un meccanismo per l'interoperabilità tra queste funzioni.

3.5 Sicurezza

Questa @Pagefamiglia di specifiche è fondamentale per i servizi Web tra organizzazioni. Queste specifiche supportano l'autenticazione e l'integrità dei messaggi, la riservatezza, l'attendibilità e la privacy. Supportano anche la federazione della sicurezza tra organizzazioni diverse.

3.5.1 WS-Security

WS-Security è il blocco predefinito di base per i servizi Web sicuri. Attualmente, la maggior parte dei servizi Web distribuiti si basa sul supporto a livello di trasporto per le funzioni di sicurezza. Esempi sono HTTP/S e BASIC-Auth l'autenticazione. Questi approcci alla sicurezza forniscono il minimo necessario per la comunicazione sicura. Il livello di funzione fornito, tuttavia, è significativamente inferiore a quello fornito dal middleware esistente e dagli ambienti distribuiti.

Due esempi evidenziano le carenze di BASIC-Auth e HTTP/S.

• Un invia un messaggio al servizio B. B elabora parzialmente i messaggi e lo inoltra al servizio C. HTTP/S consente l'autenticazione, la riservatezza e l'integrità tra A-B e B-C. Tuttavia, C e A non possono autenticarsi tra loro o nascondere le informazioni da B.
• Per A, B e C usare BASIC-Auth per l'autenticazione. Devono condividere le stesse informazioni sull'utente e sulla password replicate. Ciò non è accettabile in molti scenari.

WS-Security risolve questi problemi. Supporta:

• Token di sicurezza firmati e crittografati. Un può generare un token che C può verificare come provenire da A. B non può forgiare il token.
• Un oggetto può firmare gli elementi selezionati o l'intero messaggio. Ciò consente a B e C di confermare che il messaggio non è stato modificato dopo l'invio A.
• Un oggetto può bloccare il messaggio o gli elementi selezionati. In questo modo si garantisce che solo il servizio previsto per tali elementi possa usare le informazioni. Ciò impedisce a B di visualizzare le informazioni destinate a C e viceversa.

WS-Security usa modelli di sicurezza esistenti (Kerberos, X509 e così via). Le specifiche definiscono in modo concreto come usare i modelli esistenti in modo interoperabile. I calcoli di servizi Web multi hop non possono essere protetti senza WS-Security.

3.5.2 WS-Trust

La sicurezza si basa su relazioni di trust predefinite. Kerberos funziona perché i partecipanti "considerano attendibile" il Centro distribuzione chiavi Kerberos. L'infrastruttura a chiave pubblica funziona perché i partecipanti considerano attendibili le autorità di certificazione radice. WS-Trust definisce un modello estendibile per la configurazione e la verifica delle relazioni di trust.

Il concetto chiave in WS-Trust è un servizio token di sicurezza (STS) di . Un servizio token di sicurezza è un servizio Web distinto che rilascia, scambia e convalida i token di sicurezza. WS-Trust consente ai servizi Web di configurare e accettare quali server di sicurezza considerano attendibili e fare affidamento su questi server.

Il servizio token di sicurezza ha un'ampia applicabilità in quanto può essere usata per rilasciare token di sicurezza che rendono un'ampia gamma di asserzioni. In molti casi verrà usato per eseguire le stesse asserzioni, ma in formati diversi. Ad esempio, un servizio token di sicurezza potrebbe emettere un token Kerberos asserendo che il titolare della chiave è Susan e potrebbe farlo in base a un certificato X.509 emesso da un'autorità di certificazione attendibile. In questo modo le organizzazioni usano tecnologie di sicurezza diverse per la federazione. Un servizio token di sicurezza potrebbe anche emettere un token di sicurezza che afferma che il titolare della chiave è un membro del gruppo BankTellers basato su un token di sicurezza in ingresso che asserisce un'attestazione di identità.

3.5.3 WS-SecureConversation

Alcuni scenari di servizio Web comportano solo lo scambio sporadico breve di alcuni messaggi. WS-Security supporta facilmente questo modello. Altri scenari prevedono conversazioni multi-messaggio di lunga durata tra i servizi Web. WS-Security supporta anche questo modello, ma la soluzione non è ottimale.

In questi scenari esistono due utilizzi non ottimali di WS-Security:

• Uso ripetuto di operazioni crittografiche costose a livello di calcolo, ad esempio la convalida della chiave pubblica.
• Invio e ricezione di molti messaggi usando le stesse chiavi crittografiche, fornendo altre informazioni che consentono agli attacchi di forza bruta di "interrompere il codice".

Per questi motivi, i protocolli come HTTP/S usano chiavi pubbliche per eseguire una semplice negoziazione che definisce chiavi specifiche della conversazione. Questo scambio di chiavi consente implementazioni di sicurezza più efficienti e riduce anche la quantità di informazioni crittografate con un set specifico di chiavi.

WS-SecureConversation offre un supporto simile per WS-Security. I partecipanti usano spesso WS-Security con chiavi pubbliche per avviare una "conversazione" o "sessione" e usare WS-SecureConversation per accettare chiavi specifiche della sessione per la firma e la crittografia delle informazioni.

3.5.4 WS-Federation

WS-Federation consente a un set di organizzazioni di stabilire un singolo dominio di sicurezza virtuale. Ad esempio, un agente di viaggio, una compagnia aerea e una catena di hotel possono configurare tale federazione. Un utente finale che "accede" a qualsiasi membro della federazione ha effettivamente eseguito l'accesso a tutti i membri. WS-Federation definisce diversi modelli per fornire la sicurezza federata tramite protocolli tra topologie di WS-Trust e WS-SecureConversation.

Inoltre, i clienti spesso hanno "proprietà" quando gestiscono un'azienda. Un esempio è una preferenza per i sedili finestra o aisle o un'auto di medie dimensioni. WS-Federation consente ai membri di configurare uno spazio di proprietà federato. In questo modo ogni partecipante può avere accesso controllato sicuro alle informazioni sulle proprietà di ogni membro relative agli utenti finali.

Proprietà e informazioni sulle persone possono essere strettamente mantenute per la protezione della privacy o perché le informazioni forniscono un vantaggio competitivo a un membro specifico. Per supportare questi requisiti, WS-Federation supporta un modello pseudonimo di . Gli utenti che hanno autenticato l'agenzia di viaggi hanno generato "alias" nelle loro interazioni con la compagnia aerea o l'hotel. Ciò protegge la privacy dell'utente finale e il vantaggio competitivo che l'agenzia di viaggi può ottenere conoscendo le proprietà degli utenti.

3.6 Messaggistica affidabile

In un mondo Internet, quasi tutti i canali di comunicazione sono inaffidabili. I messaggi scompaiono. Interruzione delle connessioni.

Senza uno standard di messaggistica affidabile, gli sviluppatori di applicazioni di servizio Web devono compilare queste funzioni nelle applicazioni. Gli approcci e le tecniche di base sono ben compresi, ad esempio molti sistemi operativi e middleware assicurano che i messaggi abbiano identificatori univoci, forniscano numeri di sequenza e usino la ritrasmissione quando i messaggi vengono persi. Se gli sviluppatori di servizi Web dell'applicazione implementano questi modelli nelle applicazioni. Possono fare ipotesi o scelte di progettazione diverse, causando poco se una messaggistica affidabile.

3.6.1 WS-ReliableMessaging

WS-ReliableMessaging definisce meccanismi che consentono ai servizi Web di garantire il recapito dei messaggi su reti di comunicazione inaffidabili.

WS-ReliableMessaging garantisce che i servizi implementino approcci interoperabili e consenta anche ai fornitori di runtime di semplificare lo sviluppo di applicazioni fornendo servizi che implementano i protocolli. Questo semplifica notevolmente l'attività di sviluppo di applicazioni. La logica di business ha quindi meno condizioni di errore che deve gestire.

Infine, il settore ha un set completo di middleware orientati ai messaggi per il routing e la distribuzione affidabile dei messaggi. Ogni implementazione usa protocolli proprietari. WS-Reliable protocolli di messaggistica consentono a sistemi operativi e middleware diversi di scambiare messaggi in modo affidabile. Pertanto, supporta il bridging di due infrastrutture diverse in un unico modello end-to-end completo logicamente.

3.7 Transazioni

Uno scenario aziendale complesso può richiedere a più parti di scambiare più set di messaggi. Un esempio è costituito da una serie di istituti finanziari che configurano un'offerta finanziaria che coinvolge politiche assicurative, annualità, conti di controllo e conti di brokeraggio. I più messaggi scambiati tra i partecipanti costituiscono un "compito" logico o "obiettivo".

Per il successo, le parti devono essere in grado di:

1. Avviare nuove attività coordinate.
2. Associare le operazioni all'attività logica. Le parti possono configurare più account per clienti diversi contemporaneamente.
3. Accettare il risultato del calcolo. Ad esempio, tutti sono d'accordo che i pacchetti finanziari sono stati configurati?

WS-Coordination, WS-AtomicTransaction e WS-BusinessActivity supportano questi requisiti.

3.7.1 WS-Coordination

WS-Coordination@Pageè un meccanismo generale per l'avvio e l'accordo sul risultato delle attività del servizio Web multiparty e multi-messaggio. WS-Coordination ha tre elementi chiave:

1. Elemento di messaggio denominato contesto di coordinamento che scorre su tutti i messaggi che i servizi Web scambiano durante il calcolo. Il contesto di coordinamento contiene il riferimento all'endpoint WS-Addressing al servizio di coordinamento e contiene a sua volta informazioni per identificare l'attività specifica coordinata.
2. Servizio coordinatore . Il servizio coordinatore fornisce un servizio, descritto usando WSDL, che consente di avviare un'attività coordinata, terminare un'attività coordinata, consentire a un partecipante di registrarsi in un'attività e produrre un contesto di coordinamento che fa parte di tutti i messaggi all'interno di un gruppo.
3. Il servizio di coordinamento include anche un'interfaccia, definita in WSDL, che i servizi partecipanti usano per essere informati del risultato dell'attività coordinata.

Un servizio Web che riceve un messaggio con un nuovo contesto di coordinamento si registra con il servizio coordinatore nel contesto per ricevere informazioni sui risultati. Altre specifiche possono aumentare questo framework per requisiti specifici di dominio e garanzia.

WS-Coordination è un framework e funzionalità generali. WS-AtomicTransaction e WS-BusinessActivity estendere questo framework per consentire ai partecipanti al calcolo distribuito di determinare in modo affidabile i risultati.

3.7.2 WS-AtomicTransaction

WS-AtomicTransaction definisce un set specifico di protocolli collegati al modello di WS-Coordination per implementare protocolli di transazione atomici tradizionali in due fasi. È importante notare che il modello atomico a due fasi è solo per quanto riguarda i servizi coinvolti. I siti o le offerte di infrastruttura possono annunciare il commit in due fasi, ma usare un altro modello intra-aziendale, ad esempio compensazione o controllo delle versioni. Questa libertà rende più utile un semplice modello di commit a due fasi per i calcoli Internet a esecuzione prolungata.

3.7.3 WS-BusinessActivity

WS-BusinessActivity definisce un set specifico di protocolli che si collega al modello di WS-Coordination per implementare protocolli di transazione basati su compensazione e a esecuzione prolungata. Mentre BPEL4WS definisce un modello di transazione per i processi aziendali, è WS-BusinessActivity che specifica il rendering del protocollo corrispondente. Anche in questo caso, è un esempio per la componibilità delle specifiche dei servizi Web.

3.8 Composizione dei servizi

L'elemento più alto nel livello del servizio Web è composizione del servizio. La composizione del servizio consente agli sviluppatori di "comporre" servizi che scambiano messaggi SOAP e definiscono l'interfaccia in WSDL e WS-Policy in una soluzione di aggregazione. L'aggregazione è un servizio Web composto.

3.8.1 BPEL4WS

La specifica di del processo aziendale per i servizi Web (BPEL4WS). Consente agli sviluppatori di definire la struttura e il comportamento di un set di servizi Web che implementano congiuntamente una soluzione aziendale condivisa. Ogni elemento del set di servizi definisce la relativa interfaccia usando WSDL e WS-Policy. La soluzione composta è un servizio Web, che supporta i messaggi HTTP/SOAP e ne definisce l'interfaccia usando WSDL e WS-Policy.

La composizione presenta tre aspetti: struttura , informazioni e comportamento di . BPEL4WS introduce tre costrutti che supportano ogni aspetto della composizione.

Un partnerLink definisce un'associazione denominata tra il servizio composito e un servizio Web che partecipa alla soluzione complessiva. Il servizio composito e il servizio partecipante definiscono le rispettive interfacce tra loro usando WSDL e WS-Policy. Un esempio può essere un'associazione tra un'azienda manifatturiera e un fornitore.

Il concetto partnerLink e le interfacce WSDL/WS-Policy tra la composizione e i partner definiscono la struttura della composizione del servizio. Definiscono i tipi di servizi che collaborano per formare la composizione e quali messaggi scambiano con quali livelli di garanzia (sicurezza, transazioni e così via)

BPEL4WS fornisce inoltre supporto per la definizione delle informazioni della composizione del servizio. BPEL4WS definisce il concetto di variabile. Il servizio composito definisce un set di variabili, ognuna delle quali ha una definizione XSD. Lo stato corrente di un servizio specifico è lo stato delle relative variabili. Definisce i messaggi ricevuti o inviati.

Infine, BPEL4WS supporta la definizione del comportamento del servizio composito in base al concetto di attività . Un servizio definito BPEL4WS è un set di attività o "passaggi", che definiscono il comportamento del servizio. Le attività più di base inviano un messaggio a un partner o ricevono un messaggio da un partner. Ogni messaggio corrisponde a una variabile. BPEL4WS fornisce supporto per lo spostamento di dati tra variabili.

Un aspetto chiave delle attività di BPEL4WS è che BPEL4WS fornisce un supporto speciale per la definizione del comportamento esterno visibile (pubblico) dei servizi consentendo l'uso controllato del comportamento non deterministico. Ad esempio, il fatto che un assegno di credito venga eseguito in modo specifico nel processo decisionale per l'accettazione di un ordine di acquisto può essere una questione privata per un fornitore. BPEL4WS consente di nascondere il processo decisionale eliminando il comportamento del controllo del credito dalla descrizione del processo, ma mostrando che la risposta all'ordine di acquisto può essere accettazione o rifiuto. Questo tipo di processo astratto può essere usato in combinazione con WSDL per definire protocolli aziendali interoperabili tra partner commerciali e per domini di settore verticali, ad esempio supply chain.

BPEL4WS supporta anche diversi approcci per controllare il flusso di esecuzione delle attività. Questi includono sequenziazione e flussi basati su grafo. BPEL4WS supporta predicati sulle variabili per determinare quali percorsi di controllo seguono il servizio composito.

Per riepilogare, BPEL4WS apporta due aggiunte alle specifiche del servizio Web definite in precedenza.

1. BPEL4WS estende il supporto WSDL e WS-Policy per descrivere i servizi. BPEL4WS supportare la combinazione di servizi Web in servizi aggregati e la documentazione delle associazioni tra i servizi, ad esempio il flusso di informazioni e il comportamento. Questo offre supporto per l'interoperabilità tra strumenti di livello superiore che supportano la progettazione collaborativa di servizi Web.
2. BPEL4WS è un linguaggio di esecuzione . BPEL4WS consente agli sviluppatori di specificare completamente il comportamento di un servizio Web composito. IBM, Microsoft e altri partner forniranno ambienti che eseguono BPEL4WS documenti e supportano l'associazione di progettazione ed esecuzione ai partner.

4.0 Servizi Web in pratica: un esempio

Lo scenario seguente illustra come le specifiche WS possono essere usate insieme per creare servizi Web che risolvono le esigenze reali. Lo scenario fornisce un esempio delle potenti funzionalità disponibili per gli sviluppatori a causa della componibilità delle diverse specifiche WS.

I servizi Web descritti in questo scenario sono stati creati per una dimostrazione congiunta IBM-Microsoft della tecnologia tenutasi il 17 settembre 2003. Sono stati usati per creare un'applicazione interoperabile, sicura, affidabile e transazionata; e che si estende sui limiti dell'organizzazione.

La dimostrazione mostra un esempio in esecuzione di un sistema federato di elaborazione degli ordini e di inventario gestito fornitore (VMI) per un rivenditore di automobili che ordina una parte da un produttore di automobili; il produttore a sua volta ottiene parti da un fornitore che opera più magazzini. Tutte le comunicazioni da applicazione a applicazione nel sistema sono state create esclusivamente usando i protocolli del servizio Web descritti in precedenza e in esecuzione su una raccolta di computer con software IBM e Microsoft.

Lo scenario riguarda alcuni degli aspetti più comuni dell'attività di condotta, ovvero l'interazione tra un'azienda al dettaglio, il suo rivenditore all'ingrosso e il fornitore dell'ingrosso. Lo scenario mostra come possono essere composte diverse specifiche WS per automatizzare i concetti essenziali del processo aziendale, ad esempio:

1. Autenticazione per applicare la sicurezza (WS-Security)
2. Federazione di trust tra organizzazioni diverse ( WS-Trust e WS-Federation)
3. Scambio di dati per completare una transazione (WS-AtomicTransaction)
4. Verificare che gli ordini siano stati inviati tramite messaggistica affidabile (WS-ReliableMessaging)

4.1 Parte 1: Esperienza del cliente

L'esempio inizia con Heather, un dipendente di una società denominata Auto Dealer, che accede al sito Web Intranet sicuro della concessionaria. Questo sito Web si basa su tecnologie Web standard e non aggiornate. Heather entra nel sito usando il suo browser. L'accesso al sito è protetto da password.

Figura 4. Heather accede al sito Web Intranet sicuro dell'azienda e passa alla pagina personale personalizzata.

Heather fa clic sulla mia pagina. In background l'applicazione raccoglie informazioni dal database di inventario del concessionario auto. Se i livelli di inventario per un elemento sono inferiori a una soglia definita, viene generato un report e elencato nella visualizzazione "Avvisi" della pagina di Heather.

Heather vede che la sua azienda ha un inventario ridotto su pannelli a wiper WindshieldPro.

Heather fa clic sul collegamento e viene facilmente reindirizzato a una pagina Web sicura nella extranet Del produttore automatico, in cui Heather può effettuare un ordine. L'esperienza è perfetta perché il software del concessionario automatico si basa su servizi Web. Il servizio Web che collega la Intranet del concessionario automatico alla extranet del produttore automatico è stato composto usando WS-Federation. WS-Federation garantisce che le credenziali di sicurezza concesse da un sito vengano rispettate da un secondo sito.

Ecco come funziona. Il rivenditore automatico e il produttore dell'auto hanno accettato di federate i propri siti. WS-Federation coordina una serie di comunicazioni da server a server. Non appena Heather ha fatto clic sul collegamento WindshieldPro per portarla alla pagina Web del produttore automatico, il server di pagine Web del produttore auto ha interrogato il servizio di autorizzazione, che a sua volta ha interrogato il servizio di autorizzazione di Auto Dealer. Il servizio di autorizzazione Auto Dealer conferma che Heather è un utente autorizzato, trasmettendo le credenziali, insieme al nome della concessionaria di Heather, al servizio di autorizzazione del produttore automatico, che concede l'accesso a Heather. Questo accade così senza problemi, che tutte le note heather è che è passata da una pagina Web a un'altra.

Il servizio Web esegue anche una query sul database dei clienti del produttore automatico per ottenere informazioni sull'ordinamento collegate all'account di Heather. Le informazioni vengono presentate in una pagina Web personalizzata del produttore automatico "Pagina personale".

Figura 5: Composizione di un servizio Web con WS-Federated consente a Heather di passare facilmente dalla pagina personalizzata di Auto Dealer alla pagina personalizzata in Auto Manufacturer.

La pagina Web personalizzata di Heather nella extranet Auto Manufacturer le consente di vedere che attualmente non ha ordini in sospeso; ha un ordine (per 50 SuperTires) in transito; e che il suo elenco di ordini completati include 20 unità di CDPlus e 50 unità di Leather Cleaner.

Heather fa clic su "Crea nuovo ordine" e viene aperta una nuova pagina, prepopolato con la parte desiderata, ovvero pannelli wiper WindshieldPro e la data di ordinamento. Tutto quello che deve entrare è la quantità. Tutte le altre informazioni necessarie per completare l'ordine vengono popolate dal database del produttore automatico.

Figura 6. Un ordine viene effettuato facilmente perché gran parte dei dati di ordinamento è già stato importato dal file di Heather nel database del cliente del produttore automatico.

Heather invia l'ordine e cerca altri articoli da acquistare o fa clic su Disconnetti per terminare la sessione e impedire a chiunque altro di effettuare un ordine dal computer automatico.

Si noti che la composizione del servizio Web con WS-Federation fornito sia auto dealer che produttore automatico con costi amministrativi inferiori e sicurezza end-to-end. Senza questa tecnologia, Auto Manufacturer avrebbe dovuto mantenere un elenco di tutti i dipendenti autorizzati della concessionaria e le relative password. Ciò sarebbe costoso, soggetto a errori e ridurre la sicurezza dell'applicazione.

Ad esempio, se Heather ha lasciato il suo lavoro, il suo account utente verrà rimosso presso Auto Dealer. Ma, se l'amministratore presso la concessionaria ha dimenticato di contattare il produttore automatico circa la sua partenza, continuerà ad avere accesso al sito di acquisto. Con WS-Federation, questo non è un problema, perché l'unico sistema che deve essere modificato è il servizio provider di identità del rivenditore automatico. I sistemi del produttore automatico, sia l'applicazione che il servizio di autorizzazione, non hanno alcuna conoscenza innata di Heather, del suo nome utente o della sua password.

4.2 Parte 2: L'esperienza fornitore

Anche se Heather ordina pannelli a wiper WindshieldPro dal produttore automatico, è stato mezzo secolo da quando l'azienda ha effettivamente fatto le proprie lame. Le pale a wiper WindshieldPro provengono da un fornitore, Supplier.

Tony è il rappresentante di vendita per Supplier e inizia la sua giornata accedendo alla intranet del fornitore, proprio come Heather ha effettuato l'accesso alla intranet del concessionario auto. Ma invece di usare un Web browser standard, Tony funziona con un'applicazione Windows con supporto predefinito per i servizi Web.

Figura 7. La pagina personale di Tony sulla intranet del fornitore gli ricorda di controllare gli ordini e l'inventario presso uno dei suoi principali clienti, Auto Manufacturer.

Quando Tony fa clic per controllare gli ordini e l'inventario, la sua applicazione usa un servizio Web per richiedere i dati di inventario a cui Tony è autorizzato ad accedere.

Un aspetto chiave di questo servizio Web a livello di applicazione richiede i dati è che è composto con WS-Federation che autentica l'accesso all'extranet del produttore automatico.

Il servizio Web restituisce i risultati alla pagina del fornitore in cui viene visualizzato in base al tipo di prodotto e al numero di inventario corrente.

Figura 8. Un servizio Web popola la pagina Supplier di Tony con i dati di inventario dei database di inventario del produttore automatico. La richiesta è stata effettuata in modo sicuro componendola con WS-Security e WS-Federation.

Il fornitore ha stipulato un contratto di acquisto JUST-In-Time con Il produttore automatico. Tony è autorizzato a fornire un ordine di rifornimento automatico come parte dell'inventario gestito del fornitore (VMI) per conto del produttore automatico una volta che l'inventario scende al di sotto di 20. Tony fa clic su WindshieldPro per effettuare un ordine. Tutti i messaggi tra Tony e Produttore automatico sono protetti perché l'applicazione è supportata dai servizi Web composti con le protezioni di WS-Security.

Figura 9. Un accordo JUST-In-Time con Auto Manufacturer consente a Tony di immettere un ordine per conto dell'azienda.

L'applicazione di Tony lo fornisce con una schermata per creare richieste a Supplier con un ordine di acquisto del produttore automatico. Tony ordina 50 filtri windishieldPros da spedire direttamente al produttore automatico.

Quando Tony fa clic su OK, il servizio warehouse, un servizio Web composto con WS-AtomicTransactions, WS-Security e WS-ReliableMessaging, tenta di inserire l'ordine con un altro servizio Web, i servizi warehouse subordinati. Quando una risposta non viene immediatamente restituita dal servizio warehouse (a causa di un'interruzione temporanea della rete) WS-ReliableMessaging continua a inviare nuovamente la query fino a ricevere una risposta.

Quando il servizio magazzino riceve l'ordine, li inoltra internamente ai due magazzini fisici dell'azienda. Poiché questo implica database tra entrambi i warehouse, WS-AtomicTransaction viene usato per garantire il comportamento transazionale tra i database.

L'applicazione Warehouse divide gli ordini tra i servizi warehouse subordinati per garantire la copertura dell'inventario, 70% di ordine passa al Magazzino 1 e i rimanenti 30% va al Magazzino 2. Il coordinatore radice nel magazzino principale invia un messaggio al coordinatore radice del magazzino 2 che richiede 30% dell'ordine. Il coordinatore radice del magazzino 2 controlla l'inventario e invia un messaggio al coordinatore radice del magazzino principale che non c'è un inventario sufficiente in magazzino.

Il coordinatore radice principale sapendo che l'inventario non è sufficiente annulla l'intera transazione e invia un messaggio all'applicazione del servizio Web di Tony che indica lo stato, i livelli di inventario e che la transazione è stata annullata. Il coordinatore radice inizia a eseguire il backout della transazione e, al termine, torna al magazzino per indicare che la transazione è stata annullata.

Tony, con la conoscenza dell'inventario corrente, invia un'altra richiesta al magazzino. Il coordinatore radice coordina tra altre entità transazionali (controller di altre transazioni) e invia la richiesta ai 2 warehouse che eseguono lo stesso processo di prima. Stiamo usando WS-Security per firmare l'intero corpo del messaggio, quindi indipendentemente dal dominio in cui sei in grado di essere sicuro.

Ora il coordinatore radice esegue il commit delle transazioni, blocca le risorse e completa la transazione. Viene restituito un messaggio a Tony che indica che la transazione è stata completata correttamente.

WS-AtomicTransaction compone con WS-ReliableMessaging e WS-Security in questi messaggi, per offrire un sistema distribuito completo pronto per l'organizzazione.

5.0 Conclusioni

IBM, Microsoft e i nostri partner stanno sviluppando specifiche del servizio Web che possono essere usate come blocchi predefiniti per una nuova generazione di servizi Web avanzati, sicuri, affidabili e transazionati.

Queste specifiche sono progettate in modo modulare e componibile in modo che gli sviluppatori possano usare solo le funzionalità necessarie. Questa componibilità "componente-like" consentirà agli sviluppatori di creare potenti servizi Web in modo semplice e flessibile, introducendo solo il livello di complessità dettata dall'applicazione specifica.

Questa tecnologia consentirà alle organizzazioni di creare facilmente applicazioni usando un Service-Oriented Architecture (SOA). IBM e Microsoft hanno inoltre dimostrato applicazioni SOA sicure, affidabili e transazioni che illustrano la ricchezza dei processi aziendali che possono essere creati usando questo approccio. Inoltre, queste dimostrazioni sono state eseguite in un ambiente di sicurezza federato in un ambiente eterogeneo costituito da IBM WebSphere e software Microsoft .NET.

Queste tecnologie del servizio Web saranno disponibili nei sistemi operativi, middleware, con strumenti che renderanno ancora più semplice per gli sviluppatori l'uso di queste tecnologie. Sarà interessante vedere le applicazioni che emergono come sviluppatori e organizzazioni usano questi sistemi per creare la nuova generazione di soluzioni basate su servizi Web.

6.0 Riconoscimenti

Vogliamo riconoscere le seguenti persone che hanno contribuito a queste idee: (alfabetico) Tony Andrews, Bob Atkinson, Keith Ballinger, Don Box, John Brezak, Allen Brown, Michele Cabrera, Erik Christensen, George Copeland, Michael Coulson, Giovanni Della-Libera, Brendan Dixon, Mike Dusche, Colleen Evans, Max Feingold, Jeff Frey, Henrik Frystyk Nielsen, Praerit Garg, Omri Gazitt, Scot Gellock, Josh Gray, Martin Gudgin, MaryAnn Hondo, Destry Hood, Efim Hudis, Tomasz Janczuk, Jim Johnson, Ryan Johnson, Gopal Kakivaya, Chris Kaler, Johannes Klein, Scott Konersmann, Brian LaMacchia, Dave Langworthy, Andrew Layman, Paul Leach, Al Lee, Frank Leymann, Rodney Limprecht, Joe Long, Steve Lucco, John Manferdelli, Ashok Malhotra, Jonathan Marsh, Steve Millet, Angela Mills, Tony Nadalin, Martin Nally, Karla Norsworthy, Stefan Pharies, Scott Robinson, Yordan Rouskov, Sujay Sahni, Jeff Schlimmer, Oliver Sharp, Yasser Shohoud, Dan Simon, Jeff Spelman, Keith Stobie, Satish Thatte, Robert Wahbe, Elliot Waingold, Richard Ward, Sanjiva Weerawarana, Hervey Wilson, Eric Zinda.