WADER

java,swt,hibernate,struts,xml,spring,ant,cvs,uml,db,server
随笔 - 15, 文章 - 0, 评论 - 0, 引用 - 0
数据加载中……

2006年6月12日

在LDAP中使用角色(Role)和组(Group)来管理用户

LDAP(轻量级目录服务器)越来越被广泛的使用,特别是在管理海量用户信息和管理身份认证信息的时候,LDAP被国内大多数企业所使用,从中国电信,中国移动,新浪,和许多省市政府部门都使用LDAP来管理用户身份的信息。下面重点介绍在LDAP中管理用户的一些概念和技巧。

LDAP服务器使用树状结构来存储和查找用户的信息。这种树状结构比较适合用户身份信息的存储,因为无论在社会还是在企业中,对人的管理是分层的。从地域上的国家、省市到区域,从企业的大部门到小部门,从总经理到小职员,所有的管理都是分层的。“人类的层次划分是社会活动的自然产物”,忘了这句话是谁说的了,但是我们观察自己的周围环境,树状结构的分层无处不在,这也是LDAP为什么在人员管理上这么流行的原因,也是LDAP最初设计的需求。当然,在这里我们不讨论人类社会活动现象,只讨论LDAP技术问题。

LDAP在存储树状结构的数据比关系型数据库有很大的优势。请试图想想在关系数据库中要实现这种树状的数据,需要费一番功夫,并且要定位层次比较深的节点的数据需要经过复杂的查询和转换。但是LDAP这种树状的结构也有一个重要的缺点,就是很难反映出除了结构层次之外的其他关系(例如在同一个组织之下的管理和被管理的关系),而且当组织结构经常发生变化的情况下,树状结构很难满足这种灵活性的要求。有树状结构特点决定,当一个组织变化的时候,这个组织下的所有节点都需要一一变化。

因此,在LDAP中出现了Group(组)和Role(角色)来动态的管理节点之间的关系。例如,建立一个“管理员”的组或角色,然后可以将不同组织结构下的人员放到“管理员”这个逻辑结构下。那么通过“管理员”这个虚拟的组织结构可以将不同物理组织下的人员动态的组合在一起。例如给“管理员”赋予特殊的权力,使他们能够修改本机构中的人员信息。过了一段时间,如果需要将“管理员”这个逻辑组织取消或者改动,只需要在LDAP的单个节点上操作,而实际“管理员”逻辑结构的成员们,不需要作任何的变化,原来是在哪个物理组织,现在也不用变化。这种Group(组)和Role(角色)的出现是增加了节点之间的关联程度。

Group(组)和Role(角色)的功能基本相同,操作起来也很类似。那么Group(组)和Role(角色)到底有什么区别呢?事实上,由于实现方法不同,Group(组)和Role(角色)在某些操作上体现出不同的性能。

Group(组)的实现机制很简单,每个Group本身就是LDAP的一个实体。这个实体有个member的属性。每次将一个成员添加到这个Group中就会在Member属性中添加一条记录(成员的DN)。如果这个Group有200个成员,那么它的member属性中会有200条记录。这种实现方式非常适合下面的操作:1. 列举当前Group下的所有成员。2.将一些成员从当前的Group中删除或添加。因为所有的成员都记录在Group实体的属性里;这种实现方式非常不适合下面的操作:查找某个用户所属的所有Group。这个操作可能要去每个Group中查找信息。

Role(角色)的实现机制就比较复杂了。其实每个LDAP实体本身都有一个“nsrole”的属性。如果某个角色赋予这个用户的话,就会在这个用户的“nsrole”(其实是nsroleDN,这个会在以后解释)的属性中添加一个角色的记录。如果当前用户有10个角色(例如,他又是领导,又是员工,又是管理员,又是教授....),那么在这个用户的"nsrole"属性中会有10条记录(Role的DN)。这种实现方式非常适合下面的操作: 列举当前用户拥有的所有的角色,因为在用户的“nsrole”属性中记录了所有的角色。因此给一个用户授权通常使用角色,这是因为从用户信息中就能很快获得当前用户所有的角色,以及相关的权限。

另外还有一些准则来帮助判断在设计时到底使用Group还是Role。

1 使用Group会很容易将用户从一系列“逻辑组织”中删除或添加。只要是Group的创建者,就有权限修改Group中的member属性。而角色(Role)的信息存在每个用户的“nsroleDN”中,需要特定的权限才能修改这个属性。

2 如果要使用分布式部署(例如使用Chaining的方式),要考虑到角色(Role)是无法跨越服务器的界限

3 如果成员数量巨大(超过20000)个,可以使用动态组的概念(FilterGroup),这个以后再将。

posted @ 2007-09-24 11:32 wader 阅读(5668) | 评论 (0)编辑 收藏

Lucene in Action(中文版)

     摘要: Lucene in Action 中文版  第一部分 Lucene核心 1.      接触Lucene  2.      索引 3.      为程序添加搜索 4.    ...  阅读全文

