Virtualización de servicios - Service virtualization
| Desarrollo de software |
|---|
En la ingeniería de software , la virtualización de servicios o la virtualización de servicios es un método para emular el comportamiento de componentes específicos en aplicaciones heterogéneas basadas en componentes, como aplicaciones impulsadas por API , aplicaciones basadas en la nube y arquitecturas orientadas a servicios . Se utiliza para proporcionar acceso a los equipos de desarrollo y control de calidad / pruebas de software a los componentes del sistema dependientes que se necesitan para ejecutar una aplicación bajo prueba (AUT), pero que no están disponibles o son de difícil acceso para fines de desarrollo y prueba. Con el comportamiento de los componentes dependientes "virtualizados", las pruebas y el desarrollo pueden continuar sin acceder a los componentes activos reales. Los proveedores, los analistas de la industria y las publicaciones de la industria reconocen que la virtualización de servicios es diferente a la burla. Consulte aquí para obtener una comparación de las herramientas de simulación de API .
Visión general
La virtualización de servicios emula el comportamiento de los componentes de software para eliminar las restricciones de dependencia en los equipos de desarrollo y prueba. Tales restricciones ocurren en entornos complejos e interdependientes cuando un componente conectado a la aplicación bajo prueba es:
- No completado aún
- Sigue evolucionando
- Controlado por un tercero o socio
- Disponible para pruebas solo en capacidad limitada o en momentos inconvenientes
- Difícil de aprovisionar o configurar en un entorno de prueba
- Necesario para el acceso simultáneo de diferentes equipos con configuración de datos de prueba variada y otros requisitos
- Uso restringido o costoso para pruebas de carga y rendimiento
Aunque el término "virtualización de servicios" refleja el enfoque inicial de la técnica en la virtualización de servicios web , la virtualización de servicios se extiende a todos los aspectos de las aplicaciones compuestas: servicios, bases de datos , mainframes , ESB y otros componentes que se comunican mediante protocolos de mensajería comunes. Otras herramientas similares se denominan API simuladores, herramientas API burlarse, a través de los hilos dobles de prueba .
La virtualización de servicios emula solo el comportamiento de los componentes dependientes específicos que los desarrolladores o evaluadores deben ejercitar para completar sus transacciones de un extremo a otro. En lugar de virtualizar sistemas completos, virtualiza solo porciones específicas de comportamiento dependiente críticos para la ejecución de tareas de desarrollo y prueba. Esto proporciona la lógica de aplicación suficiente para que los desarrolladores o evaluadores obtengan lo que necesitan sin tener que esperar a que el servicio real se complete y esté disponible. Por ejemplo, en lugar de virtualizar una base de datos completa (y realizar toda la administración de datos de prueba asociada, así como configurar la base de datos para cada sesión de prueba), usted monitorea cómo la aplicación interactúa con la base de datos, luego emula el comportamiento de la base de datos relacionada (el SQL consultas que se pasan a la base de datos, los conjuntos de resultados correspondientes que se devuelven, etc.).
Solicitud
La virtualización de servicios implica la creación e implementación de un "activo virtual" que simula el comportamiento de un componente real que se requiere para ejercitar la aplicación bajo prueba, pero al que es difícil o imposible acceder para propósitos de desarrollo y prueba.
Un activo virtual sustituye a un componente dependiente al escuchar las solicitudes y devolver una respuesta adecuada, con el rendimiento adecuado. Para una base de datos, esto podría implicar escuchar una declaración SQL y luego devolver las filas de la fuente de datos. Para un servicio web, esto puede implicar escuchar un mensaje XML a través de HTTP , JMS o MQ y luego devolver otro mensaje XML. La funcionalidad y el rendimiento del activo virtual pueden reflejar la funcionalidad / rendimiento real del componente dependiente, o puede simular condiciones excepcionales (como cargas extremas o condiciones de error) para determinar cómo responde la aplicación bajo prueba en esas circunstancias.
Los activos virtuales suelen ser creados por:
- Grabación de la comunicación en vivo entre componentes a medida que el sistema se ejercita desde la aplicación bajo prueba (AUT)
- Proporcionar registros que representen la comunicación histórica entre componentes.
- Analizar las especificaciones de la interfaz de servicio (como un WSDL )
- Definir el comportamiento manualmente con varios controles de interfaz y valores de fuente de datos
Luego, se configuran aún más para representar datos, funciones y tiempos de respuesta específicos.
Los activos virtuales se implementan localmente o en la nube (pública o privada). Con los entornos de desarrollo / prueba configurados para usar los activos virtuales en lugar de los componentes dependientes, los desarrolladores o evaluadores pueden entonces ejercitar la aplicación en la que están trabajando sin tener que esperar a que los componentes dependientes se completen o sean fácilmente accesibles.
Los analistas de la industria informan que la virtualización de servicios es más adecuada para "los talleres de TI con experiencia significativa en 'omitir' las pruebas de integración debido a un 'software dependiente' y con un arnés de prueba razonablemente sofisticado.
Relación con los golpes y las burlas
Un enfoque alternativo para trabajar alrededor de las restricciones de acceso del entorno de prueba descritas en la introducción de este artículo es que los miembros del equipo desarrollen códigos auxiliares de métodos u objetos simulados que sustituyan a los recursos dependientes. La deficiencia de este enfoque se hizo evidente a principios de la década de 2000 con el surgimiento de la arquitectura orientada a servicios . La proliferación de aplicaciones compuestas que dependen de numerosos servicios dependientes, además del aumento del desarrollo de software ágil tras la publicación del Manifiesto Ágil en 2001, hizo que fuera cada vez más difícil para los desarrolladores o probadores desarrollar manualmente el número, el alcance y la complejidad de los stubs o simulacros. necesarios para completar las tareas de desarrollo y prueba para el desarrollo de aplicaciones empresariales modernas.
El primer paso en la evolución de stubbing a service virtualization fue la tecnología empaquetada en herramientas de prueba SOA desde 2002. Las primeras implementaciones de la virtualización de servicios se diseñaron para automatizar el proceso de desarrollo de emulaciones simples de stub para que las aplicaciones compuestas pudieran probarse de manera más eficiente. . A medida que los sistemas empresariales continuaron haciéndose cada vez más complejos y distribuidos, los proveedores de herramientas de software cambiaron el enfoque de los stubbing a la virtualización de servicios más centrada en el medio ambiente. Si bien el stubbing aún se puede completar mediante el desarrollo y la gestión manual de stubs, lo que se conoce como "virtualización de servicios" se completa mediante el uso de una de las tecnologías de virtualización de servicios comerciales disponibles en el mercado (COTS) como plataforma para el desarrollo y la implementación de sus "activos de virtualización de servicios".
Agile y DevOps
La creciente popularidad del desarrollo de software ágil y DevOps ha creado una demanda de un nuevo conjunto de herramientas para brindar virtualización de servicios a las comunidades que trabajan de esta manera. Prácticas como la entrega continua y el paso del desarrollo de mainframe y monolitos a arquitecturas más distribuidas basadas en microservicios encajan bien con las capacidades de virtualización de servicios. Los equipos ágiles y de DevOps prefieren trabajar con herramientas livianas que tienen menos sobrecarga acumulada y sin restricciones de licencia engorrosas.
