CN102542370A - 跨区域旅游集散中心电子商务平台的角色管理与实现方法 - Google Patents

Abstract

本专利针对跨区域旅游集散中心电子商务平台。旅游集散中心电子商务平台涉及跨区域、跨行业实体，各个实体之间具有层次关系。本发明所提出的角色管理模型，基于角色层次模型，可满足旅游集散中心涉及实体之间的角色管理与协作。在系统实现上，本发明所提出的角色管理模式可以满足动态权限分配要求。

Description

跨区域旅游集散中心电子商务平台的角色管理与实现方法

2、技术领域：数字旅游

3、背景技术

旅游要素包括航空、客运、轮船、出租、酒店、景点、导游、商店等各种旅游服务。本项目所提出的数字旅游联盟，是指上述旅游要素服务提供商，基于互联网和信息技术所形成的跨区域、跨行业资源共享联合体。

旅游业是一种典型的跨区域、跨行业的产业。在互联网的支持下，旅游业急需加强全面合作，扩大相互开放，创建平等、有序的竞争环境，推动旅游生产要素的自由流动，实现市场共建、资源共享、协作共赢的战略合作目标。

旅游动态联盟：旅游要素服务提供商在互联网和信息技术支持下所形成的旅游产业联盟。数字旅游动态联盟的特点是，成员间的合作和交互完全以特定的旅游商机和资源为导向，联盟成员可以根据资源共享需求自主决定加盟和退出。

旅游要素服务提供商通过跨区域旅游集散中心营运系统，形成旅游联盟，在独立运营的基础上，实现信息互通、统一管理、服务组合、动态联盟。成员间的合作和交互完全以特定的旅游商机和资源为导向，联盟成员可以根据资源共享需求自主决定加盟和退出。

面向旅游动态联盟的跨区域旅游集散中心营运系统，利用互联网、信息技术、无线、一卡通、虚拟现实等技术，整合数字旅游联盟的旅游资源，以及来自政府和旅游协会的公共服务。为主流的自助、半自助旅游度假人士，提供全程、全方位的旅游服务，包括“旅游套餐服务”，“旅游过程服务”，以及相关的“旅游公共服务”；为旅游服务提供商和地方政府提供品牌和保障服务。

经检索，未发现针对旅游集散中心的、与本专利类似的角色管理方法及其实现方面的专利。

4、专利目的

本专利所提出的角色管理模型，可满足跨区域、跨行业、多层次实体之间的角色管理与协作，满足动态权限分配要求，支持跨区域旅游集散中心电子商务平台的运营。

5、技术原理

5.1基本原理

跨区域旅游集散中心电子商务平台是一个集票务管理、商务合作、审核结算等各功能于一体的系统。旅游动态联盟的成员作为一个机构存在，电子商务平台根据联盟的协议或各公司的实际情况决定该机构的功能权限。

在电子商务平台基础上，各集散中心、汽车公司、酒店彼此之间根据协议进行商务合作，从而开设新的旅游线路或旅游套餐，此时集散中心通过市场反响或自身判断来制定线路班次，汽车公司人员通过与平台的交互了解到班次信息，从而能够即使的调度车辆。在一系列检查、审批之后，通过售票窗口或者网络进行售票。

电子商务平台分为业务管理层、业务操作层、技术管理层、审计核算层，来保证对各类角色进行管理。其中，业务管理层，在平台中负责业务流程设定、业务流转审核、业务组织管理；业务操作层，在平台中负责具体业务单元的操作和执行；技术管理层，在平台中负责用户权限设定、系统功能等；审计核算层，在平台中负责对以上三个层面进行核算审计。确保业务层和技术层的业务操作、权限分配等方面，符合审计的规法。附图1所示为所定义角色管理方法的多级角色划分：

5.2角色管理模型

