BOS软件架构文档.docx

BOS软件架构文档.docx

《BOS软件架构文档.docx》由会员分享，可在线阅读，更多相关《BOS软件架构文档.docx（14页珍藏版）》请在冰豆网上搜索。

BOS软件架构文档

<项目名称>

软件构架文档

项目Id

项目名称

BOS4.1

部门经理

彭璐

项目经理

张勇

修改记录

Ver.No

发版日期

作者

审核人

改动的章节号

1.0

Needle

软件构架文档

1.简介

BOS内核是一个构建大型应用系统的基础平台（Infrastructure）,开发人员、需求分析人员、实施人员、二次开发人员和最终用户，可以利用这个平台提供的工具来构建和定制应用系统。

此平台主要有两个目标一个是提高应用的开发效率，标准化开发过程，提升软件质量；另外一个是给最终用户，实施人员，二次开发人员提供简便快捷的开发和配置工具，使他们可以快速搭建应用，来满足用户的个性化需求。

BOS采用模型驱动架构（MDA）的思想搭建，BOS内部的引擎和基于BOS搭建的应用都是以元模型来驱动的。

采用模型驱动的架构架构使整个应用具有极好的可扩展性，灵活性和开发性。

本文从用例视图，逻辑视图，进程视图和部署视图，来描述BOS的静态和动态结构。

本架构不包含工作流引擎和相关工具的描述，工作流系统可以看成是应用系统的有机组成部分，而不属于BOS内核。

2.用例视图

本小节描述了BOS的用户，和BOS提供给这些用户的功能。

角色

操作BOS的人员从建模角度分主要包括业务建模人员和设计建模人员。

业务建模人员利用BOS进行粗粒度建模，面向的是业务层面，主要包括对业务数据，业务流程和部分简单业务逻辑进行建模；设计建模人员BOS进行细粒度建模，面向的是设计层面，主要完成对象建模，数据库建模，UI建模，工作流建模，对象模型和数据库模型的映射，对象模型和工作流模型的映射等。

业务建模人员包括需求分析人员，最终用户，实施人员和开发人员；设计建模人员包括开发人员。

二次开发人员是开发人员的一种，他和开发人员的区别是，二次开发人员的工作任务是面向已经发布的产品。

业务建模

业务建模人员主要维护业务数据、业务工作、业务流程。

业务数据指的是应用系统中具体业务对象的属性，如企业的基础数据、单据或帐薄等。

业务工作是对业务数据上操作的逻辑封装，是用来维护业务数据的。

业务流程有机的将业务数据和业务工作组织在一起。

设计建模

设计建模人员主要维护实体、功能、查询、界面、数据和业务功能对象。

这些对象在设计模型中会详细介绍。

3.模型视图

业务模型视图

（无，需要BIM补充）

设计模型视图

BOS设计模型分为三层MetaMetaModel,MetaModel,Model，上一层模型描述了下一层模型的结构，如下图：

其中上一层定义了下一层的结构，也就是元元模型定义了元模型的机构，元模型定义了模型的结构。

其中元元模型是BOS内置的模型层，只是用来驱动元模型引擎的。

3.1.1元元模型（MetaMetaModel）

元模型包含包，实体，属性，关系，数据类型和逻辑键。

包是用来物理划分元数据模块的，实体对象只包含属性和逻辑键。

属性分为自有属性和连接属性，自有属性的数据类型为基本类型。

连接属性用来关联其它实体。

实体通过逻辑键来唯一标识。

3.1.2元模型（MetaModel）

元元模型是元模型的一个子集，在我们的设计中没有明确区分元模型和元元模型，只有在元数据装载引擎内部处理了元元模型。

元模型包含三个层次，数据对象（DataObject），业务对象（BusinessObject）和界面对象（UIObject）。

其中数据对象包括数据表，扩展表和交叉表。

业务对象主要包括实体对象，功能对象和业务功能对象。

