BOSENT 技术架构设计文档

welkinzz

贡献于2014-02-06

字数:58718 关键词: 电子商务/商城

 BOSENT技术架构设计文档 目录 1 概述 3 2 目的 3 3 项目背景 3 4 系统建设目标 3 5 参考资料 3 6 架构设计 3 6.1 设计思想 3 6.2 设计原则 4 6.3 架构模式 5 6.4 系统技术选型 8 6.5 系统架构选型 8 6.6 架构体系 9 6.7 模块划分 10 6.7.1 包结构(package) 10 6.7.2 框架(Framework) 12 6.7.3 服务引擎(Service Engine) 13 6.7.4 实体引擎(Entity Engine) 19 6.7.5 事务管理(Transaction Manage) 26 6.7.6 缓存机制(Cache) 30 6.7.7 日志管理(Logs) 33 6.7.8 任务调度(Task Scheduling) 38 6.7.9 迷你语言(Minilang) 40 6.7.10 页面工具(Webtools) 41 6.7.11 安全控制(Security) 43 6.8 模块接口 45 6.9 配置文件 45 6.9.1 基础配置文件 45 6.9.2 服务引擎配置文件 51 6.9.3 实体引擎配置文件 76 6.9.4 迷你语言配置文件 102 1 概述 2 目的 本文档主要介绍核心银行系统的开发平台BOSENT,从架构设计思想、技术架构模式、功能模块等方面阐述了BOSENT的技术架构。通过本文档能够大体了解BOSENT,从而进一步理解掌握BOSENT平台的架构。 3 系统目标 4 读者对象 本文档适合bosent开发人员、各bosent应用技术经理及相关人员。 5 参考资料 http://ofbiz.apache.org 6 架构设计 6.1 设计思想 1. 面向组件 1) 面向组件编程的缩写是COP,COP是对OOP的补充,帮助实现更加优秀的软件结构。 2) 系统是一个个的组件,通过定义组件之间的协作关系(通过服务)来完成系统的构建。这样做的好处是能够隔离变化,合理的划分系统。而框架的意义就在于定义一个组织组件的方式。 2. 面向接口 接口和实现分离是COP的基础,没有接口和实现的分离,就没有COP。接口的高度抽象特性使得各个组件能够被独立的抽取出来,而不影响到系统的其它部分。 1) 在模块/组件/对象之间解耦。 2) 轻松的抽换实现,而不用修改客户端。 3) 用户只需要了解接口,而不需要了解实现细节。 4) 增加了重用的可能性。 3. 面向服务 面向服务的体系结构(service-oriented architecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 6.2 设计原则 1. 基于各种标准 1) 很容易使用从类似的软件中获得的技能。 2) 很容易在同样的标准基础上重用已有的软件。 3) 很容易与其它内部或合作伙伴的系统整合。 4) BOSENT基于: Sun Java,J2EE, W3C XML,HTML,SOAP, WfMC XPDL,OMG GL,Party,Product,Workflow。 2. 全部应用都基于同样的框架、工具和组件 1) 不需要学习和使用很多不同的技术。 2) 不需要整合各种应用。 3) 不会因分立技术间的糟糕整合而在功能上受到限止。 4) 因为一致的和易于维护的组件而节省大量成本。 3. 基于灵活而通用的数据模型标准 1) 覆盖了所有主要的业务中使用的实体。 2) 提供了一个简单获得定制数据的结构。 3) 对实体名称使用通用术语,易于理解和使用。 4. 灵活而高效地使用数据层 1) 不倚赖数据库系统;支持许多不同的数据库。 2) 不需要写繁琐的存储代码和设置 。 3) 易于使用XML数据定义。 4) 强大的API提供了因数据定义不同而不同的通用操作。 5) 大部分操作能够用一行简单的代码实现,不需要写支持代码。 5. 松耦合多层组件结构 1) 易于定制和重用组件。 2) 易于通过已有组件的组合实现新的应用。 3) 易于找到基于同一样式的代码和其它组件。 4) 由于很好地定义和管理了依赖关系,所以能够在不破坏其它组件的情况下替换组件。 6. 分布式架构 1) 易于扩展到多台服务器或服务器池。 2) 易于与其它系统无缝整合和通讯。 7. 基于服务的逻辑层 1) 所有逻辑都作为服务建模。 2) 易于重用逻辑。 3) 服务能自动作为Web服务暴露出来。 4) 易于添加定制用户界面,甚至一次很多个。 5) 易于把系统分布到多个服务器上。 6) 易于与其它系统通讯。 8. 高级Web应用框架 1) 分离的输入过程逻辑、浏览数据准备逻辑和浏览呈现的模板。 2) 支持许多不同类型的逻辑,包括脚本语言和服务。 3) 支持许多不同类型的浏览模板,包括XML/XSLT、FreeMarker、Velocity、JSP等。 4) 基于安全和市场考虑,记录所有访问和页面点击。 5) 从服务器运行开始按时段保存流量和性能数据。 6.3 架构模式 类别 模式 结构 层 管道和过滤器 □ 黑板 □ 分布式系统 代理 □ 交互系统 模型-视图-控制器 表示-抽象-控制 □ 自适应系统 反射 □ 微核 □ 数据访问层 也称为是持久层,其功能主要是负责数据库的访问。在数据访问层中,BOSENT使用Entity Engine 作为其工具,并且能够满足99%与数据库交互的功能。有时在某些地方Entity Engine并不是有效的。这时就需要编写自定义的JDBC代码来与数据库交互。 业务逻辑层 是整个系统的核心,它与这个系统的业务(领域)有关。如果涉及到数据库的访问,则调用数据访问层。BOSENT使用Service Engine作为调用逻辑的工具。几乎所有的业务逻辑都被实现成服务,以便提高重用和使基于组件的开发更便利。可以同步或者异步调用逻辑,甚至将它们作为一个计划表来按时间调用。当调用一个服务时,不需要知道该服务的位置或者如何实现。这也就意味着可以使用多种语言来实现该服务。例如Java,BeanShell以及任何BSF编译脚本语言(python,jacl,javascript等等)。 通过Service Engine调用远端逻辑,可以通过不同机制包括HTTP,SOAP,JMS或者其他的机制,也可以通过创建一个简单的适配器来作为调用远端服务的调用机制。很明显,大多数时间需要在一个事务里包装一些服务,以便服务能够全部成功或者全部失败。 表示层 经过分离输入处理逻辑、浏览数据预备层以及浏览显示模板。这样不仅能够在WEB程序中重用逻辑,而且也独立于胖客户端程序。 数据处理逻辑 数据处理逻辑在controller.xml文件应该与请求(request)联系,而不是与视图联系。数据处理逻辑总的来讲被实现为一个服务,并且通过服务事件句柄调用,服务事件句柄会自动从请求参数(request parameters)或者属性中抽取数据,并将它从字符串类型转化成在服务定义文件所定义的对象类型。 有一些情况是数据处理逻辑不能实现为服务的。存在多种与请求关联的逻辑的其他类型事件句柄,这些句柄给你更多的请求上下文,但像服务那样不是环境未知的。 其中一个例子是接收上传数据。另一个好的例子是作一些特殊的前置处理和在传给服务处理之前的参数验证。注意到可以从这些自定义事件中调用服务。 浏览数据预备逻辑 浏览数据预备逻辑应该与视图模板联系起来。这个应该通过JPublish在页面定义XML文件定义动作来实现。当一个页面被分割为多个模板,数据预备动作应该只和它为之准备数据的独立的小模板联系。这样使得移除模板和内容切片更容易,并且能够在很多页面中重用它们。 浏览数据预备逻辑应该使用动态脚本语言,例如JAVASCRIPT,BeanShell,jython或者Jacl来实现。这样就更容易修改在表面修改用户接口。一般数据接收应该实现成服务,这样可以从这些动态动作脚本调用。这样在多个页面和其他类型的用户接口里共享和重用功能模块。 注意到当使用JSP作为视图模板时,你不能使用JPublish,所以动作特效不能提供。我们对JSP的建议时在每个页面的上端使用单个 scriptlet准备数据。在这种情况下,尝试调用工作者服务(worker service)或者工作者的java方法来作大部分工作,尽量可能多地将逻辑排除在页面之外。 视图显示模板 FreeMarker是为HTML和其他文本生成推荐的最佳模板引擎。它像Velocity,但更灵活并且更好地与BOSENT 核心框架工具搭配。除了直接使用FreeMarker的模板以外,还强烈推荐使用JPublish,这样动作可以与页面和模板联系起来,页面可以被普通模板渲染。 视图显示模板应该尽可能保持简单。通用内容例如headers,footers,sidebars等等应该实时通过渲染模式添加。被用来渲染每个页面的模板文件在JPublish定义XML文件中定义。当你希望像视图一样显示报告,我们推荐使用JASPERREPORTS或者Datavision,在 controller.xml文件里通过视图映射(view-map)装上这些报告。如果你希望使用其他文本生成工具例如Velocity或者XSLT, 推荐通过JPublish做这项工作,特别是你想它能够被渲染或者拥有动作来为这些模板提供数据。 如果使用能够经常重复的UI模式,例如forms,请求数据显示,TAB或者menu bars,expanding tree views。推荐使用一个XML文件来描述该UI模式,然后使用XSLT转化成FreeMarker 模板,该模板可以合并最终模板和上下文的数据。注意到所推荐的会经常改变并重新定义,这也就说明了不同的方法存在多种解决方案。 当使用FreeMarker是不可能或者不切实际时,我们推荐使用其他动态模板语言例如Velocity,如果这也是不切实际,那么则推荐JSP。但是当使用JSP时不能利用动作或者渲染模板的优点,因为不能通过JPublish执行它。即使不能使用渲染模式,你可以与Bosent Region框架一起使用组合视图模式。Regions在Regions.xml文件里定义。注意到这些Regions并不和JPublish组合视图那样好用,并且它们不支持动作。但是Regions框架确实提供了很多灵活性,并且在很多情况下非常有用。 6.4 系统技术选型 语言 java c □ C++ □ C# □ delphi □ perl □ vb □ Vb.net □ 汇编 □ 其他 6.5 系统架构选型 架构选型 B/S C/S □ P2P □ 单机 □ 其他 6.6 架构体系 功能模块划分: 系统中的每个功能都以组件的形式存在,通过Componet Manager把不同组件整合起来。 Componet Manager是传统中间件技术与XML、Web服务等技术结合的产物。提供了系统中最基本的连接中枢,是构筑系统的必要元素。 各个组件之间的引用关系图: 服务是由一些组件组成的,这些组件一起工作,共同提供服务所请求的业务功能。 服务、组件、对象关系 6.7 模块划分 6.7.1 包结构(package) 1 Bosent目录结构 目录结构说明: 目录名称 描述 framework 底层框架及基础服务、工具,包括base、start、entity、security、minilang、testtools、datafile等等 applications 存放BOSENT自带的应用,包括accounting、humanres、order、party、content等等 bin 存放项目编译后的文件:配置文件、class文件 bosentbusiness 业务应用 bosentext bosent扩展应用 runtime 运行时数据。这里的运行时数据是指BOSENT运行时产生的日志,或者安装时生成的配置文件以及其他的临时文件 hot-deploy 热部署目录,部署新的组件的目录 themes 界面相关的主题包 thirdpartyjar 第三方jar文件目录 2 bosent组件结构 组件结构说明: 目录名称 描述 build 组件编译后的class文件和jar文件的目录 config 存放国际化及相关的配置文件 data 存放实体数据描述文件 entitydef 实体模型定义文件 script 脚本文件,minilang servicedef 服务定义文件 src 存放java源码文件 webapp javaweb应用目录 widget 存放页面文件 6.7.2 组件管理器(Componet Manager) 1) 功能说明: 组件管理器是Bosent系统的连接中枢,通过组件管理器把系统的各个组件整合起来。组件管理器的主要的功能有: l 初始化 初始化类路径(ClassPath) 初始化日志目录 初始化Bosent管理服务器 初始化Bosent启动装载器(StartupLoader) l 组件加载 加载基础组件 加载日志组件 加载服务引擎组件 加载实体引擎组件 加载迷你语言组件 加载页面工具组件 加载应用组件 2) 结构图 6.7.3 服务引擎(Service Engine) 1 功能说明 在Bosent中可以把一些独立的Service定义存储在同一个Service定义文件中,以满足实际业务中不同类型的需求。Service的类型有很多种,例如:Workflow, Rules, Java, SOAP, BeanShell等等。对于Java类型的Service来说,Service定义类似一个event,Service方法是static的,实际上,Service框架不仅仅在web应用中使用。Service需要的输入参数和输出结果均以Map方式提供。自从可以serialized并通过HTTP (SOAP)协议传输,使用Map是比较好的处理方式。 Service的配置定义中会指定一个Service Engine,每个Service Engine都会以适当的方式调用已经正确配置的Service。Service不再绑定于Web应用,就意味着没有response对象Service一样可以运行,因此Service也可以在Job Scheduler的调度下在指定的时间按计划在后台运行。 Service当中可以调用其它Service,许多小的Service可以连接起来完成一个大任务,Service的重用变得简单易行。定义一个全局性的Service可以令其在很多应用中都可以使用,相对的也可以定义一个Service只能运行在指定的应用中。 在Web应用中,Service与Web event结合起来,在Service框架中就充分利用Web应用的特性。一个Service若被定义为'exportable'则代表是可以被系统外部的Remote应用使用,现在SOAP方式可以利用SOAP EventHandler来发布Service。 2 结构 类图: 服务引擎同步处理流程图: 服务引擎异步处理流程图: 3 说明 Service Dispatcher 在一个Service被调用的时候,Service Dispatcher来分派服务到适合的Service Engine。每个Service Dispatcher对应一个Entity Delegator,在应用中如果有多个Entity Delegator则会有多个Service Dispatcher来对应。每个Service Dispatcher的调用是通过LocalDispatcher,一个Service Dispatcher可关联多个LocalDispatcher,每个LocalDispatcher都有唯一命名,并拥有自己的Service定义列表。当创建一个LocalDispatcher实例,同时会创建一个DispatchContext并传给ServiceEngine。 一个LocalDispatcher是与一个应用相关联的。应用是不直接和Service Dispatcher打交道的,LocalDispatcher有相应的API通过Service Dispatcher来调用Service。 Dispatch Context DispatchContext在LocalDispatcher实例化时创建,这是运行期的DispatchContext。DispatchContext保留Dispatcher执行服务所需的必要信息,包括:Service定义文件、运行Service对应的classloader、一个Delegator的引用、一个Dispatcher的包装(除去用户定义属性)。DispatchContext在Dispatcher确定service's model时起作用,并且会在Service调用的时候传递给Service。 Service Engine Service Engine是服务真正被调用的地方,每个Service在定义的时候需确定其使用的Service Engine,Service Engine在serviceengine.xml定义,在被调用的时候通过GenericEngineFactory来实例化。系统支持实现GenericEngine接口的第三方的Service Engine ,Service Engine能够以同步或异步方式调用Service。Job Scheduler使用的用来异步执行的Engine应继承GenericAsyncEngine。 Job Scheduler 检查Job Scheduler现在集成进Service框架中。Job Scheduler可以脱离Web容器运行。Job Scheduler以多线程方式执行各个Job,并且在各自独立的线程中去调用Service。当一个Job按计划执行,Job Scheduler会调用Service Dispatcher关联到这个Job使其能够在自己的线程中执行Service,这将避免长时间执行的Job影响队列中的其它Job。Job Scheduler支持日期计划的循环执行,Job不再有单独的xml配置文件,而是集成到Service Dispatcher,每个Service Dispatcher都包括一个Job Scheduler。使用Job Scheduler最好的例子是一个异步的Service调用。当一个异步的Service被调用,它会传递到队列中运行。执行顺序:创建RecurrenceInfo 和RecurrenceRule实体,保存Job,创建JobSandbox实体,序列化context (Map)且保存(创建RuntimeData实体)。Job Scheduler会将这个Job加到Job列表的顶端(异步Service是不需要等待的)并调用。Job不再单独定义的xml配置文件,而是移到JobSandbox实体,有web页面的方式可以管理Job的计划和增加Job到队列。 Service Definition Services在Service定义文件中定义,既有全局的针对所有service dispatchers的定义文件,也有对指定dispatcher的特性定义文件。当LocalDispatcher被创建,那些关于Service定义文件的位置会以集合形式传递给它,Service定义文件以XML形式存在。 Service定义需有一个唯一的名字,要指定所需的service engine,输入输出参数要明确指定。 默认情况下,在service 调用前,输入参数会进行校验,如果定义与实际传的不匹配则service 不会被调用,当然是否校验是可选的。在service被调用后,有需要的定义了的输出参数会被校验。如果一个服务没有定义了参数不需要校验,却传送了一个没有在定义中的参数则会导致服务失败。 ECAs ECA (Event Condition Action) 更象是一个触发器。当一个服务被调用时,会执查看是否为这个事件定义任何ECAs 。在验证之前,检验之前,事件在实际调用之前,在输出参数校验之前,在事务提交之前或者在服务返回之前包含进来。然后每个条件都会进行验证,如果全部返回为真,定义的动作就会执行。一个动作就是一个服务,该服务的参数必须已经存在于服务的上下文中。每个ECA可以定义的条件数或者动作数没有限制。 Interfaces interface srvice engine用来帮助定义一组服务共享相同的一些参数,interface service不能被调用,可以被继承。继承这个interface service的Service就拥有了这些定义。 Service Groups Service group是一组Service,配置一个启动的服务,调这个启动Service来调用这一组Service。需要定义一个服务,使用group service engine,并且定义好这一组Service所需要的全部parameters/attributes。 6.7.4 实体引擎(Entity Engine) 1 功能说明 BOSENT 实体引擎提供了一组工具和设计模式来对现实世界中特定的实体(数据对象)进行建模和管理。在本系统的上下文环境中,一个实体就是一个由多个数据域(fields)和该实体与其它实体之间的关系所组成的一个数据对象。这个定义来自于关系型数据库对实体关系模型(Entity-Relation modeling)概念的标准定义。实体引擎的目标是简化企业级应用中对实体数据(对应关系型数据库表)的大量操作,包括定义、维护、通用操作(增、删、改、查实体和实体之间的关系)的开发工作。 2 结构图 数据库操作结构图: 处理流程图: 获取sequenceid流程图: 3 说明 实体引擎采用了很多被大多数企业级应用系统公认的位于业务逻辑层和集成层(Business Tier and Integration Tier)的设计模式。许多表示层(Presentation Tier)的设计模式也被引入进BOSENT,但是仅仅体现在Servlet控制器(the servlet controller)中,没有包括在实体引擎中。在实体引擎中使用的设计模式包括:业务代表(Business Delegate),值对象(Value Object), 复合实体(Composite Entity(variation)),值对象组装器(Value Object Assembler),服务定位器(Service Locator)和数据访问对象(Data Access Object)。BOSENT正在计划逐步引入其它设计模式和完善已经引入的设计模式的实现。 实体引擎的一个主要目标是尽可能的提供一种通用的代码结构,来消除在针对每一个实体的事物处理过程中所有写死(hard code)的代码。这种系统抽象所关注的问题,与那些把数据从数据库中提取出来,并以报表的形式进行输出和显示处理的报表管理或类似系统是不同的,而是类似于每日都可能发生很多事物处理的商业应用系统,实体引擎能大量节省构建类似应用系统的开发费用和戏剧性的减少因为系统存在大量写死的事务处理代码所产生的bug。这种类型的应用系统目前在BOSENT中实现了一些,如电子商务,入库、出库的帐目管理,任务分配资源管理等等。这些工具能够用来报告和分析系统,但是并不意味着,它能包容千差万别的客户的应用需求。 为了达到尽可能少的在系统中出现与针对特定实体操作有关的代码,存储实体属性值的对象结构必须设计成通用的,可以用一个MAP对象来存贮实体的所有域(也可以叫字段或属性),通过实体的名称来区分它们是哪个实体的。根据字段的名称,用一个简单操作String数据的方法,来从值对象中读出或写入某字段的值,并且还可以验证给定名称的字段是否是该值对象的一个合法域。在实体引擎和应用系统之间建立了一个约定(体现实体结构定义文件和字段类型、Java数据类型、SQL字段类型映射关系的定义中),这个约定被定义在特定的 XML文件中,以减少这种灵活性可能存在对系统不利的风险(如数据类型问题可能引起数据库系统崩溃等)。 实体的定义放在XML文件中,在系统启动的时候,由实体引擎负责把这些结构定义加载进内存,并且在应用程序和数据源(通常指一个数据库或其它资源)之间建立一些对这些定义的使用规则。在这些XML实体定义中,对实体和属于它们的域,以某种规则和数据库中的表和表的字段建立映射关系。而且实体与实体之间的关系,实体域的数据类型,Java语言的数据类型,SQL 数据类型之间的映射关系,也被定义在XML文件中。实体之间的关系还可以被命名,以用来区分不同实体组合之间的特定关系。 基于实体引擎这个抽象层,与特定实体操作有关的代码的编写就变的很容易创建和修改。 使用实体引擎所提供的APIs,编写处理实体持久性(增、删、改、查)的代码,可以不同的方式来配置,以便于实现针对实体持久性操作(增、删、改、查)有变化时,可以不改变代码本身,因为它并没有写死。这种抽象的一个典型应用场景就是你既可以通过JDBC直连方式,也可以通过调用运行在EJB服务器上的实体Bean(Entity Beans)的方式或者以其它方式,甚至在系统所提供的框架范围内,使用者运用自己扩充的方式去完成对实体持久性的改变等等。这些不同方式的切换并不需要对代码做任何改动,只需要修改配置文件。 实体建模 最初需要做的是,定义或建模,创建一个新的实体。在BOSENT 实体引擎中通过二个XML 文件, 一个为实体模型和另一个是字段类型定义。原因是这两个文件被分离, 字段类型定义是根据具体数据库定义的。 实体模型XML文件配置在 framework/entity/entitydef/目录中。所有实体最初是在entitymodel.xml文件中定义的,但他们现在被分离出各种各样的文件除entitymodel.xml文件之外,全部命名以以下样式: entitymodel_*.xml。 DB2 字段类型模型XML文件为framework/entity/entitydef/fieldtypedb2.xml。有其它数据库具体字段类型文件为Postgres, Hypersonic, Oracle, 和cetera 。从实体模型文件和字段类型文件,数据库能通过checkDataSource自动地被创建。也可能自动地执行或通过工具WebTools执行 。 装载种子数据 当表自动生成的时候,数据必须由数据文件加载。这些文件可以是SQL脚本或XML实体引擎文件。所有的类型信息和其他预加载的信息,如状态, enumerations,地理数据等,分别位于framework/entity/中的XML实体引擎文件。数据文件也可以通过指定全路径的.SQL或者.XML文件形式加载。 XML实体引擎文件还可以通过webtools中的import & export页面导入和导出。 实体和字段定义 注意:字段primarykeyfieldone指定了一个column名称,其他字段没有指定的。col-name和table-name元素是可选的,可以由entity name或field name自动生成。这些自动生成极大简化定义实体的操作。 表名和列名都是用下划线区分的,例如SAMPLE_ENTITY。 实体名和字段名都可以利用Java转换为java类名和字段名,Class变量的名字必须用一个小写字母开头。后面的单词用大写字母开头。实体名对应的Java类名,所以第一个字母是大写,但字段名对应类的一个字段,所以第一个字母是小写。 例如:SampleEntity和fieldOne对应 SAMPLE_ENTITY和FIELD_ONE。 复合主键,可以使用多个标签指定字段为主键。 字段类型是指定字段使用的类型,它是指在一个fieldtypemodel XML中配置由fieldtypemodel.dtd XML定义的数据类型。各种类型对应一个Java类型和一个SQL类型。由于分离出不同的fieldtypemodel XML文件,可以使用不同的entitymodel XML与对应的数据库工作。 此外,validator可以为任何字段定义一个扩展的类型。这意味着,当数据输入,validator 可以被执行。 6.7.5 事务管理(Transaction Manage) 1) 功能描述 事务是现代数据库理论中的核心概念之一。如果一组处理步骤或者全部发生或者一步也不执行,我们称该组处理步骤为一个事务。当所有的步骤像一个操作一样被完整地执行,我们称该事务被提交。由于其中的一部分或多步执行失败,导致没有步骤被提交,则事务必须回滚(回到最初的系统状态)。事务必须服从ISO/IEC所制定的ACID原则。ACID是原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持久性(durability)的缩写。事务的原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。一致性表示当事务执行失败时,所有被该事务影响的数据都应该恢复到事务执行前的状态。隔离性表示在事务执行过程中对数据的修改,在事务提交之前对其他事务不可见。持久性表示已提交的数据在事务执行失败时,数据的状态都应该正确。 原子性(ATOMICITY):一个事务要被完全的无二义性的做完或撤消。在任何操作出现一个错误的情况下,构成事务的所有操作的效果必须被撤消,数据应被回滚到以前的状态。   一致性(CONSISTENCY):一个事务应该保护所有定义在数据上的不变的属性(例如完整性约束)。在完成了一个成功的事务时,数据应处于一致的状态。换句话说,一个事务应该把系统从一个一致状态转换到另一个一致状态。举个例子,在关系数据库的情况下 ,一个一致的事务将保护定义在数据上的所有完整性约束。        隔离性(ISOLATION):在同一个环境中可能有多个事务并发执行,而每个事务都应表现为独立执行。串行的执行一系列事务的效果应该同于并发的执行它们。这要求两件事:        在一个事务执行过程中,数据的中间的(可能不一致)状态不应该被暴露给所有的其他事务。 两个并发的事务应该不能操作同一项数据。数据库管理系统通常使用锁来实现这个特征。 持久性(DURABILITY):一个被完成的事务的效果应该是持久的。       这些属性叫做ACID属性,保证一个事务是永远不会不完整,数据永远不会不一致,并发事务是独立的,一个事务的效果是持久的。 Java事务的类型 Java事务的类型有三种:JDBC事务、JTA(Java Transaction API)事务、容器事务。 1) JDBC事务 JDBC 事务是用 Connection 对象控制的。JDBC Connection 接口( java.sql.Connection )提供了两种事务模式:自动提交和手工提交。 java.sql.Connection 提供了以下控制事务的方法: public void setAutoCommit(boolean) public boolean getAutoCommit() public void commit() public void rollback() 使用 JDBC 事务界定时,您可以将多个 SQL 语句结合到一个事务中。JDBC 事务的一个缺点是事务的范围局限于一个数据库连接。一个 JDBC 事务不能跨越多个数据库。 2) JTA(Java Transaction API)事务 JTA是一种高层的,与实现无关的,与协议无关的API,应用程序和应用服务器可以使用JTA来访问事务。 JTA允许应用程序执行分布式事务处理--在两个或多个网络计算机资源上访问并且更新数据,这些数据可以分布在多个数据库上。JDBC驱动程序的JTA支持极大地增强了数据访问能力。 如果计划用 JTA 界定事务,那么就需要有一个实现 javax.sql.XADataSource 、 javax.sql.XAConnection 和 javax.sql.XAResource 接口的 JDBC 驱动程序。一个实现了这些接口的驱动程序将可以参与 JTA 事务。一个XADataSource对象就是一个 XAConnection 对象的工厂。XAConnections是参与 JTA 事务的 JDBC 连接。需要用应用服务器的管理工具设置 XADataSource。 J2EE 应用程序用 JNDI 查询数据源。一旦应用程序找到了数据源对象,它就调用 javax.sql.DataSource.getConnection() 以获得到数据库的连接。 XA 连接与非 XA 连接不同。一定要记住 XA 连接参与了 JTA 事务。这意味着 XA 连接不支持 JDBC 的自动提交功能。同时,应用程序一定不要对 XA 连接调用 java.sql.Connection.commit() 或者 java.sql.Connection.rollback()。相反,应用程序应该使用 UserTransaction.begin()、UserTransaction.commit()和 serTransaction.rollback()。 3) 容器事务 容器事务主要是J2EE应用服务器提供的,容器事务大多是基于JTA完成,这是一个基于JNDI的,相当复杂的API实现。相对编码实现JTA事务管理,我们可以通过EJB容器提供的容器事务管理机制(CMT)完成同一个功能,这项功能由J2EE应用服务器提供。这使得我们可以简单的指定将哪个方法加入事务,一旦指定,容器将负责事务管理任务。这是我们土建的解决方式,因为通过这种方式我们可以将事务代码排除在逻辑编码之外,同时将所有困难交给J2EE容器去解决。使用EJB CMT的另外一个好处就是程序员无需关心JTA API的编码,不过,理论上我们必须使用EJB。 三种事务差异 1、JDBC事务控制的局限性在一个数据库连接内,但是其使用简单。 2、JTA事务的功能强大,事务可以跨越多个数据库或多个DAO,使用也比较复杂。 3、容器事务,主要指的是J2EE应用服务器提供的事务管理,局限于EJB应用使用。 BOSENT系统采用的JTA事务管理方式,JTA是J2EE事务服务的解决方案、描述了J2EE模型事务接口。JTA具有三个主要的接口:UserTransaction、TransactionManager、Transaction接口。这些接口共享公共的事务操作,如:commit()、rollback()。同时各自也有自己的操作。 2) 结构图 3) 功能说明 配置service时跟事务相关的几个属性介绍: use-transaction :默认为“true”。即在配置service的属性时,如果没有此属性,则默认为“true”。 如果在当前线程里没有事务,并且设置use-transaction属性为“true”,服务引擎将会为当前service启动一个新事务。如果设置use-transaction属性为“false”,或者当前线程里已经存在一个事务,那么服务引擎不会启动新事务。 transaction-timeout:默认值为“0”。即在配置service的属性时,如果没有此属性,则默认为“0”。 以“秒”为单位,定义事务的超时时间。超时设置为“0”时,事务工厂采用默认的时间“3600秒”。 这个属性只有在开启一个新事务的时候起效。即:require-new-transaction为“true”或者use-transaction为“true”,并且当前线程中没有事务。如果use-transaction为“false”,那么这个属性将被忽略。 require-new-transaction:默认值为“false”。即在配置service的属性时,如果没有此属性,则默认为“false”。 如果此属性设置为“true”,并且当前线程中存在事务,服务引擎将把当前事务挂起,然后为当前service启动一个新的事务,当前service结束后将提交或者回滚新起的这个事务,然后重启被挂起的事务。如果此属性设置为“true”,并且当前线程中不存在事务,那么服务引擎就为当前service启动一个新事务,就跟设置user-transaction属性为“true”是一样的效果。如果设置user-transaction属性为“false“,那么这个属性将不起效。 调用服务接口说明: 1.LocalDispatcher.runSync(String serviceName, Map context)方法这个接口调用服务service,系统将采用serviceName对应的service属性值,具体参照service属性说明。 2.LocalDispatcher.runSync(String serviceName, Map context, int transactionTimeout, boolean requireNewTransaction)参数transactionTimeout:如果值设置为-1,那么系统将采用service配置的transaction-timeout属性值,具体值参照transaction-timeout属性说明。参数requireNewTransaction:具体参照require-new-transaction属性说明.如果requireNewTransaction参数为”false“,且当前线程中已经存在事务,那么transactionTimeout参数的值没有任何作用。如果当前事务中已经存在事务,requireNewTransaction参数为”true“,那么系统将挂起当前事务为当前service重启一个新事务,事务的超时就涉及到两个超时时间,一个是被挂起事务的超时时间,另一个是service的超时时间。当前service在超时时间内完成(没有超时),但service的执行时间大于被挂起事务的超时时间,那么被挂起的事务将抛事务超时异常。也就是说当前service的超时时间应该小于等于被挂起事务的超时时间。 6.7.6 缓存机制(Cache) 1) 功能说明 当系统的信息量越来越多情况下,应用需要支撑的并发量就越来越多。应用服务器和数据库服务器所做的计算也越来越多,但是应用服务器资源是有限的,数据库每秒中接受请求的次数也是有限的。如果利用有限的资源来提供尽可能大的吞吐量呢,一个办法:减少计算量,缩短请求流程(减少网络io或者硬盘io)。引入缓存机制就可以解决这个问题。请求 可以从缓存里取到数据直接返回,不用与数据库服务器再一次的交互,这样不但节省了时间,提高了响应速度,而且也节省了硬件资源。 2) 结构图 3) 说明 BOSNET采用了内存作为缓存的介质,bosent的缓存分为:一级缓存和二级缓存 l 二级缓存(会话缓存) 事务范围:缓存只能被当前事务访问。缓存的生命周期依赖于事务的生命周期,当事务结束时,缓存也就结束生命周期。 l 一级缓存(全局缓存) 缓存被应用范围内的所有事务共享。 这些事务有可能是并发访问缓存,因此必须对缓存进行更新。缓存的生命周期依赖于应用的生命周期,应用结束时, 缓存也就结束了生命周期,一级缓存存在于应用范围。集群范围:在集群环境中,缓存被一个机器或者多个机器的进程共享。缓存中的数据被复制到集群环境中的每个进程节点,进程间通过远程通信来保证缓存中的数据的一致性, 缓存中的数据通常采用对象的松散数据形式,一级缓存也存在与应用范围。 l 注意:对大多数应用来说,应该慎重地考虑是否需要使用集群范围的缓存,再加上集群范围还有数据同步的问题,所以应当慎用。多种范围的缓存处理过程持久化层可以提供多种范围的缓存。如果在事务范围的缓存中没有查到相应的数据,还可以到应用范围或集群范围的缓存内查询,如果还是没有查到,那么只有到数据库中查询了。 l 缓存应用的范围:修改少,数量在可以接受的范围内 使用一级缓存的原则: l 数据不会被第三方修改 l 同一数据系统经常引用 l 数据大小在可接受范围之内 l 关键数据或不会被并发更新的数据 缓存属性 从面向对象的角度来看,缓存就是一个对象,那么是对象,必然有属性.那么下面我们来探讨一下缓存有哪些属性.以下列举我们常用到的3个属性。 l 命中率 命中率是指请求缓存次数和缓存返回正确结果次数的比例.比例越高,就证明缓存的使用率越高. 命中率问题是缓存中的一个非常重要的问题,我们都希望自己缓存的命中率能达到100%,但是往往事与愿违,而且缓存命中率是衡量缓存有效性的重要指标。 l 最大元素 缓存中可以存放得最大元素得数量,一旦缓存中元素数量超过这个值,那么将会起用缓存清空策略,根据不同的场景合理的设置最大元素值往往可以一定程度上提高缓存的命中率.从而更有效的时候缓存。 l 清空策略 FIFO ,first in first out ,最先进入缓存得数据在缓存空间不够情况下(超出最大元素限制时)会被首先清理出去。 LFU , Less Frequently Used ,一直以来最少被使用的元素会被被清理掉。这就要求缓存的元素有一个hit 属性,在缓存空间不够得情况下,hit 值最小的将会被清出缓存。 LRU ,Least Recently Used ,最近最少使用的,缓存的元素有一个时间戳,当缓存容量满了,而又需要释放空间来缓存新的元素的时候,那么现有缓存元素中时间戳离当前时间最远的元素将被清出缓存。 缓存介质 从硬件介质上来将无非就是两种,内存和硬盘(对应应用层的程序来讲不用考虑寄存器等问题)。但是往往我们不会从硬件上来划分,一般的划分方法是从技术上划分,可以分成几种:内存、硬盘文件、数据库。 l 内存 将缓存放在内存中是最快的选择,任何程序直接操作内存都比操作硬盘要快的多,但是如果你的数据要考虑到break down的问题,因为放在内存中的数据我们称之为没有持久话的数据,如果硬盘上没有备份,机器down机之后,很难或者无法恢复。 l 硬盘 一般来说,很多缓存框架会结合使用内存和硬盘,比如给内存分配的空间有满了之后,会让用户选择把需要退出内存空间的数据持久化到硬盘.当然也选择直接把数据放一份到硬盘(内存中一份,硬盘中一份,down机也不怕).也有其他的缓存是直接把数据放到硬盘上。 l 数据库 说到数据库,可能有的人会想,之前不是讲到要减少数据库查询的次数,减少数据库计算的压力吗,现在怎么又用数据库作为缓存的介质了呢.这是因为数据库又很多种类型,比如berkleydb,这种db不支持sql语句,没有sql引擎,只是key和value的存储结构,所以速度非常的快,在当代一般的pc上,每秒中十几w次查询都是没有问题的。 缓存的同步 在集群环境下,必须考虑缓存的同步。在BOSENT系统中,采用了JGROUPS作为缓存同步的机制。JGROUPS是一个可靠的组间通讯工具,进程可以加入一个通讯组,给组内所有的成员或单独的成员发送消息,同样,也可以从组中的成员处接收消息。系统会记录组的每一个成员,在新成员加入或是现有的成员离开或是崩溃时,会通知组内的其他成员,这样就不必自己去管理这些事情了。鉴于消息传输的可靠性考虑,使用TCP协议进行消息传输,当集群中的成员分布于WAN时(路由器会丢弃IP multicast报文),TCP可能是唯一可用的传输协议。 6.7.7 日志管理(Logs) 1) 功能说明 BOSENT系统中的日志管理。在应用服务器系统中根据日志信息的类型,可以分为:服务的跟踪堆栈日志信息、服务调用日志信息、服务的文件型日志信息、事务管理日志信息和其他日志信息,每种日志信息分别对应一个日志文件。BOSENT的日志目录中会在不同的文件中记录不同类型的内容,这些内容有的是供运维人员监控代码上线的一瞬间系统运营情况;有的是供开发人员(包括客户端开发人员和服务器端开发人员)查找系统运营过程中抛出的异常;有的是供开发人员在调试奇难bug时记录调试信息用的;有的是供运营人员进行数据统计和分析用的。 2) 结构图 类图: 日志目录结构: 3) 说明 l 服务的跟踪堆栈日志 日志文件命名规则 服务的跟踪堆栈日志是指服务的调用堆栈日志,此类日志文件名为:service_trace_stack_log.log。 日志文件内容 记录服务调用的日志及服务调用的sql堆栈日志。 日志格式为: 日志文件用途 服务的跟踪堆栈日志文件主要就是用来做性能分析。项目组利用这些信息来分析应用服务的执行效率情况,从而设计、优化出更加合理的代码。 日志文件生成方式(log4j.xml) l 服务调用日志 日志文件命名规则 服务调用日志是指通过serviceUi调用服务的日志,此类日志文件名为: serviceUi.log。 日志文件内容 服务调用日志文件中主要保存服务在被调用的日志信息,主要包括通过serviceUi调用服务处理过程中抛出的异常信息。 日志文件用途 服务调用日志文件主要就是监控服务被调用出错时的异常信息。 日志文件生成方式(log4j.xml) l 服务的文件型日志 日志文件命名规则 服务的文件型日志文件名格式统一为:service_log.log。 日志文件内容 服务的文件型日志中主要保存请求报文、程序对请求报文的处理过程、回应报文等信息。这里面也会包括处理过程中抛出的异常信息。 日志文件用途 服务调用日志文件主要就是监控服务被调用时传入的参数、服务处理后返回的信息以及服务出错时的异常信息。 日志文件生成方式(log4j.xml) l 事务管理日志 日志文件命名规则 事务管理日志文件名格式统一为:transaction-manager.log。 日志文件内容 事务管理日志文件中主要保存程序中抛出的事务异常日志信息,比如数据插入异常、连接异常等。 日志文件生成方式(log4j.xml) l 其他日志 日志文件命名规则 其他日志文件名格式统一为:bosent.log。 日志文件内容 其他日志文件中主要保存程序中错误,警告等等信息。 日志文件生成方式(log4j.xml) 6.7.8 任务调度(Task Scheduling) 1) 功能说明 BOSNET系统中业务处理量是非常大的,为了缓解系统压力和保障系统效率,一些对及时性要求较小的任务就可以放到处理量较小的时间段执行。在BOSENT系统中,在执行某些业务的时候不需要实时(同步)的等待执行完成才能结束,还有些任务是需要在固定的时间执行的,使用作业调度可以避免人工的干预,从而按时自动执行。 2) 结构图 3) 工作原理 Service Engine:BOSENT中的服务引擎,他将产生job,并将job存放到job队列中等待执行。 轮询线程:从数据库中不断提取任务的线程,并将提取出来的任务生成job存放到job队列中。 内部队列:存放job的池,队列是一个缓冲池,将不能及时处理的job缓冲起来,等待处理线程来提取。处于队列中的job都是等待状态,处理线程执行完一个job后,会自动从job队列中取出下一个job来执行。 处理线程:执行job的线程,并将执行完成的job释放,同时修改job的状态,再从job队列中提取新的job执行。 job在整个生命周期中的状态图: PENDING状态:新建的job都为“PENDING”状态。“PENDING”状态的job来源有两种,一种是持久化job;另一种是job在执行过程中,系统崩溃,在重启系统时,会将“QUEUED”和“RUNNING”状态的job复制出一个新的job,状态置为“PENDING”。 QUEUED状态:在队列中的job状态都为“QUEUED”。任务调度器运行过程中,会从数据库提取出“PENDING”状态的job,然后将这些job放入到job队列中,同时将job的状态置为“QUEUED”。 RUNNING状态:任务调度器从job队列中取出job,并执行job,此时的job为 “RUNNING”状态。 FAILED状态:job执行失败(执行过程中出现异常等原因)后置为“FAILED” 状态。 FINISHED状态:job执行成功后置为“FINISHED” 状态。 CRASHED状态:系统在调度执行job时出现异常情况(系统崩溃),导致job没有执行完成,系统也无法继续执行。系统重启后会置此类job为 “CRASHED”状态,并复制出一个新的job重新执行。“FAILED”、“FINISHED”状态都属于完成状态。 CANCELLED状态:处于 “PENDING”状态的job,可以取消不执行,状态就置为“CANCELLED”。 6.7.9 迷你语言(Minilang) 1) Minilang介绍 Mini-Language,顾名思义,可以解释为轻量级的、微型的语言,这门语言基于规则引擎,同时构建在JAVA语言的基础上,因此把它归结为一种高级语言,为了方便称呼,我们称Mini-Language为迷你语言。 Minilang能帮助开发人员减少他们实施简单和重复工作的时间,代码不需要经过编译就能快速的实施,打破了典型的写java代码-编译-测试周期。Minilang的一个优势是改变了代码后不需要重启应用就能够起效,一个简单的浏览器刷新,就足以看到的变化。它比java代码更易于阅读,因此更容易让那些可能不熟悉系统的人理解与维护。 Minilang也存在一些缺点,在某些场景下难以调试。Java代码可以一行一行的debug跟踪调试,但Minilang是绝对不可能做到的。虽然可以通过一些技巧让我们得到代码的能见度,但由于复杂的服务的增加,Minilang变得越来越不可行,调试代码的时间已经开始超过了快速热部署执行的代码所带来的效益。Minilang也是有限的,只有在某数目内可以使用Minilang程序编程。 Minilang存在的主要理由是为了方便简单的操作,特别是简单的CRUD操作、验证和处理数据。它不应该超出此范围太多,在这个范围内,它是比较擅长的。 Minilang语法是简单很好的xml,开发人员编写的XML是服从一个定义的架构,然后由框架和解析执行相应的命令。因此,我们可以认为Minilang的XML元素就是“命令”。 Minilang通常是写在一个简单方法的XML文件,该文件是文件头: xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/simple-methods.xsd"> 文件存放的路径是在源代码包中framework\minilang\dtd\simple-methods.xsd。 虽然Minilang主要是用来编写服务和事件的,但从Minilang概念上也是可以被用来准备屏幕小部件的数据。 2) 功能模块说明 迷你语言是一门用Xml来编码的语言,操作单元是Xml格式的标签 (Tag),通过标签来执行相应的操作(Operation)。多个这样的标签组合到一起就成了一个简单方法(Simple Method),简单方法即是迷你语言对外提供的接口。 从功能上,迷你语言主要提供两种类型的方法:simple-method 和simple-map-processor。其中simple-map-processor一般只内部调用,不对外提供,simple-method直接对外提供。 Ø simple-map-processor simple-map-processor主要实现对Map对象的校验和转换,供 simple-method调用。 Ø simple-method simple-method和Java里的static方法是一一对应的,运行时,Java编译器将simple-method翻译成Java代码,再编译执行。simple-method可以被包装成event(事件)或service(服务)对外提供,在simple-method里,可以调用Simple Map Processors、Services 和bsh scripts等。 3) 执行流程 Ø 流程说明 迷你语言属于一种脚本语言,执行的流程大致如下:装载脚本à解释à编译à运行,下面从具体实现上对迷你语言执行流程进行详细说明。 初始化: 1) 解析脚本定义文件 2) 将解析后的脚本文件封装成SimpleMethod对象进行缓存 运行: 1) 新建脚本运行上下文MethodContext(MethodContext负责参数的传递和返回结果的迭加) 2) 根据SimpleMethod标识从缓存获取SimpleMethod对象 3) 判断SimpleMethod对象是否存在,不存在直接抛异常,结束运行 4) 执行SimpleMethod对象的exec方法 a) 参数准备 b) 权限校验 c) 启动事务 d) 执行SimpleMethod对象包含的所有操作(Operation) e) 组装返回对象 f) 提交事务 g) 返回结果 5) 返回结果 Ø 流程图 6.7.10 页面工具(Webtools) 6.7.10.1 缓存工具 1 缓存管理 l 浏览缓存大小和命中/错失统计 l 清除全部缓存、单独的缓存甚至单独的缓存行 l 清除全部过期的缓存记录 l 管理缓存参数如大小限止、过期时间、软参考等 l 浏览每个缓存中的单独的元素 6.7.10.2 调试工具 1 调整调试级别 l 在应用正在运行时调整调试日志的信息级别 l 修改会一直保持到服务器关闭 l 对于持久修改,使用debug.properties文件 6.7.10.3 实体引擎工具 1 实体数据维护 l 查找、浏览、创建和删除任何实体中的数据 l 根据实体定义动态生效 l 使用灵活的权限管理,允许访问全部实体,或访问指定的一组实体 2 实体引用和编辑 l 显示关于全部已定义的实体包括域、类型、表名称和列名称、关系等的详细信息 l 在主要视图框架里,实体按包的字母顺序排列 l 在左侧有一个包的按字母顺序的列表和一个全部实体的按字母顺序的列表 l 关系显示为到实体的链接,以便浏览数据模型 l 一个正在编辑的页面能够用来创建和修改内存中的实体定义 l 有一个把实体定义和数据库进行比较的页面(如同启动时做的那样)并能够选择性地把缺失的表和列添加到数据库中 l 写实体模型和实体组模型XML文件的模板为了便于比较,采用了一致的方法(注意:这些文件用于保存对内存中实体定义的修改);这些模板还能把这个比较信息输出到浏览器 l 读数据库元数据并创建第一遍XML实体定义的模板以后能够根据你的设置而细化 3 XML数据导出 l 把实体数据作为XML文件导出 l XML的结构为每个实体实例一个元素、实体中的每个域一个属性或子元素 l XML文件能够保存到服务器的磁盘,或通过浏览器浏览和/或保存到客户端 l 基于高性能和可扩展流的输出技术能一次导出没有数量限止的实体实例 4 XML数据导入 l 从XML文件导入实体数据 l XML的结构为每个实体实例一个元素、实体中的每个域一个属性或子元素 l XML文件能够从磁盘载入或通过浏览器的表单上传 l 基于高性能、可扩展流和SAX的输入处理技术能一次导入没有数量限制的实体实例 6.7.10.4 服务引擎工具 1 任务列表 l 浏览全部列入日程的任务服务 l 显示任务ID、开始日期/时间、结束日期/时间以及调用的服务名称 2 日程任务 l 允许为一个已命名的服务手工安排日程 l 能够指定间隔大小和次数 l 能够指定一个绝对的开始和结束日期/时间 l 能够把数据手工添加到用于运行服务的持久环境中 6.7.10.5 数据文件工具 1 浏览数据文件 l 基于一个格式定义文件从文件显示数据 l 能够把数据文件写回以验证格式定义和读/写的可重复性 l 能够从URL或服务器上的文件载入数据文件和格式定义文件 6.7.10.6 其它设置工具 1 编辑定制时间段 l 浏览、新建、更新和删除分级的定制时间段 l 时间段能够与一个组织会员关联,而且浏览时间段能够用会员ID过滤 l 管理财年、季度、月、两周、星期以及任意定制时间段类型 l 跟踪一个时间段序号、时间段名称以及每个时间段的天数 2 编辑列举的信息 3 编辑状态选项 6.7.10.7 服务器点击统计工具 1 统计从服务器启动开始 l 对每个请求、每组资源和所有资源显示服务器负载和性能统计 l 跟踪有关不同类型的资源如请求、事件和浏览的数据 l 显示从服务器启动开始累积的数据 l 到显示指定时间段的这些统计数据的页面的链接 l 时间段数据会存储下来以便将来分析 6.7.11 安全控制(Security) BOSENT提供了多个层次的安全控制: 整个应用; 某个业务; 某个业务的某个具体服务. 实现用户接口层或业务逻辑层实现安全性保障。在用户接口层,整个WEB应用程序可以被一次性保护,控制器中单个的请求可以被保护,并且单个的页面可以需要特定的权限。在业务逻辑层,每一个服务可以需要特定的权限。 权限 SecurityPermission的实体描述了粒状的安全权限,这些权限可以用于特定的页面或特定的服务。 SecurityPermission是一个两部分的字符串,由”_”分开,第一部分指定了应用程序,第二部分指定了允许的操作。这样的话你就有可能会拥 有像"ORDERMGR_CREATE"的权限,它意味着拥有该权限的用户可以在订单管理应用程序里创建信息。有一些权限以_ADMIN结尾,比如 ORDERMGR_ADMIN,这些权限自动拥有对应用程序的所有操作权限。   许多单个的安全权限通过实体SecurityPermissionGroup可以被组织到一起。例如,你可以为特定客户创建一组权限,指定谁可以察看客户信息,进入订单,但是不能创建购买订单或者访问内部产品,账户,或者薪水信息和其它功能。   每一个SecurityPermissionGroup都和一个UserLogin关联。一个Party(或许是一个人,或许是一个组织)可以被关联多个 UserLogins。这样的话一个人就可以有多个Login,一些Login拥有的权限多一些,一些Login拥有的权限少一些,这样对于大客户是很有 用的。这可以在Party Manager的安全tab中操作。 保护WEB应用程序   在BOSENT-component.xml文件中定义web应用程序位置处 (标签处),你可以使用标签来指定整个web应用程序需要的权限。仅使用安全权限字符串的第一部分,即应用 程序的名字。例如,如果你使用base-permission="ORDERMGR",则web应用程序会自动需要ORDERMGR_VIEW或 ORDERMGR_ADMIN。   在许多应用程序中,你会看到base-permission="OFBTOOLS, ORDERMGR",这句话表示了权限OFBTOOLS_VIEW和ORDERMGR_VIEW。base -permission属性允许指定一系列的权限,并且它们必须是真实的同时用户是可以获得访问的。OFBTOOLS_VIEW和 ORDERMGR_VIEW的含义是:OFBTOOLS_VIEW控制了访问对于web应用程序的访问,而ORDERMGR_VIEW可用于控制任何应用 程序中订单信息的访问,包括基于web的订单管理,POS,CRM模块或其它应用程序。   在web应用程序的controller.xml中,我们可以用标签为单个的request指定安全性需求。你可以使 用标签来实现页面的安全性,可以通过使用https,或者需要一个用户login来访问页面(尽管没有为一个用户 login指定特殊的权限)。你也可以通过指定无法从浏览器中定向request来隐藏request,这对于收到了一个request链中的一个不能被单独调用的request的情况是很有效的。 安全性API 以下是最常用的安全性API方法:   * Security.hasPermission -核查该用户是否具备一个特定的权限。   * Security.hasEntityPermission - 允许你指定权限字符串,字符串有两部分,如"ORDERMGR", "_CREATE",所以,如果用户有"ORDERMGR_CREATE" 或 "ORDERMGR_ADMIN"权限,它将会通过。   * ServiceUtil.getPartyIdCheckSecurity -核查是否用户具备指定的权限,或者实际上是执行自己的操作。只要是任何情况中的一种,该方法都会返回partyId,意味着用户有权限。   * Security.hasRolePermission -核查是否用户具备指定的权限,以及是否用户关联一个角色中特殊的实体。意思是如果你给用户一个权限,比如ORDER_ROLE_VIEW,并且指定他通 过实体OrderRole和一个订单关联,这样的话那个用户就有权限察看特定的订单。相同的用户将不会拥有权限查看订单,如果他没有一个 OrderRole实体记录的话。   Minilang脚本也有可以进行权限核查的标签:。 安全性服务   可以定义是否一个服务需要一个用户login。此外,可以使用标签来定义什么权限是需要的。在服务内部,可以为自己核查权限。有一个安全性相关的方法可以用于核查是否UserLogin拥有某种权限,或者是否用户为自己执行一个任务(比如为自己创建订单)。   也可以在services.xml里是用标签定义权限. 6.8 模块接口 6.9 配置文件 6.9.1 基础配置文件 BOSENT缓存配置文件:cache.properties 文件格式及内容 # Default Settings (global) cache.file.store=runtime/data/utilcache default.maxSize=10000 default.expireTime=0 default.useSoftReference=false #default.useFileSystemStore=true # No maxSize for properties.UtilPropertiesResourceCache properties.UtilPropertiesResourceCache.maxSize=0 properties.UtilPropertiesResourceCache.expireTime=0 entity.EcaReaders.maxSize=0 entity.EcaReaders.expireTime=0 entity.EcaReaders.useSoftReference=false # No maxSize for properties.UtilPropertiesUrlCache properties.UtilPropertiesUrlCache.maxSize=0 properties.UtilPropertiesUrlCache.expireTime=0 # This should be increased if more users will be simultaneously on the system. security.UserLoginSecurityGroupByUserLoginId.maxSize=1000 security.UserLoginSecurityGroupByUserLoginId.expireTime=0 security.SecurityGroupPermissionCache.maxSize=0 security.SecurityGroupPermissionCache.expireTime=0 …… 该文件包含除实体缓存以外的所有设置,使用以上属性初始化UtilCache。默认的缓存参数可以在运行时创建,但如果缓存的参数给出了这个文件的名字,那么就采用相应的配置作为参数。 每个命名缓存有三种可选属性配置:  (缓存名称).maxSize (int型)   (缓存名称).expireTime (long型)   (缓存名称).useSoftReference (true或者false) maxSize 属性指定缓存条目的最大数量。 expireTime 属性指定缓存项在多长时间内是有效的。 默认值为“0”,即无限缓存没有到期的时间。 useSoftReference 属性用于指定缓存条目是否采用软引用。 软引用有助于保持大缓存,如果内存空间不足时,允许垃圾回收器回收这些数据。 如果值没有指定则传递到UtilCache构造函数的参数将采用默认值default.maxSize, default.expireTime 和 default.useSoftReference。 BOSENT日志级别配置文件:debug.properties 文件格式及内容 # Pack Exception Report Using Avalon Exception Util pack.exception=true # Disable log4j config (used when other app servers handle the config) disable.log4j.config=false # These top level switches are used before calling Log4J, or if Log4J is not used print.verbose=false print.timing=false print.info=true print.important=true print.warning=true print.error=true print.fatal=true BOSNET系统日志开关,打印的级别分为: 详细, 定时, 信息, 重要, 警告, 错误和致命。 Log4j配置文件:log4j.xml 文件格式及内容 …… 配置Log4j中输出源(appender),日志种类(category)等。 JNDI属性文件:jndi.properties 文件格式及内容 #RMI settings #java.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory #java.naming.provider.url=rmi://127.0.0.1:1099 # NetWeaver settings # jndi 工厂类 java.naming.factory.initial=com.sap.engine.services.jndi.InitialContextFactoryImpl # jndi 服务器地址 java.naming.provider.url=197.1.5.5:50004 #for JOTM/Carol - see carol.properties #java.naming.factory.url.pkgs=org.objectweb.carol.jndi.enc #Security settings - not enabled #java.naming.security.principal=javadev #java.naming.security.credentials=cmbc1234 当使用默认的JNDI服务器时,使用该配置文件。这是一个标准的Java JNDI配置属性文件,用于配置要使用的本地JNDI服务器。这个文件是实现JNDI服务器XML文件中的“默认”JNDI服务器的配置的。如果没有这个文件,将使用标准JNDI的Java类中的各种缺省配置。 JNDI服务器配置文件:jndiservers.xml 文件格式及内容 //密码 --> //默认的JNDI服务器 JNDI服务器配置,包含每个JNDI服务器的配置属性。通常只使用“default”服务器,而这个默认服务器是通过Java标准JNDI自动配置的,所以大多数实际系统不需要修改这个文件。 Bosnet组件目录加载配置文件:component-load.xml 文件格式及内容 组件目录加载配置文件,BOSNET系统启动时会自动加载此配置文件中各个配置目录下的组件。 BOSENT容器配置文件:bosent-containers.xml 文件格式及内容 容器加载配置文件,BOSNET系统启动时会自动加载此配置文件中各个容器。"component-container" 容器主要功能是加载组件,"classloader-container" 容器主要功能是加载类。 环境自适应配置文件:address_.properties 文件格式及内容 # EOD回调地址 EOD=197.1.4.11:50000 #安保系统地址 SC=197.1.6.2:50100 #现金管理系统地址 cashManager=197.1.5.6:50000 #支付引擎地址 PE=197.1.5.6:50000 说明:每一个部署环境有一个相应的配置文件,其中为部署环境标识,如610、550等。 JGroups属性文件:jgroups.properties 文件格式及内容 cache.cluster.instance.key:针对缓存的系统环境变量key cache.cluster.properties: jgroups需要的配置属性,如下: cache.cluster.properties=TCP(bind_port=${jgroups.port};loopback="true";\ recv_buf_size=20000000;send_buf_size=640000;discard_incompatible_packets="true";\ max_bundle_size=64000;max_bundle_timeout=30;enable_bundling="true";use_send_queues="true";\ sock_conn_timeout=300;timer.num_threads=4):\ TCPPING(timeout=3000;\ initial_hosts=195.204.92.193[7800],195.204.72.34[7801];\ port_range=1;num_initial_members=4):\ MERGE2(min_interval=10000;max_interval=30000):\ FD_SOCK():\ FD(timeout=3000;max_tries=3):\ VERIFY_SUSPECT(timeout=1500):\ BARRIER():\ pbcast.NAKACK(use_mcast_xmit="false";gc_lag=0;retransmit_timeout=300,600,1200,2400,4800;\ discard_delivered_msgs="true"):\ UNICAST(timeout=300,600,1200):\ pbcast.STABLE(stability_delay=1000;desired_avg_gossip=50000;max_bytes=400000):\ pbcast.GMS(print_local_addr="true";join_timeout=3000;view_bundling="true"):\ FC(max_credits=2000000;min_threshold=0.10):\ FRAG2(frag_size=60000):\ pbcast.STREAMING_STATE_TRANSFER() 其中 "initial_hosts" 属性为初始化的主机列表,同时还包含指定的端口,例如,有两台netweaver服务器,每台服务器上有两个netweaver实例(一个主实例和一个副实例),假如服务器ip分别为197.3.7.7和197.3.7.28,那么 "initial_hosts" 可以这样设置initial_hosts=197.3.7.7[7800],197.3.7.7[7801],197.3.7.28[7800],197.3.7.28[7801]; 其他属性默认即可。 JGroups集群配置文件:jgroups_config.xml 文件格式及内容 配置说明:jgroups_config.xml用来配置集群下给各个服务器实例分配的jgroups端口,如实例AG01分配的端口为7800。 注:实例号AG01即为NW服务器实例号。 缓存配置文件:bosent-cache.xml 文件格式及内容 1 2 3 2 2 1 1 2 2 3 配置文件说明: cache节点:为默认配置属性。 entity-cache节点:为实体缓存配置属性,针对每个具体的实体对象。 entity-name:实体名称 global-cache:实体是否做全局缓存 session-cache:实体是否做session缓存 load-on-init:实体数据是否在应用启动的时候加载 max-size:缓存的最大容量 expire-time:失效时间,单位为秒 Note:全局缓存和session缓存只能配置其中的一个,对于session缓存max-size和expire-time属性是不起效的。如果设置了session-cache为“true”那么不能同时设置load-on-init属性为“true”。 strategy子节点配置说明: 策略配置节点,只有配置全局缓存才起效。属性“type”为策略缓存的类型,有“pk”和“ls”两种策略类型。pk表示通过主键查询的结果做缓存处理; ls表示通过条件查询出的结果做缓存处理。 properties节点说明: properties节点配置几个实体属性之间的“OR”关系。 property节点说明:属性配置节点,属性“name”为实体的属性名称,子节点“value”为属性对应的值。 6.9.2 服务引擎配置文件 服务引擎配置 配置文件格式及内容 配置文件模型 权限 authorization  节点只有一个属性 service-name ,属性的值必须是校验权限的服务名,默认采用BOSENT的  userLogin  服务。 线程池 任务调度器是用来异步调度job和服务的。它使用了一个poller 线程和多个invoker 线程进行调度。通过thread-pool 节点来配置调度器属性。 属性说明: 属性 是否必须 说明 ttl Y 每个invoker 线程的存活时间,一旦时间到了invoker 线程就会自动销毁 wait-millis Y 每个invoker 线程在检查从job队列中取job运行的间隔时间 jobs Y 每个invoker 线程在销毁之前运行的最大job数 min-threads Y 系统中保持的invoker 线程最小数 max-threads Y 系统中可以创建的invoker 线程最大数 poll-enabled Y 是否允许调度器从数据库中取job poll-db-millis Y 如果允许调度器从数据库中取job,这个属性就是定义多长时间从数据库中取一次job job-queue-max-size Y job队列中存放的job最大数 failed-retry-min Y 执行job失败后重试次数 purge-job-days Y 存放的job队列中的job存活时间 引擎定义 GenericEngine接口的每个实现都需要在engine节点中配置定义才能生效。 属性说明: 属性 是否必须 说明 name Y 服务引擎的名称,必须唯一 class Y GenericEngine接口的实现类 资源加载器 resource-loader 标签用来设置一个指定的资源加载器以在其他地方加载XML文件和其他资源。 属性说明: 属性 是否必须 说明 name Y 资源加载器的名字,用于其他标签的 loader属性 class Y 通用抽象类 ResourceLoader 的扩展类。可用类包括 FileLoader, UrlLoader, 和 ClasspathLoader,同类 ResourceLoader 位于同一个包中 prepend-env N Java环境属性的名称。用来放在全部路径(full location)比较靠前的地方,在前缀前面 prefix N 当拼装全部路径(full location)时,放在前面的字符串。如果使用了prepend-env属性,将会置于其后并位于每个指定资源位置的前面 全局服务 global-services 标签用来定义服务定义文件的位置。 属性说明: 属性 是否必须 说明 loader Y 前面 resource-loader 标签定义的资源加载器 location Y 指明资源加载器加载资源要使用的文件的位置 服务配置 配置文件格式及内容 Cost Services BOSEnt 1.0 Create a WorkEffortCostCalc entry 配置文件模型 service节点 service属性 属性 是否必须 说明 默认值 name Y 唯一的服务名称   engine Y 引擎名称 (serviceengine.xml中定义)   location N 文件路径或者带包名的类   invoke N 服务调用的方法名   auth N 服务调用是否需要授权 true debug N 调用服务时是否需要打印详细日志信息 true default-entity-name N 使用auto-attributes设置值的默认实体名称   export N 服务是否允许SOAP/HTTP/JMS访问 false max-retry N 服务执行失败后重试的次数 -1 (没有限制) require-new-transaction N 服务是否需要开启新事务 true semaphore N 定义并发调用服务的策略: none:可多个同时调用服务 wait:当服务在运行时,后续调用就要排队等待 fail:当服务在运行时,后续调用者默认为失败 none semaphore-wait-seconds N 当semaphore="wait"时,后续调用者等待的时间 300 sempahore-sleep N 当semaphore="wait"时,多长时间检查一次服务是否能调用 500 transaction-timeout N 事务超时时间 0 use-transaction N 是否使用事务 true validate N 是否需要attributes的name和type匹配校验 true service 子节点 属性 是否必须 说明 默认值 notification N 服务执行执行后邮件通知配置 permission-service N 权限校验服务 required-permissions N 是否需要授权 group N implements N auto-attributes N description N 描述 namespace N 命名空间 attribute N 属性 notification节点 属性 是否必须 说明 event Y 事件(success、fail、error) group Y 通知的组 permission-service节点 属性 是否必须 说明 service-name Y 服务名称 main-action Y 执行动作(UPDATE、CREATE、DELETE、VIEW) resource-description Y 描述 attribute节点 属性 是否必须 说明 默认值 name Y 属性名称 type Y 属性类型(String,Map等) mode Y 参数类型(IN/OUT/INOUT) default-value N 默认值 form-label N entity-name N 实体名称 field-name N 字段名称 string-map-prefix N optional N 是否可选 string-list-suffix N form-display N allow-html N 值是否允许有html的特殊字符(<、>等) any safe none any 默认情况下,在service 调用前,输入参数会进行校验,如果定义与实际传的不匹配则service 不会被调用,当然是否校验是可选的。如果配置了输出参数需要检验,在service被调用后,输出参数则会被校验。如果一个服务定义了参数检验,却传送了一个没有在定义参数则会导致服务失败。 auto-attribute节点 属性 是否必须 说明 entity-name Y 实体名称 include Y mode Y optional Y form-display Y allow-html Y check-permission节点 属性 是否必须 说明 permission Y action Y check-role-member节点 属性 是否必须 说明 role-type Y 角色类型 exclude节点 属性 是否必须 说明 filed-name Y 字段名称 fail-message节点 属性 是否必须 说明 message Y 失败时提示的错误信息 fail-property节点 属性 是否必须 说明 resource Y property Y group节点 属性 是否必须 说明 name Y send-mode Y implements节点 属性 是否必须 说明 service Y optional Y override节 属性 是否必须 说明 name Y 属性名称 type Y 属性类型(String,Map等) mode Y 参数类型(IN/OUT/INOUT) default-value Y 默认值 entity-name Y 实体名称 field-name Y 字段名称 optional Y 是否可选 form-label Y form-display Y allow-html Y 值是否允许有html的特殊字符(<、>等) requeired-permissions节点 属性 是否必须 说明 join-type Y 校验权限与校验角色两者的关系类型(AND和OR) type-validate节点 属性 是否必须 说明 method Y class Y 服务ECA 配置文件格式及内容 配置文件模型 eca属性 属性 是否必须 说明 默认值 service Y eca关联的服务名称 event Y 服务触发eca的事件 事件类型有: global-commit global-commit-post-run global-rollback auth in-validate out-validate invoke commit return run-on-failture N 服务执行失败后是否继续触发eca false run-on-error N 服务执行错误后是否继续触发eca false action节点 属性 是否必须 说明 默认值 service Y eca触发的服务名称 mode Y 服务执行模式 sync/async run-as-user N 设置上下文中的UserLogin,对应UserLogin 的userLoginId属性 result-map-name N 服务的输出参数(map类型)存在上下文中的key new-transaction N 是否新启事务 false result-to-context N 服务的输出参数值是否存在上下文中 false result-to-result N 是否从服务的输出参数中移除错误信息,再将输出的参数更新到整个返回结果 false ignore-failture N 当result-to-result为false时,是否忽略失败继续执行 false ignore-error N 当result-to-result为false时,是否忽略错误继续执行 false persist N 当mode为“async”时,是否持久化job任务; 当mode为“sync”时,属性无效 false condition节点 属性 是否必须 说明 默认值 map-name N 本服务上下文属性的名字,包含要检验的字段名字组成的Map。如果没有指定这个域名,就会使用服务上下文环境(env-name) filed-name Y 要比较的map的名字 operator Y 指定比较操作符,必须为 less, greater, less-equals, greater-equals, equals, not-equals, 或 contains 当中的一个 value Y 字段要比较的值。必须为String,但是可以通过“format”属性转换成其他类型 type N 用来进行比较的数据类型。必须是 String, Double, Float, Long, Integer, Date, Time, 或 Timestamp 当中的一个 format N 指定当将String 转换成其他类型(主要是Date, Time 和 Timestamp)时使用的格式说明 condition-field节点 属性 是否必须 说明 默认值 map-name Y 本服务上下文属性的名字,包含要检验的字段名字组成的Map。如果没有指定这个域名,就会使用服务上下文环境(env-name) field-name Y 要比较的map的名字 operator N 指定比较操作符,必须为 less, greater, less-equals, greater-equals, equals, not-equals, 或 contains 当中的一个 to-map-name N 本服务上下文属性的名字,包含要与之比较的字段名字组成的Map。如果为空就会使用上面的map-name,如果map-name也为空,就会使用服务下文环境(env-name) to-field-name N 要与之比较的Map中要比较的字段名,如果为空默认为上面field-name type N 用来进行比较的数据类型。必须是 String, Double, Float, Long, Integer, Date, Time, 或 Timestamp 当中的一个。如果没指定默认为String format N 指定当将String 转换成其他类型(主要是Date, Time 和 Timestamp)时使用的格式说明 condition-service节点 属性 是否必须 说明 默认值 service-name Y set节点 属性 是否必须 说明 默认值 filed-name Y 字段名称。如果字段名称格式为”xxx.yyyy”,则表示字段yyyy是一个map类型中的key,xxx为上下文中的map的名称。 env-name N 对应上下文中的key。如果属性“value”为空或者对应通过表达式取的值为空,此属性设置才有效。 value N 固定值或者以”${}”对应的变量值 format N “value”值格式化。格式化类型有: append:“env-name”不为空时有效,在“env-name”对应的值后面增加“value” to-upper:“value” 值转化为大写 to-lower:“value” 值转化为小写 hash-code:取“value” 值的hashcode long:将“value” 值转为long型 double:将“value” 值转化为double型 upper-first-char:将“value” 值的首字母转化为大写 lower-first-char:将“value” 值的首字母转化为小写 db-to-java:将“value” 值的转化为对应的java属性类型 java-to-db:将“value” 值的转化为对应的数据库字段类型 6.9.3 实体引擎配置文件 实体引擎配置 介绍 通过介绍entityengine.xml文件每个部分,说明现有的元素和它们的用法。文件位于framework/entity/config/entityengine.xml。 实体引擎通过一个简单的XML文件来配置,此文件为 entityengine.xml ,且该文件必须存放于类路径下。 这个文件是用来定义持久化服务器的参数,如EJB服务器参数或者JDBC服务器参数。 也可以用来指定用于服务器的XML实体模型,实体组和字段类型模型。 每个应用程序使用的实体引擎都必须是 GenericDelegator 的实例,该实例被称为“代理”对象。如果需要一个新的实例,通过 代理对象的名称构造代理对象。代理对象的名字被用来在 entityengine.xml 文件中查找对应的配置。 每个代理对象使用了一个实体模型的读取器和实体组的读取器,它为实体模型文件中的每个实体指定一组。 entityengine.xml 文件包含的设置每个组的名称映射到一个 GenericHelper 。 GenericHelper 是一个接口,每种数据源都必须实现它(例如JDBC和EJB的,SOAP和HTTP等等)。  每个GenericHelper 都在entityengine.xml 文件中的datsource 节点配置。 如果是JDBC配置包括JDBC的数据库连接的URI参数,驱动程序的参数,包括名称,和数据库的用户名和密码等。如果是JNDI,需配置JNDI的名称等属性。 配置文件格式及内容 配置文件模型 资源装载器 resource-loader 标签用来命名资源配置装载器,可用于其他地方加载XML和其他资源。  有以下属性: 属性 是否必须 说明 name Y 资源加载器的名称。用于其它标签的 “loader”属性。如:field-type标签。 class Y 这个类扩展自抽象类ResourceLoader。可用的类包括FileLoader、URLLoader和ClasspathLoader。 prepend-env N Java环境属性名用于放在prefix标签值的前面构成全路径。 prefix N 资源的路径,用于放在prepend-env属性值的后面构成全路径。 JTA元素 为支持JTA,实体引擎需要访问javax.transaction.UserTransaction,也可以访问javax.transaction.TransactionManager接口,为使用TXManager实现的。这些通过类com.bosent.core.entity.TransactionFactory实现。这个类可能会依据BOSENT运行使用的应用程序服务器或事务管理器的不同而改变。 默认的TX管理器使用Tyrex,来自Exolab(www.exolab.org)。Tyrex的工厂类是com.bosent.entity.transaction.TyrexFactory。最有用处的事务工厂类是com.bosent.core.entity.transaction.JNDIFactory类。这个类使用entityengine.xml中附加元素来定位JNDI中的UserTransaction和TransactionManager对象。 user-transaction-jndi和transaction-manager-jndi标签用来指定对象在JNDI中的名称以及要使用JNDI服务的名称。两个标签都有两个必须的属性:jndi-server-name和jndi-name。一个例子:UserTransaction对象的jndi-name值为java:comp/UserTransaction,TransactionManager对象的jndi-name值为java:comp/TransactionManager。 属性说明: 属性 是否必须 说明 class Y 事务工厂类名称 子元素: 属性 是否必须 说明 user-transaction-jndi N 自定义事务jndi配置 transaction-manager-jndi N 事务管理器jndi配置 连接工厂配置属性说明: 属性 是否必须 说明 class Y 连接工厂类名称 delegator元素 GenericDelagator通过一个使用一个包含delegator名称的String类型的参数的工厂类方法产生。delegator名称用来在entityengine.xml文件中查找delegator标签。 属性说明: 属性 是否必须 说明 默认值 name Y Delegator名称,使用这个名称用来查找这个标签 entity-model-reader Y delegator使用的entity-model-reader名称 entity-group-reader Y delegator使用的entity-group-reader名称 entity-eca-reader N delegator使用的entity-eca-reader名称 entity-eca-enabled N entity-eca-handler-class-name N distributed-cache-clear-enabled N distributed-cache-clear-class-name N distributed-cache-clear-user-login-in N sequenced-id-prefix N default-group-name N 子元素group-map属性说明: 属性 是否必须 说明 group-name Y 实体组名 datasource-name Y 实体组对应的数据源名称 field-type元素 field-type标签用来配置每个指定的字段类型。标签的name属性用来指名字段类型的名字。实体组加载器使用一个单独的XML文件来获取字段类型信息。 这个标签有两个需要的属性:loader用来指定使用哪个资源加载器,location指定了资源加载器内部加载资源使用的位置。 entity-group-reader元素 entity-group-reader标签用来设置每个指定的实体组加载器。标签的name属性用来指名实体组加载器的名字。实体组加载器使用一个单独的XML文件来获取实体组的映射信息。 这个标签有两个需要的属性: loader用来指定使用哪个资源加载器,location指定了资源加载器内部加载资源使用的位置。 entity-model-reader元素 entity-model-reader标签用来为每个指定的实体模型加载器。标签的name属性用来指定实体模型加载器的名字。每个加载器可能从多个资源中加载,其中每个资源使用标签中的resource标签来指定。 每个resource标签有两个必须的标签:loader用来指定使用哪个资源加载器,location指定了资源加载器内部加载资源使用的位置。 datasource元素 很多数据源都可以使用datasource标签设置,每个数据源对应一个数据源。 属性 是否必须 说明 默认值 name Y 数据源的名字 helper-class Y 可能有许多类型的数据源帮助类,主要的一个是JDBC/DAO帮助类。可以实现com.bosent.core.entity.GenericHelper接口编写自己的辅助类。JDBC/DAO帮助类就是com.bosent.core.entity.GenericHelperDAO field-type-name Y 要使用的字段类型的名字。必须和前面field-type标签定义的字段类型名字匹配 check-on-start N 启动时是否检查数据源?必须为true或false true add-missing-on-start N 当启动时检查数据源时,是否要添加不存在的实体?必须为true或false false use-foreign-keys N 对"one"类型的关系,是否使用/创建外键?必须为true或false true use-foreign-key-indices N 是否对外键使用/创建索引(也就是外键上的索引)?注意到这个属性起作用并不需要创建外键,索引只为定义为"one"类型的关系创建。必须为true或false true check-fks-on-start N 启动时是否检查外键,当需要时是否添加?必须为true或false。有些数据库会花费很长时间,并且不会返回所有外键列表,结果导致重复的外键会添加到数据库中 false check-fk-indices-on-start N 启动时是否检查外键索引,当需要时是否添加?必须为true或false false use-pk-constraint-names N 是否为主键使用约束名字?有些数据库对此有问题,但是如果给个名字就回工作正常。必须为true或false true constraint-name-clip-length N 指定约束名的最大长度。超出的将被裁掉。这样做时当心重复的约束名。必须为整数,默认为30。 fk-style N 指定外键语法(syntax)类型:命名为外键约束或仅仅外键。大多数数据库使用name_constraint语法,但是SAPDB这样做会出现异常,可能还有其他数据库也会这样。必须为"name_constraint"或"name_fk" name_constraint use-fk-initially-deferred N 指定在许多数据库中,当创建外键时使用INITIALLYDEFERRED选项是否可用。不是所有数据库都支持这个选项。当可用且数据库支持时,外键检查只有在事务提交时才会进行,这和在事务中检查外键恰恰相反。必须为true或false true join-style N 指定当在view-entity操作中做表联接时使用的语法。许多数据库采用标准的ANSIJOIN,但是在此之前theta联接更通用。支持两个theta连接类型:Oracle和MSSQL。必须为"ansi","theta-oracle"或"theta-mssql" ansi 子元素 属性 对应关系 说明 默认值 sql-load-path 0到多 用来指定目录的完整路径列表,用来查找XML和SQL文件在install页导入到数据源中 inline-jdbc 0或1 用来指定由Tyrex使用的JDBC参数或者当Tyrex不可用时直接加载驱动程序(非常慢)。必须为DAOHelper指定inline-jdbc或者jndi-jdbc jndi-jdbc 0或1 用来指定指定jndi-server和jndi-name来从JNDI获取一个连接或XAConnection。必须为DAOHelper指定inline-jdbc或者jndi-jdbc ANY 0或1 datasource标签中的任意标签,来为其他GenericHelper的实现类指定参数。只有在DTD文件中作了修改来描述他们,在加载时才会检查这些标签 sql-load-path 0到多 用来指定目录的完整路径列表,用来查找XML和SQL文件在install页导入到数据源中 inline-jdbc标签 有如下属性: 属性 对应关系 说明 默认值 jdbc-driver Y 数据库JDBC驱动程序类 jdbc-uri Y 用来指定数据库的类型和位置的URI jdbc-username Y 连接数据库用的用户名 jdbc-password Y 用户名的密码 isolation-level N 用来指定Tyrex事物隔离级别(isolationlevel),标准JDBC事务隔离级别有: ReadCommitted ReadUncommitted RepeatableRead Serializable None Serializable pool-maxsize N 连接池的最大数,如果配置错误,默认20 pool-minsize N 连接池的最小数,如果配置错误,默认2 pool-sleeptime N pool-lifetime N pool-deadlock-maxwait N pool-deadlock-retrywait N pool-jdbc-test-stmt N pool-xa-wrapper-class N jndi-jdbc标签 有如下属性 属性 对应关系 说明 默认值 jndi-server-name Y 要用的JNDI服务的名字 jndi-name Y 连接或XAC连接对象在JNDI中的名字 isolation-level N 用来指定Tyrex事物隔离级别(isolationlevel),标准JDBC事务隔离级别有: ReadCommitted ReadUncommitted RepeatableRead Serializable None Serializable 从JNDI重新得到的数据源应该使用连接池技术并可使用事务,如果JTA事物启动的话。这可能是DataSource对象或者XADataSource对象。 如果没有指定JNDI元素,连接工厂就会从entityengine.xml文件中取到,并试图使用Tyrex作为事物管理和连接池。如果Tyrex不可用实体引擎将会在每次接收到请求时创建一个连接,这时将会有警告信息。 实体配置   配置文件格式及内容 Entity of an Business Operation System None 。。。 None 1.0 …… 配置文件模型 entitymodel:实体配置顶层节点 子元素 说明 数量 title 实体配置文件名称  0-1个 description 实体配置文件描述  0-1个 copyright 版权信息 0-n个 auth 作者  0-n个 version 版本号 0-1个 entity 实体 0-n个 view-entity 视图  0-n个 extend-entity 扩展实体 0-n个 entity:实体节点 属性说明: 属性 是否必须 说明 默认值 entity-name Y 唯一的实体名称 table-name N 实体映射到表名 package-name Y 包名 default-resource-name N 缺省的资源文件名 dependent-on N 指定父级实体和依赖的实体,仅用来指定层次化实体结构 true sequence-bank-size N 序列号步长(一次缓存的序列号数量) enable-lock N 是否在这个实体上使用优化锁 false no-auto-stamp N 不自动创建四个时间戳字段 false never-cache N 从不缓存实体 false auto-clear-cache N 自动清除缓存 true title N 标题 copyright N 版权 author N 作者 version N 版本号 子元素: 子元素 说明 数量 description 实体描述 0-1个 field 字段 1-n个 prim-key 主键 0-n个 relation 实体关联 0-n个 index 索引 0-n个 view-entity:视图节点 属性说明: 属性 是否必须 说明 默认值 entity-name Y 唯一的实体名称 package-name Y 包名 default-resource-name N 缺省的资源文件名 dependent-on N 指定父级实体和依赖的实体,仅用来指定层次化实体结构 true never-cache N 从不缓存实体 false auto-clear-cache N 自动清除缓存 true title N 标题 copyright N 版权 author N 作者 version N 版本号 子元素: 子元素 说明 数量 description 实体描述 0-1个 member-entity 成员实体 1-n个 alias-all 所有别名 0-n个 alias 别名 0-n个 view-link 视图连接 0-n个 relation 实体关联 0-n个 extend-entity:扩展实体节点 属性: 属性 是否必须 说明 默认值 entity-name Y 唯一的实体名称   子元素: 子元素 说明 数量 field 字段 0-n个 relation 实体关联 0-n个 index 索引 0-n个 实体分组配置 配置文件格式及内容 entitygroup:实体分组配置顶层节点 子元素: 子元素 说明 数量 entity-group 实体分组定义 0-n个 entity-group:实体分组节点 属性: 属性 是否必须 说明 默认值 group Y 分组名   entity Y 实体名   实体ECA配置   配置文件格式及内容 配置文件模型 ECA节点 属性说明: 属性 是否必须 说明 默认值 entity Y 实体名称 operation Y 操作名称 event Y 事件名称 run-on-error N 操作失败时还是否执行eca false 子节点: 子元素 说明 数量 condition 普通实体条件 0-n个 condition-field 字段比较条件 0-n个 set 设置单个字段的值 1-n个 action Eca执行的动作 1-n个 condition:实体条件节点 属性说明: 属性 是否必须 说明 默认值 field-name Y 字段名   operation Y 操作名称 取值枚举:less、greater、less-equals、 greater-equals、equals、not-equals、is-empty、is-not-empty、contains   value N 操作的值对象   type N 字段类型 取值枚举:PlainString、String、BigDecimal、Double、Float、Long、Intege、:Date、Time、Timestamp、Boolean、Object   format N 字段格式   set:实体SET节点 属性说明: 属性 是否必须 说明 默认值 field-name Y 字段名   env-name Y 变量名(用来存储字段的值)   value N 操作的值对象   format N 字段格式 取值枚举:append、to-upper、to-lower、hash-code、long、double、upper-first-char、lower-first-char、db-to-java、java-to-db condition-field:实体字段条件节点 属性说明: 属性 是否必须 说明 默认值 field-name Y 字段名   operation Y 操作名称 取值枚举:less、greater、less-equals、 greater-equals、equals、not-equals、contains   to-field-name N 比较的字段名   type N 字段类型 取值枚举:PlainString、String、BigDecimal、Double、Float、Long、   Intege、:Date、Time、Timestamp、Boolean、Object format N 字段格式 action:实体动作节点 属性说明: 属性 是否必须 说明 默认值 service Y 服务名 mode Y 运行模式(同步/异步) 取值:sync/async result-to-value N 把运行结果更新到实体对象(GenericEntity)当中 true abort-on-error N 当发生错误时终止操作 false rollback-on-error N 当发生错误时回滚操作 false persist N 当运行模式为异步执行时,是否对操作进行持久化 false run-as-user N 操作执行者 system value-attr N 引用实体对象变量名 6.9.4 迷你语言配置文件 simple-methods 配置文件格式及内容 配置文件模型 属性说明: 属性 是否必须 说明 默认值 method-name Y 方法名称   Short-description Y 方法描述   login-required N 是否需要登录  true use-transaction N 是否启用事务  true default-error-code N 默认错误返回码 error default-success-code N 没人成功返回码 success parameter-map-name N 方法入参名 事件:request入参的拷贝 服务:输入的上下文参数 parameters event-request-object-name N 事件请求对象名 request event-response-object-name N 事件响应对象名 response event-response-code-name N 事件响应码标识 _response_code_ event-error-message-name N 事件错误消息标识 _error_message_ event-event-message-name N 事件消息标识 _event_message_ service-response-message-name N 服务响应消息标识 responseMessage service-error-message-name N 服务错误消息标识 errorMessage service-error-message-list-name N 服务错误消息列表标识 errorMessageList service-error-message-map-name N 服务错误消息map对象标识 errorMessageMap service-success-message-name N 服务成功返回消息标识 successMessage service-success-message-list-name N 服务成功消息列表标识 successMessageList locale-name N 语言环境标识 locale delegator-name N 实体引擎标识 delegator security-name N 安全管理器对象标识 security dispatcher-name N 服务引擎标识 dispatcher user-login-name N userLogin标识 userLogin 子元素: 子元素 说明 数量 CallOperations 调用操作的父操作:在simple method中可调用其他的服务、事件、beanSheel脚本等,实现的子操作有:call-map-processor、set-service-fields、call-service、call-service-asynch、call-bsh、call-simple-method、call-object-method、call-class-method、create-object 0-n个 EventOperations 事件操作的父操作,实现的子操作有:field-to-request、field-to-session、request-to-field、request-parameters-to-list、session-to-field、webapp-property-to-field 0-n个 ServiceOperations 服务操作的父操作,实现的子操作有:field-to-result 0-n个 EnvOperations 上下文相关父操作,实现的子操作有: map-to-map、field-to-list、list-to-list 、order-map-list、set、string-append、string-to-list、to-string、clear-field、first-from-list 0-n个 EntityMiscOperations 实体相关父操作,实现的子操作有: sequenced-id、make-next-seq-id、entity-data 0-n个 EntityFindOperations 实体查询父操作,实现的子操作有: find-by-primary-key、find-by-and、entity-one、entity-and、entity-condition、entity-count、get-related-one、get-related、order-value-list、filter-list-by-and、filter-list-by-date 0-n个 EntityValueOperations 实体对象父操作,实现的子操作有: make-value、clone-value、create-value、store-value、refresh-value、remove-value、remove-related、remove-by-and、clear-cache-line、clear-entity-caches、set-pk-fields、set-nonpk-fields 0-n个 EntityListOperations 实体列表父操作,实现的子操作有: store-list、remove-list 0-n个 EntityTxOperations 实体事务父操作,实现的子操作有: transaction-rollback、transaction-commit、transaction-begin 0-n个 ControlOperations 控制相关父操作,实现的子操作有: Iterate、iterate-map、loop、check-errors、add-error、return 0-n个 IfBasicOperations 基本的条件判断父操作,实现的子操作有:if-validate-method、if-instance-of、if-compare、if-compare-field、if-regexp、if-empty、if-has-permission 0-n个 IfOtherOperations 其他条件判断父操作,实现的子操作有:Assert、if、while、if-not-empty、check-permission、check-id 0-n个 OtherOperations 其他父操作,实现的子操作有:Log、now-timestamp、now-date-to-env、property-to-field、set-current-user-login、calculate、set-calendar 0-n个 simpl-map-processors 配置文件格式及内容 配置文件模型 属性说明: 属性 是否必须 说明 默认值 name Y simple-map-processor方法名称   子元素: 子元素 说明 数量 make-in-string 根据几个输入参数来创建另外一个参数,如根据导出月份(expMonth)和导出年份(expYear)来创建导出日期(expDate)。  0-n个 process 输入参数处理标签,用来入参拷贝、校验等  0-n个

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享文档获得金币 ]
10 人已下载

下载文档

相关文档