Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La solución orientada a servicios presenta una aplicación de informes de saldo de crédito diseñada como servicio. La aplicación, a su vez, usa tres aplicaciones back-end, expuestas como servicios propios, 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 a la creación de sistemas distribuidos. Un enfoque orientado a servicios tiene varias características:
Acoplado débilmente. La lógica de negocios de la aplicación es independiente de la lógica de control del servicio.
Descubrible. Debe 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 la literatura suele tratar los enfoques orientados al servicio como sinónimos de los servicios web, no son necesariamente sinónimos. Los servicios web presentan una manera atractiva de implementar soluciones orientadas a servicios, pero puede usar otras tecnologías, como la comunicación remota de .NET, para crear servicios.
Guía del 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 supone que comprende los conceptos básicos sobre la integración de aplicaciones empresariales y los servicios web.
Además, para leer y seguir la documentación del desarrollador, 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 lo es; el escenario se basa en una aplicación real implementada para un cliente.
En el escenario, las solicitudes de saldos de tarjetas de crédito proceden de dos fuentes:
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 IVR a través de MQSeries. Controla las solicitudes del cliente interactivo a través de un servicio web mediante HTTP y SOAP.
Las nuevas aplicaciones de arquitectura orientadas a servicios suelen necesitar trabajar con aplicaciones heredadas que usan tecnologías anteriores, así como funcionar 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 usa datos de tres sistemas back-end heredados para responder a las solicitudes:
Una aplicación que proporciona el límite total de crédito. Se trata de un sistema SAP en un equipo central.
Un sistema de transacciones pendiente que informa del importe total de las transacciones pendientes en la cuenta. Este sistema es un sistema central o AS/400. La solución usa un servicio web y Microsoft Host Integration Server (HIS) para comunicarse con el sistema central o AS/400.
Un sistema de seguimiento de pagos que da el último pago realizado al sistema. Se puede acceder al sistema de seguimiento de pagos mediante MQSeries.
Después de recopilar y compilar la información de los sistemas heredados, la solución devuelve la respuesta a la aplicación de origen y, por tanto, al cliente.
Requisitos empresariales
Dado que la aplicación de informes de crédito responde en tiempo real a las solicitudes de los clientes, debe tener baja latencia para controlar las solicitudes rápidamente. Además, también debe ser capaz de controlar un gran número de solicitudes simultáneas. La solución usa información confidencial y una interfaz pública para que la seguridad sea importante. Por último, el servicio debe ser confiable.
Para obtener información sobre cómo la solución cumple estos requisitos, consulte Desarrollo de una solución orientada a servicios.
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.
El 95 % de las solicitudes que se van a atender (dentro y fuera de BizTalk Server) en menos de 2000 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 back-end.
Tres versiones de la solución
Hay tres versiones de la solución:
La versión de stub reemplaza todos los sistemas back-end con stubs de software. Los prototipos simulan los sistemas backend. Esta versión proporciona una manera rápida de implementar y ejecutar la solución en un único equipo.
La versión del adaptador usa adaptadores de BizTalk para conectarse a los sistemas back-end. Esta versión es la forma en que podría pensar primero en implementar la solución. Sin embargo, el envío de mensajes a los sistemas back-end mediante los adaptadores presenta una latencia significativa en la obtención de respuestas. Aunque los adaptadores por sí mismos podrían ofrecer una latencia muy baja, la arquitectura distribuida de BizTalk Server requiere adaptadores para comunicarse con las instancias del host de orquestación mediante el cuadro de mensaje. Esto presenta recorridos 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 back-end. La versión insertada de la solución tiene la latencia más baja y el rendimiento más alto.
La guía de implementación proporciona instrucciones para compilar e implementar las tres versiones de la solución, así como proporcionar una manera, en cada versión, de simular la conexión a través de HIS al sistema de transacciones pendiente. Para obtener información sobre cómo compilar e implementar la solución, consulte Implementación de la solución orientada a servicios.