界面对象包括UI定义。

业务模型和设计模型的映射

业务模型主要包括业务单元，业务单元封装了底层的实体，数据对象，查询对象，规则，UI对象和功能对象，是从业务的角度来展示设计模型。

4.逻辑视图

本视图描述了BOS运行期和设计期间的架构特性，BOS运行期组件图和BOS为设计期和运行期提供的组件。

BOS架构特性

BOS平台架构特性

●支持多语言

●支持多数据库

●多操作系统

●支持RichClieng&Browser

●提供嵌入式工作流引擎（?

?

?

）

BOS实现模型架构特性

●支持O/RMapping管理（包括面向对象的查询服务）

●支持WebService

●支持J2EE

●采用声明式管理事务

●支持运行时修改业务逻辑

●支持多维报表

●支持缓存服务

●提供自动更新服务

●提供任务调度服务

●提供消息服务

●提供异步处理机制

●提供强大的应用框架

BOS组件视图

BOS提供了丰富的业务组件来支持上述特性，如下图：

包括元数据管理引擎，O/RMapping管理引擎，调度服务，消息服务，工作流引擎，ORM-RPC引擎，WebService引擎，Web框架，GUI框架，多维报表服务，多数据库支持引擎KSQL，业务对象转换平台BOTP，自动更新组件等。

BOS工具集

我们通过设计期间的建模工具，以及配置管理工具来完成业务建模和设计建模，以及模型的发布，部署管理。

5.进程视图

BOS进程相关的组件主要包括客户端（GUI/Web），ORM-RPC服务器,J2EE服务器和数据库服务器。

其中客户端和数据库服务器肯定是在单独的进程中运行的，但是ORM-RPC和J2EE服务器可以部署在一个进程中，也可以部署在单独的进程中，下面的小节描述了这两种模式的进程视图，以及这些进程间的通讯方式。

下面的小节只描述了客户端为GUI的经常视图（EAS目前主要采用的模式），没有描述基于客户端是Web的进程视图。

ORM-RPC和J2EE服务器分别部署在不同的进程中

从上图可以看出Client,ORM-RPC，J2EEApplicationServer，Database分别部署在不同的进程中，其中他们的交互关系是Client访问ORM-RPC服务器里面的Remoting代理组件，Remoting代理组件再访问应用服务器中的业务组件，业务组件再和数据库服务器交互。

其中ORM-RPCServer支持TCP/HTTP两种通信协议，客户端根据应用场景，在连接服务器时可以使用TCP协议，也可以使用HTTP协议。

通常在LAN中使用TCP协议，在WAN中使用HTTP协议，并且为了减小网络负载通常采用压缩功能。

ORM-RPC采用RMI-IIOP协议访问应用服务器中的业务组件EJB（StatelessSessionBean）。

IIOP协议是一种重量级的通信协议，在传输复杂对象时，需要复杂的Marshal和UnMarshal计算，对服务器的CPU和Memory有极大的消耗，经过我们测试Apusic的RMI-IIOP协议实现，在传输复杂对象时，性能要比Java标准序列化慢30~50倍。

不幸的是，BOS设计的网络模型中要传输的对象都是极其复杂的值对象（ValueObject）,因此这种进程视图虽然在理论上使成立，并可用的，但是在实际的应用中我们已经放弃采用这种模式。

业务组件EJB和数据库服务器的交互方式，我们采用标准的JDBC，这种方式是工业标准，这里就不加描述啦！

ORM-RPC和J2EE服务器部署在一个进程中

该小节的进程视图和上面小节进程视图之间的唯一差异是将ORM-RPC服务放到了应用服务器的进程中。

对于客户端来说完全透明，客户端还是可以任意采用TCP或者HTTP协议来和ORM-RPC服务通信，但我们要注意的是运行在ORM-RPC服务中的Remoting代理，和业务组件EJB的交互方式。

