云鹤平台Introduction of EEPlat in Chinese.doc

EEPlat说明1概述EEPlat是元数据驱动的多租户解决方案，是元数据、模板、JavaScript（Rhino）的开发及运行平台。EEPlat拥有领先的元模型体系，可以实现细粒度业务的定制和复用，一次开发配置可以适配多种环境(多种浏览器、智能移动设备)。 EEPlat可运行于多种云计算平台之上如（EC2、Google App Engine、Heroku）等，同时支持传统计算环境。EEPlat支持的系统包括：l MIS（管理信息系统）l OA（办公自动化）l CRM（客户关系管理）l HR（人力资源管理）l ERP（企业资源计划）l 社交化应用 EEPlat产品特点：l 可用：体现在已经经过很多项目、公司实际实用的检验。l 实用：体现在项目开发过程中极大提高生产效率、降低开发成本。l 易用：以配置代替编程，门槛降低，实现业务人员可直接参与开发。l 灵活： 通过工作流配置，灵活变动业务流； 通过服务配置，灵活变动程序逻辑和程序流； 通过页面配置，灵活变动页面外观； 通过业务对象配置，灵活增减业务实体属性；2 EEPlat多租户基础架构所谓元数据（metadata）即描述数据的数据(data about data)，在EEPlat中，对于描述业务系统(包括业务数据、逻辑和UI)的元数据我们称之为模型（model）或声明式业务对象 （Declarative Domain Object），下面图文中元数据、模型、声明式业务对象的概念可以互相替换，如下图：对于多租户的应用，不同租户的需求几乎都是有差异的，每个租户要求定制化他们的应用也是很自然的。如果这个多租户应用是静态编译的二进制文件，那么满足这些多租户的要求及其他个性化的挑战是几乎不可能的。然而，一个多租户的应用，必须在其功能、界面等方 面，满足不同租户的合理要求。基于这些原因，EEPlat PaaS应用平台可以根据不同租户定义的元数据生成相对应的应用程序，而不是采用经过编译的二进制的可执行文件。模型驱动开发是EEPlat的核心和基 础，在模型的基础上，EEPlat又进行了进一步的抽象，称之为元模型（metamodel）,这样又进一步提高了系统的灵活性和可扩展性。EEPlat执行引擎、基础功能元数据（通用模型）、每个租户的元数据（租户相关模型），每个租户的业务数据之间有一个明确的分离。这些明显的边界使我们可以安全得定制或修改租户的应用程序而不会影响其它租户。在下图中，我们把模型分为了通用模型和租户相关模型，在EEPlat的具体实现上，通用模型和租户相关业务几乎没有任何关系，只是为了完成模型本身的管理，和保持元模型的版本一致性。EEPlat PaaS应用平台可以分为三大部分：数据存储、元模型体系、执行引擎，下图是整体架构图：3元模型体系EEPlat拥有世界领先的元模型体系。元模型是声明式业务对象的模型，声明式业务对象由元模型描 述。EEPlat元模型体系是对企业信息化、电子政务等信息化领域业务的高度抽象，拥有自描述和动态扩展特性，能准确得完成业务领域模型的描述。 元模型从承担职责的角度分为功能元模型、业务对象元模型、服务元模型、规则元模型、工作流元模型、组织元模型、UI元模型等。业务对象元模型主要描述业务功能的静态结构，服务元模型主要完成业务逻辑，同时负责业务对象元模型之间的交互；工作流元模型主要完成业务流程及业务对象元模型的协作；组织元模型通过组织元模型之间的职责关系可以实现灵活的组织结构，UI元模型是菜单、面板、表格、表格元素、功能树等的UI模型的元模型，可以实现复杂的界面表现，如下图：3.1数据处理、业务逻辑、流程数据处理、业务逻辑及流程相关的元模型包括业务对象元模型、业务对象属性元模型、服务元模型参数元模型、规则元模型、流程元模型。 业务对象是业务数据和逻辑的抽象。在具体的实现上它通常对应数据库中的一张表，也可以表示更大或更小的业务范围，例如一个独立的业务模块（销售模块），一张表可以拥有多个业务对象，一个业务对象也可以包含多张表。 业务对象除了包含数据之外，还包括通过服务完成业务逻辑。不同业务对象之间的服务可以声明式调用。 数据总线是业务对象之间共享数据、交换数据的媒介。数据总线是线程独享的、线程安全的，一个线程对数据总线的改变不会影响到其他线程对数据总线的使用，每个线程都是使用的总线的副本。 业务对象属性指业务对象所拥有的属性。对于类型为基本表的业务对象，属性基本是相应表的列名。但是属性可以不对应列，列也可以不对应属性。属性可以是一个集合，如果为属性定义一个查询服务，属性对应的是该服务执行返回的集合。这种情况下一般用于处理业务对象之间一对多或多对多的情形。服务是描述业务对象的行为。当一个数据表被初始化为业务对象后，会形成多个基本的服务，包括了常用的增删改查等常见数据操作。服务的主体是一个增删改查的SQL语句和参数关联，可以修改这些SQL语句和参数关联达到个性化的目的。例如更改数据的状态，我们可以创建一个新的服务或修改缺省的服务，只更改该状态字段的值。服务可以通过规则引用一个或多个其它的服务。规则是为了完成复杂的业务逻辑而引入的概念。 规则的主体是定义一个有执行条件的服务，也就是只有当满足条件时才会执行相应的服务。规则的执行需要依附于服务。服务只有被完全执行时才执行服务所定义的规则。规则有执行优先级，当多个规则执行时，优先级越高执行的顺序越靠前。 参数的作用主要是从业务对象总线上获取对应的值。参数一般会关联属性，表格元素一般也会关联属性，表格元素被提交后存储于业务对象总线上FORM节点 的KEY指使表格元素关联属性的名称。从而，参数根据关联属性的名称从业务对象总线中取值，如果没有关联属性或根据关联属性没有取到值，则根据参数名称。 参数检查是指当服务执行操作前先检查服务对应的参数是否合法，如果不合法则不执行。参数检查可以自定义计算表达式、正则表达式、扩展脚本等。参数检查定义在参数上面，可以被多个服务所复用。工作流可以使业务流程自动化，工作流主要通过转移由节点组成。 工作流的启动，节点任务的提交和回退都是有服务触发，节点的执行也可以触发服务，这些服务可以是数据表的更改、业务逻辑的执行或者是发送EMail或SMS信息。自定义动作是平台功能的扩展，即为了完成平台不能配置的功能。自定义动作的应用场景有：1，服务使用自定义动作：这时服务的执行委托给自定义动作，不再执行服务定义的SQL语句；2，参数使用自定义动作，自定义动作的返回值为参数的值；3，编码使用自定义动作：自定义动作的返回值编码的值；4，平台提供的javascript callAction 的函数，直接调用自定义动作，完成前台和后台的直接交互等。其它无法完成配置的地方也可以通过脚本来实现。3.2用户界面EEPlat UI开创性的利用HMVC模式组织用户界面。用户界面可以划分为多个部分，每个部分又可以划分为多个部分，可以一直划分下去.。EEPlat对界面的这些部分进行了抽象出元模型，分别为面板元模型、表格元模型、表格元素元模型、菜单元模型、树元模型以及外部资源定义。面板为UI容器，可以包含面板、表格、菜单、树、资源。由于面板可以嵌套面板，所以可以形成复杂的界面布局。UI模型被显示时，需要定义控制器，控制器是EEPPlat UI部分的核心概念，EEPPlat中界面展示都是通过各种控制器控制输出的。传统的MVC模式，一个界面对应一个控制器，这个界面和控制器是粗粒度的， 这也是传统MVC模式在复用方面无法做到更细更深层次的一个根本原因。由于EEPPlat采用HMVC模式，使得界面层能够实现从粗粒度到细粒度的灵活的复用，也就是说从比较大的界面区域到最细粒度的界面元素都能够得到良好的复用支持。 例如一个查询页面包含的模型有：1，查询总面板（对应可滚动面板控制器）、查询条件面板模型（对应面板控制器），查询结果面板模型（对应面板控制器）；2，查询条件表格模型（对应查询条件控制器），查询结果表格模型（对应查询结果控制器）；3，若干个查询条件表格模型包含的表格元素模型（表格元素控制器的非常多，如录入框、下拉框、日期选择、日期显示等），若干个查询结果表格包含的表格元素模型（表格元素控制器的非常多，如录入框、下拉框、日期选择、日期显示等）。EEPlat缺省提供了100多的控制器，还可以自定义扩展，可以在线通过模板（FreeMarker）创新新的控制器而实现界面的个性化。如下图：下面对不用的元模型进行了描述：面板主要作用为了UI布局。UI布局可以是上下布局、左右布局，并且可以嵌套。 面板是一个容器，可以包含表格、功能树、菜单、资源等。当一个数据表被初始化为业务对象后，会形成多个基本面板，这些基本面板对应数据增删改查的相关界面，用户可以非常容易的扩展界面。表格是数据的重要展示方式，一般分为表单视图（常作为显示单条数据），网格视图（常作为显示多条记录）。 表格的显示结构由表格元素构成，显示数据由表格对应的服务执行后返回的数据填充。表格元素是组成界面的最小单位。基本的表格元素包括录入框，下拉框，按钮等。 一个表格元素可以包含一个或多个其它的表格元素。表格元素可以表现丰富的、复杂的界面。表格元素和数据的绑定依靠表格元素对应的业务对象属性的名称或表格元素的“重命名”。在平台运行状态下，通过表格元素可以得到一行完整的数据。树是数据的树形展示方式。一般树所展示的是层次结构的数据，树由节点构成，节点和节点之间是上下层次关系。一般节点需要定义一个服务，该服务对应的业务对象必须定义主键列和特征值列，树节点为该服务运行所返回的值。菜单是功能的索引。菜单一般连接一个面板，当菜单被点击时，面板会被展示给用户。菜单的样式有控制器显示。系统提供两种缺省的控制器OutLook风格和Tree风格，还可以扩展自定义自定义风格。资源也可以称为插件，在平台不能满足需求的情况引入自定义的JSP页面或者第三方的JSP文件，也可以是html文件、js文件、css文件、java文件、jar文件等其它格式的文件。4 多租户数据存储EEPlat支持下述方式的数据隔离技术：Sparce Column，tenantId字段隔离，每个租户独立数据库。1，Sparce Column， 和Salesforce Appforce l类似，主要通过一个通用表来存放所有自定义信息，里面有租户字段和很多统一的数据栏位（比如500个）。EEPlat通过租户分区的方式进行租户数据的查询优化。2，TenantId字段隔离。TenantId的字段隔离是为每个业务表加上TenantID字段，用以区分租户的数据。在这种模式下，一般用于系统的初始业务。而不是租户的自定义业务。3，租户独立数据库。对于MySQL数据库，创建数据库的开销比较小。租户独立数据库可以获得最大的安全性和可扩展性。当租户被激活时，EEPlat可以为每个租户创建自己独立的数据库，并初始化自己的业务表，并且EEPlat提供界面可供租户管理自己的数据。对于MySQL，租户独立数据库是EEPlat推荐的数据库隔离方法。5 EEPlat 手机支持EEPlat支持手机的基础是MetaData，拥有PC和Mobile两种界面引擎，一次配置，同时支持PC和Mobile，即可以根据同样的元数据生成PC和Mobile两种界面，也可以个性化定制Mobile界面。一套MetaData对应的不同设备显示，如下面几张图，第一张为PC界面的截图，后面几张为该UI在Mobile界面引擎下显示的效果。6 应用商店一般的SaaS应用商店中只是提供第三方应用的链接入口，应用间基本都是相互 割裂的，每个应用都是信息孤岛，无法互联互通，比如一个应用中决策需要另外一个系统的数据，但是无法导出和导入；还如，一个应用中有组织结构，另外一个应 用也存在，存在功能重叠的现象，由于两个系统独立得存在，也容易造成数据不一致; 另外还存在其它问题如多次登录、界面不统一，操作习惯不一致，数据分散等等。EEPlat的应用商店AppShare 不但解决了上述的问题，而且在应用间互联互通、软件复用、产业链分工等方面有更好的实践和思路，不同于一般SaaS应用商店只提供业务系统的链接入口，EEPlat中的应用可以分为三大类：6.1业务系统或模块业务系统和一般应用商店提供的业务系统类似，如CRM（客户关系管理）、ERP（企业资源计划）、 OA（办公自动化）、HR（人力资源挂历）等等。另外，这些应用可以不是一个完整的系统，也可以是系统的一个模块或辅助工具，例如公司A开发有OA系统， 公司B可以为OA系统开发会议管理模块。业务系统或模块基于EEPlat开发，运行于EEPlat提供的基础设施之上，应用可能来自不同的开发商，但是统一平台，统一登录，数据统一，操作习惯统一，界面统一；应用间数据互联互通。6.2组件组件和具体业务关联性弱，是平台本身功能的扩展，运行于EEPlat提供的基础设施之上。平台并不区分系统组件和自定义组件，默认组件和自定义组件的级别是等同的、可互换的。 组件包含后台通用处理动作、流程模板、报表模板、UI组件等。 后台通用处理动作基于EEPlat API，可以在某个特定场景下处理同类后台处理请求，如默认提供了批量保存、启动工作流、提交任务等通用处理动作。6.3基础服务基础服务和上两类应用不同，它可以不运营在EEPlat提供的基础设施之上，但需要按照EEPlat Open Api提