soa - servicios - ¿Es la orquestación una responsabilidad de ESB?
service bus soa (7)
¿Es un Enterprise Service Bus (una herramienta que actúa como mediador, intermediario de mensajes, habilitador de servicios, potenciador de transformación de esquemas, proveedor de ubicación transparente, agregador de servicios, equilibrador de carga, monitor y todo eso) responsable de organizar los servicios ?
¿Qué hay de poner un proceso de negocio comercial automatizado con más de mil pasos y docenas de invocaciones de servicio dentro de su bus de servicio empresarial?
¿Lo haría o utilizaría un especialista en orquestación como un motor BPEL?
Por favor dame tu opinión.
Ahora mi propia visión.
En cuanto a todo el trabajo que un ESB tiene que hacer, poner la orquestación de servicios dentro del elemento de infraestructura principal de su SOA no es una buena idea.
Agregado, vale! Pero mantener su canal de comunicación ocupado con la lógica del negocio seguramente causará un impacto terrible en la capacidad de entregar otras funciones.
Después de todo, la mayoría de los ESB , como BEA Aqualogic Service, tienen un soporte limitado para la orquestación, incluida la falta de capacidades con estado y actividades como wait (a timer) o pick (wait for input para avanzar en el proceso), split / join capabilities ( ya se ha agregado en ALSB 3.0), y así sucesivamente.
De ninguna manera. Solo use herramientas como un motor BPEL o una herramienta como la Integración Weblogic.
Gracias.
Mi breve respuesta rápida es NO, eso no es su responsabilidad.
Preferiría dejar eso en BPEL o en una suite de BPM.
Mhh, no sé qué más agregar :) ... ¿Buena suerte?
Si y no. Existe una línea delgada y, a veces, indistinguible entre la orquestación y el aumento de agregación / servicio.
En general, si tiene un proceso comercial complejo o de larga duración (el proceso es la palabra clave, aunque voy a evitar definirlo), es lo más adecuado para BPEL.
Tareas simples, como agregar los resultados de tres llamadas de servicio, podrían y a menudo deberían hacerse en una capa de ESB.
No vale la pena perder demasiado tiempo para dormir, aunque
Descargo de responsabilidad: soy un consultor de IBM ESB, aunque no estoy escribiendo esto de manera oficial.
Siempre que tenga dos o más servicios que interactúen, use el orquestador de servicios, es decir, los servicios de composición y control de procesos. Si tiene esb, exponga este servicio de composición en esb. Ahora, si tiene que componer un nuevo servicio que incluya este servicio de composición, use orchestrator y vuelva a exponer en esb. Utilice esb como mecanismo de prestación de servicios y agente y intermediario del servicio web. Al componer un servicio, el orquestador usará esb para llegar a los servicios que interactúan. Si estos servicios que interactúan utilizan esquemas xml incompatibles, esb puede transformarlos / asignarlos a un esquema común en tiempo de ejecución y enrutar las solicitudes de servicio en función del contenido, por ejemplo, el espacio de nombres.
Sí, la orquestación es una responsabilidad, en la mayoría de los casos, del ESB. O, alternativamente, si traza una línea entre infra ESB y orquestación infra, entonces lo está haciendo en un nivel físico por razones de rendimiento, no por atribución lógica de responsabilidad.
Tiene 2 opciones: cuando, por ejemplo, un sistema de recursos humanos recibe un empleado nuevo, ¿dónde ubica la lógica empresarial que dice que "el departamento de cumplimiento deberá aprobar y verificar primero y luego, si está bien, el departamento de recursos humanos necesitará para finalizar el alquiler, entonces el departamento de contabilidad necesitará una nueva entrada, y luego el sistema de nómina necesitará actualizarse, y si eso falla, entonces tendremos que enviar un correo electrónico a HR "? Si el departamento / aplicación iniciador considera que todos los procesos comerciales son ''propiedad'', entonces el sistema general que es la empresa se vuelve complejo, con sistemas de orquestación dispares.
La segunda opción es centralizar la orquestación, esencialmente convirtiéndolo en un socio lógico de la plataforma de mensajería. Si elige ver estos artefactos por separado, depende de usted, pero es igualmente válido describirlos como ESB.
No, la responsabilidad de un ESB no es la orquestación de servicios (per se). El ESB proporciona una capa de abstracción en el "nivel de infraestructura de software".
Esto significa que un ESB es un "único puerto de llamada abstracto y lógico para la conectividad" con cualquier servicio que se publique en el bus.
El ESB es abstracto, significa que los consumidores de servicios en el autobús, no "necesitan saber" detalles de la implementación del servicio, y es posible exponer "servicios internos" con un único modelo de documento. El ESB proporciona servicios de bajo nivel (como la traducción de protocolos y la transformación de mensajes) para que los servicios internos puedan comunicarse de forma simplificada.
Esto implica cierta orquestación: el ESB proporciona la orquestación de los servicios de bajo nivel antes mencionados (por ejemplo, cuando el servicio X se llama a través de IIOP, tradúzcalo a SOAP con Anexos. Luego, transforme la solicitud de cualquier dato serializado a una carga XML).
La orquestación que normalmente evitaría en un ESB es: Para procesar esta venta (de seguro), primero debemos validar la información proporcionada por el comprador, luego debemos garantizar el riesgo de seguro y, finalmente, calcular la prima que necesita. para ser pagado por el seguro, después de lo cual tenemos que ... etc.
Los pasos descritos anteriormente son claramente un proceso comercial (que incluso podría verse interrumpido ... por ejemplo, si la suscripción automática no es posible, entonces un suscriptor humano necesita evaluar más el riesgo).
Los Servicios Comerciales (por ejemplo, Validación, Suscripción, Cálculo Premium) que conforman un Proceso Comercial (por ejemplo, Venta de Seguro), que es lo que comúnmente se conoce como Orquestación, se pueden realizar en un Motor de Proceso de Negocio y se definen mediante un Proceso de Negocio formalizado Lenguaje de modelado (como BPEL).
También adivinando los muchos pasos de su proceso: en el ejemplo anterior, la Validación es un servicio (de curso completo). Las reglas de validación son internas a ese servicio. Para reglas comerciales complejas (es decir, no procesos comerciales), puede ser necesario el uso de un motor de reglas empresariales.
Un Enterprise Service Bus nunca debería ser responsable de la orquestación de servicios.
La orquestación implica un mínimo de "inteligencia", específicamente la capacidad de compensar las transacciones fallidas. Las herramientas de bus de servicio a menudo dicen que ofrecen "try-catch" o algo así, pero la capacidad de ejecutar componensación con ámbito es la marca de una herramienta de orquestación adecuada. Además, la capacidad de esperar, conocer su propio estado o mantener las cosas en suspenso es otro indicador de que se trata de un orquestador y no de un autobús.
Hablando de más de 1000 pasos más docenas de servicios, considere los if-then en el proceso. Si todas las declaraciones if-then en tus 1000 pasos solo se refieren al enrutamiento sin cambios en las cargas útiles, entonces aún estás en "enrutamiento" y, por lo tanto, aún en ESB. Pero si hay un solo anidado , entonces, y empiezo a buscar diferentes herramientas. Además, si los que se parecen al enrutamiento pueden afectar rápidamente la lógica empresarial. Una vez que la lógica comercial comienza a aparecer, un mejor lenguaje, como BPEL o BPMN, es mejor.
El ejemplo de un director de orquesta a menudo se da para describir cómo funciona la orquestación, un individuo central que dirige a los músicos según un puntaje. A menudo, lo que queda es la idea de que el conductor no solo está dirigiendo, sino también escuchando, y si algo sale mal, puede compensar de manera confiable y repetible.
Por ejemplo, imaginemos que nuestro primer conductor va a traer al jugador de tuba, pero dicho jugador de tuba ha decidido hacer otra cosa. Un simple "orquestador" estilo pinball traerá la sección de tuba, sabiendo muy bien que no está allí, y luego esperará a que la audiencia se queje más tarde. Un conductor realmente hábil vería desaparecer la tuba e inmediatamente subiría los profundos cuernos de barítono para compensar.