所定义角色管理模型，基于角色流程将系统功能抽象为元节点，根据不同类型的权限，合并、提炼出角色和层次。由于旅游电子商务联盟涉及众多利益实体，其所扮演的角色各不相同，采用基于角色的多级角色管理，既能够满足上级对下级的监管要求，也能够保证实现同级实体间的商务合作。该种角色管理模式可以随时更改角色的元功能节点，满足动态的权限分配要求。

用户在所定义角色管理方法模型中指某个具体的使用个体。用户组是指具有相关单元职能的多个用户组成的集合。在跨区域旅游集散中心电子商务平台中，所定义角色管理方法对用户和用户组基本定义如下：

根据平台的业务层面、技术层面、审计层面，用户组主要包含以下几类：

技术管理层面：技术管理层面主要是从整个平台的角度考虑，平台包含系统管理组、电子商务平台管理组、电子商务规则管理组；

业务管理层面：业务管理层首先按照集散中心组织架构来划分为各中心的业务管理组，包括上海、舟山、杭州等业务管理组。在每个中心，分别设有票务管理组，景点管理组，售票管理组等；

业务操作层面：业务操作组基本位于整个平台组织结构的最深层次。通常不可以再细分为其他用户组。根据旅游集散中心的平台业务划分，业务操作层面主要包括：票务调度组、景点检票组、售票组等；

平台除了定义以上三个层面的用户组以外，还允许定义动态用户组。动态用户组是指：对于某些情况，用户组会依照一定的条件，动态地调整更新。所定义角色管理方法模型对用户组的定义，进一步引入了日期属性、时间属性、条件判断语句、循环语句等，丰富对用户组的定义。例如，在旅游集散中心平台，组织中对每年的“黄金周”、各地“旅游节”等会成立特别小组，统筹“黄金周”、“旅游节”的售票、景点等业务安排。因此，本专利需要通过日期、时间、地点的条件判断语句，来动态定义每年的“黄金周”、“旅游节”特别小组。

在本专利的所定义角色管理方法模型中，角色指的是具有相似职能、权限集合的抽象。根据平台的业务层面、技术层面、审计层面，平台主要角色包括以下：

旅游集散中心：指各地的旅游集散中心，是独立的经营单位，是各旅游线路营运的主体。

集散中心系统管理员：负责集散中心软件系统的维护。

集散中心商务管理员：负责集散中心商务要求在系统中的实现。

集散中心线路管理员：负责线路信息和营运计划的编制、维护。

集散中心成本管理员：负责线路成本的管理。

集散中心结算管理员：负责集散中心结算工作。

集散中心高级决策员：指集散中心的经营管理层，能够监控、查询集散中心各类业务报表。

售票点：各旅游集散中心直接下属的票务销售场所。安装有系统终端软件，配备出票机，通过认证可以实时联网售票。各旅游集散中心可以拥有多个售票点。

代理点：通过有关商务协议，代理旅游集散中心的票务销售。

售票员：在各售票点负责具体的售票工作。

退票员：负责退票工作。

汽车公司管理员：负责本公司车辆信息、司机信息的维护；班车具体服务的配置(车辆、司机、导游)；旅客车票的检票、上传。

景点管理员：负责旅客门票的检票、上传。

会员：经确认具有足够信用度的个人或单位。

游客：购票者。

针对旅游集散中心对角色及规则的需求，特别是平台需要从纵向上，扩展现有角色管理规则。所定义角色管理方法对角色进行了扩展定义，具体包括：

父与子。角色与角色之间可以存在父与子的关系。父组定义的属性、规则，在子组中有相应的体现。而子组中往往还包含比父组更具体、更贴近业务的属性。

继承与覆盖。对于父与子间相关、相似的属性，存在继承和覆盖关系。继承指子组对父组的属性进行完整保留，不做任何修改。覆盖指子组对父组的属性进行重新定义，与父组的属性存在适度的不同，一般是对父组属性的具体化和精细化。例如，在旅游集散中心平台中，成本管理员和成本统计员就是父子组的关系，成本统计员继承了成本管理员的查看、统计成本信息的属性。

