Service virtualisering - Service virtualization
| Softwareudvikling |
|---|
I softwareteknik er servicevirtualisering eller servicevirtualisering en metode til at efterligne specifikke komponenters adfærd i heterogene komponentbaserede applikationer såsom API -drevne applikationer, skybaserede applikationer og serviceorienterede arkitekturer . Det bruges til at give softwareudvikling og QA/ testhold adgang til afhængige systemkomponenter, der er nødvendige for at udøve en applikation under test (AUT), men som ikke er tilgængelige eller vanskelige at få adgang til til udviklings- og testformål. Med opførsel af de afhængige komponenter "virtualiseret" kan testning og udvikling fortsætte uden at få adgang til de faktiske levende komponenter. Servicevirtualisering anerkendes af leverandører, brancheanalytikere og branchepublikationer som anderledes end spottende. Se her for en sammenligning af API -simuleringsværktøjer .
Oversigt
Servicevirtualisering efterligner softwarekomponenters adfærd for at fjerne afhængighedsbegrænsninger for udviklings- og testteam. Sådanne begrænsninger opstår i komplekse, indbyrdes afhængige miljøer, når en komponent, der er forbundet til den testede applikation, er:
- Endnu ikke afsluttet
- Stadig under udvikling
- Styres af en tredjepart eller partner
- Kun tilgængelig til test i begrænset kapacitet eller på ubelejlige tidspunkter
- Vanskeligt at tilvejebringe eller konfigurere i et testmiljø
- Behov for samtidig adgang fra forskellige teams med varieret testdataopsætning og andre krav
- Begrænset eller dyrt at bruge til belastnings- og ydelsestest
Selvom udtrykket "servicevirtualisering" afspejler teknikkens første fokus på virtualisering af webtjenester , strækker servicevirtualisering sig over alle aspekter af sammensatte applikationer: tjenester, databaser , mainframes , ESB'er og andre komponenter, der kommunikerer ved hjælp af fælles meddelelsesprotokoller. Andre lignende værktøjer kaldes API -simulatorer, API -mockingværktøjer, over wiretesten fordobles .
Servicevirtualisering efterligner kun adfærden for de specifikke afhængige komponenter, som udviklere eller testere skal udøve for at gennemføre deres ende-til-ende-transaktioner. I stedet for at virtualisere hele systemer virtualiserer det kun specifikke udsnit af afhængig adfærd, der er kritisk for udførelsen af udviklings- og testopgaver. Dette giver lige nok applikationslogik, så udviklerne eller testerne får det, de har brug for, uden at skulle vente på, at den faktiske service er fuldført og let tilgængelig. For eksempel, i stedet for at virtualisere en hel database (og udføre al tilknyttet testdatahåndtering samt konfigurere databasen for hver testsession), overvåger du, hvordan applikationen interagerer med databasen, derefter emulerer du den relaterede databaseadfærd ( SQL forespørgsler, der sendes til databasen, de tilsvarende resultatsæt, der returneres osv.).
Ansøgning
Servicevirtualisering involverer oprettelse og implementering af et "virtuelt aktiv", der simulerer adfærden for en reel komponent, som er nødvendig for at udøve den testede applikation, men som er vanskelig eller umulig at få adgang til til udviklings- og testformål.
Et virtuelt aktiv står for en afhængig komponent ved at lytte efter anmodninger og returnere et passende svar - med den passende ydelse. For en database kan dette indebære at lytte efter en SQL -sætning og derefter returnere datakildrækker. For en webtjeneste kan dette indebære at lytte efter en XML -besked via HTTP , JMS eller MQ og derefter returnere en anden XML -besked. Det virtuelle aktivs funktionalitet og ydeevne afspejler muligvis den faktiske funktionalitet/ydeevne for den afhængige komponent, eller det kan simulere usædvanlige forhold (f.eks. Ekstreme belastninger eller fejlbetingelser) for at bestemme, hvordan den testede applikation reagerer under disse omstændigheder.
Virtuelle aktiver oprettes typisk af:
- Optagelse af live kommunikation mellem komponenter, mens systemet udøves fra den testede applikation (AUT)
- Tilvejebringelse af logfiler, der repræsenterer historisk kommunikation mellem komponenter
- Analyse af specifikationer for servicegrænseflader (f.eks. En WSDL )
- Definere adfærden manuelt med forskellige grænsefladekontroller og datakildeværdier
De konfigureres derefter yderligere til at repræsentere specifikke data, funktionalitet og svartider.
Virtuelle aktiver implementeres lokalt eller i skyen (offentlig eller privat). Med udviklings-/testmiljøer konfigureret til at bruge de virtuelle aktiver i stedet for afhængige komponenter, kan udviklere eller testere derefter udøve det program, de arbejder på, uden at skulle vente på, at de afhængige komponenter er færdige eller let tilgængelige.
Industrianalytikere rapporterer, at servicevirtualisering er bedst egnet til "IT -butikker med betydelig erfaring med at 'springe over' integrationstest på grund af 'afhængig software' og med en rimelig sofistikeret testsele.
Forholdet til stubbing og hån
En alternativ tilgang til at arbejde omkring testmiljøets adgangsbegrænsninger, der er skitseret i denne artikels introduktion, er, at teammedlemmer udvikler metodestubbe eller spotter objekter, der erstatter afhængige ressourcer. Manglen ved denne tilgang blev tydelig i begyndelsen af 2000'erne med fremkomsten af serviceorienteret arkitektur . Spredningen af sammensatte applikationer, der er afhængige af adskillige afhængige tjenester, plus stigningen i Agile softwareudvikling efter 2001 -udgivelsen af Agile Manifesto, gjorde det stadig vanskeligere for udviklere eller testere at manuelt udvikle antallet, omfanget og kompleksiteten af stubbe eller mocks påkrævet for at fuldføre udviklings- og testopgaver for moderne virksomhedsapplikationsudvikling.
Det første trin i udviklingen fra stubbing til service virtualisering var teknologien pakket i SOA testværktøjer siden 2002. De tidligste implementeringer af service virtualisering var designet til at automatisere processen med at udvikle simple stub-lignende emuleringer, så sammensatte applikationer kunne testes mere effektivt . Efterhånden som virksomhedssystemer blev ved med at blive mere og mere komplekse og distribuerede, flyttede softwareværktøjsleverandører fokus fra stubbing til den mere miljøfokuserede servicevirtualisering. Selvom stubbing stadig kan gennemføres ved manuel udvikling og håndtering af stubbe, afsluttes det, der er blevet kendt som "servicevirtualisering" ved at bruge en af de tilgængelige kommercielle off -shelf (COTS) service virtualiseringsteknologier som en platform for udvikling og implementering af deres "service virtualiseringsaktiver".
Agile og DevOps
Den stigende popularitet af Agile softwareudvikling og DevOps har skabt efterspørgsel efter et nyt sæt værktøjer til at levere servicevirtualisering til samfund, der fungerer på denne måde. Praksis som Kontinuerlig levering og bevægelse væk fra mainframe og monolitudvikling til mere distribuerede mikroservice -baserede arkitekturer passer godt med mulighederne for service virtualisering. Agile og DevOps -teams foretrækker at arbejde med lette værktøjer, der har mindre ophobning og ingen besværlige licensrestriktioner.
