Web Services: Il punto sulla standardizzazione

II parte: Specifiche di seconda generazionedi e

Nel precedente articolo si è parlato delle specifiche base (XML, XSL, XSD, XQuery, XPath) e di prima generazione (SOAP, UDDI, WSDL) dei Web Services. In questo articolo ci dedicheremo alle specifiche di seconda generazione.

Specifiche di seconda generazione

Come abbiamo visto nel precedente articolo [MOKA_WSS_1] 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
  • Qualità  del servizio

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 nella tabella di figura 3 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.

:

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à  del 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.

Riferimenti

[MOKA_WSS_1]
S. Rossini, R. Spazzoli, "Web Services: Il punto sulla standardizzazione. I parte" 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

Condividi

Pubblicato nel numero
98 luglio 2005
Stefano Rossini è nato a Giussano (MI) il 29/10/1970 e ha conseguito il diploma universitario in Ingegneria Informatica presso il Politecnico di Torino. Ha maturato più di venti anni di esperienza in diversi progetti Enterprise mission-critical ricoprendo i ruoli di IT Program Manager, Project Manager & Software Architect presso importanti…
Raffaele Spazzoli ha lavorato per piu di 10 anni a Imola Informatica come consulente con il ruolo di architetto delle applicazioni e delle integrazioni. Attualmente lavora in KeyBank, una banca statunitense, come architetto dei canali fisici (filiali e contact center) e digitali (web e mobile).
Articoli nella stessa serie
Ti potrebbe interessare anche