业务流程与消息驱动架构

时间:2009-08-12 08:13:16

标签: java soa orchestration

Orchestration引擎与消息驱动系统的职责是什么。

如果我必须构建一个系统,必须将不同的独立组件(不需要公开Web服务端点的交叉技术/平台组件)串联起来,这是要选择的工具集吗?

有更好的选择吗?

4 个答案:

答案 0 :(得分:2)

将openESB与netbeans编辑器或任何其他开源BPEL引擎一起使用,这些引擎提供标准方法或编排流程。如果您认为性能比标准化非常重要,您可以尝试一些专有的ESB或BPM工具,如Jboss jBPM或mule ESB等。

请注意,如果您的组件不是Web服务,则BPEL只能用于使用Web服务,那么您可能必须使用某些ESB,如Mule,它可以支持大约200多个带扩展的协议。

答案 1 :(得分:1)

在决定是否应该使用Orchestration或Message Directed工作流程时,您面临的最大问题是,您是否认为有必要定期更改您的业务流程工作流程。如果您认为业务流程需要灵活,因为它可能会发生变化,那么采用Canonical Message格式并使用Orchestration,这将最大限度地减少他对服务之间关系变化的影响。如果您认为工作流程稳定,您可以采用消息驱动的工作流程。我个人认为Orchestration一般来说是一种优越的方法,但是它确实需要更多的软件基础设施,而Apache Camel这样的工具投资是时间,可以增加长期灵活性。

答案 2 :(得分:0)

虽然这个问题被标记为Java,但我不敢说我​​见过的最好的工具,如果你真的必须走这条路是Microsoft's BizTalk Server

当我不得不对这类产品进行评估时(这是几年前),它在竞争中处于领先地位,其主要特征是:

  • Visual Studio作为开发环境
  • 描述工作流程和转换的不错的可视化工具
  • 用于连接参与者的可扩展连接器架构
  • 功能强大的工作流引擎,具有出色的实时报告功能

最后,我们选择 keep-it-simple 并进入消息传递路径,尽管这确实需要您控制所有参与者,但情况可能并非如此。

答案 3 :(得分:0)

我建议你首先通过网络将你的单个独立组件作为服务公开(如果你已经有了web服务,我不明白)。 之后......最佳选择取决于您的系统工作负载/复杂性。

基本上,您可以在服务编排与编排之间进行选择。使用BPM / BPEL / ESB创建的Service Orchestration是一种架构选择,其中单个组件(服务协调器/服务组合器)知道需要执行哪些步骤,并且它负责以正确的顺序调用服务(在orchestrator本身上配置) 。它还处理事务管理(如果需要)。

相反的是编排,其中构成整个系统的每个单一服务都知道如何在收到特定消息时采取行动。事实上,这是各个组成部分之间的协议问题。服务编排是一种分散的服务组合问题方法。

如果你有很多服务,复杂的规则等等......可能会更容易使用像jBPM这样的服务协调器。

相关问题