上级与下级：角色间还存在上级与下级的关系。上下级与父子角色不同，上级角色有对下级角色进行调整、管理的权限。上下级角色之间不一定会存在相关或相似的属性。例如，在旅游集散中心平台中，票务管理员和售票员就是上下级角色的关系，票务管理员负责对所有售票员、退票员进行管理。

角色间共享：包括内容共享和权限共享。内容共享指用户可以看到组内其他用户内容，但无操作权限。权限共享指，组内用户的权限完全一致。组间共享目的是解决旅游集散中心平台权限相关的实际业务需求。通过内容共享，平台可以支持组内高级别用户检查低级别用户工作内容的情况。通过权限共享，平台可以解决业务决策时相关组内用户不可达的情况，将权限暂时共享，使组内其他用户代替不可达用户完成业务决策操作。

组间协同：指业务环节或技术流程中，涉及到多个组的协同。为了明确表示组间的协同关系，所定义角色管理方法引入了组间协同的概念。例如，旅游集散中心平台中，票务组与售票组存在协同售票的关系，为了在业务流程中明确体现这种关系，需要定义这两组的协同关系。

权限在所定义角色管理方法模型中，指的是对模型对象的操作方式。在跨区域旅游集散中心电子商务平台中，所定义角色管理方法对权限的基本定义如下：

业务层面：包括设定景点、设定旅游路线、设定票务、核定成本等；

技术层面：包括设置用户权限、设置权限规则、平台参数设置等；

审计层面：包括审计权限设置、审计业务流程、审计权限规则等。

所定义角色管理方法对权限和规则进行了扩展定义，具体包括：

最少权限。所定义角色管理方法模型要求每个角色所拥有的权限，必须是该角色能够使用的最少权限。即不允许存在角色拥有过度的权限。例如，在旅游集散中心平台中，票务管理角色的权限只能仅限于订票、出票的管理，而不能涉及景点设置、线路设置等的相关权限。当两个权限发生重叠时，以判定条件较明确者为先。例如，“早上10点发车”与“早上发车”，前者时间限制显然较后者更为明确，因此应先满足前者的需求。

基数约束。所定义角色管理方法模型要求在定义权限时，明确指定权限与对象之间是一对一、一对多还是多对多的关系。基数约束，是整个平台数据库设计的基础。

角色容量。所定义角色管理方法模型对每个权限对应的角色数量进行了约束。避免重要权限被过多角色、用户拥有。

正向权限、反向权限。权限在赋予的过程中，存在对拥有或剥夺某些权限的强调性。正向权限确保了该角色必须能拥有某些权限，而不管该角色之前的权限如何定义；反向权限确保了该角色必须不能拥有某些权限，而不管该角色之前的权限如何定义；引入正向权限和反向权限，能方便平台在设定重要权限时，避免陷入过多的权限判断。

先决关系，即必要条件。通常指角色在拥有某个权限时，必须已拥有其他一个或多个权限。

双岗(多岗)权限。在旅游集散中心平台，存在以下需求场景：某个操作，要求必须多个指定用户或角色同时发起，才能执行的情况。所定义角色管理方法引入双岗权限的概念，在定义权限时，增加了专门的属性，用于描述多岗权限的情况。例如，旅游集散中心平台要求，修改核心业务流程，必须有业务管理角色和技术管理角色同时执行的情况下，才能执行。

静态互斥关系、动态互斥关系。权限之间存在互斥的关系，包括静态互斥与动态互斥。静态互斥指在权限定义时即已明确两个权限为互斥关系；动态权限指两个权限需结合其他条件时，才能构成互斥关系。

