MARMOT核心整合原理

在引入DORADO时，开发商可能并不希望自己的业务逻辑层的实现代码与之发生耦合。因此往往需要在原有的核心代码与第三方产品之间建立一个胶合层，利用这层代码完成对第三方产品的集成工作。这里的胶合层应该是轻量的、灵活可配的。在实现此胶合层的过程中，Spring作为一个成熟的、被广泛认可的IOC框架应当是一个很自然的选择。另一方面，随着技术的发展，基于Struts、WebWork、Spring、Hibernate、iBatis等开源框架的开发模式正被越来越多的开发商所接受。当他们又要引入一个DORADO来增进前台的展现能力时往往会无从下手，弄不清框架中的各个部件应该如何与DORADO协调合作。MARMOT填补了这个空缺，使DORADO与各种后台框架能够很好的进行协调配合。

MARMOT提供了DORADO展现层中间件与后台业务逻辑层框架的无缝整合方案，并提供源代码。如果与项目需求匹配度高，可以直接使用MARMOT，如果有差距，可以在其基础上修改，或者至少可以当成一个范例来看。

具体说来MARMOT是包括展现中间件dorado、业务对象层框架Spring、数据持久层框架，流程引擎、权限框架、企业服务总线，以及报表工具、门户引擎、规则引擎、页面控制层框架等以松耦合集成形式形成的大型Web应用系统的开发平台与运行平台。

在MARMOT没有出现时，我们可以把下图想象成传统开发模式与DORADO之间的关系。

（图：尚未集成的框架）

如图所示，其中的Business Logic代表开发商现有的业务逻辑代码。而DORADO包含了服务端引擎和客户端引擎两部分，这两个部分是密切相关，相互配合的，他们共同完成了表现层的功能。与业务逻辑的对接将主要通过与DORADO Server Engine之间的交互来完成。

基本的集成思路大致如下。

（图：基本的集成思路图）

如上图，DORADO Server Engine与Business Logic直接的通过Spring来起到承上启下的作用。而在DORADO的Server Engine和Client Engine之间我们也可以看到一些变化，那就是控制层的引入。

对于AJAX应用而言在操作的过程中客户端存在着大量的远程过程调用(RPC)，这里的RPC并不是我们通常意义上所说的Server-Server的远程调用，而是指从浏览器客户端到服务端，利用JavaScript中的iFrame或XMLHttpRequest完成的方法调用。这些来自客户端的RPC请求，需要类似Servlet这样的对象来接收和处理。在上图中可以看出，我们利用了开源控制层框架(Spring MVC、Struts、WebWork)来处理这些请求。使用这种方式主要基于如下的考虑：

l  这些是应用非常广泛的产品，开发商原有的开发框架中极有可能已经使用了其中的某一个，在这种情况下没有必要为RPC请求单独注册一组Servlet。

l  目前的技术人员可能已经常常熟悉其中的某种框架，他们可以在MARMOT中直接选择他们熟悉的框架来使用，这有利于他们更快的了解MARMOT运转机制。

这些框架往往都提供了很完善的配置方案和扩展机制。例如其中的Spring MVC和WebWork都能很好的利用AOP机制来辅助功能扩展。

回到前面的话题，在集成Business Logic、Spring、DORADO、Controller的过程中我们需要一些代码和配置来完成整个工作。MARMOT为我们填补了这些空缺。

（图：MARMOT在集成过程中的作用）

MARORT应用框架正是基于上述基础架构之上开发的一套包含WEB应用系统常见功能的应用框架，开发人员可以将MARMOT作为软件开发的基础，对于MARMOT没有的功能，开发人员也可以方便的进行扩充。

