2009-08-12 13 views
8

¿Cuáles son las responsabilidades de un motor de orquestación frente a un sistema controlado por mensajes?Orchestration vs Message Driven Architecture

Si tengo que construir un sistema que tenga que encadenar diferentes componentes independientes (componentes de tecnología cruzada/plataforma que no necesitan exponer un punto final del servicio web), ¿cuál es el conjunto de herramientas que se debe elegir?

¿Existe una opción mejor?

Respuesta

0

Si bien esta pregunta está etiquetada con Java, me temo que la mejor herramienta que he visto si realmente tiene que seguir esta ruta es Microsoft's BizTalk Server.

Cuando tuve que hacer una evaluación de este tipo de producto (y esto fue hace unos años) era muy por encima de la competencia con las principales características ser:

  • Visual Studio como el desarrollo
  • ambiente agradable
  • herramientas visuales para describir los flujos de trabajo y las transformaciones
  • arquitectura extensible conector utilizado para conectar a los participantes
  • potente motor de flujo de trabajo con la presentación de informes en tiempo real
  • gran

Al final elegimos keep-it-simple y seguimos la ruta de mensajes, aunque esto requiere que tenga el control de todos los participantes, lo que puede no ser el caso.

2

Utilice openESB con el editor netbeans o cualquier otro motor BPEL de código abierto que proporcione una forma estándar u orquene el proceso. Si considera que el rendimiento es muy importante que la estandarización, puede probar algunas herramientas patentadas de ESB o BPM como JBoss jBPM o mula ESB, etc.

Tenga en cuenta que BPEL solo puede usarse para consumir servicios web si sus componentes no son servicios web. es posible que deba utilizar algún ESB como Mule, que puede admitir más de 200 protocolos con extensiones.

1

Al decidir si debe usar orquestación o flujo de trabajo orientado a mensajes, la gran pregunta que enfrenta es, ¿cree que será necesario cambiar el flujo de trabajo de su orquestación de forma regular. Si cree que Business Process necesita ser flexible porque está sujeto a cambios, adopte un formato de mensaje canónico y utilice Orchestration, lo que minimizará el impacto de las relaciones cambiantes entre los servicios. Si cree que el flujo de trabajo es estable, puede adoptar un flujo de trabajo impulsado por mensajes. Personalmente, creo que Orchestration es el enfoque superior en general, sin embargo, requiere más infraestructura de software que con herramientas como Apache Camel la inversión es el tiempo con la recompensa de una mayor flexibilidad a largo plazo.

0

Le sugiero que primero exponga sus componentes independientes individuales como servicio a través de la web (no entendí si ya tiene servicios web para esto). Después de eso ... la mejor opción depende de la carga de trabajo/complejidad de su sistema.

Básicamente puede elegir entre servicio Orquestación vs Coreografía. Service Orchestration, hecho con BPM/BPEL/ESB, es una elección arquitectónica donde un componente único (el orquestador de servicios/compositor de servicios) sabe qué pasos se deben ejecutar y es responsable de invocar servicios en el orden correcto (configurado en el propio orquestador) . También maneja la gestión de transacciones (si es necesario).

Lo opuesto es Coreografía donde, de hecho, cada servicio individual que compone todo el sistema sabe cómo actuar cuando recibe un mensaje específico. De hecho, es una cuestión de acuerdo entre los diversos componentes. Coreografía de servicio es un enfoque descentralizado al problema de la composición del servicio.

En caso de que tenga muchos servicios, reglas complejas, etc. probablemente sea más fácil usar un orquestador de servicios como jBPM o algo así.