BOS软件架构文档.docx

1、BOS软件架构文档软件构架文档 项目Id项目名称BOS4.1部门经理彭璐项目经理张勇修改记录Ver. No发版日期作者审核人改动的章节号1.0Needle软件构架文档 1.简介BOS内核是一个构建大型应用系统的基础平台(Infrastructure),开发人员、需求分析人员、实施人员、二次开发人员和最终用户，可以利用这个平台提供的工具来构建和定制应用系统。此平台主要有两个目标一个是提高应用的开发效率，标准化开发过程，提升软件质量；另外一个是给最终用户，实施人员，二次开发人员提供简便快捷的开发和配置工具，使他们可以快速搭建应用，来满足用户的个性化需求。 BOS采用模型驱动架构(MDA)的思想搭建

2、，BOS内部的引擎和基于BOS搭建的应用都是以元模型来驱动的。采用模型驱动的架构架构使整个应用具有极好的可扩展性，灵活性和开发性。 本文从用例视图，逻辑视图，进程视图和部署视图，来描述BOS的静态和动态结构。本架构不包含工作流引擎和相关工具的描述，工作流系统可以看成是应用系统的有机组成部分，而不属于BOS内核。2.用例视图本小节描述了BOS的用户，和BOS提供给这些用户的功能。角色 操作BOS的人员从建模角度分主要包括业务建模人员和设计建模人员。业务建模人员利用BOS进行粗粒度建模，面向的是业务层面，主要包括对业务数据，业务流程和部分简单业务逻辑进行建模；设计建模人员BOS进行细粒度建模，面向

3、的是设计层面，主要完成对象建模，数据库建模，UI建模，工作流建模，对象模型和数据库模型的映射，对象模型和工作流模型的映射等。 业务建模人员包括需求分析人员，最终用户，实施人员和开发人员；设计建模人员包括开发人员。二次开发人员是开发人员的一种，他和开发人员的区别是，二次开发人员的工作任务是面向已经发布的产品。业务建模业务建模人员主要维护业务数据、业务工作、业务流程。业务数据指的是应用系统中具体业务对象的属性，如企业的基础数据、单据或帐薄等。业务工作是对业务数据上操作的逻辑封装，是用来维护业务数据的。业务流程有机的将业务数据和业务工作组织在一起。设计建模设计建模人员主要维护实体、功能、查询、界面、

4、数据和业务功能对象。这些对象在设计模型中会详细介绍。3.模型视图业务模型视图（无，需要BIM补充）设计模型视图BOS设计模型分为三层MetaMetaModel, MetaModel, Model，上一层模型描述了下一层模型的结构，如下图：其中上一层定义了下一层的结构，也就是元元模型定义了元模型的机构，元模型定义了模型的结构。其中元元模型是BOS内置的模型层，只是用来驱动元模型引擎的。3.1.1元元模型(MetaMetaModel)元模型包含包，实体，属性，关系，数据类型和逻辑键。包是用来物理划分元数据模块的，实体对象只包含属性和逻辑键。属性分为自有属性和连接属性，自有属性的数据类型为基本类型。

5、连接属性用来关联其它实体。实体通过逻辑键来唯一标识。3.1.2元模型(MetaModel)元元模型是元模型的一个子集，在我们的设计中没有明确区分元模型和元元模型，只有在元数据装载引擎内部处理了元元模型。元模型包含三个层次，数据对象(DataObject)，业务对象(BusinessObject)和界面对象(UIObject)。其中数据对象包括数据表，扩展表和交叉表。业务对象主要包括实体对象，功能对象和业务功能对象。界面对象包括UI定义。业务模型和设计模型的映射业务模型主要包括业务单元，业务单元封装了底层的实体，数据对象，查询对象，规则，UI对象和功能对象，是从业务的角度来展示设计模型。4.逻辑

6、视图本视图描述了BOS运行期和设计期间的架构特性，BOS运行期组件图和BOS为设计期和运行期提供的组件。BOS架构特性BOS平台架构特性支持多语言支持多数据库多操作系统支持RichClieng&Browser提供嵌入式工作流引擎(?)BOS实现模型架构特性支持O/R Mapping管理(包括面向对象的查询服务)支持WebService支持J2EE采用声明式管理事务支持运行时修改业务逻辑支持多维报表支持缓存服务提供自动更新服务提供任务调度服务提供消息服务提供异步处理机制提供强大的应用框架BOS组件视图BOS提供了丰富的业务组件来支持上述特性，如下图：包括元数据管理引擎，O/R Mapping管理

7、引擎，调度服务，消息服务，工作流引擎，ORM-RPC引擎，WebService引擎，Web框架，GUI框架，多维报表服务，多数据库支持引擎KSQL，业务对象转换平台BOTP，自动更新组件等。BOS工具集我们通过设计期间的建模工具，以及配置管理工具来完成业务建模和设计建模，以及模型的发布，部署管理。5.进程视图BOS进程相关的组件主要包括客户端(GUI/Web)，ORM-RPC服务器, J2EE服务器和数据库服务器。其中客户端和数据库服务器肯定是在单独的进程中运行的，但是ORM-RPC和J2EE服务器可以部署在一个进程中，也可以部署在单独的进程中，下面的小节描述了这两种模式的进程视图，以及这些进

