Enterprise Service Bus
El Bus de Servicios de Empresa, es un entorno de aplicación basado en mensajes que permitirá a las aplicaciones acceder a los servicios tanto desde dentro de la propia empresa, como externamente de forma remota. En él se realiza una labor crucial en toda arquitectura SOA, posibilitando la publicación de los servicios y la normal interacción entre ellos.
Las interacciones realizadas de manera interna al propio bus, deberán cumplir las siguientes características:
- Publicación de Servicios: Los servicios podrán contactar entre sí a través del intercambio de documentos definidos en un formato estándar (normalmente XML), e invocar sus respectivos modelos de objetos, clases y APIs.
- Middleware Orientado a Mensajes: El transporte debe ser fiable, eficiente y robusto en todo el canal de intercambio de datos, es decir, extremo a extremo.
- Encaminamiento Inteligente: El encaminamiento de mensajes deberá estar basado en su contexto y contenido, así como en reglas de proceso de negocio.
- Modelo Asíncrono: Los servicios interactuarán entre sí siguiendo un enfoque asíncrono, que asegure que aún no habiendo terminado de procesar las peticiones de servicio previas, seguirá procesando nuevas solicitudes. Esta comunicación asíncrona se logrará utilizando colas de mensajes, registros de callback e interacciones peer-to-peer entre clientes y servidores.
- Posibilidad de Interceptación: Los servicios podrán interactuar entre ellos bien de forma directa, o utilizando nodos intermedios capaces de interceptar los mensajes intercambiados, inspeccionándolos, filtrando y aplicando las políticas que se consideren oportunas. También serán capaces de operar como proxies para servicios.
- Modelo de gestión de estados: Los servicios podrán mantener de manera opcional información sobre el estado de su sesión, de forma temporal o persistente, recogida bien en los extremos o en los nodos intermediarios. Para ello sería necesario enviar en la cabecera de los mensajes intercambiados dicha información de estado.
- Modelo Fiable: Deberá poder asegurarse un modelo fiable de entrega única de mensajes, aunque finalmente se decida optar por otros basados en sistemas de mejor esfuerzo y por tanto no seguros.
