1 SOA简介：
1.1 SOA 是一种 IT 体系结构样式，支持将业务作为链接服务或可重复业务任务进行集成，可在需要时通过网络访问这些服务和任务。这个网络可能完全包含在公司总部内，也可能分散于各地且采用不同的技术，通过对来自纽约、伦敦和香港的服务进行组合，可让最终用户感觉似乎这些服务就安装在本地桌面上一样。需要时，这些服务可以将自己组装为按需应用程序——即相互连接的服务提供者和使用者集合，彼此结合以完成特定业务任务，使业务能够适应不断变化的情况和需求（在有些情况下，甚至不需要人工干预）。
1.2 当前架构所面临的问题：
1.2.1 复杂性：如一个“银行”可能拥有数套针对不同领域用户服务的“软件”，每一个运行正常，但同时带来了巨大的冗余
1.2.2 接口多样性：各个软件之间必须要考虑接口，可能形成网状的接口环境
1.3 Java 技术促成了平台中立的编程，而 XML 促成了自描述，因而也促成了平台中立的数据。现在，Web 服务通过允许应用程序以对象模型中立的方式实现互连，它具有以下特点：
1.3.1 无处不在的、开放标准的、低成本的网络基础架构和技术。它有助于一个分布式环境的形成，这个环境更有利于采用 Web 服务，而不是 CORBA 和 DCE
1.3.2 在一个以网络为中心的领域内达到的接受程度的技术成熟水平。它要求互操作性以实现关键的业务目标（比如，分布式协作）
1.3.3 基于 Internet 的开放标准和相关技术是实现低成本互操作性的最好方法。
1.3.4 基于网络的技术（比如 TCP/IP）、工具集（IDE、UML等等）、平台（比如 J2EE 平台）和相关的方法（比如 OO、服务等等）的成熟水平。它们提供了简化松散耦合的、可互操作的、机器到机器的交互（一种比 CORBA 用户体验到的高级得多的状态）所需的基础架构
1.4 更重要的机会刚刚出现，其中第一个就是网格计算，网格计算不仅是使用拥有大量 MIPS 的应用程序来进行计算的解决方案，而且还将提供一个框架，通过此框架可以动态地定位、重定位、平衡和管理大量的服务，这样，无论系统上的负载如何，总可以保证安全地获取所需的应用程序。而这又明显地需要按需计算的概念（on-demand computing），按需计算可能是在任何配置下实现的，从简单的服务器集群到有1024个节点的 SP2 网络。用户需要解决问题和适当的用于解决问题的计算资源——不多也不少——并且为实际使用的资源付费
1.5 Web 服务是包括 XML，SOAP，WSDL 和 UDDI 在内的技术的集合，它使您能够针对特定的消息传递和应用程序集成问题构建编程解决方案。
1.6 其一，服务是真正独立的；其二，它们是可以管理的。管理包括许多功能，其中有：
1.6.1 安全性——请求的授权、加密和解密（在需要时）、确认等等
1.6.2 部署——出于性能、可用性冗余或其他方面的原因，允许服务在网络内重新部署（移动）
1.6.3 日志——用于审核、测量等等
1.6.4 动态重新路由——用于故障排除（fail over）或负载平衡
1.6.5 维护——管理服务的新版本
1.7 体系结构中的集成需求：
1.7.1 应用程序集成：
1.7.2 终端用户界面集成：终端用户界面集成涉及如何集成特定用户访问的全部应用程序和服务来提供可用、高效、一致的界面
1.7.3 应用程序连接：应用程序连接是一种集成方式，它涉及体系结构必须支持的所有类型的连接。在一个层次上，这意味着数据的同步和异步通信、路由、转换和高速分布、以及网关和协议转换器等等。而在另一个层次上，它还与输入和输出或源（sources）和汇（sinks）的虚拟化有关
1.7.4 流程集成：流程集成涉及开发映射到业务流程和为业务流程提供解决方案的计算流程、将应用程序集成到流程以及集成一些流程与其他一些流程。
1.7.5 信息集成：信息集成是一个流程，其作用在于为所有需要它的应用程序提供对企业中全部数据的一致访问，而不管这些应用程序是以什么形式需要它，也不受数据的格式、来源或位置的限制。在实现时，这项需求可能包括 适配器和转换引擎，不过它通常要比这复杂
1.7.6 构建集成开发模型：
1.8 部署面向服务的体系结构的好处：
1.8.1 利用现有资产 —— 这是首要的需求。通过使用适当的 SOA 框架并使其可用于整个企业，可以将业务服务构造成现有组件的集合。使用这种新的服务只需要知道它的接口和名称。服务的内部细节以及在组成服务的组件之间传送的数据的复杂性都对外界隐藏了。这种组件的匿名性使组织能够利用现有的投资，从而可以通过合并构建在不同的机器上、运行在不同的操作系统中、用不同的编程语言开发的组件来创建服务。遗留系统可以通过 Web 服务接口来封装和访问。
1.8.2 商品化基础架构 —— 在所有不同的企业应用程序之间，基础架构的开发和部署将变得更加一致。现有的组件、新开发的组件和从厂商购买的组件可以合并在一个定义良好的 SOA 框架内。这样的组件集合将被作为服务部署在现有的基础构架中，从而使得可以更多地将基础架构作为一种商品化元素来加以考虑
1.8.3 更快的产品上市速度 —— 组织的 Web 服务库将成为采用 SOA 框架的组织的核心资产。使用这些 Web 服务库来构建和部署服务将显著地加快产品的上市速度，因为对现有服务和组件的新的创造性重用缩短了设计、开发、测试和部署产品的时间。
1.8.4 减少成本 —— 随着业务需求的发展和新的需求的引入，通过采用 SOA 框架和服务库，为现有的和新的应用程序增强和创建新的服务的成本大大地减少了。同样，开发团队的学习难读也降低了，因为他们可能已经熟悉了现有的组件。
1.8.5 降低风险 —— 重用现有的组件降低了在增强或创建新的业务服务的过程中带来的风险。如前所述，这也减少了维护和管理支持服务的基础架构的风险。
1.8.6 持续改进业务过程 —— SOA 允许清晰地表示流程流，这些流程流通过在特定业务服务中使用的组件的顺序来标识。这给商业用户提供了监视业务操作的理想环境。业务建模反映在业务服务中。流程操纵是以一定的模式重组部件（构成业务服务的组件）来实现的。这将进一步允许更改流程流，而同时监视产生的结果，因此促进了持续改进。
1.8.7 以流程为中心的体系结构—— 现有的体系结构模型和实践往往是以程序为中心的。应用程序是为了程序员的便利而开发的。通常，流程信息在组件之间传播。应用程序很像一个黑匣子，没有粒度可用于外部。重用需要复制代码、合并共享库或继承对象。在以流程为中心的体系结构中，应用程序是为过程开发的。流程可以分解成一系列的步骤，每一个步骤表示一个业务服务。实际上，每个过程服务或组件功能都相当于一个子应用程序。将这些子应用程序链接在一起可以创建能够满足业务需求的流程流。这种粒度允许利用和重用整个组织中的子应用程序。
2 SOA生命周期：
2.1 建模：面向服务的体系结构项目的第一步几乎和技术没有任何关系，所有事项都与业务相关。面向服务的方法将业务所执行的活动视为服务，因此第一步是要确定这些业务活动或流程实际是什么。对业务体系结构进行记录，这些记录不仅可以用于规划 SOA，还可以用于对实际业务流程进行优化。通过在编写代码前模拟或建模业务流程，可以更深入地了解这些流程，从而有利于构建帮助执行这些流程的软件。建模业务流程的程度将依赖于预期实现的深度。另外，这个程度还依赖于开发团队中担任的角色。如果是企业架构师，将会对实际的业务服务进行建模。如果是软件开发人员，将可能对单个服务进行建模。
2.2 组装：对业务流程进行了建模和优化后，开发人员可以开始构建新的服务和/或重用现有的服务，然后对其进行组装以形成组合应用程序，从而实现这些流程。在“建模”步骤中，已经确定了需要何种类型的服务以及它们将访问何种类型的数据。已经存在某种形式的实现这些服务或访问该类数据所需的一些软件。“组装”步骤将要找到已经存在的功能，并为其添加服务支持。另外，还涉及到创建提供功能和访问数据源所需的新服务，以便满足 SOA 涉及的业务流程范围内的需求。
2.3 部署：进行了建模和组装后，要将组成 SOA 的资产部署到安全的集成环境中。此环境本身提供专门化的服务，用于集成业务中涉及的人员、流程和信息。这种级别的集成可帮助确保将公司的所有主要元素连接到一起协同工作。此外，部署工作还需要满足业务的性能和可用性需求，并提供足够的灵活性，以便吸纳新服务（并使旧服务退役），而不会对整个系统造成大的影响。
2.4 管理：系统就位，一切都正常运行。部署后，需要从 IT 和业务两个角度对系统进行管理和监视。在“管理”步骤中收集的信息用于帮助实时地了解业务流程，从而能更好地进行业务决策，并将信息反馈回生命周期，以进行持续的流程改进工作。需要处理服务质量、安全、一般系统管理之类的问题。 在本步骤中，将监视和优化系统，发现和纠正效率低下的情况和存在的问题。由于 SOA 是一个迭代过程，因此，在此步骤中，不仅要找出技术体系结构中有待改进之处，而且还要找出业务体系结构中有待改进之处。完成此步骤后就要开始新的“建模”步骤了。在“管理”步骤中收集的数据将用于重复整个 SOA 生命周期，再次进行整个过程。
2.5 控制：SOA 是一种集中系统；其中可以包含来自组织的不同部门的服务，甚至还能包含来自组织外的服务。如果没有恰当的控制，这种系统很容易失控。控制对所有生命周期阶段起到巩固支撑作用，为整个 SOA 系统提供指导，并有助于了解系统全貌。它提供指导和控制，帮助服务提供者和使用者避免遇到意外情况。
3 SOA的采用
3.1 构建服务：具有特殊连接的根据需要提供的服务
3.1.1 在 SOA 采用第一个阶段，通常会很偶然地着手构建 SOA 服务。也就是说，由于需要解决特定的问题，他们选择了面向服务的方法，而不使用传统方法。在此阶段，服务构建将更多地关注解决特定的问题，而不是对企业现有系统进行转换。IT 部门将构建一些新服务，或许会将一些现有应用程序转换为一组基于 Web 的服务。它们之间的链接将根据需要提供，而不是源自整个体系结构的要求
3.2 集成：具有可靠连接的系统标准化服务接口
3.2.1 发现了松散耦合体系结构的优势、方便性和易维护性后，下一步就是利用这种灵活性通过组合服务来创建新的组合应用程序。例如，员工状态服务可以与经理审批服务组合，以形成请假服务。这个过程可以采用自顶向下的方法，将重点放在最终结果和查找组件组成部分上。或者，可以采用自底向上的方法，将重点放在各个组成部分上，看看可以基于这些组成部分构建何种服务。他们之间的链接是预先计划的且定义良好。
3.3 转换 IT：组合可重用服务，利用多个来源的功能
3.3.1 这个阶段涉及到对信息技术基础设施进行转换，以便充分利用 SOA 的优势。在此阶段，所有系统将转换为基于服务的应用程序，松散耦合是其中的规范做法，而不是例外。系统的所有组件都将根据 SOA 进行集成和连接，IT 系统的所有部分都在 SOA 内工作。
3.4 转换业务：对服务进行动态的事件驱动的重新配置
3.4.1 在 SOA 成熟的最后一个阶段，业务与 SOA 完全集成，达到了这样一个程度：所有合适的业务活动都被视为服务，可以最终在技术体系结构中对其进行建模、分析和实例化。达到此阶段需要业务部门进行大量的工作和投入；不过，达到此阶段后，业务将从面向服务的体系结构获得最大的回报。
4 采用SOUP：
4.1 SOUP （Service-Oriented Unified Process）是一种使用 RUP(Rational Unified Process，这里可使用Rose2003) 和 XP(极限编程，采用jUnit单元测试等方式) 中的最佳部分来构建和管理 SOA 项目的软件方法。它的目标是任何组织中正在进行的 SOA 项目。
4.1.1 典型的软件开发项目包含应用程序开发过程、项目管理以及所使用的技术。此外，软件开发项目通常具有四个变量：时间、预算、范围 和质量。任何一个变量的变化对整个项目都有影响。不断变化的业务需求使得范围和质量成为两个最难管理的因素。技术复杂性可能导致时间和预算管理方面出现问题。 SOA 项目比通常的软件项目复杂得多，因为它们要求配备更大的跨功能的团队，并且还有因此而带来更复杂的团队间沟通和日常管理工作。 虽然 SOA 可以为组织带来许多好处，但同时也可能带来很大的成本支出和时间消耗。如果项目没有经过良好定义，并且在项目启动时没有关于最终结果的远景，则失败的可能性就非常大。
4.1.2 可以帮助 SOA 成功完成的关键因素有：
4.1.2.1 明确定义的开发过程
4.1.2.2 与业务相关的项目团队之间增强的沟通渠道
4.1.2.3 明确的支持和控制策略
4.1.3 在初始开发过程中，采用正式软件方法是尽可能地减少已确定的风险的最好办法。成功建立了 SOA 项目后，可利用正式的维护和增量开发方法来增加项目的 ROI。然而，XP 之类的灵活方法可能不够正式，不适合在初始阶段使用。SOUP 方法可帮助减少 SOA 推出阶段的风险，并能让您随后进行持续 SOA 优化工作
4.2 SOUP 是一个由六个阶段组成的软件开发方法。每个阶段代表对于 SOA 成功推出非常关键的一组特有的活动
4.2.1 初始：
4.2.1.1 确定组织对 SOA 项目的需求。您可以通过应用 SOA 成熟度模型来确定组织的体系结构成熟度水平并确定 SOA 的驱动因素。此时，您将需要向为业务服务的所有项目团队说明 SOA 的基本概念，并拟订与反馈和建议流程有关的策略计划
4.2.1.1.1 SOA 远景和范围：给出项目的整体远景。它还提供了确定项目范围的边界，该范围至少应包含两个业务线或项目。
4.2.1.1.2 SOA 策略：说明项目将如何执行的概略计划。
4.2.1.1.3 ROI 分析：给出此项目将带来的成本支出和节省情况。
4.2.1.1.4 沟通计划：说明 SOA 团队将如何与其他项目团队和业务用户进行沟通。
4.2.1.2 跨功能分析人员和项目管理人员将对客户的业务进行分析，以确定基于 SOA 的解决方案的优势。分析人员将对客户的内部操作进行研究，此外还要分析其与合作伙伴、供应商以及他们的客户的交互情况，而且也会研究其总体业务模型。这些因素有助于分析人员制定 SOA 策略并向客户推荐。在此阶段，您还需要对推荐的 SOA 策略进行全面的 ROI 分析。此分析应当清楚地表明短期、中期和长期的成本优势
4.2.2 定义：
4.2.2.1 是 SOA 项目中最为关键的阶段。此阶段业务和项目团队的参与将最终决定项目的成功
4.2.2.2 项目生命周期的此阶段的活动包括：
4.2.2.2.1 收集需求
4.2.2.2.2 分析需求
4.2.2.2.3 定义非功能需求
4.2.2.2.4 制定项目计划，其中包含时间安排和项目估算
4.2.2.2.5 定义技术基础设施
4.2.2.2.6 定义和实现用例
4.2.2.2.7 定义和记录总的体系结构
4.2.2.3 此阶段的主要交付内容有：
4.2.2.3.1 功能需求文档：详细描述 SOA 将作为业务服务提供的所有业务流程。
4.2.2.3.2 非功能需求文档：包括性能注意事项、服务水平协议 (SLA) 和基础设施要求。
4.2.2.3.3 用例和用例实现：详细说明将构建的所有业务服务的用例。
4.2.2.3.4 SOA 体系结构文档：描述项目总的体系结构，包括硬件和软件组件。
4.2.2.3.5 SOA 适用性文档：说明哪些项目将在 SOA 项目的范围内以及如何在 SOA 的基础上构建后续项目。
4.2.2.3.6 基础设施定义文档：包括详细的基础设施部署图，其中列出相关服务器以及实现 SOA 所需的服务器的连接和连接位置。
4.2.2.3.7 项目计划：整个项目的详细计划，包括里程碑和依赖关系。
4.2.2.3.8 支持和控制模型：描述将如何支持和控制 SOA。其中包括各种注意事项，如 SLA 监视和管理。
4.2.3 设计：
4.2.3.1 对定义阶段确定的设计构件进行细化。用例实现和软件体系结构文档将转化为详细的设计文档
4.2.3.1.1 此阶段的主要交付内容有：
4.2.3.1.1.1 详细设计文档：描述如何设计和构建服务。
4.2.3.1.1.2 应用程序编程模型：提供有关设计开发项目的结构的指南。涉及的主题包括使用的流程和技术、编码标准以及部署过程。
4.2.3.1.1.3 数据库模型：包括 SOA 使用的数据库的实体关系图。
4.2.3.1.1.4 测试和 QA 计划：详细说明测试和 QA 计划，并在其中包括测试用例。
4.2.4 构造：
4.2.4.1 使用选择的迭代构建方法来构建 SOA。此阶段中包括新的开发和集成活动。活动不仅限于软件方面，还涉及到与基础设施相关的子项目，如硬件整合项目或服务器承载集中化工作。虽然整个工作是在单个 SOA 项目中进行管理的，但仍然很有可能将由各种小型子团队进行不同的构造活动
4.2.4.2 项目生命周期的此阶段将涉及到各种活动：
4.2.4.2.1 迭代开发
4.2.4.2.2 迭代 QA 和测试
4.2.4.2.3 用户文档
4.2.4.3 此阶段的主要交付内容：
4.2.4.3.1 基本代码：该代码应存储在某类源代码管理存储库中。
4.2.4.3.2 测试结果：执行测试用例和 QA 计划的结果应可供进行检查分析。
4.2.4.3.3 文档：文档中应包含关于代码以及对设计文档的任何更新的详细信息
4.2.5 部署：
4.2.5.1 在部署阶段，将向各个项目团队推出 SOA，这些项目团队将开始在其生产环境中的项目上使用此 SOA。此阶段最明显的主要交付内容或许就是投入生产环境中使用的应用程序。然而，SOA 试验项目的计划却是更为重要的交付内容。这将导致进入 SOUP 方法的下一个步骤，该步骤将确定后续项目如何使用新体系结构。
4.2.5.2 此阶段的其他主要交付内容有：
4.2.5.2.1 部署模型：给出总的 SOA 部署结构。
4.2.5.2.2 用况模型：提供有关如何使用 SOA 的指南。随着各个项目团队和业务线开始使用新体系结构，此模型会变得非常重要。
4.2.5.2.3 后续支持级别模型：将对定义阶段开发的支持和控制模型的任何更新进行系统化。
4.2.6 支持：
4.2.6.1 软件开发周期的这最后一个步骤非常重要。在支持阶段，您将确保提供后续 SOA 支持、错误修正和进行新功能开发。项目生命周期的此阶段将涉及到各种活动：
4.2.6.1.1 维护
4.2.6.1.2 错误修正
4.2.6.1.3 培训
4.2.6.1.4 持续项目投入
757
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
