A2K学习笔记3.1.docVIP

第二部分 Architect 2004 technical section 第七集 面向服务的体系结构（一） OOA的产生 OOA的产生来源于软件危机的应对（复杂性，一致性，易变性，不可见性） 关注组件的选择而不是组件的编写 技术的发展使得OO的实现成本逐渐下降 OO从最擅长In process sigle thread 环境扩展到 Out of Process,Distributed的环境。 Ooa vs Soa OO的扩展遇到了挑战 随着时间的推移，接口继承的复杂度在累积 随着系统间距离的延伸，透明的足见调用成本在上升，类型系统的不同步 扩展组件的功能成本高，不可确定未来需求，不可堆叠的扩展方式 重用与标准化，重用是OO的第一原则，难以维持和维护复杂的重用标准和机制 Soa的定义 Service: 是定义良好的，自包含的，不依赖于上下文和其他Service的一组功能。 Service-Oriented Architecture：本质上是一组服务的集合。这些服务之间相互沟通。这种沟通可以是简单的数据传输，或者是由两个或多个服务共同参与的一些活动，SOA也包括Service之间的连通技术。 Soa的特性 明确地定义系统边界，边界的种类有： 技术边界（信任，安全，运行环境），非技术边界（不同的团队，地理位置），正视跨越边界的成本，Message-based vs. RPC Soa的特性 每一个Service是自治的（Autonomous） 部署和版本 对待故障的态度 对待安全的态度 对待标准的态度 Soa的特性 Services与他们的消费者之间共享的是Schema和Contract(弹性的设计Schema/contract) 图 Soa的特性 以适用为目的的设计 避免预测未来 暴露过多的Schema，接口，方法 采用XP的方法来重构 Ooa vs soa OO仍然适用于Service的开发 明显的性能优势 成熟的设计与开发方法 SOA适用于系统的互联 互操作性的要求强于性能的要求 第八集 面向服务的体系结构（二） Soa设计范例 Process Service 承担着最主要的职责。所有的业务逻辑的实现都由其控制。 Process Service要求： 可以方便的修改和定义 对于业务人员来说易于掌握 方便的工具来开发和调试 健壮的异常处理（交易补偿） 大的Process 可以包含对于一系列小的Process 的调用 Soa设计范例 Entity Service 提供状态数据的修改服务 Business Services: 该服务用于更新一个或多个Entity的状态，相应的补偿服务也应该被定义 Query Services : 提供对Entity的查询功能 Event Services: 发出Entity状态变化通知，相关的订阅者（Entity Aggregation service, Reference Data Nodes） Entity Service 为遗留系统模拟出Request/Response或 One Way 交互方式 转换标准数据到遗留系统可以接受的格式可能使用遗留系统适配器 Entity Aggreqation Service 一个Entity里面的内容可能来源于多个系统。同一个Entity可能被复制到多个遗留系统。 Schema不同： 不同系统间的Schema相互包含，数据需要裁减 不同系统间的Schema的Key不同，需要跟踪合并数据实例。 Schema合并 实例合并 基础Web Services Single Sign-on Process Service 需要访问其下游的所有的服务，但是对于用户来说只须登陆一次，用户标识的传递是必须的 每一个遗留系统都有不同的用户验证机制，需要身份映射机制 不同的遗留系统其存储用户数据的方式/格式也不一样，需要同步用户数据 Single Sign-on Trusted Subsystem Model 服务使用特定的用户访问下游的子服务 Impersonation / Delegation Model 扮演：服务使用上游用户身份访问下游的服务，下游的服务和调用服务运行在相同的计算机上 委派：下游服务运行在不同的计算机上。 Saml Security Assertion Markup Language 使用Web Service作为交互手段 为什么使用 Web Service 建立在广泛的互操作基础上（URL，XML，HTTP） 支持自治的应用模型 灵活的发现和绑定服务 Web Service Specifications and Functions 第九集 企业应用集成的概述（一） 什么是企业应用集成EAI