Semillero de
Integración -AWS
Conceptos y Laboratorios SOA, IIB, MQ, ACE,
OpenShift, Api Connect, Datapower
SOA
Una arquitectura orientada a servicios (SOA) es una arquitectura
software basada en los conceptos clave de frontend de aplicaciones,
servicio, repositorio de servicios, y bus de servicios. Un servicio está
formado por un contrato, uno o más interfaces y una
implementación. Los bloques de construcción de SOA son los
servicios, los cuales están débilmente acoplados para favorecer su
reutilización y son altamente interoperables a través de sus
contratos. Los servicios en sí mismos son "ajenos" a las interacciones
requeridas a nivel de transporte para hacer posible la comunicación
entre el suministrador del servicio y el consumidor del servicio.
Dia 1 y 2.
SERVICIO- CONTRATO WSDL
Un servicio es un componente software con un significado funcional que lo distingue de
otros, y que típicamente encapsula un concepto de negocio de alto nivel. La Figura 2
muestra los elementos que forman parte de un servicio.
El contrato del servicio proporciona una especificación informal sobre el propósito,
funcionalidad, restricciones, y uso del servicio. La forma de dicha especificación puede
variar dependiendo del tipo de servicio. La definición formal de la interfaz basada en
lenguajes tales como IDL y WSDL no es obligatoria.
Si bien añade un beneficio significativo: proporciona una abstracción e independencia de la
tecnología, incluyendo al lenguaje de programación, protocolo de red y entorno de
ejecución. Es importante comprender que un contrato de un servicio proporciona más
información que una especificación formal. El contrato puede imponer una determinada
semántica sobre la funcionalidad o el uso de parámetros que no están sujetos a
especificaciones IDL o WSDL.
Dia 1 y 2.
REPOSITORIO DE
SERVICIOS
El repositorio de servicios proporciona facilidades para encontrar servicios y adquirir toda la información para utilizar los servicios,
particularmente si estos servicios deben encontrarse fuera del ámbito funcional y temporal del proyecto que los creó. Si bien mucha de la
información requerida forma parte del contrato del servicio, el repositorio de servicio puede proporcionar información adicional, tal como la
localización física, información sobre el proveedor, personas de contacto, tasas de uso, restricciones técnicas, cuestiones sobre seguridad, y
niveles de servicio disponibles.
Obviamente, un repositorio de servicios es un elemento muy útil de una SOA. Si bien no es indispensable disponer de un repositorio de
servicios, éste resultará indispensable a largo plazo. Una arquitectura puede evitar el uso de un repositorio si el ámbito de un servicio es
justamente un proyecto, si tiene muy pocos servicios, o si todos los proyectos son llevados a cabo por el mismo equipo de personas. En un
escenario real, la mayoría de las veces habrá múltiples proyectos concurrentes, grupos de trabajo cambiantes, y una gran variedad de servicios.
Dia 1 y 2.
BUS DE SERVICIOS
Un bus de servicios (ESB: Enterprise Services Bus) conecta a todos los participantes de una SOA (tanto servicios como frontends). El bus
de servicios es similar al concepto de bus software definido en el contexto de CORBA. Aunque existen diferencias significativas, entre ellas la
más importante es que el bus de servicios no necesariamente debe estar formado por una única tecnología, sino que puede comprender varios
productos y conceptos.
Las principales características de un bus de servicios son:
•Conectividad: el objetivo principal de un bus de servicios es del de interconectar a los participantes de una SOA. Por lo tanto debe
proporcionar facilidades para permitir a los participantes de una SOA invocar las funcionalidades de los servicios.
•Heterogeneidad de tecnología: puesto que la realidad de las empresas se caracteriza por tecnologías heterogéneas, el bus de servicios
debe ser capaz de conectar participantes basados en diferentes lenguajes de programación, sistemas operativos o soporte de ejecución.
Además, normalmente encontraremos muchos productos middleware y protocolos de comunicación en la empresa, todas las cuales deben ser
soportadas por el bus de servicios.
Dia 1 y 2.
TIPOS DE BUSES
FABRICANTES
Dia 1 y 2.
IBM WebSphere MQ
•IBM WebSphere MQ es middleware de mensajería y gestión de colas, con modalidad de operación de punto a punto, de publicación/suscripción y
de transferencia de archivos. Las aplicaciones pueden publicar mensajes a muchos suscriptores a través de la multidifusión.
IBM MQ es una familia de productos de middleware de mensajería que IBM lanzó en diciembre de 1993. IBM MQ fue originalmente
llamado MQSeries, y fue rebautizado como WebSphere MQ en 2002 para unificar un conjunto de productos en la suite WebSphere. En abril de
2014, volvió a cambiar de nombre a IBM MQ. Los productos que está incluidos en la familia MQ son IBM MQ, IBM MQ Advanced, IBM
MQ Appliance, IBM MQ para z/OS, e IBM MQ en IBM Cloud.
MQ permite que aplicaciones independientes y potencialmente no concurrentes en un sistema distribuido puedan comunicarse con seguridad
con otras, usando mensajes. MQ está disponible sobre un gran número de plataformas (tanto IBM como no IBM), incluyendo z/OS (mainframe),
OS/400 (IBM System i o AS/400), TPF, UNIX (AIX, HP-UX, Solaris), HP <i>NonStop</i>, OpenVMS, Linux, y Windows de Microsoft.
Los componentes core de MQ son los siguientes:
•Mensaje: Los mensajes son colecciones de datos binarios o de carácter (para caso ASCII o EBCDIC) que tienen algún significado para un programa
participante. Al igual que en otros protocolos de comunicaciones, acciones de almacenamiento, encaminamiento, y entrega de información son
añadidas al mensaje antes de que transmisión y retirados del mensaje antes de su entrega a la aplicación receptora.
•Cola: Las colas de mensajes son objetos que almacenan mensajes en una aplicación.
•Gestor de colas: Se refiere a un servicio del sistema que provee un contenedor lógico para la cola de mensajes. Es responsable de transferir los
datos a otro gestor de colas vía canales de mensajería. A pesar de que no es estrictamente requerido para los middleware de mensajería, sí lo es
para IBM MQ, gestionan almacenamiento, temporalidad de eventos, triggering, y todas las otras funciones no directamente relacionadas al propio
movimiento de datos.
Los programas integrados con IBM MQ usan una interfaz de programa de aplicación (API) consistente y compatible a través de todas las
plataformas para las que está disponible.
Dia 1 y 2.
IBM WebSphere MQ
Dia 1 y 2.
LAB. 1 CREACIÓN GESTOR COLAS -Practica
•Paso 1, Crear el gestor
Dia 1 y 2.
LAB. 1 CREACIÓN GESTOR COLAS
•Paso 2, Asignar parámetros
Dia 1 y 2.
LAB. 1 CREACIÓN COLAS
•Paso 3, Crear Cola (Local, Alias)
Dia 1 y 2.
GESTOR COLAS, CONEXIÓN MÉTODO TRADICIONAL
•Paso 1:
•Paso 2: Asignar nombre según la hoja de datos
Dia 1 y 2.
GESTOR COLAS, CONEXIÓN MÉTODO TRADICIONAL
•Paso 4: Autenticación, antes de realizar este proceso se
•Paso 3: Asignar según la hoja de datos debe validar con los expertos del area si el usuario esta en
el archivos .exits del MQ
•Paso 5: Validar conexión
Dia 3 y 4.
GESTOR COLAS, CONEXIÓN CONTENERIZADO
Dia 3 y 4.
GESTOR COLAS, CONEXIÓN CONTENERIZADO
Dia 3 y 4.
GESTOR COLAS, CONEXIÓN CONTENERIZADO
Dia 3 y 4.
GESTOR COLAS, CONEXIÓN CANAL SEGURO
(CERTIFICADO)
LAB. 2 Cree su certificado personal
•Paso 1: Ejecutar la aplicación KeyTool •Paso 2: Crear un almacén de llaves
Dia 3 y 4.
GESTOR COLAS, CONEXIÓN CANAL SEGURO
(CERTIFICADO)
LAB. 2
•Paso 3: Asignar una contraseña al almacén •Paso 4: Crear nuestro autofirmado
Dia 3 y 4.
GESTOR COLAS, CONEXIÓN CANAL SEGURO
(CERTIFICADO)
LAB. 2
•Paso 5: Diligenciar datos •Paso 6: Validar que nuestro autofirmado esté dentro del
almacén especificado
Dia 3 y 4.
IBM INTEGRATION BUS 10
•IBM Integration Bus es una evolución compatible de WebSphere® Message Broker que está diseñada para incorporar
características que se encuentran en WebSphere Enterprise Service Bus . IBM Integration Bus proporciona una capacidad
de integración universal que aborda una amplia gama de escenarios de integración. Estos escenarios incluyen servicios
web como SOAP y REST, mensajería, base de datos, archivos, sistemas ERP, móviles, dispositivos físicos, correo
electrónico, sistemas personalizados y más.
Dia 5 y 6.
IBM INTEGRATION BUS 10
LAB. 3 Importar un servicio con sus respectivas librerías,
crear y desplegar en un grupo de ejecución
•Paso 1: •Paso 2:
Dia 5 y 6.
IBM INTEGRATION BUS 10
LAB. 3
•Paso 3: Importar fuentes •Paso 4:Validar el correcto funcionamiento del APP
Dia 5 y 6.
IBM INTEGRATION BUS 10
LAB. 3
•Paso 5: Cree un servidor de prueba •Paso 6: Cree un grupo de ejecución
Dia 5 y 6.
IBM INTEGRATION BUS 10
LAB. 3
•Paso 7: Cree un archivo .BAR de la aplicación
Dia 5 y 6.
IBM INTEGRATION BUS 10
LAB. 3
•Paso 8: Despliegue el .BAR del APP •Paso 9: Elija su grupo de ejecución
•Paso 10: Valide el correcto despliegue de la aplicación
Dia 5 y 6.
LABORATORIO
CONTRATOS-WSDL FRAMEWORK INTEGRACION
Ver video creación firma 1
Conocer framework Bancolombia y generar un WSDL o contrato desde el integration toolkit, ver video 2 y 3
Channel adapter
Service Mediator
Service Gateway
Integration Adapter
Video 2
Video 3
Video 1
Dia 7 y 8.
IBM INTEGRATION ACE11
El software IBM® App Connect Enterprise combina las tecnologías existentes y confiables de la industria de
IBM Integration Bus con IBM App Connect Professional y con tecnologías nativas de la nube, para ofrecer una
plataforma que admita todas las necesidades de integración en una empresa digital moderna.
Dia 5 y 6.
IBM INTEGRATION ACE11
Contenerización de servicios (OpenShift)
OpenShift, formalmente llamado Openshift Container Platform (OCP), es un producto de computación en la nube de plataforma
como servicio de Red Hat.
Esta plataforma se desarrolla a partir de contenedores kubernetes que los desarrolladores utilizan para desplegar apps en
diferentes lenguajes de programación. Su principal objetivo es mejorar la productividad de los desarrolladores y promover la
innovación.
IBM INTEGRATION ACE11
Contenerización de servicios (OpenShift)
IBM INTEGRATION ACE11
Contenerización de servicios (AWS)
Amazon Web Services (AWS abreviado) es una colección de servicios de computación en la nube pública (también llamados
servicios web) que en conjunto forman una plataforma de computación en la nube, ofrecidas a través de Internet por
[Link]. Es usado en aplicaciones populares como Dropbox, Foursquare, HootSuite. Es una de las ofertas internacionales
más importantes de la computación en la nube y compite directamente contra servicios como Microsoft Azure, Google Cloud
Platform y IBM Cloud. Es considerado como un pionero en este campo.
IBM INTEGRATION ACE11
Contenerización de servicios (AWS)
Estándares de Mensajes para la Capa de
Integración
Interfaz del Servicio
Aplicación conoce
Consumidora I
expone
Serviciosconsumidos como
invoca Web Services interoperables
Service
XML SOA
WSChannel resuelve
Registry implementa P
Adapter
Service invoca Service
Gateway Component
MQChannel
Tecnología homogénea de
comunicación, basada en
JSON TRAMA
Adapter mensajería y asincronismo.
…
ComponentesComunes/ ESB
Aplicación
Proveedora
Framework Adaptadores
MQ 8 y 2 y Broker 10 (IIB)
DevOps
• Configuration Management
• Continuous Integration
• Continuous Testing
• Release Management
Configuration Management
Practica GIT
[Link]
Continuous Integration
Objetivo del pipeline de compilación
• Para ejecutar y publicar pruebas unitarias en los casos que aplique.
• Para realizar análisis estático de código.
• Para validar que el servicio compila sin problema los cambios realizados.
• Es un requisito para completar el "pullrequest" que nos permite integrar el
código en las ramas base.
• Para llevar a Artifactory todos los artefactos necesarios para un despliegue
bajo el estándar de directorios que tengamos definido para cada
plataforma. (Eso lo vemos más adelante).
• Para publicar en Azure Devops los artefactos que vayamos a utilizar para
pruebas automatizadas.
Continuous Testing
• Consulta aquí las definiciones correspondientes a la estrategía de
calidad en el ciclo de vida de desarrollo de servicios de
integración.
Pruebas de Rendimiento
• Se debe diligenciar la lista de chequeo de pruebas no funcionales,
se puede consultar la siguiente guía: Lista de chequeo de Pruebas
No Funcionales.
• ⚠ Cuando no se tengan requisitos no funcionales (RNF) definidos
específicamente para los componentes de la capa de
integración, la lista de chequeo se debe diligenciar con los
requisitos no funcionales que se hayan definido para el back-
end.
• En la siguiente guía se explica detalladamente cómo configurar el
pipeline de release para ejecutar pruebas de rendimiento con
jmeter: Creación pipeline performance RM - Jmeter.
Release Management
¡Gracia
s!
