Pregunta

es un bus de servicios empresariales (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 esas cosas) responsable de organizar los servicios ?

¿Qué pasa con poner un proceso 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.

¿Fue útil?

Solución

Sí y no. Hay una línea delgada, ya veces indistinguible, entre la orquestación y la agregación / aumento de servicio.

En general, si tiene algún proceso comercial complejo o de larga duración (proceso es la palabra clave, aunque voy a evitar definirlo), eso es lo más adecuado para BPEL.

Las tareas simples, como la agregación de los resultados de tres llamadas de servicio, podrían y a menudo deberían realizarse en una capa ESB.

Sin embargo, no vale la pena perder demasiado sueño

Descargo de responsabilidad: soy consultor de IBM ESB, aunque no estoy escribiendo esto a título oficial.

Otros consejos

No, la responsabilidad de un ESB no es la orquestación de servicios (per se). El ESB proporciona una capa de abstracción a nivel de "infraestructura de software".

Esto significa que un ESB es un "puerto lógico abstracto de llamada para conectividad". con cualquier servicio que se publique en el bus.

El hecho de que el ESB sea abstracto significa que los consumidores de servicios en el autobús no "necesitan saber". detalles de implementación del servicio, y es posible exponer "servicios internos enfrentados" con un solo modelo de documento. El ESB proporciona servicios de bajo nivel (como traducción de protocolos y transformación de mensajes), de modo que los servicios internos pueden comunicarse de manera simplificada.

Esto implica cierta orquestación: el ESB proporciona la orquestación de los servicios de bajo nivel mencionados anteriormente (por ejemplo, cuando se llama al servicio X a través de IIOP, traduzca esto a SOAP con archivos adjuntos. Luego transforme la solicitud de cualquier dato serializado a una carga útil XML).

La orquestación que normalmente evitaría en un ESB es: Para procesar esta venta (de seguros), primero debemos validar la información proporcionada por el comprador, luego debemos suscribir el riesgo de asegurar y finalmente calcular el prima que debe pagarse por el seguro, después de lo cual necesitamos & # 8230; etc.

Los pasos descritos anteriormente son claramente un proceso comercial (que incluso podría interrumpirse & # 8230; por ejemplo, si la suscripción automática no es posible, entonces un suscriptor humano necesita evaluar aún más el riesgo).

Los Servicios comerciales (por ejemplo, Validación, Suscripción, Cálculo de primas) que conforman un Proceso comercial (por ejemplo, Venta de seguros), que es lo que generalmente se conoce como Orquestación, se adaptan mejor a un Motor de procesos comerciales y se definen utilizando un Lenguaje de modelado de procesos de negocio formalizado (como BPEL).

También adivinando los muchos pasos en su proceso: En el ejemplo anterior, Validación es un servicio (por supuesto). Las propias reglas de validación son internas de ese servicio. Para reglas comerciales complejas (es decir, no procesos comerciales), puede ser necesario el uso de un motor de reglas comerciales.

Mi respuesta rápida y breve es NO, esa no es su responsabilidad.

Prefiero dejar eso en BPEL o en una suite BPM.

Mhh, no sé qué más añadir :) ... ¿Buena suerte?

Ahora mi propia visión.

Con respecto a todo el trabajo que tiene que hacer un ESB, poner la orquestación de servicios dentro del elemento de infraestructura principal de su SOA no es una buena idea.

Agregado, ¡ok! Pero mantener su canal de comunicación ocupado con la lógica de negocios, sin duda, causará un impacto terrible en la capacidad de ofrecer otras funciones.

Después de todo, la mayoría de los ESB , como BEA Aqualogic Service, tienen un soporte limitado para la orquestación que incluye falta de capacidades con estado y actividades como esperar (un temporizador) o elegir (esperar que se mueva alguna entrada en el proceso), capacidades de división / unión (ya agregadas en ALSB 3.0), y así sucesivamente.

De ninguna manera. Simplemente use herramientas como un motor BPEL o una herramienta como Weblogic Integration.

Gracias.

Siempre que tenga dos o más servicios que interactúen, use el orquestador de servicios, es decir, para 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 el orquestador y vuelva a exponer en esb. Utilice esb como mecanismo de prestación de servicios y agente de servicios web y proxy. Al componer un servicio, el orquestador usará esb para llegar a los servicios interactivos. Si estos servicios interactivos usan esquemas xml incompatibles, esb puede transformarlos / asignarlos a esquemas comunes en tiempo de ejecución y enrutar solicitudes de servicio basadas en el contenido, p. espacio de nombres

Sí, la orquestación es responsabilidad, en la mayoría de los casos, del ESB. O, alternativamente, si trazas una línea entre ESB infra y la orquestación infra, entonces lo estás haciendo a 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 nuevo empleado, ¿dónde coloca la lógica de negocios que dice "el departamento de cumplimiento deberá aprobar y verificar primero, y luego, si está bien, el El departamento de recursos humanos deberá finalizar la contratación, luego el departamento de contabilidad necesitará una nueva entrada, y luego el sistema de nómina deberá actualizarse, y si eso falla, entonces tendremos que enviar un correo electrónico a recursos humanos '' 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éndola en un socio lógico de la plataforma de mensajería. Si elige verlos como artefactos separados, eso depende de usted, pero es igualmente válido describirlos como ESB.

Un Enterprise Service Bus nunca debe ser responsable de organizar los 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 por el estilo, pero la capacidad de ejecutar una composición de á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 si-entonces en el proceso. Si todas las declaraciones if-then en sus 1000 pasos hablan solo de enrutamiento sin cambios en las cargas útiles, entonces todavía está en '' enrutamiento '' y por lo tanto todavía en ESB. Pero si hay incluso un anidado if-then y empiezo a buscar diferentes herramientas. Además, los if-thens que parecen enrutamiento pueden impactar muy rápidamente en la lógica empresarial. Una vez que la lógica de negocios 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 una partitura. A menudo, lo que queda es la idea de que el conductor no solo dirige, sino que también escucha, y si algo sale mal puede compensarlo de manera confiable y repetible.

Por ejemplo, imagina que nuestro primer conductor va a traer al jugador de tuba, pero dicho jugador de tuba ha decidido hacer otra cosa. Un simple orquestador de 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 inteligente vería que la tuba se había ido e inmediatamente sacaría los cuernos de barítono más profundos para compensar.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top