作者:知乎用户
链接:https://www.zhihu.com/question/20146512/answer/33354578
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
融资租赁系统同四个子系统组成:贷前销售,贷前信审,合同管理,贷后管理。
ESB负责子系统之间的流程服务交互, WorkFlow负责子系统内部的流程流转。
<noscript>&lt;img src="https://pic2.zhimg.com/e6ad9a353e1958c89a11238dfd3b6d15_b.jpg" data-rawwidth="727" data-rawheight="623" class="origin_image zh-lightbox-thumb" width="727" data-original="https://pic2.zhimg.com/e6ad9a353e1958c89a11238dfd3b6d15_r.jpg"&gt;流程说明:</noscript>
流程说明:
1、贷前销售子系统的 业务申请作为第一个节点,会启动贷前销售子流程;
2、到 信用审核节点时, 通过ESB向贷前信审子系统的流程服务发消息,触发流程从 调查报告节点向下执行,审批通过后,回到贷前销售的 签署合同节点;
3、类似1~2的流程,直到所有流程结束
链接:https://www.zhihu.com/question/20146512/answer/33354578
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
1、服务总线(ESB)适合传统企业系统应用下系统间的小报文/短消息同步服务交互场景;
服务框架(Dubbo)适合互联网系统应用下系统间的小报文/短消息同步服务交互场景;
如果服务过少,不打算进行服务治理的话,其实无需ESB/Dubbo,直接选择WS即可。
2、MQ适合系统间的可靠小报文/短消息异步服务交互适合场景。如果允许小报文/短消息丢失的话,可以直接选择WS。
3、以文件方式直接传输适合系统间的大报文/长消息服务交互场景。
系统间服务交互的企业级ESB方案,分两个场景来说。
互联网系统应用场景,适合选择服务框架方案
通过接口分解系统耦合性,不同子系统通过相同的接口描述进行服务启用
服务框架是一个点对点模型
服务框架面向同构系统
实现技术举例:开源Dubbo
传统企业系统应用场景,适合选择服务总线方案
同服务框架方案一样,均是通过接口分解系统耦合性,不同子系统通过相同的接口描述进行服务启用
服务总线是一个总线式的模型
服务总线面向同构、异构系统
实现技术举例:开源ESB Mule,商业ESB Oracle OSB等
融资租赁系统同四个子系统组成:贷前销售,贷前信审,合同管理,贷后管理。
ESB负责子系统之间的流程服务交互, WorkFlow负责子系统内部的流程流转。
<noscript>&lt;img src="https://pic2.zhimg.com/e6ad9a353e1958c89a11238dfd3b6d15_b.jpg" data-rawwidth="727" data-rawheight="623" class="origin_image zh-lightbox-thumb" width="727" data-original="https://pic2.zhimg.com/e6ad9a353e1958c89a11238dfd3b6d15_r.jpg"&gt;流程说明:</noscript>
![](https://pic2.zhimg.com/e6ad9a353e1958c89a11238dfd3b6d15_b.jpg)
1、贷前销售子系统的 业务申请作为第一个节点,会启动贷前销售子流程;
2、到 信用审核节点时, 通过ESB向贷前信审子系统的流程服务发消息,触发流程从 调查报告节点向下执行,审批通过后,回到贷前销售的 签署合同节点;
3、类似1~2的流程,直到所有流程结束