① Web 系统中用户 权限之间的关系 是一对多 还是 多对多 他们之间有联系吗
前言：
权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“who对what(which)进行how的操作”的逻辑表达式是否为真。针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等n多个方案之间比较权衡，选择符合的方案。
目标：
直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。
简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。
扩展，采用可继承在扩展上的困难。的group概念在支持权限以组方式定义的同时有效避免了重定义时
现状：
对于在企业环境中的访问控制方法，一般有三种：
1.自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(acls)。
2.强制型访问控制方法。用于多层次安全级别的军事应用。
3.基于角色的访问控制方法（rbac）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显着的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
名词：
粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特
定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。
细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细
粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。
原则：
权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。
需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整。回到权限的问题公式，通用的设计仅解决了who+what+how 的问题，其他的权限问题留给业务逻辑解决。
概念：
who：权限的拥用者或主体（principal、user、group、role、actor等等）
what：权限针对的对象或资源（resource、class）。
how：具体的权限（privilege, 正向授权与负向授权）。
role：是角色，拥有一定数量的权限。
operator：操作。表明对what的how 操作。
说明：
user：与 role 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。user是不能与 privilege 直接相关的，user 要拥有对某种资源的权限，必须通过role去关联。解决 who 的问题。
resource：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关可定义是否将其权限应用于子节点。
privilege：是resource related的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做"部门新闻发布权限"。这就表明，该privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。privilege是由creator在做开发时就确定的。权限，包括系统定义权限和用户自定义权限用户自定义权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理 权限 包含 前两种权限)。privilege 如"删除" 是一个抽象的名词，当它不与任何具体的 object 或 resource 绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时，才会产生真正的 privilege。这就是 privilege instance。权限系统根据需求的不同可以延伸生很多不同的版本。
role：是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是role，具体业务实现可以直接继承或拓展丰富role的内容，role不是如同user或group的具体实体，它是接口概念，抽象的通称。
group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。group要实现继承。即在创建时必须要指定该group的parent是什么group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个group那么它就具备这个group的所有操作许可。细粒度控制上，在业务逻辑的判断中，user仅应关注其直接属于的group，用来判断是否“同组” 。group是可继承的，对于一个分级的权限实现，某个group通过“继承”就已经直接获得了其父group所拥有的所有“权限集合”，对这个group而言，需要与权限建立直接关联的，仅是它比起其父group需要“扩展”的那部分权限。子组继承父组的所有权限，规则来得更简单，同时意味着管理更容易。为了更进一步实现权限的继承，最直接的就是在group上引入“父子关系”。
user与group是多对多的关系。即一个user可以属于多个group之中，一个group可以包括多个user。子group与父group是多对一的关系。operator某种意义上类似于resource + privilege概念，但这里的resource仅包括resource type不表示resource instance。group 可以直接映射组织结构，role 可以直接映射组织结构中的业务角色，比较直观，而且也足够灵活。role对系统的贡献实质上就是提供了一个比较粗颗粒的分配单位。
group与operator是多对多的关系。各概念的关系图示如下：
解释：
operator的定义包括了resource type和method概念。即，what和how的概念。之所以将what和how绑定在一起作为一个operator概念而不是分开建模再建立关联，这是因为很多的how对于某what才有意义。比如，发布操作对新闻对象才有意义，对用户对象则没有意义。
how本身的意义也有所不同，具体来说，对于每一个what可以定义n种操作。比如，对于合同这类对象，可以定义创建操作、提交操作、检查冲突操作等。可以认为，how概念对应于每一个商业方法。其中，与具体用户身份相关的操作既可以定义在操作的业务逻辑之中，也可以定义在操作级别。比如，创建者的浏览视图与普通用户的浏览视图要求内容不同。既可以在外部定义两个操作方法，也可以在一个操作方法的内部根据具体逻辑进行处理。具体应用哪一种方式应依据实际情况进行处理。
这样的架构，应能在易于理解和管理的情况下，满足绝大部分粗粒度权限控制的功能需要。但是除了粗粒度权限，系统中必然还会包括无数对具体instance的细粒度权限。这些问题，被留给业务逻辑来解决，这样的考虑基于以下两点：
一方面，细粒度的权限判断必须要在资源上建模权限分配的支持信息才可能得以实现。比如，如果要求创建者和普通用户看到不同的信息内容，那么，资源本身应该有其创建者的信息。另一方面，细粒度的权限常常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。相比之下，粗粒度的权限更具通用性，将其实现为一个架构，更有重用价值；而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐，而且不是那么的有必要，用定制的代码来实现就更简洁，更灵活。
所以细粒度控制应该在底层解决，resource在实例化的时候，必需指定owner和groupprivilege在对resource进行操作时也必然会确定约束类型：究竟是ownerok还是groupok还是allok。group应和role严格分离user和group是多对多的关系，group只用于对用户分类，不包含任何role的意义；role只授予user，而不是group。如果用户需要还没有的多种privilege的组合，必须新增role。privilege必须能够访问resource，同时带user参数，这样权限控制就完备了。
思想：
权限系统的核心由以下三部分构成：1.创造权限，2.分配权限，3.使用权限，然后，系统各部分的主要参与者对照如下：1.创造权限 - creator创造，2.分配权限 - administrator 分配，3.使用权限 - user：
1. creator 创造 privilege， creator 在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是 privilege 与 resource 的对象声明，并没有真正将 privilege 与具体resource 实例联系在一起，形成operator。
2. administrator 指定 privilege 与 resource instance 的关联。在这一步， 权限真正与资源实例联系到了一起， 产生了operator（privilege instance）。administrator利用operator这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等...这些操作都是由 administrator 来完成的。
3. user 使用 administrator 分配给的权限去使用各个子系统。administrator 是用户，在他的心目中有一个比较适合他管理和维护的权限模型。于是，程序员只要回答一个问题，就是什么权限可以访问什么资源，也就是前面说的 operator。程序员提供 operator 就意味着给系统穿上了盔甲。administrator 就可以按照他的意愿来建立他所希望的权限框架可以自行增加，删除，管理resource和privilege之间关系。可以自行设定用户user和角色role的对应关系。(如果将 creator看作是 basic 的发明者， administrator 就是 basic 的使用者，他可以做一些脚本式的编程) operator是这个系统中最关键的部分，它是一个纽带，一个系在programmer，administrator，user之间的纽带。
用一个功能模块来举例子。
一．建立角色功能并做分配：
1．如果现在要做一个员工管理的模块(即resources)，这个模块有三个功能，分别是：增加，修改，删除。给这三个功能各自分配一个id，这个id叫做功能代号：
emp_addemp，emp_deleteemp，emp_updateemp。
2．建立一个角色(role)，把上面的功能代码加到这个角色拥有的权限中，并保存到数据库中。角色包括系统管理员，测试人员等。
3．建立一个员工的账号，并把一种或几种角色赋给这个员工。比如说这个员工既可以是公司管理人员，也可以是测试人员等。这样他登录到系统中将会只看到他拥有权限的那些模块。
二．把身份信息加到session中。
登录时，先到数据库中查找是否存在这个员工，如果存在，再根据员工的sn查找员工的权限信息，把员工所有的权限信息都入到一个hashmap中，比如就把上面的emp_addemp等放到这个hashmap中。然后把hashmap保存在一个userinfobean中。最后把这个userinfobean放到session中，这样在整个程序的运行过程中，系统随时都可以取得这个用户的身份信息。
三．根据用户的权限做出不同的显示。
可以对比当前员工的权限和给这个菜单分配的“功能id”判断当前用户是否有打开这个菜单的权限。例如：如果保存员工权限的hashmap中没有这三个id的任何一个，那这个菜单就不会显示，如果员工的hashmap中有任何一个id，那这个菜单都会显示。
对于一个新闻系统(resouce)，假设它有这样的功能(privilege)：查看，发布，删除，修改；假设对于删除，有"新闻系统管理者只能删除一月前发布的，而超级管理员可删除所有的这样的限制，这属于业务逻辑(business logic)，而不属于用户权限范围。也就是说权限负责有没有删除的permission，至于能删除哪些内容应该根据userrole or usergroup来决定(当然给userrole or usergroup分配权限时就应该包含上面两条业务逻辑)。
一个用户可以拥有多种角色，但同一时刻用户只能用一种角色进入系统。角色的划分方法可以根据实际情况划分，按部门或机构进行划分的，至于角色拥有多少权限，这就看系统管理员赋给他多少的权限了。用户—角色—权限的关键是角色。用户登录时是以用户和角色两种属性进行登录的（因为一个用户可以拥有多种角色，但同一时刻只能扮演一种角色），根据角色得到用户的权限，登录后进行初始化。这其中的技巧是同一时刻某一用户只能用一种角色进行登录。
针对不同的“角色”动态的建立不同的组，每个项目建立一个单独的group，对于新的项目，建立新的 group 即可。在权限判断部分，应在商业方法上予以控制。比如：不同用户的“操作能力”是不同的(粗粒度的控制应能满足要求)，不同用户的“可视区域”是不同的(体现在对被操作的对象的权限数据，是否允许当前用户访问，这需要对业务数据建模的时候考虑权限控制需要)。
扩展性：
有了用户/权限管理的基本框架，who(user/group)的概念是不会经常需要扩展的。变化的可能是系统中引入新的 what (新的resource类型)或者新的how(新的操作方式)。那在三个基本概念中，仅在permission上进行扩展是不够的。这样的设计中permission实质上解决了how 的问题，即表示了“怎样”的操作。那么这个“怎样”是在哪一个层次上的定义呢？将permission定义在“商业方法”级别比较合适。比如，发布、购买、取消。每一个商业方法可以意味着用户进行的一个“动作”。定义在商业逻辑的层次上，一方面保证了数据访问代码的“纯洁性”，另一方面在功能上也是“足够”的。也就是说，对更低层次，能自由的访问数据，对更高层次，也能比较精细的控制权限。
确定了permission定义的合适层次，更进一步，能够发现permission实际上还隐含了what的概念。也就是说，对于what的how操作才会是一个完整的operator。比如，“发布”操作，隐含了“信息”的“发布”概念，而对于“商品”而言发布操作是没有意义的。同样的，“购买”操作，隐含了“商品”的“购买”概念。这里的绑定还体现在大量通用的同名的操作上，比如，需要区分“商品的删除”与“信息的删除”这两个同名为“删除”的不同操作。
提供权限系统的扩展能力是在operator (resource + permission)的概念上进行扩展。proxy 模式是一个非常合适的实现方式。实现大致如下：在业务逻辑层(ejb session facade [stateful sessionbean]中)，取得该商业方法的methodname，再根据classname和 methodname 检索operator 数据，然后依据这个operator信息和stateful中保存的user信息判断当前用户是否具备该方法的操作权限。
应用在 ejb 模式下，可以定义一个很明确的 business层次，而一个business 可能意味着不同的视图，当多个视图都对应于一个业务逻辑的时候，比如，swing client以及 jsp client 访问的是同一个 ejb 实现的 business。在 business 层上应用权限较能提供集中的控制能力。实际上，如果权限系统提供了查询能力，那么会发现，在视图层次已经可以不去理解权限，它只需要根据查询结果控制界面就可以了。
灵活性：
group和role，只是一种辅助实现的手段，不是必需的。如果系统的role很多，逐个授权违背了“简单，方便”的目的，那就引入group，将权限相同的role组成一个group进行集中授权。role也一样，是某一类operator的集合，是为了简化针对多个operator的操作。
role把具体的用户和组从权限中解放出来。一个用户可以承担不同的角色，从而实现授权的灵活性。当然，group也可以实现类似的功能。但实际业务中，group划分多以行政组织结构或业务功能划分；如果为了权限管理强行将一个用户加入不同的组，会导致管理的复杂性。
domain的应用。为了授权更灵活，可以将where或者scope抽象出来，称之为domain，真正的授权是在domain的范围内进行，具体的resource将分属于不同的domain。比如：一个新闻机构有国内与国外两大分支，两大分支内又都有不同的资源（体育类、生活类、时事政治类）。假如所有国内新闻的权限规则都是一样的，所有国外新闻的权限规则也相同。则可以建立两个域，分别授权，然后只要将各类新闻与不同的域关联，受域上的权限控制，从而使之简化。
权限系统还应该考虑将功能性的授权与资源性的授权分开。很多系统都只有对系统中的数据（资源）的维护有权限控制，但没有对系统功能的权限控制。
权限系统最好是可以分层管理而不是集中管理。大多客户希望不同的部门能且仅能管理其部门内部的事务，而不是什么都需要一个集中的administrator或administrators组来管理。虽然你可以将不同部门的人都加入administrators组，但他们的权限过大，可以管理整个系统资源而不是该部门资源。
正向授权与负向授权：正向授权在开始时假定主体没有任何权限，然后根据需要授予权限，适合于权限要求严格的系统。负向授权在开始时假定主体有所有权限，然后将某些特殊权限收回。
权限计算策略：系统中user，group，role都可以授权，权限可以有正负向之分，在计算用户的净权限时定义一套策略。
系统中应该有一个集中管理权限的accessservice，负责权限的维护（业务管理员、安全管理模块）与使用（最终用户、各功能模块），该accessservice在实现时要同时考虑一般权限与特殊权限。虽然在具体实现上可以有很多，比如用proxy模式，但应该使这些proxy依赖于accessservice。各模块功能中调用accessservice来检查是否有相应的权限。所以说，权限管理不是安全管理模块自己一个人的事情，而是与系统各功能模块都有关系。每个功能模块的开发人员都应该熟悉安全管理模块，当然，也要从业务上熟悉本模块的安全规则。
技术实现：
1．表单式认证，这是常用的，但用户到达一个不被授权访问的资源时，web容器就发
出一个html页面，要求输入用户名和密码。
2．一个基于servlet sign in/sign out来集中处理所有的request，缺点是必须由应用程序自己来处理。
3．用filter防止用户访问一些未被授权的资源，filter会截取所有request/response，
然后放置一个验证通过的标识在用户的session中，然后filter每次依靠这个标识来决定是否放行response。
这个模式分为：
gatekeeper ：采取filter或统一servlet的方式。
authenticator： 在web中使用jaas自己来实现。
用户资格存储ldap或数据库：
1. gatekeeper拦截检查每个到达受保护的资源。首先检查这个用户是否有已经创建
好的login session，如果没有，gatekeeper 检查是否有一个全局的和authenticator相关的session？
2. 如果没有全局的session，这个用户被导向到authenticator的sign-on 页面，
要求提供用户名和密码。
3. authenticator接受用户名和密码，通过用户的资格系统验证用户。
4. 如果验证成功，authenticator将创建一个全局login session，并且导向gatekeeper
来为这个用户在他的web应用中创建一个login session。
5. authenticator和gatekeepers联合分享cookie，或者使用tokens在query字符里
② 基于Web的合同管理系统
下面是中达咨询给大家带来关于Web的合同管理系统的相关内容，以供参考。
合同管理作为企业管理中的重要一环,对合同数据的准确性、数据传输的安全性和业务处理的规范性有很高的要求.也正因如此,合同管理工作中繁琐的业务流程限制了管理人员工作效率的提高;另外,如何有效地利用庞大的合同历史数据,为合同管理人员提供必要的决策支持也成为一磨亮旅项新的课题.
随着我国企业信息化水平的提高,合同管理已逐步由传统的手工作业转化为计算机管理.初期的合同管理系统为文档管理系统,实现合同生命周期的过程记载,而后发展为数字化合同模型,对合同实行元素化管理,形成了规范的数据结构,可方便进行数据统计、比键迅较和查询分析.技术架构也由单机模式逐步向局域网环境下的客户端/服务器结构过渡.由于合同管理工作的严谨性瞎凳和不同企业、政府部门在合同业务的处理上存在的巨大差异,所采用的合同管理系统多是根据自身的实际情况定制而成.例如:某军事单位针对其科研合同管理中具有高保密度的要求和严格的审批程序,开发了科研合同管理系统[1];江苏电视台根据广告合同业务量大和需要播出编排等特殊情况,开发了广告合同管理系统[2]等.
上述系统采用的是基于C/S结构的合同管理系统.而针对一些公司企业规模大、部门地域分散的特点,笔者提出了基于Web的合同管理模式,以满足企业对信息灵敏度、规范化管理和辅助决策分析的要求.
1大型企业跨地域合同管理的需求分析
软件系统的设计与开发中,最重要是从用户的专业领域中整理出需要计算机处理的需求.在企业规模大,部门地域分散的特定情况下,下属单位可能根据自身实际情况形成内部独立的合同管理工作模式,这对整个企业集团合同管理的标准化造成了困难;而且基础数据存留在基层部门,将形成信息孤岛现象,造成信息不准确,利用率低等问题,合同数据传输的滞后也会对企业决策层的决策产生影响.除此之外,软件应用存在跨地域实施的特点使得软件开发人员必须要考虑应采用何种技术架构来解决软件系统与不同软件平台之间的兼容性问题,以及日后的升级、维护等问题.
通过对某公司进行调研,可以总结该企业跨地域合同管理的需求如下:
1)实现信息处理的标准化和数据化,在集团企业内部建立标准的合同管理流程和内容规范;
2)建立统一的数据库系统,实现全企业数据集中管理,避免信息孤岛的出现;
3)在合同生命周期内,实现数据信息跟踪管理,包括基本信息和履行信息的管理;
4)实现合同的归档管理,以及合同数据查询、统计等处理功能;
5)提供标准报表、自定义报表等多种格式的报表处理功能;
6)对客户信息进行管理,在合同签署前为客户的资质评估提供数据支持;
7)提供合同示范文本、相关法律法规和授权委托信息等资料的信息管理功能;
8)确保合同管理工作的规范性和安全性.
2基于Web的合同管理系统设计
2.1Web应用系统的特点
目前,很多企业的管理信息系统采用了C/S的系统结构,这类系统的优点是与大型数据库的联接紧密,数据处理速度快,系统安全性好.但应用C/S结构建设的管理信息系统专用性强,难以跨平台使用,开发周期长、生命周期短,系统维护和升级成本太高,系统只能在局域网的小范围内实现信息集成和信息共享,其封闭性限制了系统对外部资源的利用[3].而且,如果需要提供Internet/Intranet上的数据服务,旧的管理信息系统必须要以新的软件技术重新编写,造成重复开发成本高.
随着互联网在世界范围内的普及和信息技术的发展,基于Web的信息系统对传统管理信息系统的体系结构产生了巨大的影响.与C/S结构相比,基于Web的管理信息系统具有如下优势:
1)开放性:基于Web的管理信息系统可以做到开放式的、跨平台的应用;
2)易于维护和升级:采用分布式多层应用技术,大大节省了用于系统维护和升级的时间和费用,也改善了C/S结构的延展性问题;
3)标准化:基于Internet上的公开协议和技术标准(如TCP/IP,HTTP,XML,SOAP等)可实现应用系统在Internet/Intranet上的集成,具有良好的扩展性.对于操作人员来说,客户端可使用标准化的浏览器软件,用户界面的操作简单易学[3-4];
4)安全性:与传统的C/S结构相比,基于Web的管理信息系统在客户端与数据库服务器之间增加了Web层服务器和其他的中间层服务器,使客户端和数据库服务器不直接相连,可有效地防止用户的非法入侵[5].此外,中间层为系统提供了基本的安全保护,并支持软件开发人员使用SSL(SecuritySocketLayer)对传输的资料进行加密解密.
2.2合同管理系统的技术架构
系统采用基于Web的技术架构体系,使用大型数据库MSSQLServer,以Delphi作为应用程序开发工具.在开发过程中,严格遵循了面向对象(ObjectOriented)技术原则,采用组件式(ComponentBased)开发,注重产品的技术架构(TechnicalInfrastructure)的建立,运用了WebService技术,能够有效的支持产品的进一步发展和第三方的集成应用.图1为系统结构图.
WebService使用了标准的输出接口WSDL(WebServiceDescriptionLanguage)为Internet/Intranet上的客户端提供服务,它不再注重以什么技术来实现Web解决方案.WebService将Web应用中以程序设计为导向的概念转换为以服务为导向的概念,其最有价值的地方就在于能够成为不同组件模型和异构系统之间的胶水集成技术.笔者所讨论的合同管理系统采用了WebService技术,为日后必然出现的企业内部和企业间的系统集成提供了技术保障.
2.3合同管理的内容
合同内容一般应包括:当事人的名称和住所;标的;数量;质量;价格与报酬;履约期限、地点和方式;违约责任;解决争议的方法[6].合同管理系统中所包含的合同基本信息元素最终要根据企业所在的行业背景和企业自身的实际情况来决定.
合同管理的业务处理中,根据企业的实际情况制定标准一致的合同编码规则,内容的规范性为构造数字化的合同模型,实现元素级的合同管理提供了方便.所讨论的合同管理系统包含了合同编号、合同名称、合同分类(内部合同、关联交易合同、外部合同)、专业类别(买卖合同、工程建设合同、承揽合同、技术合同、其它合同)、管理方式(授权、审查、审批、局本部)、自定义分类、甲方/乙方、甲方单位、乙方单位、合同金额、项目计划金额、签约时间、审查时间、计划履行开始、计划履行截止等42项合同基本信息.
系统还包括了合同项目履行信息的实时跟踪和管理.合同项目的履行信息有:合同项目的收(支)情况、标的物交付进度、争议处理情况、合同变更信息以及资料归档情况等.项目实际履行数据与合同规定条款的对比可帮助合同管理者对合同履行情况全面、准确的把握.
另外,示范文本、法律法规等辅助信息的便捷查询有助于合同的规范性管理,系统对客户信息的记录和分析能够在客户资质评估方面为合同管理人员提供决策支持.
2.4合同管理系统的功能模型
2.4.1客户端的主要功能
客户端的Web页面分为合同业务客户页面和业务管理员页面.业务客户的Web页面实现了客户在线填写合同申请表、在线下载申请表和在线打印申请表的功能.
业务管理员的Web页面主要包含5个模块,各模块的功能如图2所示.
1)合同信息管理
合同信息管理包括了对合同基本信息和合同履行信息的管理,合同基本信息的数据项设置应根据企业不同的行业背景或者政府机构对合同管理系统的不同实施要求制定,并提供数据项的用户自定义功能以拓展系统的实用性.对合同执行情况的跟踪,包括了对合同履行进度、结算情况、变更内容、争议解决办法、合同履行完毕资料归档等情况的信息管理,并提供各项数据的对比分析功能.批量导入提供了传统的Excel表格在指定格式下向数据库的导入接口.系统提示根据系统管理员设置的提前天数,定期向用户提示合同收付款和合同到期期限等信息.
2)报表处理
实现常规的报表运算和个性化的自定义报表处理功能.对于大型企业的合同管理工作,报表处理是一项十分麻烦的工作,基于Web的合同管理系统在统一管理合同数据信息的基础上,可以提供便捷的报表运算和分析功能.
3)辅助信息
实现了客户基本信息的管理,根据对客户的历史记录和目前运营状况的数据分析,提供对客户资质的初步评估;实现对合同示范文本和相关法律法规的管理,以规范合同文本的录入,方便用户对法律法规及其相关规定的查询.
4)系统管理
系统用户的管理模块负责对用户的使用权限进行设置,权限分级管理对维护系统安全、正常的运行是非常必要的;拥有访问权限的用户可以通过系统数据设置模块,对合同管理的基础数据项进行设置.
5)在线帮助
利用Internet技术快捷方便的为各级系统管理人员和用户提供帮助信息.
2.4.2服务器端的主要功能
系统的服务器端负责接受和处理客户端发出的请求,并以Web页面的形式将处理结果返回给客户端.合同管理系统采用了分布式多层应用的系统结构,服务器端分为负责Web发布的Web服务器,提供Internet/Intranet服务接口的WebService服务器,存放主要的逻辑应用程序并提供事务管理功能的中间层服务器,以及负责数据管理的数据库服务器.主要功能如下:
1)对登录用户进行身份验证;
2)根据系统的分级权限设定,限制用户的使用权限;
3)处理数据查询、数据修改、报表处理等客户端请求,返回Web页面;
4)维护和管理系统数据库;
5)运用中间层MTS(MicrosoftTransactionServer)所提供的交易管理服务,实现数据资料在操作过程中的完整性和一致性保护;
6)具备同时处理多个用户请求的事务处理能力;
7)为数据传输和接收提供安全保障;
8)提供标准的服务接口WSDL,可以在Internet/Intranet上实现与其他应用系统的集成.
2.5基于Web的合同管理系统的安全性解决方案基于Internet的网络技术实现了各个终端跨地域的开放性互连和信息共享,但同时带来了严重的安全性问题.运行在互联网上的应用软件系统,其安全性可能将受到如下几种类型的威胁:数据被非法截获、读取和修改;未经授权的用户访问内部网络;用户被冒名欺骗.合同信息属于商业机密,因此基于Web的合同管理系统对系统的安全性有很高的要求[6],本系统采用了如下的安全性解决方案:
1)信息资源的第一层保护手段应是在内部网和互联网的节点处设置防火墙,利用防火墙对网络和服务器上的某些流量进行过滤和保护,监视在互联网和内部网的数据交换过程中各类活动是否符合了站点的安全规定,这类活动包括电子邮件、文件传输、远程登录等[7].
2)互联网环境下,数据的传输过程中很容易造成信息的泄漏,所以对浏览器和服务器之间传输信息的加密是极有必要的.利用Internet的安全标准-安全套接层协议SSL(SecuritySocketLayer),可以对网络上传输的信息进行加密,实现客户端浏览器和Web服务器之间的信息以密文形式传输[8].
3)系统的用户管理也是安全管理的重要组成部分,系统综合运用了应用程序提供的基本安全控制功能,中间层MTS/COM+提供的组件、套件组件安全控制功能和数据库服务器所提供的资源安全控制功能,对用户权限进行了严格的管理和控制.
4结论
1)在合同管理计算机化之前,必须制定标准的工作流程和内容规范,实现全企业合同管理的标准化;
2)在企业规模较大、部门地域分散的情况下,为避免信息孤岛的出现,必须建立企业级数据库,应用Web技术设计合同管理软件系统,保证数据的准确性和信息传输的实时性;
3)根据企业的实际情况构造软件的功能模块,系统共建立了17个子模块;
4)建立完善的安全防范体系,确保合同管理工作的安全性.
更多关于工程/服务/采购类的标书代写制作，提升中标率，您可以点击底部官网客服免费咨询：https://bid.lcyff.com/#/?source=bdzd