权限的动态定义。权限的动态定义，是对以上各属性的综合丰富。在定义权限的各个属性时，通过引入日期、时间、条件语句等多种参数，来动态定义权限。使得权限的定义更加开发和自由，也能更好地满足业务需求。例如，在旅游集散中心平台，对于审计管理角色，本专利需要为它赋予在每季度末进行相关审计的权限。且此权限有时间段、业务单元范围、审计流程等一方面的约束。通过权限动态定义，能完整地描述审计管理角色的“季度审计”权限和约束。

5.3角色管理实现

5.3.1角色管理采用的设计模式

实施例采用MVC三层结构，基于.NET框架进行实现，将用户显示(视图)从动作(控制器)中分离出来，提高了代码的重用性。同时将数据(模型)从对其操作的动作(控制器)分离出来，降低了系统间的耦合问题。一旦平台业务规则和角色管理逻辑发生改变，只需要编写新的实现类，即可与现有的视图和模型代码接驳，不需要对整个平台作较大的调整。这能很大的提高平台的灵活性。

5.3.2角色管理的持久层设计

持久层设计是平台设计中的一个重点。本专利需要在表结构中，尽可能地定义满足角色管理的相关字段。并给平台进一步的权限要求，留下接口。整个平台的角色管理相关表大致包括以下：

1)User表、UserGroup表，分别保存用户信息和用户组信息。其中核心的字段为：

ActiveRuleType，用于表示用户动态规则。

2)ActiveRule表，用于保存权限相关的动态规则。核心字段为：

ActiveDate，有效日期；

ActiveTime，有效时间；

LoopType，循环周期类型；

ConditionType，其他复合条件，额外通过SP代码进行编写实现。

3)Role表，用于保存角色信息。核心字段为：

ParentRole，用于保存该角色的父角色列表，当前角色可以从父角色继承相关的属性；

ChildrenRole，用于保存该角色的子角色列表，子角色可以从当前角色继承相关的属性；

SuperiorRole，用于保存该角色的上级角色列表，上级角色可以指派当前角色的相关权限；

SubordinateRole，用于保存该角色的下级角色列表，当前角色可以指派下级角色的相关权限；

ShareRole，用于保存与该角色互为共享角色的列表，即该角色与当前角色对某对象有同等的权限；

CooperateRole，用于保存与该角色互为协同角色的列表，即该角色必须与当前角色一起，才能对某对象进行某种操作；

需要特别强调，父子角色与上下级角色有较大的区别。当前角色无条件的从父子角色处继承/被继承各种相关属性。而上下级角色只有指派权限的功能，不继承/被继承其自有的属性。

4)Permision表，用于保存权限信息，其核心字段为：

InheritRule，用于保存继承规则，权限是否可以继承，主动继承还是被动继承等；

RadixRule，用于保存维度规则，表示权限矩阵管理维度属性；

CapacityRule，用于保存容量规则，表示当前权限是否有容量限制。权限所有者的最大和最小数量等；

PositiveGroup，用于保存正向权限列表；

NegativeGroup，用于保存负向权限列表；

PremiseRule，用于保存权限前提列表；

ABRule，用于保存双岗、多岗权限列表；

StaticMutexRule，用于保存静态互斥权限列表；

DynamicMutexRule，用于保存动态互斥权限列表；

ActiveRuleType，用于保存进一步的动态权限定义。

5)InstantAppSession表，用于保存持久应用会话信息。其核心字段包括：

UserId，用户唯一标识；

LogonDate，用户登录日期；

LogonTime，，用户登录时间；

InstantUserRole，用户登录后的角色列表。

6)MatrixRule表，用于保存矩阵管理的相关属性。其核心字段包括：

MaxParticipantRule，矩阵管理最多参与数；

DimensionRule，矩阵维度参数；

电子商务平台数据库的设计，以集散中心的角色管理为模型，同时结合SQL2000的特性，进行了一定的优化。根据上文所定义角色管理方法模型的设计思路，本专利将业务逻辑映射到数据库中的多个表。包括用户表、角色表、权限表、用户角色表、权限表、模块表等。通过表与表之间的E-R关系。能够很好地将角色管理中的业务逻辑约束在数据库底层逻辑上。图2为平台权限关系部分的E-R图：