MARMOT各层框架的选择

       表现层框架是展现中间件dorado。dorado支持OPOB设计模式、迭代式表现层MVC架构与视图建模，丰富的控件库Widget Lib由BRICH引擎统一驱动，内置AJAX通讯引擎、数据抽象集合是其一大特色、此外还提供国际化、表现层角色控制、外观皮肤切换等辅助功能。对于复杂页面，传统JSP中代码很长很复杂，不利于项目开发，更不利于上线后的维护。基于dorado的复杂页面，JSP中只保留TagLib的声明代码与排版代码，复杂的部分被剥离出来放到一个XML中。一些特效，如表格行通过鼠标drag&drop进行表格行拖动，已在控件中实现，开箱即用。因此基于dorado建设J2EE Web应用，开发迅速，维护方便。

业务对象层框架选择的是Spring。Spring是基于依赖注入（DI）设计模式等设计的BO层框架，采用XML格式的文件来指定业务对象之间的关系。Spring的作者在编写Spring之前先是写了一本书介绍其设计思想，这种“兵马未动粮草先行”的做事风格值得称道。

数据持久层框架是对象关系映射框架，对JDBC进行轻量级的对象封装，负责Java对象和关系数据库之间的映射的ORM，使用对象编程思维来操纵数据库，自动化或半自动化地完成数据持久化功能、POJO 与SQL之间的映射关系等。通常采用XML格式的文件来指定对象和关系数据之间的映射，在运行时，根据这个映射文件来生成各种SQL语句，使应用程序可以在不同数据库平台下迁移。数据持久层框架选择的是Hibernate与iBatis。前者是“全自动”ORM 实现，后者是半自动的。

权限框架选择的是Acegi。Acegi是为基于Spring的应用提供的声明式安全框架。它通过在Spring的应用上下文中配置一系列的Bean完成安全设置，完成利用了Spring提供的依赖注入和IoC编程方式。为了保证Web应用的安全需求，Acegi使用过滤器拦截servlet请求，并执行认证来执行安全措施。 Acegi通过安全方法级调用来执行更低层次的安全需求。通过使用Spring的AOP，Acegi使用代理对象来确保用户有适当的权限来调用被保护的方法。无论是较高层次的Web应用的安全，还是较低层次的方法级安全，Acegi都可以通过四个主要组件完成安全需求。 Security Interceptor 用于拦截那些需要访问受保护资源的请求。 Authentication Managers 用于验证主体的身份，如principal(典型的如用户名)和Credentials（典型的如密码）。能过验证，可以证明Who are you 。 Access Decision Mangers 用于决定已验证通过的principal是否有访问受保护资源的特权。 Run-as Managers 用于在通过验证和并得到授权之后，对访问资源进行更多的安全约束。

流程引擎既可以WfMC标准，也可以是BPEL标准。WfMC（Workflow Management Coalition，工作流管理联盟）是创建于1993年8月，由工作流软件供应商、用户、大学以及其他研究团体共同组成的一个非盈利性的国际组织。其任务是制订标准推动工作流管理的应用和发展，统一工作流软件术语，加强工作流产品供应商之间的协同工作与联系。WfMC对工作流（Workflow）的定义是：自动运作的业务过程的部分或整体，表现为参与者对文件、信息或任务按照规程采取行动，并令其在参与者之间传递。简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。BPEL（业务流程执行语言Business Process Execution Language）是一门用于自动化业务流程的形式规约语言。 用XML文档写入BPEL中的流程能在Web 服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。通过允许顾客们在各种各样的创作工具和执行平台之间移动这些流程，BPEL使得他们保护了他们在流程自动化上的投资。WfMC更接近于人机交互，倾向于审批流转型Workflow；BPEL更接近于数据与服务，倾向于自动执行型Business Process。近年来支持BPEL标准的厂商在其产品中增加了Human Task，以适用审批型需求。

企业服务总线选择的是IBM WebSphere Process Server。ESB (Enterprise Service Bus，企业服务总线)是为分散服务提供交互、组合和治理，是实现SOA的基础架构。ESB支持多类信息服务(multiple messaging services)，提供不同格式数据的转换引擎，事件通知功能及注册及储存(registry/repository)功能。

报表工具、门户引擎、规则引擎、页面控制层框架等都可以根据实际需求灵活选择。