Specifiche di seconda generazione
Come abbiamo visto nel precedente articolo il trio di specifiche di prima generazione mette a disposizione le funzionalità di connettività e comunicazione fra consumer e provider del servizio.

La pura connettività però non consente di avere servizi di livello enterprise.
Per lo sviluppo di servizi enterprise è necessario potere gestire aspetti quali Sicurezza, Transazionalità e Workflow, qualità del servizio, ecc...
Il "salto" che il mercato sta chiedendo ai Web Services è paragonabile a quello che ci fu nel passaggio dalla RMI alla gestione di componenti enterprise che si è concretizzato con l'introduzione dei Container J2EE.
Sono nate e stanno nascendo perciò una serie di specifiche atte a definire servizi simili a quelli che troviamo negli Application Server. Questo insieme di specifiche viene anche indicato come specifiche di seconda generazione.
Le aree principali cui si rivolgono queste specifiche sono:

• Coordinamento fra Web Services
  
• Gestione della sicurezza
  
• Quality of service

Figura 1: Specifiche di seconda generazione

Le specifiche di seconda generazione (vedere [TE_WSS]) hanno in generale le seguenti caratteristiche:

• Non sono stabili
  
• Non sono completamente accolte dal mercato
  
• Spesso ci sono delle proposte alternative (in competizione)

Data la velocità con cui lo scenario evolve e la moltitudine delle specifiche è necessario cercare di "orientarsi" pertanto nella restante parte dell'articolo si cercherà di illustrare brevemente il contenuto e il livello di standardizzazione raggiunto dalle principali specifiche di seconda generazione.

Stato dell'arte delle specifiche di seconda generazione
La tabella che segue riassume lo stato dell'arte di alcune tra le principali specifiche relative ai Web Services.
Si riporta il nome dello standard, i propositori e lo stato dello stesso.

Coordinamento fra Web Services
Le specifiche di coordinamento dei Web Services si basano su WS-Coordination.
Questa specifica descrive un framework estensibile che mette a disposizione protocolli in grado di coordinare azioni di applicazioni distribuite basate su Web Services. Il coordinamento di Web Services può avere diversi fini. In particolare in questo momento ci si sta concentrando su:

• Processi atomici (da un punto di vista transazionale) composti da Web Services (WS-AtomicTransaction)
  
• Long running process composti da Web Services (WS-BusinessActivity)

WS-AtomicTransaction usa ed estende il framework di WS-Coordination per definire 3 livelli di coordinamento transazionale crescente: completion, volatile two phase commit, durable two phase commit. Questi protocolli sono da usarsi quando si ha la necessità di aggregare due o più Web Services in un unità logica di lavoro (LUW).
WS-BusinessActivity usa ed estende il framework d WS-Coordination per definire dei protocolli di coordinamento atti ad aggregare operazioni di business non contenute in un'unità di logica di lavoro. Il protocollo prevede la gestione delle eccezioni nel caso si abbia un fallimento. In questi casi è anche possibile lanciare delle operazioni di compensazione.