5.3.3访问控制验证策略

在系统的数据库中，保存一张登记有每个用户名称、ID、口令和有关情况的表，用于对用户进行识别。表中的用户名、标识是公开的，口令则是保密的，当用户要访问系统时，须首先把自己的名称或功和口令登记到系统中(即出示证件)。为了安全起见，防止他人盗用帐号，系统限制用户不得连续三次输错登陆口令，否则自动封锁帐号。用户在登录界面输入用户标识(名称或ID)和口令P，应用程序端将用户ID传送至数据库端，数据库按照用户ID查找存储在表内的对应用户的口令密文HP，产生一个随机数R，并将密文HP与随机数R进行一次加密运算得到密文H(HP+R)，同时数据库端将口令密文HP和随机数R返回应用程序端，应用程序将口令P进行一次加密后得到密文HP，并将HP与返回的随机数R再做一次加密运算，得到密文H(HP+R)，并发送到数据库端，数据库端将两个密文进行比较，若一致，则认定登录用户合法，若不一致，则判本次登录非法。对于合法的登陆，数据库返回对应用户的活动角色集及其可以访问的功能列友。

为了提高平台的安全性，尽可能避免恶意的攻击，本专利要求所有的PC终端和打印机必须通过登记和认证。用户通过电子商务Web网站提出申请，经过中央商务平台进行审核，如图3所示：

在所定义角色管理方法模型中，本专利采用了部分控制访问的策略，预先对角色、权限制定了一系列的约束，这种自检的过程能够大量减轻管理员的工作负担，减少用户在访问过程中产生的大部分冲突。

5.4软硬件选型

5.4.1开发环境

开发语言：ASP.NET(.NET Framework 2.0)

开发工具：Microsoft VS.NET 2005

服务器操作系统：Windows2000/2003 Server

服务器数据库：SQL Server2000

5.4.2服务器

1)托管独享服务器或自建中央机房。

2)网络接入具备2M以上独享带宽，VPN接入。

5.4.3用户环境

接入互联网的普通计算机：CPU PIII 1G以上，内存256M以上，网速512K以上时有好的用户体验。

5.4.4其它要求

1)根据并发用户数量来逐步更新服务器配置与带宽。

2)根据情况安排双服务器热备机制，并托管于不同机房。

3)对于非注册用户，采用DNS轮询机制选择服务器；对于注册用户采用规则判断及自动跳转方式。

4)服务器用户数据每晚进行同步传输。

6、专利效果

本专利涉及的角色管理及其实现方法，已经在长三角城市如上海旅游集散中心黄埔站、舟山旅游集散中心等实施例中实现。运营系统自2009.7月正式运营以来，系统稳定，班次编排有效，每月处理业务量达1500万元左右。

7、附图说明

图1.电子商务平台用户—角色—操作图

图2.角色管理ER图

图3.终端注册方案图

图4.机构管理—查询

图5.机构管理—添加

图6.机构管理—编辑

图7.机构管理—停止

图8.机构管理—恢复

图9.用户组织图

图10.角色管理

图11.角色管理-权限设定

8、具体实施方式

本专利涉及的角色管理与实现方法，已经在长三角城市如上海旅游集散中心黄埔站、舟山旅游集散中心等实施例中实现。以下是对该实施例的描述。

8.1机构管理

可以管理本集散中心下属的所有二级机构信息，具体功能包括查询、新增、修改、停止、恢复。

1、查询

从菜单点击“权限控制-机构管理”进入本模块，系统会默认分页显示本机构所有一级机构简要信息。通过查询条件，可以查找特定的机构，操作方式：首先选择查询条件(机构代码、机构名称)，然后在条件内容输入框中输入具体内容，可以是条件的部分内容，系统支持模糊查询，然后点击“查询”按钮，系统就将查找结果显示在下方的表格中，如图4所示：

