Compartir vía


Descripción de la solución orientada a servicios

La solución orientada a servicios presenta una aplicación de informes de saldo de crédito diseñada como un servicio. La aplicación, a su vez, utiliza tres aplicaciones de servidor expuestas como servicios para obtener la información necesaria para el saldo de crédito.

Una arquitectura orientada a servicios (SOA) es un enfoque que se superpone parcialmente con la generación de sistemas distribuidos. Un enfoque orientado a servicios tiene varias características:

  • Ligeramente acoplado. La lógica empresarial de la aplicación está separada de la lógica de control del servicio.

  • Se puede detectar. Debería haber un mecanismo para que las aplicaciones encuentren el servicio.

  • Contractual. La interfaz del servicio implementa el contrato entre los usuarios y el servicio.

    Aunque en la literatura se trata con frecuencia los enfoques orientados a servicios como sinónimos de los servicios Web, no son necesariamente sinónimos. Los servicios Web presentan un modo atractivo de implementar soluciones orientadas a servicios, pero puede usar otras tecnologías, como el entorno remoto de .NET, para crear servicios.

Instrucciones para el lector

En la documentación de esta solución se da por supuesto que está familiarizado con BizTalk Server y Microsoft Visual Studio. También asume que comprende los conceptos básicos de la integración de aplicaciones empresariales y los servicios Web.

Además, para leer y seguir la documentación para desarrolladores, debe estar familiarizado con cómo compilar aplicaciones mediante Visual Studio y realizar las siguientes tareas: crear proyectos, establecer referencias y depurar y probar soluciones de BizTalk.

Informes de tarjetas de crédito en Woodgrove Bank

La solución de arquitectura orientada a servicios es un servicio de informes de saldo de tarjetas de crédito para Woodgrove Bank. Aunque el banco es ficticio, el escenario no es , el escenario se basa en una aplicación de cliente real, implementada.

En el escenario, las solicitudes de saldo de tarjeta de crédito proceden de dos orígenes:

  • Una aplicación de respuesta interactiva de voz (IVR).

  • Un cliente interactivo como una página Web o una aplicación cliente personalizada.

    La solución recibe solicitudes de la aplicación de IVR a través de MQSeries. Administra las solicitudes del cliente interactivo a través de un servicio Web que utiliza HTTP y SOAP.

    Las nuevas aplicaciones de arquitectura orientada a servicios tienen que trabajar con frecuencia con aplicaciones heredadas que usan tecnologías más antiguas y con aplicaciones modernas como sitios Web que consumen servicios Web. El escenario modela este requisito real: la aplicación IVR representa una aplicación heredada, mientras que la aplicación cliente de servicio al cliente es la moderna.

    La aplicación Woodgrove Bank utiliza datos de tres sistemas de servidor heredados para responder a las solicitudes:

  • Una aplicación que proporciona el límite de crédito global. Es un sistema SAP en un gran sistema (mainframe).

  • Un sistema de transacciones pendientes que informa del importe total de las transacciones pendientes en la cuenta. Es un sistema en un gran sistema (mainframe) o AS/400. La solución utiliza un servicio Web y Microsoft Host Integration Server (HIS) para comunicarse con el gran sistema (mainframe) o el sistema AS/400.

  • Un sistema de seguimiento de pago que da el último pago realizado al sistema. Al sistema de seguimiento de pago se llega usando MQSeries.

    Tras recopilar y compilar la información de los sistemas heredados, la solución envía la respuesta a la aplicación de origen, por tanto, al cliente.

Requisitos empresariales

Puesto que la aplicación de informes de crédito responde en tiempo real a las solicitudes del cliente, debe tener una latencia baja para administrar las solicitudes con rapidez. Además, debe poder administrar también grandes cantidades de solicitudes simultáneas. La solución utiliza información confidencial y una interfaz pública, de manera que la seguridad es un preocupación importante. Finalmente, el servicio debe ser confiable.

Para obtener información sobre cómo la solución cumple estos requisitos, consulte Developing a Service Oriented Solution.

Características de rendimiento

Para cumplir los requisitos empresariales, el escenario tiene las siguientes características de rendimiento:

  • Rendimiento sostenido de 40 solicitudes entrantes por segundo.

  • Rendimiento máximo de 100 solicitudes entrantes por segundo.

  • El 90 % de las solicitudes que se van a atender (dentro y fuera de BizTalk Server) en menos de 1000 milisegundos.

  • 95 por ciento de las solicitudes para atender (dentro y fuera de BizTalk Server) en menos de 2.000 milisegundos.

  • El 100 % de las solicitudes que se van a atender (dentro y fuera de BizTalk Server) en menos de 5000 milisegundos.

Nota

Estos tiempos no incluyen los tiempos de latencia de los sistemas de servidor.

Tres versiones de la solución

Hay tres versiones de la solución:

  • La versión de código auxiliar reemplaza todos los sistemas de servidor con código auxiliar. Este código auxiliar simula los sistemas de servidor. Esta versión proporciona un modo rápido de implementar y ejecutar la solución en un solo equipo.

  • La versión de adaptador utiliza adaptadores de BizTalk para conectarse a sistemas de servidor. Esta versión es como se podría pensar en principio implementar la solución. Sin embargo, el envío de mensajes a los sistemas de servidor usando adaptadores supone una latencia importante a la hora de obtener de nuevo las solicitudes. Si bien los adaptadores por sí solos podrían ofrecer una latencia muy baja, la arquitectura distribuida de BizTalk Server requiere que los adaptadores se comuniquen con las instancias de host de la orquestación mediante el cuadro de mensajes. Esto produce acciones de ida y vuelta a la base de datos y afecta a los tiempos de latencia.

  • La versión en línea reemplaza los adaptadores por código en línea que se comunica directamente con los sistemas de servidor. La versión en línea de la solución tiene la latencia más baja y el mayor rendimiento.

    La guía de implementación proporciona instrucciones para crear e implementar todas las versiones de la solución, y también proporciona en cada versión una forma de simular la conexión a través de HIS con el sistema de transacciones pendientes. Para obtener información sobre cómo compilar e implementar la solución, consulte Implementación de la solución orientada a servicios.

Consulte también

Solución orientada a servicios