Definizione di processi di business
Un motore di workflow che si basi sugli standard WS-Coordination è in grado di eseguire processi di business. A livello di sviluppo però è necessario disporre di strumenti per la definizione dei workflow. Sono nati dunque alcuni linguaggi per la definizione di processi come BPEL (BPEL4WS è l'implementazione per Web Services), XPDL, XLANG, WSFL.
Non è ancora chiaro chi riuscirà ad imporsi, però oggi lo standard che sembra avere maggiori probabilità è BPEL4WS che è patrocinato da IBM, Microsoft, Siebel, SAP e altri.
Ci si può dunque aspettare che questa collaborazione possa convergere velocemente verso una specifica ufficiale.
Nell'attesa che emerga una specifica sopra le altre i vendor hanno implementato i propri motori di workflow a volte scegliendo arbitrariamente un linguaggio a volte definendone uno nuovo.
Sono comunque disponibili tool come il BPWS4J editor o l'Oracle BPEL Designer (vedere [ORA_BPD] ) che permettono di diseganre in modo grafico i processi ed ottenere la generazione automatica del codice BPEL4WS.

:
Figura 2 - Oracle BPEL Designer: BPEL4WS Design View

Figura 3: Oracle BPEL Designer: BPEL4WS Source View

Gestione della sicurezza
Esistono varie specifiche di sicurezza (più di 20!) nell'ambito del gruppo WS-* che formano un framework di specifiche detto WS-Security.
Alcuni dei temi affrontati dal framework sono:

• Autenticazione, autorizzazione
  
• Confidenzialità, integrità, non ripudiabilità dei messaggi
  
• Federazione di domini di Sicurezza
  
• Definizione e gestione delle Policy
  
• Relazione con altre tecnologie di sicurezza (ad es: algoritmi di crittazione, protocolli di trasporto sicuri, sistemi di autenticazione).
  

Nel campo della sicurezza, tanto per complicare lo scenario, esistono diverse specifiche al di fuori della framework WS-Security (ad es: XML-Encryption, XML-Digital Signature, XKMS, XRML, SAML). Queste specifiche sono spesso parzialmente sovrapposte a quelle di WS-Security e a volte in diretta competizione.
Come si vede il numero enorme di specifiche non aiuta affatto la convergenza per raggiungere uno standard ufficiale "favorendo" l'implementazione custom da parte dei vendono di prodotti che supportano i Web Services.
Le specifiche di sicurezza sono quelle che probabilmente presentano il maggiore livello di instabilità. Questa situazione è una delle maggiori cause della lenta adozione dei Web Services nelle comunicazioni inter aziendali. E' chiaro infatti che in questo scenario la sicurezza diventa un must, ma non essendoci specifiche i prodotti in larga parte non sono interoperabili per cui il problema diventa difficile da normare e risolvere.
Qualità Of Service
Sotto questa "etichetta" abbiamo raggruppato gli ultimi tre insiemi di specifiche della tabella:

• Messaging
  
• Policy
  
• Management

In generale queste specifiche servono a definire e osservare i livelli di servizio che devono essere rispettati dai web service.
I particolare le Policy servono a definire livelli di servizio ed eventuali altre regole di business dei Web Service. Mediante queste specifiche è possibile introdurre delle asserzioni nei messaggi scambiati durante la comunicazione. Tali asserzioni dovranno essere comprese dal runtime dei web service (non certo dalla logica del servizio) che agirà di conseguenza.
Le specifiche relative al messaging rientrano in questa logica ma sono gestite separatamente più che altro per motivi storici (sono nate prima per gestire gli immediati problemi della comunicazione asincrona) . Di queste conviene approfondire quella sull'affidabilità della comunicazione asincrona.
WS-Reliable Messaging è una specifica che indirizza i problemi di gestione dei messaggi asincroni.
In particolare si occupa di:

• Assicurare la consegna dei messaggi (delivery guaranteed)
  
• Assicurare l'ordine di consegna dei messaggi (In-order delivery)
  
• Eliminazione dei messaggi duplicati (At most once delivery)

Questa specifica assume un ruolo rilevante in architetture SOA poiché questo tipo di architetture è fortemente basato su comunicazione asincrona (vedere [MOKA_SOA]).

Le specifiche sul management definiscono i protocolli di comunicazione delle infrastrutture di management. Con tali protocolli sarà possibile gestire qualunque elemento del sistema informativo, ma naturalmente in prima battuta ci si focalizza sulla gestione dei Web Services stessi.

Standard su domini di business verticali
Alcune organizzazioni stanno cercando di normare e standardizzare la struttura delle informazioni che descrivono domini di business ben specifici. Si va da settore medico alla logistica, dalla finanza alla contabilità ecc…
La normalizzazione avviene mediante la pubblicazione di schemi XSD contenenti appunto la modellazione dei concetti inerenti un certo argomento.
Nello scenario di comunicazione inter-enterprise questo è un passo necessario. Infatti nessuno dei due pari (peer) che partecipano alla comunicazione può arrogarsi il diritto di definire la modellazione dei dati scambiati, inoltre è evidente che le rappresentazioni interne del proprio business che ogni azienda ha normalmente difficilmente potranno essere compatibili con quelle di un'altra azienda. E' necessario dunque che qualcuno definisca il modello dei dati da usarsi durante la comunicazione poi sarà compito di ciascun partecipante alla comunicazione rimappare il modello standard nel proprio modello interno.
Una serie di organizzazioni sono nate con questo intento. Fra esse vale la pena citare Oasis , RosettaNet e Xml.org
Lo stato di maturazione di queste specifiche, è in alcuni settori ormai piuttosto avanzato, vale la pena citare ad esempio nel campo del banking XBRL (vedere [XBRL]). Questa specifica è stata recentemente adottata dall'ABI e dovrebbe diventare il linguaggio standard di comunicazioni interbancarie in Italia.

Conclusioni
In questi due articoli si è parlato dello stato dell'arte delle specifiche dei Web Services.
Si è visto che per le specifiche di base e di prima generazione c'è accordo fra i fornitori e che le specifiche hanno raggiunto un livello di stabilità accettabile. Al contrario le specifiche di seconda generazione, necessarie alla creazione di servizi enterprise, non sembrano convergere verso un livello di stabilità che consenta la creazione di prodotti interoperabili.
Questa situazione, nonostante l'attività del WS-I, dà spazio a soluzioni proprietarie.
Quanto detto trova riscontro nell'hype chart di Gartner (vedere [HCWS2003], [HCWS2004]): dalla curva (vedere [GARTHYPE]) si vede come le sole specifiche di base e di prima generazione vengano considerate consolidate.

Figura 4: Hype Cycle for Web Services

Bibliografia
[MOKA_WSS_1] S. Rossini, R. Spazzoli: Web Services: il punto sulla standardizzazione (I) - MokaByte 96, Maggio 2005
[TE_WSS] Thomas Erl: Specification.WS - http://www.specifications.ws/default.asp
[IBM_TLV] IBM-Technical library view: http://www-128.ibm.com/developerworks/views/webservices/libraryview.jsp?type_by=Standards
[ORA_BPD] Oracle BPEL Designer - http://www.oracle.com/technology/software/index.html
[OASIS] http://www.oasis-open.org/home/index.php
[ROSETTANET] http://www.rosettanet.org
[XBRL] http://www.xbrl.org
[HCWS2003] Technology Landscape:
http://www.oclc.org/membership/escan/downloads/technology.pdf
[HCWS2004] Hype Cycle for Web Services, 2004 (richiede registrazione Gartner)
http://www.gartner.com/DisplayDocument?doc_cd=120919
[GARTHYPE] Understanding Hype Cycles:
http://www.gartner.com/pages/story.php.id.8795.s.8.jsp