2、添加

从菜单点击“权限控制-机构管理”进入本模块，系统会默认分页显示本机构所有一级机构简要信息。通过添加按钮，可以新增机构信息，操作方式：首先点击添加按钮

在弹出框中输入要新增的机构信息，单击确定按钮新增记录，如图5所示：

3、编辑

从菜单点击“权限控制-机构管理”进入本模块，系统会默认分页显示本机构所有一级机构简要信息。通过编辑按钮，可以更改机构信息，操作方式：首先点击机构代码前的选择按钮，选中需要进行修改的机构，点击停止按钮

在弹出框中修改机构信息，单击确定按钮保存修改，如图6所示：

4、停止

从菜单点击“权限控制-机构管理”进入本模块，系统会默认分页显示本机构所有一级机构简要信息。通过停止按钮，可以注销机构，使其状态更改为无效，操作方式：首先点击机构代码前的选择按钮，选中需要注销的机构，点击停止按钮

该机构状态即改变为无效，如图7所示：

5、恢复

从菜单点击“权限控制-机构管理”进入本模块，系统会默认分页显示本机构所有一级机构简要信息。通过恢复按钮，可以恢复被注销的机构，使其状态更改为有效，操作方式：首先点击机构代码前的选择按钮，选中需要恢复的机构，点击恢复按钮

该机构状态即改变为有效，如图8所示：

8.2用户管理

系统中每个用户都必须隶属于一个组织机构(用户组)，每个旅游集散中心可以管辖下属的用户，如图9所示。

所有的用户分为3种类型：系统管理员、业务管理员、业务操作员，系统管理员只能进行权限控制工作，不能操作业务模块；业务管理员和业务操作员能够操作业务模块，不能操作权限控制模块。

中央商务平台的系统管理员、业务管理员是由系统内置的默认管理员来开设。

每个一级机构在中央平台上被创建时默认都开设一个系统管理员和业务管理员。一级机构的系统管理员，其可以管辖该组织里所有下属的用户和系统参数设置；一级机构的业务管理员可以管辖所有的业务操作模块，但是不能开设用户。中央电子商务平台的系统管理员可以管辖平台中所有的用户，但是不参与业务运作。

用户信息主要包括：用户代码、用户登录名称、登录密码、用户级别、用户类型、姓名、工号、职务等。在用户管理页面中，可以用户信息进行新建、编辑、停止、恢复和强制离开的操作。

强制离开

当终端没有正常退出，集散中心管理员可以通过点击需要强制退出的用户帐号前的圆圈，然后点击

按钮，强制该用户即退出系统。

8.3角色管理

如图10、图11所示。

8.4应用效果

实施例中的跨区域旅游集散中心电子商务平台，维护着4类角色层级、38类角色、101类用户。其中一类角色5类，包括：集散中心、汽车公司、景点、酒店、结算公司。二类角色4类，分别为业务操作层、业务管理层、技术管理层、审计核算层的各级管理员。三类角色8类，此层次的角色主要从第四类角色中继承部分操作权限。四类角色21类，包括各类实际操作角色，如售票员、检票员、设计员等。由于本专利所定义的角色模型有效解决了角色层级、矩阵管理等问题，整个电子商务平台可对复杂灵活的权限控制加以有效管理。

Claims (2)

1.一种跨区域旅游集散中心电子商务平台的角色管理。特征：本专利所提出的角色管理模型，将传统的单一角色分为技术管理层、业务管理层、业务操作层、审计核算层，进行角色权限的管理与分配。

2.权利要求(1)所提角色管理方法在实施例中基于.NET的系统设计实现方法。特征：基于.NET和B/S结构；基于角色流程将系统功能抽象为元节点，满足不同层次实体之间的分层角色管理与协作；可以动态更改角色的元功能节点，满足动态权限分配要求。

Images