Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La soluzione orientata ai servizi presenta un'applicazione di report sul saldo del credito progettata come servizio. L'applicazione, a sua volta, usa tre applicazioni back-end, esposte come servizi stessi, per ottenere le informazioni necessarie per il saldo del credito.
Un'architettura orientata ai servizi è un approccio che si sovrappone parzialmente alla creazione di sistemi distribuiti. Un approccio orientato ai servizi presenta diverse caratteristiche:
Accoppiato liberamente. La logica di business dell'applicazione è separata dalla logica di gestione del servizio.
Scopribile. Dovrebbe esserci un meccanismo per le applicazioni per trovare il servizio.
Contrattuale. L'interfaccia del servizio implementa il contratto tra gli utenti e il servizio.
Anche se la letteratura considera spesso approcci orientati ai servizi come sinonimi di servizi Web, non sono necessariamente sinonimi. I servizi Web presentano un modo interessante per implementare soluzioni orientate ai servizi, ma è possibile usare altre tecnologie, ad esempio la comunicazione remota .NET, per creare servizi.
Linee guida per i lettori
La documentazione per questa soluzione presuppone che si abbia familiarità con BizTalk Server e Microsoft Visual Studio. Si presuppone anche di comprendere i concetti di base relativi all'integrazione delle applicazioni aziendali e ai 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, riferimenti all'impostazione e debug e test di soluzioni BizTalk.
Rapporti sulle carte di credito presso la Woodgrove Bank
La soluzione di architettura orientata ai servizi è un servizio di reporting del saldo della carta di credito per Woodgrove Bank. Anche se la banca è fittizia, lo scenario non è, lo scenario si basa su un'applicazione cliente effettiva, distribuita.
Nello scenario, le richieste di saldo della carta di credito provengono da due origini:
Applicazione IVR (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. Gestisce le richieste dal client interattivo tramite un servizio Web tramite HTTP e SOAP.
Le nuove applicazioni di architettura orientata ai servizi spesso devono lavorare con applicazioni legacy che usano tecnologie meno recenti, nonché funzionare con applicazioni moderne, ad esempio siti Web che usano servizi Web. Lo scenario modella questo requisito reale: l'applicazione IVR rappresenta un'applicazione legacy, mentre l'applicazione client del servizio clienti è quella moderna.
L'applicazione Woodgrove Bank usa i dati di tre sistemi back-end legacy per rispondere alle richieste:
Applicazione che fornisce il limite di credito complessivo. Si tratta di un sistema SAP in un computer mainframe.
Sistema di transazioni in sospeso che segnala l'importo totale delle transazioni in sospeso rispetto all'account. Questo sistema è un mainframe o un sistema AS/400. La soluzione usa un servizio Web e Microsoft Host Integration Server (HIS) per comunicare con il mainframe o il sistema AS/400.
Sistema di rilevamento dei pagamenti che fornisce l'ultimo pagamento effettuato al sistema. È possibile raggiungere il sistema di rilevamento dei pagamenti usando MQSeries.
Dopo aver raccolto e compilato le informazioni dai sistemi legacy, la soluzione invia la risposta all'applicazione di origine e, di conseguenza, al cliente.
Requisiti aziendali
Poiché l'applicazione di segnalazione crediti risponde in tempo reale alle richieste dei clienti, deve avere bassa latenza per gestire rapidamente le richieste. Inoltre, deve anche essere in grado di gestire un numero elevato di richieste simultanee. La soluzione usa informazioni riservate e un'interfaccia pubblica in modo che la sicurezza sia un problema significativo. Infine, il servizio deve essere affidabile.
Per informazioni sul modo in cui la soluzione soddisfa questi requisiti, vedere Sviluppo di una soluzione orientata ai servizi.
Caratteristiche delle prestazioni
Per soddisfare i requisiti aziendali, lo scenario presenta le caratteristiche di prestazioni seguenti:
Velocità effettiva sostenuta di 40 richieste in ingresso al secondo.
Velocità effettiva massima di 100 richieste in ingresso al secondo.
Il 90% delle richieste da gestire (in e in uscita da BizTalk Server) in meno di 1000 millisecondi.
Il 95% delle richieste da gestire (in e in uscita da BizTalk Server) in meno di 2000 millisecondi.
Il 100% delle richieste da gestire (in e in uscita da BizTalk Server) in meno di 5000 millisecondi.
Annotazioni
Questi tempi 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 software stub. Gli stub simulano i sistemi back-end. Questa versione offre un modo rapido per distribuire ed eseguire la soluzione in un singolo computer.
La versione dell'adattatore usa gli adattatori BizTalk per connettersi ai sistemi di backend. Questa versione è il modo in cui si potrebbe pensare di implementare la soluzione. Tuttavia, l'invio di messaggi ai sistemi back-end tramite gli adapter introduce una latenza significativa nel recupero delle risposte. Sebbene gli adattatori stessi possano offrire una latenza molto bassa, l'architettura distribuita di BizTalk Server richiede che gli adapter comunichino con le istanze dell'host di orchestrazione usando la finestra di messaggio. Ciò introduce viaggi di andata e ritorno al database e influisce sui tempi di latenza.
La versione inline sostituisce gli adattatori con codice inline che comunica direttamente con i sistemi back-end. La versione inline della soluzione ha la latenza più bassa e la velocità effettiva più elevata.
La guida alla distribuzione fornisce indicazioni per la creazione e la distribuzione di tutte e tre le versioni della soluzione, oltre a fornire un modo, 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.