串讲ApacheOFBiz技术架构



从决定读ApacheOFBiz源码到现在不知不觉一年就过去了。这一年因为各种原因,导致源码读得断断续续。其实最大的问题还是因为无法深刻得理解里面的一些东西,导致热情骤减。直到最近,公司在开发的一个“应用快速开发平台”引发了我的一些思考,所以决定再把源码拿出来重新阅读。到最近对其架构设计近乎迷恋。



个人认为对于ApacheOFBiz的剖析可以分成三大块来进行:技术、业务、数据库设计。这三块个个都是非常顶尖的水准,每个方向深入进去都可以学到很多东西。之前只是对OFBiz各个部分的单独解析,现在是时候写一篇文章来串讲它的各个部分。当然,这篇主要还是涉及到OFBiz的技术这一块。

# 框架简介



这张图是OFBiz的整体框架图。从图中可以看到OFBiz的所有app都构建在其framework之上。而其framework的核心就是ServiceEngine(服务引擎)以及EntityEngine(实体引擎)。其实体引擎对于数据库的种类以及拓扑结构的支持都非常健全。它支持本地数据库与远端数据库并存并且支持多达8种主流数据库。

# OFBiz技术串讲

下面以一个客户端请求的处理过程来看OFBiz各个组件是如何交互以及衔接的。



(1)客户端浏览器向web服务器发出一个请求(http/https),请求会被web容器接收并作相应的处理(比如参数的封装等)。
(2)请求被路由到一个代理servlet中,该servlet会分析请求是发往哪个app的,然后再到该项目的下的controller.xml配置文件中去匹配request-map配置项,该配置项用于只是OFBiz如何处理这个请求。通常的处理过程是先进行安全检查以及权限确认,然后触发某个“事件”或者服务调用,最后会以一个view作为响应。如果是以一个view作为响应的话,OFBiz会去view-map中匹配该视图,每一个视图view都有它对应的handler。
(3)OFBiz会用配置的handler来处理该view。handler的作用主要用于渲染页面元素,并将需要展示的数据跟页面元素合并。
(4)数据准备。前端的请求归根到底还是请求对后端数据的操作。而ofbiz中用于获取数据的方式十分丰富。考虑到这里对业务逻辑而言,是代码量占比很大的地方,因此OFBiz尝试利用动态语言来编写这部分代码。主要是想利用动态语言的简洁、代码量少、快速开发的优势。随着java语言的发展,OFBiz选择并且替代了多种不同的JVM脚本语言,比如:beanshell,Groovy。采用脚本语言来编写跟操作实体相关的业务逻辑代码,可谓有利有弊:
> 弊端:动态语言(弱类型语言)固有的类型安全性的缺失以及纯解释执行性能跟Java这种解释+编译型语言还是无法比拟。
>
> 优势:大量传统行业,不需要那么高的性能要求;即便需要也可以用提升硬件来改善;脚本语言在编程效率、逻辑简洁性都是Java冗长的代码所望其项背的;脚本语言更贴近人类语言的表达,更适合实现DSL,来表述业务逻辑(而且OFBiz的下一步目标也将增强对Groovy实现DSL的支持)。(5)OFBiz的viewhandler通过模板引擎绑定页面元素与数据后,渲染出最终的输出流,通过http响应给客户端浏览器。

# 页面渲染

Apache OFBiz使用XML+Widget的布局,来将页面切分成一个个Widget以增强各个widget的灵活性以及复用性。



这些widget可以互相嵌套形成一个decorator-widget产生模板,在widget可以直接编写html标签,或者引用各种服务端模板引擎支持的模板文件(比如freemaker)。

前端的内容通常是HTML+数据。widget并没有忽略数据这部分。只是一种布局技术,它最终会由webcontainer转化为html,只不过数据的处理(CRUD)通常位于服务器端。而这些动作都被抽象成为了widget中的“action”。一个screen通常包含各种其他组件widget的引用,这些组件widget可以是:form,screen,menu等。

# 权限检查

OFBiz中采用的是角色+安全组的授权模型。



从图中可以看出常用的几个权限有:_ADMIN(管理员权限),_VIEW(浏览权限,为最小权限),_CREATE(创建权限),_UPDATE(编辑权限),_DELETE(删除权限)。因此如果controller.xml中配置了授权检查时,将会进行上图的权限检查流程。一个请求在处理之前,会检查其是否需要先进行登录。如果登录验证通过,会获取该会员的security group。而security group又是security permission的集合。进而可以判断用户是否有某个操作的权限。

# 请求事件

因为OFBiz使用了公共代理的servlet,因此对每个请求而言,其处理逻辑就没有独享的servlet了。这里OFBiz引入了Event的机制来处理每个请求需要执行的特定的操作逻辑。



每收到一个请求,如果有特殊的处理,就触发一个event。上图是event的触发机制。它的配置在controller.xml文件下的request-map配置项内。

# 服务引擎

OFBiz执行服务基于其自身实现的服务引擎框架。该服务引擎借鉴了《CoreJ2EE Pattern》里的“BusinessDelegate”模式。



调用程序通过服务引擎框架调用服务后,服务引擎首先将调用服务的参数提取并构建服务调用的上下文。然后选择合适的dispatcher,它其实就是businessdelegate。由他选择合适的引擎来执行服务。OFBiz会先判断服务有没有“特殊性”,比如它是否是异步的?是否是递归执行的。如果是,那么会选择它内置的JobScheduler来执行。还有它是否是带SECA(ServiceEvent Control Action)的?如果是SECA,那么会先执行SECA然后选择已配置的特定引擎来执行真正的目标服务,而在这个过程中会有一个Map来充当执行的上下文,用于存储中间结果、错误信息以及最终结果。执行完成之后,上下文对象会在调用栈中层层回退,并将最终的执行结果返回给调用端。

# 服务事件控制响应器
所谓SECA是Service Event Control Action的单词首字母的缩写形式。可以简单得理解成“服务编排”(可能会执行多个服务,但是某些服务需要满足特定的执行条件)。

比如上面一个带SECA的服务X,在服务引擎执行之前,会先处理其ECA(这里先调用一个action,它需要执行服务B)。当ECA处理完成之后,会将控制权返回给执行引擎。执行引擎会根据服务B的执行结果来判断是否会调用真正的服务X。SECA被用于在OFBiz中替代了其原有的规则引擎以及工作流引擎,可见其灵活性是足以满足复杂业务支撑的。

写在最后

更多的技术分析,请看之前的系列文章以及后续的持续更新。
<div  style="padding-top:20px">         

版权声明:本文为博主原创文章,未经博主允许不得转载。

</div>