架构设计(Java).ppt

* 数据是分层的； 兼职问题有些麻烦，简单地依赖LDAP是比较麻烦； UI方面：为其它应用提供人员选择和查询的UI。 * 有两种基本的授权策略： 基于角色：对操作（通常是方法）的访问是基于调用者的角色成员保护的。 使用角色将应用程序的用户群分成在应用程序内共享相同安全特权的用户组；例如“高级经理”、“经理”和“职员”。用户被映射到角色，如果用户有权所请求的操作，则应用程序就会使用固定的身份访问资源。这些身份受各自的资源管理器（例如数据库、文件系统等）所信任 * 这是一个常见的模型； 基于角色的授权系统：用户、角色、权限。 * * 对外服务的种类： 接口 UI * 得到角色中的所有人资料相对复杂，尤其是存在着兼职情况。 * * 各逻辑层的划分： 系统分为三层结构：表现层、业务逻辑层、数据访问层； 管理用的业务组件应包含权限判断，服务用的业务组件不包含权限判断； 服务认证包括：机构人员底层服务、授权管理底层服务，服务有认证，但是应用没有认证； 业务逻辑层： 业务组件相互使用情况； 业务实体的封装：基于接口的设计，定义各个对象的基本属性，通过工厂模式创建对象，接口和实现都要体现出对象之间继承关系，必须能够序列化，最好能够序列化为xml，可以供客户端脚本处理； 业务实体的保存、加载：业务实体与O/R Mapping，定义业务实体和数据库表的对应，定义业务实体属性和表字段的对应，根据对应关系，生成CRUD的SQL语句；采用Lazy Loading加载子对象；通过UnitofWork来反映对象属性的变化； 业务实体和缓存：在授权系统中，为了提高判断效率，所有用到的机构人员对象，都会被保存到缓存中；运行一段时间后，缓存中将包含大多数机构人员对象，缓存中对象的时效，依赖于机构人员数据变更的消息通知。 * 数据存储： AD和关系数据库的比较； 关系数据库中保存树型结构，在机构人员中，每一个对象包含一个Path，使用Path来判断父子关系，Path可以用来表示深度有限的树,如： 总公司\办公室\秘书科\张三； 动态角色，动态角色描述保存为一个大文本字段(XML或表达式)； 服务接口： 服务接口也包含认证，但是仅仅对服务帐号进行认证，而不是应用帐号； 服务接口提供的形式：必须在服务接口的调用前后能够插入扩展功能，日志、缓存，Web Service和Socket具有一定的扩展性。 * 服务代理： 服务代理不一定封装服务接口暴露出来的所有方法； 服务代理的入口参数类型、返回参数的类型、调用方式都是为了方便调用者； 服务代理这一层可以设置缓存，缓存和调用者可以在一个AppDomain中； 授权系统在判断权限时所用到机构人员对象，都是通过服务代理得到的并且进行缓存的； 缓存： 服务接口中的缓存，缓存失效可能跟时间有关（有效期）； 服务代理中的缓存，缓存的失效可能和时间有关，也可以和外界的消息通知有关； 管理界面中用户认证信息的缓存，缓存的失效可能和Cookie有关。 消息通知： 我们参照Passport机制编写了统一的Web认证服务，认证方式可以动态地配置（LDAP、数据库），认证界面也可以定制（IC卡认证），为很多应用编写了Filter，帮助应用通过认证服务来生成角色。 * 用户界面： 调用者和人员选择界面不在一个站点上，只能通过标准的Get/Post/Frame(IFrame)来交换数据； 调用者和人员选择界面不在一个站点上，可以使用Web Dialog来传递复杂数据； 日志审核： 日志类型：调试信息、程序的异常、应用日志、安全审计日志、测试的状态数据… 产生日志的源：某一段代码、某一个应用、某一个站点； 日志的输出：根据不同的来源、类型等输出到不同的目的地；文件、邮件、Log、数据库；Log往往是缺省的选择（写日志出错也会尽量写到Log）；日志属性和日志输出的目的地之间的对应关系需要动态映射； 日志中需要保存哪些信息：环境信息：服务器地址，来源、严重程度、操作人… 测试 单元测试-对代码是否运行正确的低层测试； 集成测试-存在接口的模块之间的完成特定功能的测试； 业务测试-从业务执行的角度进行的黑盒测试； 服务水平测试-性能测试、容量测试； 验收测试-客户方执行的对系统整体是否符合要求的测试； 部署和可用性： 机构人员和授权系统的管理程序、后台服务、数据库、认证服务器可以单独部署到不同的服务器上； 机构人员和授权系统的管理程序的设计要考虑Cluster的情况。 * * * 讨论…… Workshop-实现案例2 关于需求 机构人员 机构包含组，组不包含机构，防止嵌套 组不再包含组，也是为了简化处理。在LDAP中，组可以包含组 在我们的应用中，通常需要象LDAP一样，权限控制在每个对象上，权限可继承。通常用户将部门分为几级，不同级别的管理