An Evaluation of Web Services in the Design of a B2B Application

K. Hogg, P. Chilcott, M. Nolan and B. Srinivasan

Presentato da: Fabrizio Nuzzo, Amanda Accalai

Di cosa parliamo:
considerazioni architetturali sulla progettazione di una applicazione web fornitrice di servizi B2B; vantaggi della programmazione orientata agli oggetti e delle tecnologie dei web services; questioni riguardanti il controllo della concorrenza in ambienti web service B2B. obiettivo principale: superare i limiti delle architetture e gli standard degli attuali web services.

The Product Provisioning System (PPS)

Lo staff di un call center e il service providers

1. Controllano lidoniet del cliente 2. Controllano se nella regione del cliente c la disponibilit del prodotto 3. Prenota la richiesta per il servizio 4. Archivia i risultati di tutte queste interazione nel database locale del PPS per future interrogazioni e reporting.

Priorit aziendali che hanno contribuito al finanziamento di questa iniziativa:

Aumento delle prestazioni dei Service Provider, agevolata dalla disponibilit di modelli di accesso multiplo alle funzionalit del PPS; ridurre la necessit per i Service Providers di inserire richieste doppie nelle proprie applicazioni; diminuzione del carico di lavoro manuale per le richieste al Service Provider; contenere i costi delle operazioni dei service provider quando il volume delle richieste aumenta; consentire l'integrazione delle funzioni del PPS con i processi di business del Service Provider.

Fattori critici di successo

-->prima relase

Requisiti Funzionali: Fare in modo che le interfaccie di lavoro B2B espongano le funzionalit PPS; Fornire una soluzione valida a lungo termine che garantisca la possibilit di estendere le funzionalit con altri prodotti; La soluzione non discrimina in termini di capacit tecnica e tratta i service providers in maniera equa indipendentemente dal volume della clientela. Requisiti non funzionali: I servizi eseguiti saranno esposti in modo sicuro utilizzando un approccio gi esistente nel PPS e infrastrutture su rete pubblica; I servizi esposti saranno adatti sia a utilizzo on-line sia batch processes; conformit alla sicurezza aziendale.

Influenze Architetturali Significative

Le funzionalit esistenti del PPS non saranno modificate; Riutilizzo di risorse gi esistenti (Hardware e Software); Le funzionalit esposte saranno indipendenti dalla piattaforma utilizzata; Possibilit di includere funzionalit non presenti nella prima release; Migrazione verso SOA (Service Oriented Architecture); Utilizzo di SOAP come protocollo per lo scambio di messaggi invece di http(s); Descrizione delle interfaccie tramite WSDL.

Web Service Tecnology

Le tecnologie dei Web Services sono state approvate da molte aziende come la direzione strategica in linea con lindustria IT che ormai utilizza SOA. I modelli web services sono costruiti su un set di standard aperti basati su XML (SOAP, WSDL, UDDI) che consentono l'interoperabilit tra piattaforme eterogenee. Questi standard fondamentali, identificano tutte le informazioni necessarie per l'accesso ad essi, compresi il formato del messaggio, i protocolli di trasporto e la locazione di rete. Questo permette di avere una maggiore integrazione con i servizi indipendentemente dalla piattaforma e dal linguaggio in cui sono stati sviluppati.

Benefici apportati:
Integrazione tra applicazioni sia esterne che interne all'azienda; Flessibilit e riutilizzabilit dei componenti software; Sviluppo evolutivo senza richiedere cambiamenti alle infrastrutture; Interoperabilit: riduzione degli sforzi per l'integrazione tra sistemi diversi; Estendere le funzionalit esistenti.

Conceptual Web Services Stack

Nella Relase 1 B2B PPS sono implementati il core Web Services Layers compreso il network Layer, XML-Based messaging Layer, Service Description Layer e anche alcuni Security Layer applicabili al network Layer. L'intenzione quella di integrare gradualmente altri componenti alla soluzioni successive, man mano che gli standard evolvono e sono adottati.

Modelli Sincroni E Asincroni

Immediate Model Implementazioni Request/Response sincrone: Il provider riceve il messaggio, lo processa e poi restituisce una risposta.

Delayed Model Implementazione non dipendente dal tempo: due web service Request/Response sincroni dovranno essere definiti.

Controllo della concorrenza nelle applicazioni Web Service PPS B2B

Status Locking Concurrency Control scheme: un approccio pessimistico, che utilizza una struttura gerarchica, di sostegno a un modello di transazione nidificata. stato concepito per ridurre al minimo le modifiche richieste pur consentendo al browser-based e alle funzioni B2B di condividere un approccio comune per il controllo della concorrenza. impedisce alle transazioni client concorrenti di interferire tra di loro a livello richiesta. prevede un meccanismo per notificare alle sub-transazioni figlie il fallimento del padre o delle sub-transazione root, anche quando il processo padre in esecuzione ha cessato di esistere.

