工作流、soa以及esb

最近公司项目经理派我研究工作流并考虑在项目中使用。很有一些心得。工作流应用我将之分为狭义工作流和广义工作流。对狭义工作流而言,你可以将之理解为在工作流设计器里画画节点以及方向箭头,设置好就节点数据,动作就差不多了。(具体可以参见jbpm的websale这个demo)。

广义的工作流是对服务之间的整合。核心问题是业务节点和工作流节点之间的映射,以及业务数据和工作流数据之间的映射,和普通工作流一样还有流程判断等等服务。实现了这些,各个业务模块之间的数据就可以通过服务,以定好的方式(进行方向控制和格式转化)在各个节点之间流通,达到了服务整合的目的。


 

  IBM为ESB定义了四个必备的功能:“路由器”——根据信息内容,在不同应用和服务之间进行信息传输和路由;“转换器”——进行应用之间的通信协议转换;“翻译机”——进行应用之间的消息格式转换;“收发室”——处理来自不同渠道的业务事件(同步传输,异步传输,发布/订阅等方式)。

  其中“路由器”和“收发室”都是针对服务的重用而设计的,而“转换器”和“翻译机”则专门用来解决异构的通信问题。

  针对重用和异构这两个难题,倪晓兵认为ESB提供了两个核心的功能,服务的管理和数据的转换。


我们DEC项目的目标就是建立一个全能服务仓库(暂时我在DEC设计人员zy哪里得到的信息),而服务之间如何路由,如何转换,语义的协调都没有考虑,而后者却是成败的关键。

最关键的语义翻译这一点,就现在的技术上来说还不能做到(需要很高的机器智能才能达到使得不同的系统的业务词汇可以正确的映射,更何况是在所有的系统之间进行映射,同时应用在企业级的应用环境中)

也许真的有这样的幻想,但是真的能够做到这一步么?我深深的怀疑。就目前的技术手段,如果要达到数据映射的高度正确性,必须由人不同系统之间需要协调的数据进行语义确认方能进行有效的映射。

当考虑到还必须做到ESB系统对其接入的所有的服务数据的语义都这样做时。我怀疑真的需要做到协调所有的服务么?

也许ESB的应用范围就是在公司内部或者有限范围内的整合目标明确的业务节点之间业务的整合。
        

posted on 2008-04-11 17:11 wanglin 阅读(675) 评论(1)  编辑  收藏

评论

# re: 工作流、soa以及esb 2008-04-11 17:22 wanglin

而为了真正达到服务之间的松耦合。有一个很重要的问题需要解决:业务流程谁发起?还有一个比较次要的问题:开始服务节点和工作流之间的关系互动关系。其他的流程稍微简单一点。

初始我考虑使用定时器轮训各个开始节点的服务。考虑到性能原因就放弃了。也许更可行的方案是ESB在应该有一个客户端去配置监控各个服务节点,并主动向ESB提交服务,同时接受服务回馈。

不存在一种对现有模块零要求的整合,这也许是最少侵入性的方案了。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 
<2008年4月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

导航

统计

常用链接

留言簿(1)

随笔档案

搜索

最新评论

阅读排行榜

评论排行榜