bea-01-SOA的实施思路与方法.ppt

SOA的实施思路与方法 刘晓宇 内容 SOA对基础架构的需求 BEA的SOA方法学 参考架构 项目与应用 服务的生命周期 什么是面向服务架构 (SOA) 应用基础架构 应用基础架构提供了设计、构建应用程序与服务的工具、框架和运行时支持，使其作为统一的运行时环境来管理 为业务应用及服务提供统一的开发和运行时支撑 为系统架构师、开发者及系统管理员提供管理其业务应用生命周期的工具 为现有和新生的开发模型 (J2EE、Web Services、SIP等)和行业应用框架 (OSS等)提供支撑 为企业级运营健壮性、安全性和零宕机体系提供支撑 应用基础架构的不足 企业IT完善过程中，服务逐渐增多，系统越来越复杂 所谓无形的IT资产，企业到底有哪些服务呢？ 在应用集成时，如何了解并获取所需的服务？ 服务如何能够更方便地被随时、随地复用呢？ 当接入的服务发生变化时，对系统有哪些影响呢？ 基础架构平台应对SOA挑战 浮出水面的服务基础架构 内容 SOA对基础架构的需求 BEA的SOA方法学 参考架构 项目与应用 服务的生命周期 经验证的方法学— BEA的SOA域模型 构建成本 业务和IT优势 主要衡量指标 BEA的SOA参考架构模型 信息和访问服务 企业数据访问的管理 提供访问任何数据源数据的能力 利用公用的企业级词汇 通过统一入口来执行数据授权规则 描述现有企业应用提供的功能性 根据现存企业资源创建或收获而来 为业务人员和业务应用暴露这些资源内的数据 通过实现流程或查询来提取跨越分布式数据源内的信息 整合不同数据结构和格式 共享业务服务 共享业务服务层表示业务的核心功能。 这一层通过创建新的可重用的业务逻辑来传递业务服务 它利用信息与访问服务层中的服务，来提供公共业务功能。 展现服务 通过使用公用的展现组件推进丰富的用户交互管理 Portlets提供了可重用的展现组件 为处理展现层功能的基础架构。如： 展现管理 用户管理 安全管理 内容管理 从事活动管理 多渠道传递 通过共享业务服务获得业务功能，通过信息和访问服务获得数据 复合应用 应用都是由底层的服务合成而来的 合成典型是通过编排底层服务来实现 合成通常是跨业务线和现存企业应用来传递业务需求的。例如： 跨企业业务流程的处理（典型的B2B应用） 业务事件的处理 从项目的方法来看SOA 劣势 是长期的 更大的前期投资 需更高的原则和技能 更小的灵活性 减小了标准性 遗失了SOA的好处 增加了长期的成本 通过服务基础架构，体现SOA厚积薄发优势 每个服务构件块都有自己对应的生命周期 与应用开发的生命周期类似融入了服务的概念 以可重用并可升级的方式来管理此生命周期是企业级SOA成功的关键 在服务生命周期的每个阶段使用适当的基础架构产品和最佳实践 组织架构和项目计划应该增加对生命周期的支持 服务生命周期需要基础架构的支持 应用基础架构提供了开发、运行和管理基于开放标准应用的平台 依赖于编程模式 使用了开放和事实上的标准 用于提高产出能力的框架 （开发和运行时） 强壮的平台还为停用提供零宕机和易管理的特性 Service Identification Design Service identification可通过以下几种方式来完成： 创建新的应用 或从现存企业应用中提取 组合新的业务流程 通用服务（如：logging和exception management）可以使用上述任一种方式来实现 通过开发新应用来实现Service Identification的例子 对现有传统软件设计方法学的扩充（RUP、UML等） 在应用开发中进行Service Identification的发展进程： 在这个应用中需要产生那些粗粒度的服务？ 谁是使用和提供这些服务的参与者？ 交互的顺序如何？有哪些消息需要交换？有哪些操作需要执行？ 创建一个应用开发项目的0级别视图，然后再通过放入具体的服务来细化这个视图 从现存应用中提取Service Identification 使用业务流程作为Service Identification的驱动 定位Service Identification时经常会问的问题 这些服务真的会在未来的一些项目中用到吗？ 创建服务的成本能否通过被重用的潜力来证明是正当的？ 需要将应用功能做成何种粒度的服务？ 这个服务是否使用系统中立的格式？ 这会否需要额外的开发工作量？花费是否可被证明是正确的？ 哪些是与性能相关的需要考虑事项？ 新服务层的介入添加了潜在的SOAP消息序列化和反序列化花销 不断增长的服务消费者可能为后端系统带来未预料的负载 是否有新带来的安全问题？ 企业服务将被更多不同的人访问 Service Identification后 Service Identification的最终结果：