posted @ 2007-09-09 11:45 wader 阅读(1903) | 评论 (0)编辑 收藏

UI项目的团队组合(来自微软的借鉴)

UI项目的团队组合(来自微软的借鉴)


2006.06.11    

来源:ChinaUI

UI设计人员是对产品的使用界面进行设计和订正的人员。 Usability Engineer是检验UI设计的合理性的人员。

在很多团队,真正的界面设计都是由PM做完了Spec,才找UI设计人员来征求意见。像我们团队,我的设计规范书写完后,我才找UI设计人员来,他们所做的也就不过是对我的设计作小改动,如那些英语词句用得不妥,哪里的按钮该改变大小,等等。我所知道的其它视窗操作系统的团队,也是差不多。这主要是因为我们能自己进行界面设计——视窗操作系统部门的PM是微软PM中最厉害的。可是,这是不太正确的方法,因为如果你有很强的PM,你可用这种方法,要是你的 PM的设计能力不强,这样的流程就要出问题。你的项目的成功不应该寄托在几个强有力的PM上,而是要用完善的流程来保证。好的流程应该是,在产品开发的早期,在做设计时,PM就应该和UI设计人员一起来考虑产品设计的合理性。

这个问题在微软内部我们自己也有很大的争论。 UI设计人员就常常抱怨,在产品开发的早期,他们常常不被看重,被抛在一边。UI设计的领导人甚至在全公司的培训大会上讲,我们的这个文化有问题,领导对 UI设计人员在产品开发早期能起的作用不够重视。可是这个争论已有几年了,结果仍无改变。我想这主要还是跟我们这个行业的产品开发的特性有关系。因为软件开发是很技术性的,常常在早期的技术讨论中,UI设计人员对技术讨论说不出个所以然来(因为他们大多是学艺术设计的),渐渐地各开发团队对UI设计人员的作用就看轻了。在使用界面因素占很大比例的产品团队,像 Office 和 MSN ,这种情况要好一些。

Usability Engineer 所做的事和UI设计人员不同。他们是将UI设计的模型版,找客户来进行实用和使用性能的检验调查和测试,并根据调查结果对UI设计提出进行修改的意见。也就是说,他们的工作是检验UI设计的合理性,有点像测试人员对程序进行检验的功能。可以说,Usability Engineer 和UI设计人员的关系像测试人员与开发编程人员的关系。

User Education team 是编写使用说明书的编辑人员。

从大方面的来说,微软的产品组是公司的几大部门之一,其他还有市场/销售部门,服务部门,运作部门,还有研究院什么的。

合理的开发团队组合应该是什么? 允许我抛砖引玉,先谈一下微软的经验:

项目经理团队:(Program Management Team)
• 设计项目经理(Feature Design PM):负责具体的产品设计,写Design Spec,PM 队伍中,80%的PM是做这个。
• 发行项目经理 (Release PM):负责整个项目的流程和进度管理,制定进度表等,协调整个团队的工作。大的PM 队伍中有一人专门做这个。这是整个项目的领头人。大型的项目的成功与否,常常靠得力的发行经理的领导。
• 协助项目经理(Supporting PM):负责其它产品发行需要照顾到的事情,如客户交流、和市场开发人员交流、负责beta program(初版试行)等等。大的PM 队伍中少不了这样的人。20%的PM是做这个。

开发团队:(Development Team)
• 开发团队领导(Development Manager): 负责管理各个开发小组,并对开发编程的工作做总体的规划。
• 开发组长(Development Lead): 负责管理开发工程师,也参加对开发编程的工作做总体的规划。
• 开发工程师(Develop Engineer,or Developer):负责具体的编程开发。
• 构架师(Architect): 大的产品团队有一两个资深工程师专门做整体系统的设计规划。

测试团队:(Quality Assurance or Test Team)
• 测试团队领导(QA Manager): 负责管理测试小组。
• 测试组长(Test Lead): 负责管理测试工程师,制定测试计划等。
• 测试工程师(Tester or Test Engineer):负责具体的测试工作。
• 测试开发工程师(Developer in Test,or STED): 负责测试工具的开发。

产品可用性团队:(Usability Team)
• 产品可用性工程师(Usability Engineer): 做使用性能的调查和测试,采访客户或将客户邀请来做调查。
• 界面设计师(UI Designer): 负责具体的界面设计。
• 产品设计师 (Product Designer): 负责产品的总体设计,特别是硬件产品。

客户教育或文档团队:(User Education,or UE Team)
• 文档组长(UE Lead):负责管理文档小组。
• 文档编辑(UE Editor):负责具体的文档编辑和撰写。

以上只是一个大约的组合模式。不同的团队有各自的侧重点和变化。在很大程度上这些也受到具体的产品的影响。我想我在微软的产品部门的其他同事们会再做补充。希望这些信息能对国内的软件开发公司能有参考价值。我们希望通过这样的交流,我们能为中国软件开发事业的进一步发展尽我们的一点微薄之力。

posted @ 2006-06-12 09:47 wader 阅读(285) | 评论 (0)编辑 收藏