Informazioni sulla soluzione orientata ai servizi
La soluzione orientata ai servizi presenta un'applicazione di comunicazione del saldo attivo come servizio. L'applicazione utilizza a sua volta tre applicazioni back-end, esposte come servizi, per ottenere le informazioni necessarie per il saldo attivo.
Un'architettura SOA (Service Oriented Architecture) è un approccio che si sovrappone in parte alla creazione di sistemi distribuiti. L'approccio orientato ai servizi presenta diverse caratteristiche:
Loosely coupled. La logica di business dell'applicazione è separata dalla logica di gestione del servizio.
Individuabilità. Deve essere presente un meccanismo per consentire alle applicazioni di trovare il servizio.
Contrattualità. L'interfaccia del servizio implementa il contratto tra gli utenti e il servizio stesso.
Anche se nella letteratura gli approcci orientati ai servizi vengono spesso considerati analoghi ai servizi Web, ciò non è necessariamente vero. I servizi Web rappresentano una soluzione efficace per implementare le soluzioni orientate ai servizi, ma è possibile utilizzare altre tecnologie, ad esempio Servizi remoti .NET, per creare i servizi.
Informazioni aggiuntive per i lettori
La documentazione per questa soluzione presuppone che si abbia familiarità con BizTalk Server e Microsoft Visual Studio. e che conosca i concetti di base sull'integrazione di applicazioni aziendali e i servizi Web.
Inoltre, per leggere e seguire la documentazione per gli sviluppatori, è necessario avere familiarità con la compilazione di applicazioni usando Visual Studio e con l'esecuzione delle attività seguenti: creazione di progetti, impostazioni di riferimenti e debug e test di soluzioni BizTalk.
Comunicazione del saldo delle carte di credito in Woodgrove Bank
La soluzione SOA è un servizio di comunicazione del saldo della carta di credito per Woodgrove Bank. Anche se la banca è fittizia, lo scenario è basato su un'applicazione reale distribuita presso un cliente.
Nello scenario le richieste di saldo delle carte di credito provengono da due origini:
Un'applicazione IR (Interactive Voice Response).
Un client interattivo, ad esempio una pagina Web o un'applicazione client personalizzata.
La soluzione riceve le richieste dall'applicazione IVR tramite MQSeries. Le richieste provenienti dal client interattivo vengono gestite con un servizio Web tramite HTTP e SOAP.
Le nuove applicazioni SOA devono spesso essere compatibili con applicazioni legacy basate su tecnologie precedenti, nonché con applicazioni moderne quali siti Web che utilizzano servizi Web. Lo scenario riproduce questo requisito reale: l'applicazione IVR rappresenta un'applicazione legacy, mentre l'applicazione client del servizio clienti quella moderna.
L'applicazione Woodgrove Bank utilizza i dati di tre sistemi legacy back-end per rispondere alle richieste:
Un'applicazione che fornisce il limite di credito complessivo. Si tratta di un sistema SAP eseguito in un computer mainframe.
Un sistema di transazioni in sospeso che segnala la quantità totale di transazioni in sospeso per il conto corrente. Questo sistema è un mainframe o un sistema AS/400. Per comunicare con il mainframe o il sistema AS/400, vengono utilizzati un servizio Web e Microsoft Host Integration Server (HIS).
Un sistema di registrazione pagamenti che fornisce l'ultimo pagamento effettuato nel sistema e può essere raggiunto tramite MQSeries.
Dopo aver raccolto e compilato le informazioni provenienti dai sistemi legacy, la soluzione restituisce la risposta all'applicazione di origine e, pertanto, al cliente.
Requisiti aziendali
Poiché l'applicazione di comunicazione del saldo attivo risponde in tempo reale alle richieste del cliente, è necessario che abbia una latenza bassa per gestire rapidamente le richieste. Deve inoltre essere in grado di gestire un numero elevato di richieste simultanee. Dal momento che vengono utilizzate informazioni sensibili e un'interfaccia pubblica, la sicurezza rappresenta un requisito fondamentale. Infine, il servizio deve essere affidabile.
Per informazioni su come la soluzione soddisfa questi requisiti, vedere Sviluppo di una soluzione orientata ai servizi.
Caratteristiche di prestazioni
Per soddisfare i requisiti di business, lo scenario presenta le seguenti caratteristiche di prestazioni:
Velocità effettiva sostenibile di 40 richieste in arrivo al secondo.
Velocità effettiva di picco di 100 richieste in arrivo al secondo.
90% delle richieste da elaborare (in ingresso e in uscita da BizTalk Server) in meno di 1000 millisecondi.
95% delle richieste da elaborare (in ingresso e in uscita da BizTalk Server) in meno di 2000 millisecondi.
100% delle richieste da elaborare (in ingresso e in uscita da BizTalk Server) in meno di 5000 millisecondi.
Nota
Tali periodi non includono i tempi di latenza dei sistemi back-end.
Tre versioni della soluzione
Esistono tre versioni della soluzione:
La versione stub sostituisce tutti i sistemi back-end con stub software. Gli stub simulano i sistemi back-end. Questa versione consente di distribuire ed eseguire rapidamente la soluzione in un unico computer.
La versione adapter utilizza gli adapter BizTalk per la connessione ai sistemi back-end. Questa versione potrebbe sembrare la prima opzione da considerare per implementare la soluzione. Tuttavia, l'invio di messaggi ai sistemi back-end tramite gli adapter comporta una latenza significativa nella ricezione delle risposte. Anche se gli adapter possono offrire una latenza molto bassa, l'architettura distribuita di BizTalk Server richiede che comunichino con le istanze dell'host dell'orchestrazione tramite MessageBox. In questo modo vengono introdotti cicli di andata e ritorno nel database che influiscono sui tempi di latenza.
Nella versione inline gli adapter vengono sostituiti da codice inline che comunica direttamente con i sistemi back-end. La versione inline della soluzione offre la latenza più bassa e la velocità effettiva più elevata.
Nella guida alla distribuzione vengono fornite indicazioni per lo sviluppo e la distribuzione delle tre versioni della soluzione e viene offerta la possibilità, in ogni versione, di simulare la connessione tramite HIS al sistema di transazioni in sospeso. Per informazioni sulla compilazione e la distribuzione della soluzione, vedere Distribuzione della soluzione orientata ai servizi.