Enterprise Service Bus y API Managers
•Descargar como PPTX, PDF•
4 recomendaciones•1,550 vistas
API Managers, Entreprise Service
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Enterprise Service Bus y API Managers
Similar a Enterprise Service Bus y API Managers (20)
Último
Último (7)
Enterprise Service Bus y API Managers
- 2. ¿Qué es un Enterprise Service Bus? ESB Se acopla a SOA, reduciendo la complejidad y permite a las empresas centrarse en sus actividades básicas. Unifica las capacidades de comunicación. Describe un conjunto de normas y principios para la integración de las d iferentes aplicaciones para fines de comunicación a través de una infraestructura BUS. Enterprise Service Bus, es una platafor ma de integración para facilitar el acoplamiento de las aplicaciones en la empresa.
- 3. Características VENTAJAS Soporte de patrones de intercambio de mensajes complejos (MEP) Estandarización Enrutamiento Transformación de datos Fiabilidad, tolerancia a fallos, equilibrio de carga y alta dispnibilidad.
- 5. Flujo de información J2EE$ OS/390'
- 6. 5 Aplicaciones = 10 interfaces 13 Aplicaciones = 78 interfaces Número de interfaces P2P
- 7. J2EE$ OS/390' SOA Service Oriented Architecture
- 10. Arquitectura de un ESB
- 11. Características
- 12. Invocación de Servicios (Find Bind Invoke) J2EE$ OS/390' ESB Registro de Servicios
- 13. Invocación de Servicios (Find Bind Invoke)
- 14. Aplicación X1 SOAP Aplicación X2 HTTP Aplicación X3 JMS M1 M2 Message Router Mn Aplicación Y2 HTTP Transforma de Mn a M2 Mn M2 M2 Routing - Content Based Routing (CBR)
- 19. Modelo Federado ESB ESB ESB Portal Interno Móvil HTTPS PoS HTTPS Servidor Externo SOAP SAP COBOL ESB SaaS HTTPS BAM HTTP LDAP LDAP B2B SOAP Legacy HTTP SOAP API Terceros HTTP WS ESB Back office Front office
- 21. Organizaciones Proyectizadas ESB Puntos deVenta HTTPS B2B SOAP External ESB SFA DP Front Office Portales comerciales ERP ESB SCM LDAP Back Office CRM ESB SCM LDAP Business unit Proyecto A Proyecto B Proyecto C Proyecto D Integration Broker
- 22. Soluciones
- 23. Herramientas – Jboss Fuse IDE
- 24. Mule IDE
- 25. API Managers
- 26. ¿Qué es un API? API API Gestionada Es una capacidad de negocio expuesta en inter net para ser consumida exter na o internamente. Disponible utilizando protocolos WEB Diseñada para ser accedida por terceros. Con interfaces bien diseñadas Está disponible con acuerdos de nivel de servicios SLA Alto nivel de Quality of Service QoS Segura, autenticada, autorizada, y protegida Monitorizada y monetizada con métricas Activamente anunciada y sujeta a subscripción
- 27. Qué NO es un API ¿Aporta una funcionalidad que si al ser utilizada por un tercero pueda ser capaz de producir valor? Si no, entonces no es un API!
- 28. API Manager
- 29. API Manager Protocol Transformation Optimización para Móviles Versionado Convertir de REST a SOAP y Viceversa Convertir de XML a JSON y Viceversa Combinar puntos HTTP y HTTPS Compresión y Descompresión Procesamiento de mensajes largos Control de paginación Gestión de Caché Agiliza la creación de Mocks Emula futuras releases Mashups de diferentes fuentes de datos Mashups de funcionalidades de distintas fuentes
- 30. API Manager Securización Gestión de Tráfico Reglas de control Gestion de credenciales Autenticación a nivel de aplicaciones Autenticación a nivel de usuario Traceo y auditoría Gestión de Ratio y de Quota Blockeo de inyección de cód igo Protección contra ataques DoS Bogus Traffic / Probing attack
- 31. API Manager
- 32. Patrón Façade Mediador API Façade J2EE$ OS/390' Canales de Distribución B2B Public Cloud
- 33. Llamada API tradicional http://api.organizacion.es/v1/seguros Autenticar Validar Convertir SOAP Enrutar XML A JSON 5 1 2 3 4 Servicios
- 34. Flujo de Llamadas API Manager Autenticar Validar Convertir SOAP Enrutar XML /JSON Políticas Cache http://api.organizacion.es/v1/seguros Métricas Servicios
- 36. Políticas del API Manager APP BACKEND REQUEST RESPONSE P1 P2 P3 P4
- 37. Metodología de Implantación Definición Monitorización Actualizaciones Pruebas de rendimiento Implementación Operación Definir API Office Definir la estrategia Objetivos Criterios de éxito Metas de negocio Definir requisitos de negocio Diseño del API Construir y probar Estrategias de versionado
- 38. Responsabilidades de la API Office
- 39. Responsabilidades de la API Office
- 40. Ciclo Iterativo Instalación de la Platafor ma Construir procesos y componentes comunes Sprints de 3 semanas Desarrollo, pruebas, y despliegue continuo. Desarrollo de las APIs Exposición y Releases Dominio de las APIs Formación de la API Office Reuniones con el equipo de arquitectura Operaciones y transferencia Transmisión de los conocimientos Documentación Training y formación 1 2 3 SoporteBalanceadores y servidor de métricas Formación y uso de la plataforma
- 41. Ciclo Iterativo de Desarrollo
- 42. Soluciones
- 45. Apigee Analytics
- 46. Apigee API Developer Console
- 47. Apigee API Debugger Console
- 48. Gracias!
Notas del editor
- Representación de una empresa normal Un gran abanico de de aplicaciones ----- Meeting Notes (17/04/14 10:53) ----- Bases de datos LDAP Gestion de documentación Mensajería Software as a Service Aplicaciones J2EE LEGACY
- A mayor cantidad de aplicaciones el grado de complejidad interacción y coste de mantenimiento aumenta.
- A mayor cantidad de aplicaciones el grado de complejidad interacción y coste de mantenimiento aumenta. La fómula para el número de interfaces es N(n-1)/2 cuando hay 5 aplicaciones esta bien, pero cuando hay 13, el número de interfaces aumenta a 78
- Para este tipo de problematica tenemos una solución sencilla SOA Es el primer paso para la homogenización de la empresa. ----- Meeting Notes (17/04/14 11:43) ----- Todas hablamos el mismo lenguaje. Monitorización Reglas de negocio
- Un ESB es la columna vertebral de una implementación SOA.
- Un ESB es la columna vertebral de una implementación SOA.
- Hasta el día de hoy regularmente en SOA se utiliza el modelo cliente-servidor. Mediación de protocolos: Una aplicación cliente envia un requerimiento usando un protocolo diferente al de invocación del servicio requerido. Por ejemplo, el mensaje de la aplicación cliente podría utilizar HTTP, mientras que el mensaje saliente requerido para invocar el servicio podría usar WebSphere MQ. Se encarga de proporcionar apoyo a los protocolos de transporte de manera sincrónica y asincrónica. En un ESB modelo find, Bind, and invoke asume que existe un registro o directorio donde se almacenan la ubicación de destino de los recursos, y cualquier posible metadata sobre la implementación del servicio. ----- Meeting Notes (17/04/14 12:44) ----- WSRR Websphere Service REgistry and Repository ----- Meeting Notes (17/04/14 12:45) ----- A service registry is the central catalog for services within an organisation. It provides important governance and registration functions, enabling an organisation to keep track of what stage its services are in, who is using them, and policies and other metadata associated with them. IBM® WebSphere® Service Registry and Repository (hereafter called WSRR), IBM's service registry product, gives visibility to services and provides a central place to search for them. ----- Meeting Notes (19/04/14 10:44) -----
- The key importance of the ESB approach to SOA is that the service definition is separated from the mechanism for locating and invoking services. La mayor importancia del Service Bus con respecto a SOA, erradica en que la definición del servicio está separada del mercanismo de localización e invocación de servicios.
- Responsable para el envío de la información para un lugar u otro, lo hace de un modo estático o dinámico. Podemos usar el enrutamiento basado en reglas con Drools por ejemplo. This process can be further automated and generalized by introducing another ESB concept, Content-Based Routing (CBR). A CBR service can be plugged into the message flow between the producer X1 and the consumer Y1. This CBR service can be a lightweight process with the sole purpose of applying an XPath expression, such as the one used in our example, to determine whether the message conforms to the format of M1 or M2. If the message is of type M1, it can be routed automatically to another special service that fills in the missing pieces of data Enrutamiento de Mensajes: Un mensaje entrante es enviado a un destino ya sea teniendo en duro la información del destino, o empleando ruteo dinámico basado en contenido. El ruteo es una función clave para la virtualización de servicios. Estableciendo un nivel intermedio de abstracción entre el invocador y el servicio a invocar por medio de un servicio encargado de la localización del servicio que debe satisfacer el requerimiento.
- Patrones de mensajería, para definir la lógica de integración.
- Patrones de mensajería, para definir la lógica de integración. Se encarga de proporcionar la transformación de protocolos, por ejemplo entrar en una http y salir en un SFTP. ESB can support multiple message transfer protocol so as to improve the overrall efficiency of the machine communication, from P2P connection type message to BroadCasting messages, diferent MEPs are supported by esb.
- Patrones de mensajería, para definir la lógica de integración.
- Patrones de mensajería, para definir la lógica de integración.
- The federated/autonomous capabilities of the ESB also contribute to the ability to adopt an ESB one project at a time. Incrementally staged deployments of ESB integration projects can provide immediate value while working toward the broader corporate initiatives. This notion of incremental adoption is also further supported by the ability to bridge into an existing integration broker hub and legacy message brokers. Integration broker hubs and their traits are explored in more detail in ESB Federation Due to different reasons, it is likely that several instances of ESB are deployed in the architecture: - Different requirements (e.g. performance, security, etc) for different parts in the OB. A typical example can be two different federated ESBs for Third Party applications access and for internal applications access, where the security requirements are different. - Administrative reasons. For instance, different geographical areas or different responsibility domains.
- The two ESB nodes can now be connected using a secure link that is based on reliable messaging Furthermore, the remote locations can continue to operate within their own segregated integration environments, but still selectively share data as needed. For example, the remote locations may be independently owned and operated retail stores belonging to a collective franchise. They have no need to share information about their daily operations, but they do need to share data such as price updates and inventory information. The remote ESB nodes can be connected together with the ESB network at headquarters, and can selectively expose message channels to each other to share price updates and so on.
- La forma en que ServiceMix separa la lógica de la comunicación de la lógica de procesamiento es muy buena y todo eso a través de JBI. Lo bueno es que se puede distribuir de forma cargada con todo el soporte de Spring Framework o de manera stand alone, incluso con otro ESB. Podemos utilizar Drools con ServiceMix, esta integración ya está lista, así podemos exponer las reglas de enrutamiento para un analista de negocio o hasta el mismo usuario de un sistema.
- Este es modelo de empresa, donde encajaría el api Manager.
- Este es modelo de empresa, donde encajaría el api Manager.
- Este es modelo de empresa, donde encajaría el api Manager.
- Este es modelo de empresa, donde encajaría el api Manager.
- Este es modelo de empresa, donde encajaría el api Manager.
- Este es modelo de empresa, donde encajaría el api Manager.
- El patron Façade se hace presente
- Este es modelo de empresa, donde encajaría el api Manager. ----- Meeting Notes (19/04/14 12:54) ----- JAX-RS RESTFUL implementation
- Este es modelo de empresa, donde encajaría el api Manager.
- Este es modelo de empresa, donde encajaría el api Manager.
- En cada momento tengo el control del flujo y puedo establecer una serie de politicas en cada uno de los flujos