8、程间的通讯方式。下面的小节只描述了客户端为GUI的经常视图(EAS目前主要采用的模式)，没有描述基于客户端是Web的进程视图。ORM-RPC和J2EE服务器分别部署在不同的进程中 从上图可以看出Client, ORM-RPC，J2EE Application Server，Database分别部署在不同的进程中，其中他们的交互关系是Client访问ORM-RPC服务器里面的Remoting代理组件，Remoting代理组件再访问应用服务器中的业务组件，业务组件再和数据库服务器交互。其中ORM-RPC Server支持TCP/HTTP两种通信协议，客户端根据应用场景，在连接服务器时可以使用TCP

9、协议，也可以使用HTTP协议。通常在LAN中使用TCP协议，在WAN中使用HTTP协议，并且为了减小网络负载通常采用压缩功能。ORM-RPC采用RMI-IIOP协议访问应用服务器中的业务组件EJB(Stateless SessionBean)。IIOP协议是一种重量级的通信协议，在传输复杂对象时，需要复杂的Marshal和UnMarshal计算，对服务器的CPU和Memory有极大的消耗，经过我们测试Apusic的RMI-IIOP协议实现，在传输复杂对象时，性能要比Java标准序列化慢3050倍。不幸的是，BOS设计的网络模型中要传输的对象都是极其复杂的值对象(ValueObject),因此这

10、种进程视图虽然在理论上使成立，并可用的，但是在实际的应用中我们已经放弃采用这种模式。业务组件EJB和数据库服务器的交互方式，我们采用标准的JDBC，这种方式是工业标准，这里就不加描述啦！ORM-RPC和J2EE服务器部署在一个进程中该小节的进程视图和上面小节进程视图之间的唯一差异是将ORM-RPC服务放到了应用服务器的进程中。对于客户端来说完全透明，客户端还是可以任意采用TCP或者HTTP协议来和ORM-RPC服务通信，但我们要注意的是运行在ORM-RPC服务中的Remoting代理，和业务组件EJB的交互方式。为了提高性能，J2EE EJB2.0规范中新增了EJBLocal的概念，采用这种方

11、式访问EJB将可以采用Pass-by-Reference的方式来访问EJB，这种方式要比原来的Pass-by-Value方式，减少一次对象的Marshal和UnMarshal，从而可以大大改善ORM-RPC Remoting代理和业务组件的通信成本。注意：BOS目前生成的部署文件，只能在Apusic上使用Local模式，不能在Weblogic和Websphere上使用；但是WebSphere提供了Pass-by-reference的选项， 设置此选项作用与Local方式调用效果一样；据称Weblogic可以将一个进程里面的调用，自动转换为Pass-by-Reference，如果这样Remoti

12、ng Proxy在Weblogic上采用Remote方式调用EJB性能也没有问题。(没有在Weblogic上验证此特性)6.部署视图进程视图主要分析了基于BOS应用进程间的通信方式，以及各个进程间的通信成本，为了性能我们采用将ORM-RPC服务纳入到应用服务器进程中的方式，这种方式会影响基于BOS产品的最终的部署模型。部署视图要考虑整个应用的性能（吞吐量）和可伸缩性，当然还要考虑可用性和易用性。由于应用的规模不同，我们要考虑用不同的部署方式来使应用可以满足需求。我们提供的部署方式共有两种，一种是小规模应用部署模式，一种是大规模应用部署模式。在开发和演示期间，我们可以采用小规模应用的部署模式，并

13、通过一些优化策略（如采用非EJB模式，元数据采用惰性加载等）来降低对资源的消耗。 小规模应用小规模应用的部署模型和进程视图基本一致，但是在部署视图里面我们可以更清楚的看到，ORM-RPC服务同时提供了TCP/HTTP的支持，同时客户端还可以选择是否采用压缩，注意压缩功能是客户端发起的。这样客户端和服务器的通信模式就有四种组合：TCP, HTTP, TCP + Compress, HTTP + Compress。 客户端可以根据网络状况来选择不同的通信模式。大规模应用6.1.1集群为了能够支持更多的并发用户，并且通过简单的增强一台服务器配置，服务器已经不能满足并发压力啦，我们必须考虑采用集群的方

14、式来解决这个问题。由于一些应用服务器本身没有提供EJB Container的集群功能，但为了在这些应用服务器上支持大规模的应用，我们在ORM-RPC服务上提供了集群功能，这样我们的应用的伸缩性就不依赖与应用服务器的集群功能啦。除了上面这个原因外，采用EJB的集群我们必须要用到EJB Remote Interface，这样在进程视图描述的性能杀手(复杂对象在传输效率极低)又浮现出来啦，所以综合考虑我们的应用模式在软件集群这个层次只能采用ORM-RPC提供的集群功能，而不能采用应用服务器自身提供的EJB集群功能。除了利用软件做集群外，我们还可以使用工业标准，采用硬件来做集群，比如Net Switc

15、h来完成应用的集群，此功能没有在此部署模型中体现。我们的集群不是对称的，分为Master Server,和Slave Server。在一个集群中Master Server只能部署一台，Salve Server可以部署多台，Master Server部署了工作流引擎，消息中心等。6.1.2集群实现策略ORM-RPC提供的Load Balance Router是基于连接级别的，而不是基于对象级别的。6.1.3工作流引擎的部署工作流引擎需要支持该部署模式。6.1.4缓存的使用为了提升性能我们肯定会在服务器端使用缓存，在集群环境中必须要考虑缓存的同步更新。6.1.5消息中心为了简化部署模型，我们将消息中心部署在了Master Server中，消息中心需要支持该部署模式。6.1.6唯一编码生成唯一编码生成策略，不能利用本地文件来记录自增序号，需要采用数据库或者其它方式作为中间介质，来支持该部署模式。部署模型带来的问题License管理，我们的License管理是基于业务功能呢，还是与站点数相关?