企业集团办公自动化系统概要设计Word格式.docx
《企业集团办公自动化系统概要设计Word格式.docx》由会员分享，可在线阅读，更多相关《企业集团办公自动化系统概要设计Word格式.docx（25页珍藏版）》请在冰点文库上搜索。
部署集团总部应用、涉及到集团全局的一些应用。
●单分部服务器（群）
部署某个分部的应用
●多分部服务器（群）
部署多个分部的应用
5.复制关系拓扑
由于采用单域的结构，主服务器在公司总部，各分部也需要放置服务器，所有分部服务器和主服务器之间需要保持双向复制（包括公用通讯录），为了避免给主服务器的整体性能带来很大影响，建议在主服务器和分部服务器间增加一个Hub服务器，主服务器与Hub服务器之间进行同步，Hub服务器再与各分局服务器作同步，这样主服务器的复制部分的开销就很小了。
6.域拓扑结构
域是共享相同Domino目录的Domino服务器和用户的集合，所有Domino服务器和用户都在某一个Domino目录中。
域的主要功能是邮件路由。
域的所有属性都包含在该域的Domino目录中，并通过Domino目录管理域。
域中每个服务器都保存Domino目录的一份拷贝。
域拓扑定义在一个机构中需要多少个域，这些域之间的关系及如何相互作用以满足业务需要。
域拓扑的目标是提供一个可管理的，可支持的和优化的Domino/Notes基础设施。
一般一个组织中有两种Domino域模式，单域和多域。
单域适合集中管理模式；
多域适合分散管理模式，适合于前面提到的多网络域分布式系统部署方式。
单域易于维护和管理，邮件路由也较简单，适合于前面提到的大集中式系统部署和大网络域分布式系统部署的方式。
一般而言，集团办公系统中更常见的是使用单域方式。
因此下文将主要讨论单生产域的相关设计与设置。
6.1.单生产域的拓扑结构
如下图所示，除了集团公司生产域，为了与其它外部Domino域建立连接，同时又保证生产域系统的安全，需要定义外部连接域，并用该域与外部域、集团公司的生产域进行交叉验证。
该外部连接域将作为生产域和外部域进行邮件路由和复制的桥梁。
按照这种设计，外部访问者只可以连接外部连接域的服务器，而不可以直接访问生产域的任何服务器（注：
上述连接均指Domino连接和Domino邮件连接）。
生产域和外部连接域之间的交叉验证只限于服务器间，验证字间的交叉验证是不必要的，且应严格禁止。
另外，为了应用开发和测试，一般还要定义一个或多个应用开发和测试域。
这些域将把开发和测试环境和生产环境分开，并保证生产域的安全、可靠和正常运行。
图5单生产域的拓扑结构
7.节点OA服务器（群）规划方案
对于集团型企业而言，由于人员、业务分布、负载类型的不平衡，在一些瓶颈节点上往往使用不止一台OA服务器，通过建立群集、复制等方式，可以实现系统的高效率和高可用性要求。
下面将会讨在企业应用拓扑图节点上可能使用的几种OA服务器（群）结构。
7.1.单服务器单Domino
最常用的形式，优点是配置、实施、维护简单；
缺点是在相同负载条件下对硬件配置要求高，容易出现性能瓶颈，而且不同应用运行在同一个Domino服务器上，某一个应用的负载过重或有缺陷都可能导致整个服务器的不稳定。
]
7.2.单服务器多Domino分区服务器
由于在一台服务器上运行多个Domino分区，因此对硬件配置的要求很高，适用于应用的负载大都很小，但服务器硬件配置很高的情况。
可以通过对分区资源的分配来避免出现负载的不均衡。
与1相比，可用性有了很大提高，但对硬件的要求更高了，所以一般并不常见。
7.3.双服务器方案
随着企业规模的扩大，用户数和负载的增加，单纯挖掘一台服务器的潜力往往不能满足我们对系统响应时间和稳定性、可用性的要求。
因此我们又在此提出几种基于双服务器的改良的服务器规划方案。
这几种方案的核心是将企业级的应用与邮件服务的负载分开。
因为以我们多年的项目实施经验来看，企业邮件服务的负荷往往比较最重，将其从应用服务器上单独剥离出来，有助于提高办公系统的整体性能和稳定性。
7.3.1.方案一：
将mail服务和app服务放置在两台机器上，mail和app的数据分离，两台机器处理各自的任务同时对另一部分任务互为热备份；
此方案：
每台机器只运行一个DOMINO，服务器性能状态较好。
由于应用数据目录与邮件数据目录存在复制关系，当一台机器宕机时，所有数据保证在另一台服务器上。
但必须保证所有访问指向活动服务器。
此性能需要对DNS的配置。
此方案可实现失效转移，但不能实现平衡负载。
若这两个DOMINO作成一个群集，亦可实现平衡负载。
7.3.2.方案二：
两台机器分别建立两个Domino分区服务器，装载相同的全部应用（APP、MAIL），建立两套相互复制的数据库，通过ICM进行负载均衡及失效转移。
此方案不牵涉DNS的切换，理论上，其中一台服务器宕机或某个分区服务器失效都不会影响到系统的可用性。
同时也可以避免有效负载的不均衡，所以是理论上非常好的方案。
但是对于ICM本身的稳定性、对系统性能的影响和分区服务器对性能的影响曲线，我们还比较缺乏实际数据，因此不一定能够达到理想的性能。
7.3.3.方案三：
还有一种替代方案是：
所有的邮件Domino分区服务器使用相同的物理文件位置，所有的应用Domino分区服务器也使用相同的物理文件位置。
正常情况下，每台服务器只且应该只启动一个DOMINO分区（分别对应邮件或应用）。
当某台机器宕机，另外一台机器上的备份分区服务器启动，全部应用转移到此DOMINO上
这种方案不需要进行比较消耗资源的复制任务，也是一种性能较好的的满足失效转移的方案
7.3.4.方案四：
一台机器承担全部负载，另外一台平时不工作，只作为备份机（热备份）使用（Master－Slave结构）。
利用操作系统级的CLUSTER，当某台机器宕机时，操作系统会自动启动另一台服务器。
平时只有一台机器处于工作状态，另一台待机状态。
特点：
优点是配置相对简单，Domino现有应用无需修改，不需要进行Domino复制，对主服务器性能影响小，系统的稳定性和可用性都非常好。
缺点是空置一台服务器，未承接任何负载，经济性不好。
本方案适用于对稳定性和可用性要求较高的情况。
7.4.服务器群
在某个节点上增加更多的服务器来分担负载，以满足更大的系统负荷。
这需要根据实际情况和负载类型来分别考虑，就不在这里讨论了。
8.集团用户注册方案
用户的web端自动注册功能并不是企业集团办公自动化的必需功能，而是增值服务，用以简化各级系统管理员的工作和提供额外的注册验证功能。
事实上，如果企业集团的各级系统管理员都是经验丰富的Domino管理员，用户的web端自动注册功能可以不提供，以节省用户预算和简化开发维护工作量。
8.1.验证拓扑与验证方案
所有验证标识符文件名均采用英文或拼音缩写，文件扩展名为cid。
●系统管理员验证字
用于验证在整个集团办公系统中具有系统管理员权限的特殊用户，用于提供更高的管理安全性和灵活性；
●服务器验证字
用于验证整个集团办公系统中的所有服务器，使服务器与部门的安全特性分开；
●用户验证字
用户验证使用几级验证字，应参考集团办公系统的用户注册节点的拓扑结构。
事实上，Domino用户管理的一个特色就是允许分布式的用户注册与管理。
用户注册节点的拓扑结构需要综合考虑企业集团的组织机构拓扑与分布和系统管理人员的分布特点。
从我们面向项目开发的目标来看，这里需要考虑灵活性和可配置性。
解决的办法是将注册用户的模块应用化――即在办公节点中，是否包含和使用用户注册模块和注册功能的分布化都是可以配置的。
这里不建议用户注册节点过于分散化，这会带来管理和维护的复杂化。
当然，有一种简化的方法是所有的用户注册都使用相同的验证字层次，以最深的注册节点层次为准，上层的注册节点的所注册的用户以该层组织单元名称补齐所缺的层次。
这样可以减少所需验证字的的个数，并简化管理节点范围内用户迁移的工作。
下面以两级组织单元为例：
总公司的直属用户使用验证字为如下形式：
/总公司/总公司/集团缩写
分公司的直属用户使用验证字为如下形式：
/分公司/分公司/集团缩写
分公司下面部门注册节点的直属用户使用验证字为如下形式：
/部门/分公司/集团缩写
8.2.用户命名和重名问题方案
8.2.1.用户命名方案
要求所有验证字都支持等价语言：
简体中文。
用户中文姓名填写在“姓”一栏作为用户名；
用户名在同一组织单元下不允许重复。
用户姓名缩写（方案依用户习惯而定，建议姓全拼+名拼音缩写）作为用户ID，集团公司生产域（同一公共地址簿内）不能重复。
8.2.2.重名解决方案
●如果在不同验证字下出现用户重名，由于其用户全名不会重复，因此依然使用上面的命名方案。
●如果在同一个验证字下出现用户重名，则在把用户中文姓名加上序号（注册的第一个人姓名中无序号出现，但分配给序号1）填写在“姓”一栏作为用户名，同时把用户中文姓名作为等价名，序号作为等价组织。
注：
在上述两种重名解决方案中，权限控制和用户选择都不会出现问题（因为重名用户的fullname值肯定不同），但是用户在一些项目中习惯的一些快速输入方式（例如用户直接输入用户姓名作为收件人）则会产生multipilematch的问题。
一种方法是建议用户放弃这些输入方式，直接输入用户全称，或者增加额外的输入有效性检查，确保输入的用户姓名不会产生重名问题。
8.3.用户注册方式
与面向中小企业的Indi·
Office产品不同，企业集团用户注重的是系统功能的稳定性与完备性。
因此是否象Indi·
Office以前版本一样缺省提供web端自动用户注册功能值得商榷。
注册新用户和用户管理的结合可以使用两种方式：
导入型和集成型。
分别解释如下：
8.3.1.导入型
导入型是指我们的OA方案中不包含用户注册部分，只有用户管理。
用户的注册工作交给有经验的Domino管理员通过DominoAdministrator来进行。
用户管理数据库只是从公共通讯录中进行导入和管理。
这种方式的优点是将用户注册与维护部分（例如用户的改名、迁移等工作）从办公系统中剥离出来，简化了用户管理的相关工作。
缺点是Domino管理员需要比较有经验，而且如果需要进行分布式注册，或者比较复杂的拓扑结构时，对分部门的管理员要求也比较高。
8.3.2.集成型
集成型是指在我们的OA方案中既包含用户管理部分，也包含web端用户注册功能。
用户的注册工作与用户管理紧密结合，全部在办公系统的用户管理功能中完成。
因此注册工作对用户完全透明。
这种方式的优点是注册工作对管理员透明，容易实现管理的规范化，对管理员的要求比较低。
对用户方便。
缺点是大部分的注册工作和维护工作都需要通过编程来实现，服务器拓扑可能会影响到编码的实现与复用，功能不容易做得完备，用户ID的改名等维护工作难以实现。
集成型用户注册的实现需要考虑到分布式注册的需要，整个集团企业可以按照地域和管理功能的分布划分为几个注册节点，每个注册节点可以注册和管理自己管辖范围内的用户。
注册节点和用户管理节点的概念与区别在下一小节会详细介绍。
考虑到管理的方便和可行性，注册功能应当考虑到管理节点双机或多机方案的要求。
8.4.注册节点与用户管理节点
在大多数情况下，我们是把注册节点与用户管理节点混为一谈。
但事实上，这两者管理的对象不同：
注册节点直接管理的是Domino用户及其层次名，而用户管理节点管理的是OA系统用户及其部门属性，后者是前者的子集，依托于前者而存在。
通常，我们把两者重合在一起管理，即新用户在注册的同时，也进入我们OA系统的用户管理范畴。
这样做常常会遇到一个问题：
集团公司中，技术力量往往集中在公司（分公司）一级，其管理员往往难以了解下面所有子单位的人员设置与权限调整；
而下面子单位的人员又难以掌握和了解系统所在服务器的注册策略。
这使得用户管理的分布化很难实现。
问题产生的原因在于两者的需求与管理要求并不相同：
注册节点，一般位于系统一级，其管理员需要了解一些Domino的系统管理知识和系统的注册策略，其责任是维护Domino的用户层次，一般不直接涉及到用户在OA系统中的层次与权限。
一般而言，其管理员应当由服务器的管理员兼任，属于技术人员。
用户管理节点，则往往与公司的行政管理层次相对应。
其管理员应当可以清楚地掌握自己职责范围内的人员结构，其责任是维护OA系统的用户和部门层次，其关心的是用户的姓名和部门，对其Domino用户层次并不关心。
我们所设想的理想的管理方案是将注册节点与用户管理节点分开，注册节点集中在服务器（群）这一级别（也可适当下放到技术力量强的子单位），在注册节点下可以按照行政管理的实际需要设置若干个用户管理节点，利用层次化授权来实现办公系统用户的分级管理和维护。
这样，就形成了相互关联的注册树和用户管理树。
注册树的授权是逻辑意义上的，由于注册树是在系统实施过程配置实现的，因此不需要在程序架构中处理其授权管理的操作。
用户管理树则需要实现用户管理数据库的分布化，每个管理节点可以进行新用户的注册申请、管辖范围内用户信息的维护、用户部门的调整、对子节点的授权等功能。
8.5.用户注册设计思路
由于整个集团办公信息网络建立在一个Domino网络域中，各服务器是相互复制的。
如果把各级单位应用单独来看，各级单位的系统管理员（注册节点管理员）可以在自己所在服务器（或服务器群）注册用户，通过复制的方式更新到其他服务器。
因此用户注册可以简单的看成单一服务器注册，如果是服务器群，则可能是App服务器和Mail服务器分离，也就是需要进行多个个服务器结构的跨服务器注册。
因此，出于维护和管理的需要，希望在系统设计时，注册节点尽量依托于服务器（群）节点。
以上的方式还存在一个问题没有解决：
如何避免注册功能下发所带来的用户名称重复的问题（主要是指用户ID）。
拥有注册用户权限的用户有很多，命名规则相似，发生重名概率很大。
为了解决重名，在以上框架基础上需增加用户注册单点效验机制。
单点效验是指：
各级注册节点的管理员在注册用户时，需把注册申请（注册申请主要包括用户名信息）发到根节点服务器，根结点服务器上的单点验证引擎根据用户申请的用户名，效验是否存在重名用户，如果用户重名，反馈给用户一个有效的用户名。
例如：
目前系统中已经存在简名为xiajin的用户，如再有申请简名为xiajin的用户时，系统反馈类似于用户名xiajin021的用户名给申请人，各单位用户管理数据库根据反馈的用户信息注册用户。
单点验证引擎数据库保存集团的所有注册用户的信息
用户注册的框架将是以下模式。
9.办公用户管理设计思路
与原indioffice的办公用户管理相比，本方案中的办公用户管理不再处理Domino的用户注册。
其主要功能如下：
●用户管理申请（添加、删除、迁移等申请）
用户管理节点不负责用户的注册以后，节点上需要添加新用户、删除旧用户（注意与迁移的区别）、节点与节点外部的用户迁移等工作都不会直接在用户管理节点中完成，而是通过向对应的注册节点提出用户管理的申请，由注册节点管理员在注册节点完成相应的工作，再将修改结果反馈到用户管理相关数据库中。
●用户信息维护与管理
用户管理节点的适度下放，正是为了适应复杂的企业集团的组织结构，分担和分散系统管理员的工作，适应其组成机构的不断调整和扩张，因此用户管理节点的重要职能之一就是负责其管理范围内的用户的信息维护、更新。
●用户树的生成与管理
对于普通用户而言，他们不会关心办公用户的注册结构，他们关心的是用户在整个机构树中所处的地位。
因此如何标识和维护用户在机构树中的位置，是用户管理节点的另一个重要职能。
●“用户池”与管理授权
实现用户管理与注册的分离，还需要解决如何实现用户管理节点的权限授权问题。
由于用户管理节点是树状结构配置，同时为了避免冲突问题，需要保证同一个用户只能被一个用户管理节点管理，因此，这里提出了“用户池”的概念。
所谓“用户池”是一个虚拟的概念，代表当前用户管理节点的所能管理的用户范围。
当前节点可以维护和管理用户池中的所有用户的信息，指定其在当前用户树片断中的位置等。
当然也包括将其中一部分用户的管理权下发给下面的用户管理节点――这就是授权。
用户一旦被授权给下级节点，就会从当前节点的用户池中去掉，并添加到对应下级节点的用户池中。
其逻辑图如下
每一个用户节点对应一个用户池；
注册节点添加的新用户，只能初始添加到对应层次的用户管理节点的用户池中。
●部门维护与管理
部门的定义支持层次化定义，是生成用户树的基础。
部门的维护与管理也是用户管理节点的重要职能
10.数据库访问对象与接口
从我们的项目开发实践来看，影响代码复用性的原因除了编码规范、数据结构以外，还有数据交换的实现方式。
一般而言，我们习惯于直接访问数据库对象（常常连服务器名称和路径都省略了），就象下例所示一样：
setdb=session.getDatabase（“”,”names.nsf”）
这种方式，在不同的项目，尤其是在集团办公方案中，节点的单/双/多服务器的规划方案中可能会导致代码重用的困难。
解决的方法是将数据库对象的访问封装起来，使其对应用开发和维护人员透明。
为此，我们需要首先分析一下常见的几种数据库访问形式。
10.1.数据访问实现的基本方式
10.1.1.服务器内部直接访问
即存取相同服务器上的数据库，是最基本、最常用的方式，虽然简单，但有可能涉及到数据库路径的获取和设置问题，因此也建议进行封装。
10.1.2.跨服务器访问
即存取位于不同服务器的数据库，使用的机会比较少，但一般都很重要。
例如删除其他服务器上的邮件数据库、将公文下发到分公司等等。
从可能的实现手段上看，主要有以下几种：
10.1.2.1.消息引擎
基于邮件的实现方式：
利用邮件发送相关的数据请求到对应服务器的消息引擎数据库（函件数据库）中，消息引擎数据库会触发一个代理来执行指定的数据请求，完成相关的操作，操作完毕后，会视需要将执行结果返回申请发起的服务器。
根据消息引擎数据库触发代理的条件不同，又可以分为邮件到达触发和定时触发两种。
消息引擎方式的优点是通用性强，即使网络条件不好也可使用，很容易扩展到广域网应用中去。
其缺点是始终会有一个较长的等待延时时间，因此只适用于对时效性要求不高的场合，例如注册申请等
10.1.2.2.JAVACORBA
使用CORBA接口。
其优点是即时访问，没有延迟时间。
其缺点是，必须保证不同服务器间连接的的稳定性，不容易扩展到广域网应用中去。
而且必须使用java代理。
10.1.2.3.数据库复制
修改本地数据库复本，利用复制关系复制到其他服务器上。
除特殊情况外，一般不推荐使用本方法，主要是配置和维护上都增加了很多工作，同时过多的复本会影响到系统的效率。
以上三种方法，个人建议尽量选择第一种，或者使用R6来实现跨服务器的访问。
10.2.数据访问的逻辑需求
在逻辑的层次上看，数据的访问形式实际上有三种：
10.2.1.访问本办公子系统的数据
虽然是访问同一个子系统中的数据，但是由于实际节点的规划不同，可能也会涉及到跨服务器的数据访问（例如邮件与应用分开的双服务器结构）。
10.2.2.访问本集团Indi·
Office办公系列的其他办公子系统的数据
由于规划的不同，同样涉及到单服务器（例如单服务器多子单位应用的情况）和跨服务器（一般情况）两种方式。
10.2.3.访问外部数据
不在本文考虑范围之内。
10.3.集团办公系统通用数据库对象和接口的实现方案
从上面的分析可以看出，由于集团办公系统的数据访问的逻辑需求与实际的实现方式之间的并不一一对应的复杂关系，如果想要实现系统的高可配置性和编码的高可重用性，必须重新构架我们的数据访问的实现方案。
因此我们这里提出服务器应用映射（下一节讨论）和通用数据库对象的概念。
10.3.1.通用数据库对象
所谓通用数据库对象，实际上是我们定义的用户定义类。
通过这些类，我们可以把数据库的访问细节封装起来，使得二次开发者和维护人员都可以从逻辑层面上访问数据库对象，而不需要考虑实际的实现方式及数据库的分布。
对应于前面分析的逻辑需求，可以分别对应两个类：
一个是应用内部访问的数据库类；
另一个是跨应用访问的数据库类。
至于该访问是否跨服务器，则封装在这两个类中，不需要开发者考虑。
当然，从目前的技术手段来看，在r5中还难以实现跨服务器的访问（消息引擎不能做到即时读取，Corba又只能在java代理中使用），但是封装后，将来很容易升级并使用r6的特性来完成。
10.3.2.通用数据库对象访问接口
为了达到屏蔽数据库的物理分布带来的代码改变的目的，我们需要改变访问数据库的接口。
事实上，Domino的notesdatabase对象的访问需要两个参数（服务器和数据库路径）,考虑到多应用目录的需要，我们也可以将其拆分为三个部分：
服务器、应用根目录、数据库相对路径。
数据库的物理分布带来的影响，主要是服务器和应用根目录的不同。
因此，我们设计的通用数据库对象参数需要尽量将服务器和应用根目录的获取封装起来，为此，并考虑到前面提到的逻辑需求，我们应该使用应用名称来代替这两个参数。
对于相同应用的数据库访问，只需要数据库的相对路径；
对于不同应用的数据库访问，则需要额外增加应用名称作为参数。
目前阶段，我们还只能支持跨服务器的异步写（利用消息引擎来实现），跨服务器的读因为必须考虑实时性，因此在R5还难以实现（暂不推荐使用COM），但是R6中经过试验好像可以。
所以在目前的项目的服务器规划中需要考虑这个问题，一个子系统中
升级会员 