为了提高性能，J2EEEJB2.0规范中新增了EJBLocal的概念，采用这种方式访问EJB将可以采用Pass-by-Reference的方式来访问EJB，这种方式要比原来的Pass-by-Value方式，减少一次对象的Marshal和UnMarshal，从而可以大大改善ORM-RPCRemoting代理和业务组件的通信成本。

注意：

BOS目前生成的部署文件，只能在Apusic上使用Local模式，不能在Weblogic和Websphere上使用；但是WebSphere提供了Pass-by-reference的选项，设置此选项作用与Local方式调用效果一样；据称Weblogic可以将一个进程里面的调用，自动转换为Pass-by-Reference，如果这样RemotingProxy在Weblogic上采用Remote方式调用EJB性能也没有问题。

（没有在Weblogic上验证此特性）

6.部署视图

进程视图主要分析了基于BOS应用进程间的通信方式，以及各个进程间的通信成本，为了性能我们采用将ORM-RPC服务纳入到应用服务器进程中的方式，这种方式会影响基于BOS产品的最终的部署模型。

部署视图要考虑整个应用的性能（吞吐量）和可伸缩性，当然还要考虑可用性和易用性。

由于应用的规模不同，我们要考虑用不同的部署方式来使应用可以满足需求。

我们提供的部署方式共有两种，一种是小规模应用部署模式，一种是大规模应用部署模式。

在开发和演示期间，我们可以采用小规模应用的部署模式，并通过一些优化策略（如采用非EJB模式，元数据采用惰性加载等）来降低对资源的消耗。

小规模应用

小规模应用的部署模型和进程视图基本一致，但是在部署视图里面我们可以更清楚的看到，ORM-RPC服务同时提供了TCP/HTTP的支持，同时客户端还可以选择是否采用压缩，注意压缩功能是客户端发起的。

这样客户端和服务器的通信模式就有四种组合：

TCP,HTTP,TCP+Compress,HTTP+Compress。

客户端可以根据网络状况来选择不同的通信模式。

大规模应用

6.1.1集群

为了能够支持更多的并发用户，并且通过简单的增强一台服务器配置，服务器已经不能满足并发压力啦，我们必须考虑采用集群的方式来解决这个问题。

由于一些应用服务器本身没有提供EJBContainer的集群功能，但为了在这些应用服务器上支持大规模的应用，我们在ORM-RPC服务上提供了集群功能，这样我们的应用的伸缩性就不依赖与应用服务器的集群功能啦。

除了上面这个原因外，采用EJB的集群我们必须要用到EJBRemoteInterface，这样在进程视图描述的性能杀手（复杂对象在传输效率极低）又浮现出来啦，所以综合考虑我们的应用模式在软件集群这个层次只能采用ORM-RPC提供的集群功能，而不能采用应用服务器自身提供的EJB集群功能。

除了利用软件做集群外，我们还可以使用工业标准，采用硬件来做集群，比如NetSwitch来完成应用的集群，此功能没有在此部署模型中体现。

我们的集群不是对称的，分为MasterServer,和SlaveServer。

在一个集群中MasterServer只能部署一台，SalveServer可以部署多台，MasterServer部署了工作流引擎，消息中心等。

6.1.2集群实现策略

ORM-RPC提供的LoadBalanceRouter是基于连接级别的，而不是基于对象级别的。

6.1.3工作流引擎的部署

工作流引擎需要支持该部署模式。

6.1.4缓存的使用

为了提升性能我们肯定会在服务器端使用缓存，在集群环境中必须要考虑缓存的同步更新。

6.1.5消息中心

为了简化部署模型，我们将消息中心部署在了MasterServer中，消息中心需要支持该部署模式。

6.1.6唯一编码生成

唯一编码生成策略，不能利用本地文件来记录自增序号，需要采用数据库或者其它方式作为中间介质，来支持该部署模式。

部署模型带来的问题

License管理，我们的License管理是基于业务功能呢，还是与站点数相关?