Status e Request Locks (1/3)

Le dipendenze tra sub-transazioni sono di due tipi: dipendenze strutturali: 1. in cui azioni atomiche sono previste in alcune sequenze predefinite; 2. sono a livello sub-transazione e sono mantenute usando il concetto di 'Status lock'. dipendenze dinamiche: 1. derivano da dati condivisi e coinvolgono qualsiasi numero di azioni atomiche che non si basano sulla gerarchia d'invocazione; 2. sono gestite dal 'Request locks' e standard 2PL, come previsto dal gestore di lock dei sistemi preesistenti. Lo Status lock e il Request lock vengono fissati dalla subtransazione padre durante l'inizio della fase di transazione.

Status e Request Locks (2/3)

Status Lock: definisce lo stato corrente della sub-transazione padre. composto da 3 stati: 1. In Progress 2. Complete - tutte le sub-transazioni sono state completate con successo 3. Unable to Complete - quando un child fallisce o una sub-transazione padre soggetta ad un' interruzione controllata Request Lock: usato per informare le altre transazioni che consumatore e relativi dati di prodotto sono potenzialmente in fase di aggiornamento.

Status e Request Locks (3/3)

E' possibile che un sub-transazione figlia possa restituire il risultato dopo che la sub-transazione padre stata interrotta. Status lock quindi: utilizzato per informare le sub-transazioni figlie quando devono funzionare o interrompersi. Ad Esempio, se un processo padre soggetto ad un aborto controllato o a un timeout si avr quindi che: 1. la Request lock creata viene rimossa; 2. e Status lock viene settato a 'Unable to Complete'.

Visione architetturale di un Web Service PPS B2B

Questa architettura: stata ideata al fine di massimizzare il riutilizzo dei componenti browser-based esistenti, riducendo al minimo la quantit di codice scritto a mano; L'implementazione del pattern selezionato basato sul WS-I Basic profile per garantire l'interoperabilit dei web Service. WS-I Basic profile composto da specifiche che restringono le sovrabbondanti capacit espressive di SOAP, individuando un set minimo di caratteristiche comunemente supportate dai Service Provider.

Componenti del modello

Devono essere generate due classi per ogni Web Service, che deve essere creato dal progetto B2B: 1. la Command Bean, che viene chiamata dal server stub generato, chiamer la Faade Class per eseguire la logica di business. 2. la Faade Class utilizzer oggetti business PPS o altre application service PPS per effettuare la logica di business richiesta. 3. sono,inoltre, richiesti Data Beans per settare e ottenere i valori dei dati in XML. Le classi indicate controllano e trasmettono messaggi basati su XML ai Business Objects e ritornano la risposta al Service Provider client.

PPS Component

le zone ombreggiate rappresentano le nuove componenti che sono state sviluppate come parte della soluzione

PPS B2B Command Bean Design

Una transazione avviene medieante 3 command beans e 2 data beans. Command Beans: B2bRequestResponse un wrapper che implementa la funzionalit sincrone dell'interfaccia. B2bRequest processa la Request, interroga il database PPS. B2bResponce sta in attesa della Responce.
Data Beans: B2bRequestMessage incapsula una Request data. B2bResponseMessage incapsula una Request ID o una Responce data.

Benefici ottenuti
introduzione di un terzo livello di sicurezza per impedire l'esecuzione di API B2B senza autorizzazione; introduzione della nozione di Status Locks nell'ambito della concorrenza; utilizzo di documenti WSDL per catturare errori di validazione a livello SOAP (migliore qualit dei dati ricevuti e minore carico); definizione precisa e facile delle interfacce mediante standard WSDL; soddisfacimento delle richieste del client di avere un'architettura standard-based, ottenendo un framework comune.

Conclusioni
Si dimostrato che: la struttura dell'applicazione PPS B2B sviluppata approfitta dei vantaggi dei benefici proposti per tecnologie web service; vi sono sufficienti tecnologie disponibili per attuare con successo un applicazione B2B; i Web Services sono una buona architettura di base per risparmiare significativamente sui costi grazie al riutilizzo; anche se i servizi transazionali sono ancora in fase di sviluppo,i work-Arounds sono semplici ed efficaci.

Sviluppi futuri

E' previsto l'inserimento degli altri livelli del Conceptual Web Services Stack nella soluzione proposta: UDDI BPEL4WS WS-Security WS-RM

THE END