Dienstvirtualisatie - Service virtualization
| Software ontwikkeling |
|---|
In software-engineering is servicevirtualisatie of servicevirtualisatie een methode om het gedrag van specifieke componenten te emuleren in heterogene componentgebaseerde applicaties zoals API- gestuurde applicaties, cloudgebaseerde applicaties en servicegerichte architecturen . Het wordt gebruikt om softwareontwikkelings- en QA-/ testteams toegang te geven tot afhankelijke systeemcomponenten die nodig zijn om een te testen applicatie (AUT) uit te voeren, maar die niet beschikbaar of moeilijk toegankelijk zijn voor ontwikkelings- en testdoeleinden. Met het gedrag van de afhankelijke componenten "gevirtualiseerd", kan het testen en ontwikkelen doorgaan zonder toegang tot de daadwerkelijke live componenten. Servicevirtualisatie wordt door leveranciers, brancheanalisten en branchepublicaties erkend als iets anders dan spotten. Zie hier voor een vergelijking van API-simulatietools .
Overzicht
Servicevirtualisatie emuleert het gedrag van softwarecomponenten om afhankelijkheidsbeperkingen voor ontwikkelings- en testteams weg te nemen. Dergelijke beperkingen treden op in complexe, onderling afhankelijke omgevingen wanneer een component die is verbonden met de te testen applicatie:
- Nog niet voltooid
- Nog steeds in ontwikkeling
- Beheerd door een derde partij of partner
- Alleen beschikbaar voor testen in beperkte capaciteit of op ongelegen tijden
- Moeilijk in te richten of te configureren in een testomgeving
- Nodig voor gelijktijdige toegang door verschillende teams met gevarieerde testgegevensconfiguratie en andere vereisten
- Beperkt of duur in gebruik voor belasting- en prestatietests
Hoewel de term "servicevirtualisatie" de aanvankelijke focus van de techniek op het virtualiseren van webservices weerspiegelt , strekt servicevirtualisatie zich uit over alle aspecten van samengestelde applicaties: services, databases , mainframes , ESB's en andere componenten die communiceren met behulp van gemeenschappelijke berichtenprotocollen. Andere vergelijkbare tools worden API- simulators, API-spottools, over-the-wire -testdubbels genoemd .
Servicevirtualisatie emuleert alleen het gedrag van de specifieke afhankelijke componenten die ontwikkelaars of testers moeten uitvoeren om hun end-to-end-transacties te voltooien. In plaats van hele systemen te virtualiseren, virtualiseert het alleen specifieke segmenten van afhankelijk gedrag die essentieel zijn voor de uitvoering van ontwikkelings- en testtaken. Dit biedt net genoeg applicatielogica zodat de ontwikkelaars of testers krijgen wat ze nodig hebben zonder te hoeven wachten tot de daadwerkelijke service is voltooid en direct beschikbaar is. In plaats van bijvoorbeeld een hele database te virtualiseren (en al het bijbehorende testgegevensbeheer uit te voeren en de database voor elke testsessie in te stellen), bewaakt u bijvoorbeeld hoe de applicatie met de database interageert, en emuleert u het gerelateerde databasegedrag (de SQL query's die aan de database worden doorgegeven, de bijbehorende resultatensets die worden geretourneerd, enzovoort).
Sollicitatie
Servicevirtualisatie omvat het creëren en implementeren van een "virtueel activum" dat het gedrag simuleert van een echte component die nodig is om de te testen applicatie uit te voeren, maar die moeilijk of onmogelijk toegankelijk is voor ontwikkelings- en testdoeleinden.
Een virtueel activum vervangt een afhankelijke component door te luisteren naar verzoeken en een passend antwoord te geven, met de juiste prestaties. Voor een database kan dit betekenen dat u moet luisteren naar een SQL-instructie en vervolgens gegevensbronrijen moet retourneren. Voor een webservice kan dit betekenen dat u naar een XML- bericht luistert via HTTP , JMS of MQ en vervolgens een ander XML-bericht retourneert. De functionaliteit en prestaties van het virtuele activum kunnen de werkelijke functionaliteit/prestaties van de afhankelijke component weerspiegelen, of het kan uitzonderlijke omstandigheden simuleren (zoals extreme belastingen of foutcondities) om te bepalen hoe de te testen applicatie onder die omstandigheden reageert.
Virtuele activa worden doorgaans gemaakt door:
- Live-communicatie tussen componenten opnemen terwijl het systeem wordt uitgeoefend vanuit de te testen applicatie (AUT)
- Logboeken verstrekken die historische communicatie tussen componenten vertegenwoordigen
- Analyseren van specificaties van de service-interface (zoals een WSDL )
- Het gedrag handmatig definiëren met verschillende interface-besturingselementen en gegevensbronwaarden
Ze worden vervolgens verder geconfigureerd om specifieke gegevens, functionaliteit en reactietijden weer te geven.
Virtuele middelen worden lokaal of in de cloud (openbaar of privé) geïmplementeerd. Met ontwikkel-/testomgevingen die zijn geconfigureerd om de virtuele activa te gebruiken in plaats van afhankelijke componenten, kunnen ontwikkelaars of testers de applicatie waaraan ze werken uitoefenen zonder te hoeven wachten tot de afhankelijke componenten zijn voltooid of gemakkelijk toegankelijk zijn.
Industrie-analisten melden dat servicevirtualisatie het meest geschikt is voor "IT-winkels met aanzienlijke ervaring met het 'overslaan' van integratietests vanwege 'afhankelijke software' en met een redelijk geavanceerd testharnas.
Relatie met stompen en spotten
Een alternatieve benadering voor het omzeilen van de toegangsbeperkingen van de testomgeving die in de inleiding van dit artikel worden beschreven, is dat teamleden methodestubs of nepobjecten ontwikkelen die afhankelijke resources vervangen. De tekortkoming van deze aanpak werd begin jaren 2000 duidelijk met de opkomst van servicegerichte architectuur . De wildgroei van Composite-applicaties die afhankelijk zijn van tal van afhankelijke services, plus de opkomst van Agile-softwareontwikkeling na de publicatie van het Agile Manifesto in 2001, maakten het voor ontwikkelaars of testers steeds moeilijker om het aantal, de omvang en de complexiteit van stubs of mocks handmatig te ontwikkelen vereist om ontwikkelings- en testtaken uit te voeren voor de ontwikkeling van moderne bedrijfsapplicaties.
De eerste stap in de evolutie van stubbing naar servicevirtualisatie was de technologie die sinds 2002 is verpakt in SOA-testtools. De vroegste implementaties van servicevirtualisatie waren ontworpen om het proces van het ontwikkelen van eenvoudige stub-achtige emulaties te automatiseren, zodat samengestelde applicaties efficiënter konden worden getest . Naarmate bedrijfssystemen steeds complexer en gedistribueerder werden, verlegden leveranciers van softwaretools de aandacht van stubbing naar de meer omgevingsgerichte servicevirtualisatie. Hoewel stubbing nog steeds kan worden voltooid door handmatige ontwikkeling en beheer van stubs, wordt wat bekend is geworden als "servicevirtualisatie" voltooid door een van de beschikbare commerciële off-the-shelf (COTS) servicevirtualisatietechnologieën te gebruiken als platform voor de ontwikkeling en implementatie van hun "servicevirtualisatie-assets".
Agile en DevOps
Door de toenemende populariteit van Agile-softwareontwikkeling en DevOps is er vraag ontstaan naar een nieuwe set tools om servicevirtualisatie te leveren aan gemeenschappen die op deze manier werken. Praktijken zoals continue levering en het overstappen van mainframe- en monolietontwikkeling naar meer gedistribueerde microservice- gebaseerde architecturen passen goed bij de mogelijkheden van servicevirtualisatie. Agile- en DevOps-teams werken het liefst met lichtgewicht tools die minder opgezwollen zijn en geen omslachtige licentiebeperkingen hebben.
