Virtualizzazione del servizio - Service virtualization
| Sviluppo software |
|---|
In ingegneria del software , virtualizzazione servizio o servizio virtualizzazione è un metodo per emulare il comportamento dei componenti specifici nelle applicazioni basate su componenti eterogenei come API -driven applicazioni nuvola e applicazioni basati architetture orientate ai servizi . Viene utilizzato per fornire ai team di sviluppo software e QA/test l' accesso ai componenti di sistema dipendenti che sono necessari per esercitare un'applicazione in prova (AUT), ma non sono disponibili o di difficile accesso per scopi di sviluppo e test. Con il comportamento dei componenti dipendenti "virtualizzato", il test e lo sviluppo possono procedere senza accedere ai componenti live effettivi. La virtualizzazione dei servizi è riconosciuta dai fornitori, dagli analisti di settore e dalle pubblicazioni di settore come diversa dalla derisione. Vedi qui per un confronto degli strumenti di simulazione API .
Panoramica
La virtualizzazione dei servizi emula il comportamento dei componenti software per rimuovere i vincoli di dipendenza sui team di sviluppo e test. Tali vincoli si verificano in ambienti complessi e interdipendenti quando un componente connesso all'applicazione in prova è:
- Non ancora completato
- Ancora in evoluzione
- Controllato da una terza parte o da un partner
- Disponibile per test solo in capacità limitata o in momenti scomodi
- Difficile da fornire o configurare in un ambiente di test
- Necessario per l'accesso simultaneo da parte di diversi team con varie impostazioni dei dati di test e altri requisiti
- Limitato o costoso da utilizzare per i test di carico e prestazioni
Sebbene il termine "virtualizzazione dei servizi" rifletta l'attenzione iniziale della tecnica sulla virtualizzazione dei servizi Web , la virtualizzazione dei servizi si estende a tutti gli aspetti delle applicazioni composite: servizi, database , mainframe , ESB e altri componenti che comunicano utilizzando protocolli di messaggistica comuni. Altri strumenti simili sono chiamate API simulatori, strumenti API scherno, sopra il filo test raddoppia .
La virtualizzazione del servizio emula solo il comportamento dei componenti dipendenti specifici che gli sviluppatori o i tester devono esercitare per completare le loro transazioni end-to-end. Invece di virtualizzare interi sistemi, virtualizza solo sezioni specifiche di comportamento dipendente fondamentali per l'esecuzione di attività di sviluppo e test. Ciò fornisce una logica applicativa sufficiente in modo che gli sviluppatori o i tester ottengano ciò di cui hanno bisogno senza dover attendere che il servizio effettivo sia completato e prontamente disponibile. Ad esempio, invece di virtualizzare un intero database (ed eseguire tutta la gestione dei dati di test associati e impostare il database per ogni sessione di test), si monitora il modo in cui l'applicazione interagisce con il database, quindi si emula il comportamento del database correlato (l' SQL query passate al database, i corrispondenti set di risultati restituiti e così via).
Applicazione
La virtualizzazione del servizio implica la creazione e l'implementazione di un "asset virtuale" che simula il comportamento di un componente reale necessario per esercitare l'applicazione in fase di test, ma a cui è difficile o impossibile accedere per scopi di sviluppo e test.
Una risorsa virtuale sostituisce un componente dipendente ascoltando le richieste e restituendo una risposta appropriata, con le prestazioni appropriate. Per un database, ciò potrebbe comportare l'ascolto di un'istruzione SQL, quindi la restituzione delle righe dell'origine dati. Per un servizio Web, ciò potrebbe comportare l'ascolto di un messaggio XML su HTTP , JMS o MQ , quindi la restituzione di un altro messaggio XML. La funzionalità e le prestazioni dell'asset virtuale potrebbero riflettere le effettive funzionalità/prestazioni del componente dipendente oppure potrebbero simulare condizioni eccezionali (come carichi estremi o condizioni di errore) per determinare come l'applicazione in prova risponde in tali circostanze.
Le risorse virtuali sono generalmente create da:
- Registrazione della comunicazione in tempo reale tra i componenti durante l'esercizio del sistema dall'applicazione in prova (AUT)
- Fornire registri che rappresentano la comunicazione storica tra i componenti
- Analisi delle specifiche dell'interfaccia del servizio (come un WSDL )
- Definizione manuale del comportamento con vari controlli dell'interfaccia e valori dell'origine dati
Vengono quindi ulteriormente configurati per rappresentare dati, funzionalità e tempi di risposta specifici.
Le risorse virtuali vengono distribuite localmente o nel cloud (pubblico o privato). Con gli ambienti di sviluppo/test configurati per utilizzare le risorse virtuali al posto dei componenti dipendenti, gli sviluppatori o i tester possono quindi esercitare l'applicazione su cui stanno lavorando senza dover attendere che i componenti dipendenti siano completati o facilmente accessibili.
Gli analisti del settore riferiscono che la virtualizzazione dei servizi è più adatta per "negozi IT con una significativa esperienza con il "salto" dei test di integrazione a causa del "software dipendente" e con un cablaggio di test ragionevolmente sofisticato.
Relazione con stordimento e derisione
Un approccio alternativo per aggirare i vincoli di accesso all'ambiente di test delineati nell'introduzione di questo articolo prevede che i membri del team sviluppino stub di metodo o oggetti fittizi che sostituiscano le risorse dipendenti. Il difetto di questo approccio è diventato evidente nei primi anni 2000 con l'avvento dell'architettura orientata ai servizi . La proliferazione di applicazioni composite che si basano su numerosi servizi dipendenti, oltre all'aumento dello sviluppo di software Agile in seguito alla pubblicazione del 2001 dell'Agile Manifesto, ha reso sempre più difficile per gli sviluppatori o i tester sviluppare manualmente il numero, l'ambito e la complessità di stub o mock necessario per completare le attività di sviluppo e test per lo sviluppo di applicazioni aziendali moderne.
Il primo passo nell'evoluzione dallo stub alla virtualizzazione dei servizi è stata la tecnologia contenuta negli strumenti di test SOA dal 2002. Le prime implementazioni della virtualizzazione dei servizi sono state progettate per automatizzare il processo di sviluppo di semplici emulazioni simili a stub in modo che le applicazioni composite potessero essere testate in modo più efficiente . Poiché i sistemi aziendali hanno continuato a diventare sempre più complessi e distribuiti, i fornitori di strumenti software hanno spostato l'attenzione dallo stub alla virtualizzazione dei servizi più incentrata sull'ambiente. Mentre lo stub può ancora essere completato attraverso lo sviluppo e la gestione manuale degli stub, quella che è diventata nota come "virtualizzazione dei servizi" viene completata utilizzando una delle tecnologie di virtualizzazione dei servizi commerciali disponibili (COTS) come piattaforma per lo sviluppo e l'implementazione di loro "risorse di virtualizzazione dei servizi".
Agile e DevOps
La crescente popolarità dello sviluppo software Agile e DevOps ha creato la domanda per un nuovo set di strumenti per fornire la virtualizzazione dei servizi alle comunità che lavorano in questo modo. Pratiche come la distribuzione continua e il passaggio dallo sviluppo di mainframe e monoliti ad architetture basate su microservizi più distribuite si adattano bene alle capacità della virtualizzazione dei servizi. I team Agile e DevOps preferiscono lavorare con strumenti leggeri che hanno meno ingombro e nessuna restrizione di licenza ingombrante.
