SOA Practitioners Guide Part 2_CN

1 SOA专业人员指南专业人员指南专业人员指南专业人员指南 第第第第2部分部分部分部分 SOA参考架构参考架构参考架构参考架构 作者：Surekha Durvasula 2 参与本书参与本书参与本书参与本书的的的的SOA专业人员专业人员专业人员专业人员 Surekha Durvasula，Kohls，企业架构师 Martin Guttmann，Intel公司Customer Solutions Group，首席架构师 Ashok Kumar，Avis/Budget，SOA Architecture经理 Jeffery Lamb，Wells Fargo，企业架构师 Tom Mitchell，Wells Fargo Private Client Services，首席技术架构师 Burc Oral，个人贡献者 Yogish Pai，BEA Systems, Inc.，AquaLogic Composer首席架构师 Tom Sedlack，SunTrust Banks, Inc.，企业架构工程师 Dr Harsh Sharma，MetLife，高级信息架构师 Sankar Ram Sundaresan，HP-IT，首席电子商务架构师 审校审校审校审校人员人员人员人员 Steve Jones，Capgemini Group的Application Development Transformation部门，首席技术官 Prasanna Deshmukh，WebEx Communications，架构主管 Noam Fraenkel，Mercury Interactive，首席IT技术官 Ashok Nair，关于EAI和信息技术服务的管理系统分析师，卡尔加里城 Jeff Pendelton，SOA Alliance，执行主管 Annie Shum，BEA，SOA战略副总裁 Brenda Michelson，Elemental Links, Inc.，首席顾问及分析师 George Paolini，Georgepaolini.com，顾问 作者十分感谢为本文档做出贡献的组织和个人，他们撰写了部分文档，进行了大量编辑工作，还帮 助审校了文档并提供反馈。此外，作者还要特别感谢BEA Systems, Inc.，是这个公司提供了本文档 中的开发和演示所需的基础架构和平台。 3 目目目目 录录录录 1 关于本文档 ...................................................................................................................................4 1.1 摘要............................................................................................................................................4 1.2 目标受众 ....................................................................................................................................4 1.3 《SOA 专业人员指南》的优点 .................................................................................................4 1.4 SOA 专业人员指南：章节 .........................................................................................................4 2 SOA——参考架构.........................................................................................................................5 2.1 定义............................................................................................................................................5 2.2 SOA 参考架构方法.....................................................................................................................5 2.2.1 SOA 基础 .................................................................................................................................5 2.2.1.1 业务架构 ..............................................................................................................................5 2.2.1.2 基础架构 ..............................................................................................................................6 2.2.1.3 数据架构 ..............................................................................................................................8 2.2.1.4 信息架构 ..............................................................................................................................8 2.2.1.5 SOA 补充架构.......................................................................................................................9 2.2.2 企业 SOA 成熟度模型 ..........................................................................................................11 2.2.2.1 Web 应用程序开发阶段 ......................................................................................................11 2.2.2.2 开发复合应用程序 .............................................................................................................12 2.2.2.3 自动化业务流程 .................................................................................................................14 2.3 SOA 参考架构 ..........................................................................................................................14 2.3.1 Web 应用层 ............................................................................................................................15 2.3.1.1 打包的应用程序 .................................................................................................................15 2.3.1.2 自定义应用程序 .................................................................................................................16 2.3.1.3 门户服务 ............................................................................................................................20 2.3.1.4 企业基础架构服务 .............................................................................................................21 2.3.1.5 企业（基于角色的）门户..................................................................................................22 2.3.2 服务层 ...................................................................................................................................23 2.3.2.1 服务总线 ............................................................................................................................23 2.3.2.2 服务注册表.........................................................................................................................24 2.3.2.3 SOA 储存库.........................................................................................................................25 2.3.2.4 服务管理器.........................................................................................................................26 2.3.2.5 共享数据服务.....................................................................................................................26 2.3.2.6 业务流程管理.....................................................................................................................31 2.3.3 SOA 框架 ...............................................................................................................................32 2.3.4 应用程序层 ...........................................................................................................................33 2.3.4.1 旧应用程序.........................................................................................................................33 2.3.4.2 大型机应用程序 .................................................................................................................33 2.3.4.3 企业应用程序集成 .............................................................................................................33 2.3.5 企业安全 ...............................................................................................................................34 2.3.6 业务服务管理........................................................................................................................34 2.3.6.1 监控的典型当前状态 .........................................................................................................35 2.3.6.2 业务服务管理的未来状态..................................................................................................36 2.3.7 面向服务的基础架构（SOI） ..............................................................................................36 2.3.7.1 面向服务的基础架构（SOI）的业务价值.........................................................................38 2.3.8 将 SOA 参考架构映射到企业 SOA 成熟度模型 ..................................................................39 4 1 关于本文档关于本文档关于本文档关于本文档 1.1 摘要摘要摘要摘要 SOA是一门相对较新的技术，所以很多致力于实现它的公司无法获得良好的实践专业指导。如果没有 基于共同经历的通用语言和行业词汇，SOA技术很可能最终只会为IT基础架构带来更多自定义逻辑并 提高其复杂度，而无法实现其提供企业内和企业间服务重用和流程互操作性的承诺目标。为了帮助 开发共享语言和有关SOA的知识集，一群SOA专业人员创建了《SOA专业人员指南》这个文档系列。在 这个文档系列中，这些SOA专家描述并评注了一些与SOA相关的最佳实践和关键知识，以帮助其他公 司迎接SOA的挑战。他们对《SOA专业人员指南》的期望是，这个分为多个部分的知识集在出版之后， 能够作为所有SOA相关人员的标准参考百科全书。 1.2 目标受目标受目标受目标受众众众众 本文档的目标受众为： � 需要跨企业/LOB启动和管理SOA战略的业务和IT领导 � 需要促进实现SOA计划的理想和路线图以及其中包含的每个实现的架构的企业架构师 � 需要管理SOA整体业务战略中的子项目组合的程序管理员 � 需要映射依赖关系并开发满足业务期望的时间线的项目团队成员 � 为业务和IT提供新业务能力的解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 和工具的供应商 � 需要更好地了解业务和IT计划如何利用技术实现其目标的使用案例的标准机构。 1.3 《《《《SOA专业人员指南专业人员指南专业人员指南专业人员指南》》》》的优点的优点的优点的优点 本文档可帮助读者： � 向他人学习：很早就开始使用SOA的用户可共享其有关跨行业采用SOA的最佳实践、看法以及 观点 � 比较替代产品：标识和定义SOA的关键技术组件，建立对选项比较的基线参考 � 改进合作：使用一种通用语言澄清本文档中定义的SOA组件的性质 � 加速实现：本指南定义了其服务生命周期和需求、建议的工具以及每个阶段的最佳实践。 � 了解标准的价值：本文档建议了用于SOA的各个方面的标准 � 避免潜在风险：本指南指出了供应商社区尚未指出的一些问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 领域。 1.4 SOA专业人员指南专业人员指南专业人员指南专业人员指南：：：：章节章节章节章节 《SOA专业人员指南》包含三个单独的部分。 第1部分（《为何使用面向服务的架构？》）提供了一个高层次的SOA摘要。 5 本文档（《SOA参考架构》）是第二部分。它提供企业级SOA实现的工作 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 ，包括详细的架构图、 组件描述、详细要求、设计模式、有关标准的观点、法规遵从性模式、标准模板以及成员的潜在代 码资产。 第3部分《服务生命周期简介》提供了在整个服务生命周期（从项目初期到完成或重新定位服务）中 提供服务管理的详细过程。该文档还包含一个附录，其中包含组织和治理最佳实践、模板、对关键 SOA标准的评论以及建议的到详细信息的链接。 2 SOA——参考架构参考架构参考架构参考架构 2.1 定义定义定义定义 SOA参考架构为企业或LOB定义了一个理想的目标架构。有些人还将其称为企业的“未来状态”或 “未来理想”。SOA参考架构是构造从当前状态到目标状态的路线图的关键。 2.2 SOA参考架构方法参考架构方法参考架构方法参考架构方法 要想开发参考架构，必须了解SOA的两个方面： � 三个SOA基础组件 � 企业SOA成熟度模型 2.2.1 SOA 基础基础基础基础 SOA基础组件如下图所示。 图1：SOA基础 2.2.1.1 业务架构 业务架构描述SOA要支持的业务战略、目标、优先级和流程。只有在业务架构上提供的SOA才会成 功。与基础架构或数据组件的潜在重用相比，业务流程的重用能够提供较高的ROI。 6 图2：业务架构的关注领域 开发业务架构的最佳实践包括： � 审查当前系统 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 和基础技术 � 将这些映射到业务战略以便找出差异 � 审查水平（业务流程）和垂直（基于角色的视角）要求 � 确定应用程序（服务）组合的优先顺序以便提供这些功能 � 跨应用程序标准化用户体验 � 定义有关关键方面的业务策略，例如应用程序和数据访问和法规遵从性 附加参考：开发业务架构视图（TOGAF） http://www.opengroup.org/architecture/togaf8-doc/arch/p4/views/vus_bus.htm 2.2.1.2 基础架构 这是启用SOA的引擎。它应该能够解决可伸缩基础架构的所有方面，从网络、企业服务器、数据中 心和防火墙到应用程序基础架构、安全性、监控和中间件。 基础架构团队要负责标识提供业务能力所需的基础架构组件（架构构建块）。 图3：架构构建块示例 上图显示了要提供主要关注业务流程的业务能力所需的架构构建块的一个示例。同时，基础架构还 7 需要包含基于角色的门户要求。 图4：基于角色的门户的示例 基础架构需要将架构构建块和基于角色的门户组合起来以便实现以下目标： � 高度重用公共服务 � 重用基础架构和基础组件 � 减少开发新功能所需的时间。 基础架构组件基础架构组件基础架构组件基础架构组件 描述描述描述描述 自定义应用程序框架 数据服务 记录服务 异常处理 审计服务 搜索框架 通知框架 开发自定义应用程序所需的公共组件 安全 身份验证 授权 单点登录（SSO） 委派管理 _ 可扩展到企业级的安全框架 共享数据服务 主要数据管理 数据分析 数据质量服务 数据匹配 支持SOA的数据服务 8 数据验证 数据建模 分析服务 门户服务 常见外观 个性化 报告 本地化 Web流量监控 用于一致用户交互的门户服务与利用WRSP的能力 企业基础架构服务 LDAP 电子邮件 协作（Chat/IM/Whiteboard） 内容管理 集成的结构化和非结构化搜索 需要的企业级公共服务 主要数据管理 客户数据集成 主要产品 跨应用程序和业务孤岛执行业务流程所需的功能 有关基础架构组件的附加详细信息可在“SOA参考架构”一节中找到。 附加参考：基础架构（TOGAF） http://www.opengroup.org/architecture/togaf8-doc/arch/p4/infra/infra_arch.htm 2.2.1.3 数据架构 数据架构处理数据的逻辑和物理建模以及数据操作和数据质量。SOA参考架构在任何可能的情况下 通过提供方法、要求和设计模式详细地介绍所有这些领域。 2.2.1.4 信息架构 信息架构对给定业务流程的关键概念和事件进行建模。该业务概念表示需要由支持企业的流程或应 用程序交换的任何业务实体。 信息建模可创建用XML模式表示的正则模型。正则模型是一种很脆弱的业务概念属性定义，包括属 性关系、价值枚举、价值模式、XML文档相关属性的先后顺序以及该属性的必需性。SOA使用正则 模型表示服务交易的请求和响应文档以及返回到消费者的内容负载。 业务应用程序交换的正则表达式通常是业务概念。例如，搜索产品目录可能会返回“候选产品列表”。 业务流程销售或者发布的正则模型通常是业务事件。例如，“销售订单批准”业务事件可能由“供 应链管理”业务流程发布，并且需要提供商订阅。 信息架构的另一个方面是捕获业务级别信息的关键性能指标（KPI）的定义。KPI可帮助组织来定义 9 和度量到组织目标的进展。KPI是指报告了从业务流程提取的值的信息提取。 附加参考：关于信息架构的Wikipedia定义 http://en.wikipedia.org/wiki/Information_architecture 2.2.1.5 SOA 补充架构 SOA本身是一种架构样式，必须认识到其他架构是与SOA策略成功与否息息相关的。下面几节概述了 SOA策略中可能存在的一些架构。 2.2.1.5.1 模型驱动架构模型驱动架构模型驱动架构模型驱动架构（（（（MDA）））） 对象管理组（OMG）的模型驱动架构（MDA，http://www.omg.org/mda/）是一种使用平台无关 （platform-agnostic）模式的方法，了解和管理运营中的企业的所有方面：包括“什么，怎么样，在 哪里，什么时候，哪些人和为什么这样” （http://www.omg.org/mda/mda_files/09-03-WP_Mapping_MDA_to_Zachman_Framework1.pdf ）。MDA的主要目标包括可移植性、互操作性和重用性，以及使用模型在业务和IT之间架起一座桥 梁 MDA可通过开发计算无关模型（CIM）帮助减少业务和IT之间的差异，该模型会去除特定于计算的 详细信息，因此主题内容专家可更容易地了解该模型。 组织最好开发平台无关（platform-agnostic）的模型，因为这些模型可以帮助组织保留其知识产权， 并在技术平台实现的灾难性急剧下滑中存活下来。具有足够的平台独立性级别的平台无关 （platform-agnostic）的模型（PIM）可对此提供支持，并可帮助决策人员了解规定的过程流。一旦 整体架构得到批准，这些就可以使用标准转换规则转换为平台特定的模型（PSM），并使用标准交 换格式进行交换。 MDA基于良好地建立的OMG标准（也是ISO标准），包括： � 软件行业的主要公司都使用和支持的普遍建模表示法统一建模语言™（UML http://www.uml.org/），它允许业务、架构、结构和行为建模。此外，UML Profiles可作为“专 业化”开发以便用于特定的计算领域，例如EJB、Web服务、本体论（ontologies）、调度、 测试和信息建模。 � 元对象设施（http://www.omg.org/mda/specs.htm#MOF）OMG的关于建模语言和转换模型的 基础规范。MOF定义建模语言（元模型）以及模型的集成、互换与管理。 � XML元数据互换（XMI， http://www.omg.org/technology/documents/modeling_spec_catalog.htm#XMI），这是一种使 用XML跨工具存储和交换模型的标准。 � 公共仓库元模型（CWM，http://www.omg.org/technology/cwm/）是一种描述跨仓库生命周期、 业务智能、知识管理和门户技术的元数据互换的规范。CWMl将转换成为更广泛的信息管理元 模型（IMM），该模型允许使用UML进行数据和XML建模 （http://adtf.omg.org/adptf_info.htm#RFIs,RFPs）。 2.2.1.5.1.1 作为作为作为作为SOA的基础的的基础的的基础的的基础的MDA 由于具有将企业和软件的所有方面进行建模的成熟度和丰富的功能，MDA很适合用作SOA生命周期 的基础。许多其他的OMG标准则可通过与MDA协作对SOA提供一种由业务和架构驱动的方法。相关 概述请参见：http://www.omg.org/attachments/pdf/OMG-and-the-SOA.pdf和http://soa.omg.org/。 此外，MDA允许开发集成的SOA注册表/储存库，后者支持发现服务及其组件，也可映射到业务流程 和目标。 其他人也对用于SOA的MDA的价值进行了 评价 LEC评价法下载LEC评价法下载评价量规免费下载学院评价表文档下载学院评价表文档下载 。下面的链接提供了有关MDA价值的第三方观点： 10 � 模型驱动的SOA：http://www.opengroup.org/events/q405/mdasoa.pdf � The Open Group的SOA工作组主管Chris Harding博士曾在文中指出，“SOA以及OMG的MDA 的组合正是要得到真实的灵活性所需要的；模型驱动架构（MDA）是一个很好的概念，很适合 SOA……。那么它是否可以变得更加简单，更加容易使用，并更广泛地使用以推广SOA技术呢？ 答案是‘是’”。http://www.ebizq.net/topics/soa/features/6639.html?&pp=1 � IBM的SOA和Web服务部门的首席架构师Ali Arsanjani博士在文章中指出，“面向服务的建模方 法提供了建模、分析、设计技术以及定义SOA基础的活动。该方法通过在SOA的每一层定义元 素以及进行各种级别的重要架构决策提供帮助。” http://www-128.ibm.com/developerworks/webservices/library/ws-soa-design1/和 http://www.webservices.org/categories/enterprise/strategy_architecture/how_to_identify_spe cify_and_realize_services_for_your_soa/(go)/Articles OMG现在处理软件服务配置文件标准RFP，该标准可增强用于建模服务的UML，例如服务规范和合 同。有关更多详细信息，请打开下面的链接： http://soa.omg.org/SOA%20ABSIG%20RFPs,%20RFIs.htm 2.2.1.5.2 SOA的补充事件驱动架构的补充事件驱动架构的补充事件驱动架构的补充事件驱动架构（（（（EDA））））和复杂事件处理和复杂事件处理和复杂事件处理和复杂事件处理（（（（CEP）））） 典型的SOA环境中的连接服务的出现顺序是线性可预测的，而EDA允许多个可预测性较低的异步事 件并行出现并触发单个操作。在EDA中，业务内外会出现一个著名的“事件”。“事件系统”会感 知并收集这些事件，并通过服务选择性地将分散的模式与所有感兴趣的方面（手动或自动）关联起 来。感兴趣的涉众会评估这些事件，还可以通过调用服务，触发业务流程或者发布或组织附加信息 进行响应。EDA可根据过去趋势和未来预测使事件的多元联系相关联。EDA通常被认为是SOA的子 集，但把它看作SOA的补充可能更加正确。 有关EDA及其与SOA的关系的附加信息，请参见下面的链接所指向的文章： � 广泛采用的事件驱动架构 http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,81133,00.html � 入门书：事件驱动架构 http://www.baselinemag.com/article2/0,1540,1606126,00.asp � 事件驱动架构与发布-订阅系统 http://www.developer.com/design/article.php/3499031 � SOA中的事件驱动服务 http://www.javaworld.com/javaworld/jw-01-2005/jw-0131-soa.html � 使用企业服务总线把面向服务的架构与事件驱动架构组合起来 http://www-128.ibm.com/developerworks/webservices/library/ws-soa-eda-esb/index.html � 事件驱动SOA仅仅是整个EDA世界的一部分 http://www.psgroup.com/research_michelson.aspx 2.2.1.5.2.1 复杂事件处理复杂事件处理复杂事件处理复杂事件处理（（（（CEP））））和和和和SOA 复杂事件处理（CEP）是一种新兴的技术，可帮助公司开发和管理业务活动监控（BAM）、企业应 用程序集成、网络和系统安全以及业务流程。 斯坦福大学教授及CEP权威David Luckham认为，CEP的目标是提供有关IT系统中发生情况的可理 解信息。反过来，这些信息又可用于各种目的，例如检测异常活动，提高安全性以及识别CRM和供 应链系统中的优势方案。 “IT系统中的事件包含未使用的信息，CEP使您能够通过希望的方式提取并使用这些信息”， Luckham说到。他认为2005年CEP开始并入Web服务、中间件和应用程序服务器。他还估计，到2008 年，CEP标准、语言和复杂事件模式的搜索引擎将出现，到2012年CEP将被广泛采用。 有关CEP的附加信息，请参见：http://www.complexevents.com/和 http://complexevents.com/?page_id=59 11 2.2.1.5.2.2 MDA、、、、EDA-SOA和和和和CEP解决的问题解决的问题解决的问题解决的问题 通过利用MDA、EDA、SOA和CEP，组织可以开发模型驱动的、灵活的“感知和响应”系统，该系 统可（近乎实时地）检测业务价值事件并触发服务来管理这些事件。了解哪个应用程序对每个架构 进行了优化以及这些应用程序之间接口的方式将有助于改进架构。此外，这样的架构方法使得业务 流程及其支持功能的端对端管理变为可能。 EDA的标准及其与SOA和CEP的关系仍在发展中。由MDA作为基础，OMG SOA SIG已经启动了一个 子组来关注SOA的这一方面。（http://soa.omg.org/SOA%20ABSIG%20RFPs,%20RFIs.htm）。 2.2.2 企业企业企业企业 SOA 成熟度模型成熟度模型成熟度模型成熟度模型 SOA成熟度模型可帮助企业开发路线图来达到企业的目标状态。 图5：企业SOA成熟度模型 上图显示了企业SOA成熟度模型的各个阶段。 2.2.2.1 Web 应用程序开发阶段 在这个阶段，团队关注为内外部用户提供丰富的基于客户和浏览器的业务解决方案。它们可能会选 择推广基于Web的CRM、ERP或者支持连接的但偶尔会断开连接的操作的自定义应用程序。此外， IT组织通常会部署基于企业的解决方案和服务，例如内容管理、搜索、即时消息传递、博客、Wiki、 讨论论坛和白板。 2.2.2.1.1 业务要求业务要求业务要求业务要求 通常情况下，大多数企业都已经部署了外部网站以及许多内部网站和应用程序来支持每个业务单位 的各种需要。第一个步骤是通过提供公共外观的基础架构标准化、共享和集成这些分散的解决方案。 这样客户、合作伙伴和员工就可以更方便地找到所需要的信息。 在这个阶段，团队应该关注： � 统一外部站点的用户体验，使得潜在用户、合作伙伴、客户和分析师能够容易地找到他们所需 的信息 12 � 使所有站点（内部和外部）的外观以及发布内容的所有流程和过程标准化 � 创建一个my（例如http://my.company.com）站点，供所有员工、承包商、 合作伙伴、客户个性化服务和内容 � 提供对所有内部和外部站点的机密信息的安全访问 � 提供具有高可靠性、可用性和可伸缩性的环境 � 允许使用AJAX进行站点操作来改进性能和用户体验。 2.2.2.1.2 关键挑战关键挑战关键挑战关键挑战 这个阶段的关键挑战包括如下内容的开发： � 应用程序支持升级路径 � 对无数并行活动的支持 � 团队的领导地位和技术质量 � 用于生产期间的开发的物理环境，以及版本管理流程和有经验的人力资源 � 专用的生产支持流程和人员配备 � 承载。 2.2.2.1.3 退出条件退出条件退出条件退出条件 出现下面的情况时团队可认为此阶段已经完成： � 外部网站成立并且正在运行 � 为一个或多个打包的应用程序开发了门户前端 � 可通过门户站点访问一个或多个自定义应用程序 � 部署了大多数企业服务 � 业务用户可从多个应用程序请求信息 � 完成了建立程序管理办公室（PMO）以及用于部署应用程序门户的LOB治理模型的工作 � 业务部门对交付时间线很有信心，并且能够一致地构建可用于所有主要计划的程序办公室。 2.2.2.1.4 成功因素成功因素成功因素成功因素 如果具有如下条件，则此阶段是成功的： � LOB级别的业务参与度很高 � 为所有复合应用程序建立了赞助/执行监管 � 可快速开发和交付基于Web的应用程序 � 项目管理已经到位，团队能够进行领导并了解重要程度和方向 � 开发、部署和状态报告的流程已经在LOB之间进行了标准化 � 团队已经开发了标识的和创建了有经验的资源。 2.2.2.2 开发复合应用程序 复合应用程序聚集和提供来自各种源和通道的信息和数据，并在合适的时候使其对内部和外部用户 13 可用。Enterprise 2.0服务可提供合适的SLA级别。 2.2.2.2.1 业务要求业务要求业务要求业务要求 业务要求是指IT适应不断变化的业务要求。个别业务单位会帮助IT开发自定义应用程序，增强他们 自己的品牌，提高生产力，或者为客户、合作伙伴或员工提供附加信息。 业务要求可能包括： � 通过门户推出和公开多个应用程序 � 来自多个应用程序的信息的可用性 � 为用户提供基于Web的桌面 � 基于用户角色和责任的个性化服务 � 可降低用户培训要求的单个标准化外观 � 降低在一个平台上进行标准化的维护成本 � 降低操作和支持成本，允许IT将稀缺的资源部署在新功能上。 2.2.2.2.2 关键挑战关键挑战关键挑战关键挑战 这个阶段的关键挑战包括如下内容的开发： � 共享服务的应用程序支持升级路径 � 跨多个LOB多个并行活动的支持 � 共享服务的治理 � 团队的领导能力和技术质量 � 用于生产期间的开发的物理环境，以及版本管理流程和有经验的人力资源 � 专用的生产支持流程和人员配备 � 承载。 2.2.2.2.3 退出条件退出条件退出条件退出条件 如果满足以下条件，则此阶段已经完成： � 已经创建了跨多个LOB的程序管理办公室（PMO），并且建立了用于部署共享服务的企业级 治理模型 � 业务部门对交付时间线很有信心，并且使用能够完成所有主要计划的程序办公室 � 部署了多个利用SOA基础的应用程序门户 � 业务单位讨论应用程序或数据的集成时间框架。 2.2.2.2.4 成功因素成功因素成功因素成功因素 如果达到以下条件，则此阶段可认为是成功的： � 所有复合应用程序的业务参与和赞助（包括执行监管）都已经到位 � 团队开发了快速开发和交付的方法 � 项目管理逐渐有了领导力、对紧急事务的判断力以及项目方向 � 开发、部署和状态报告的流程已经在企业之间进行了标准化以便提供共享服务 14 � 公司已经通过灵活的方法（并行开发）开发了有经验的资源。 2.2.2.3 自动化业务流程 这个阶段是指应用程序、数据和基础架构通过在合适的时间提供合适的信息来帮助用户有效地执行 其角色。在这个阶段，企业开始通过将多个业务系统合并到单个系统获得较高的ROI。业务组织现 在应该准备好丢弃他们的单点解决方案并转移到端对端业务流程管理的目标状态。 2.2.2.3.1 业务要求业务要求业务要求业务要求 此阶段的基本要求如下： � 业务的兴趣在于企业之间业务流程的标准化 � 通过基于标准的技术整合基础架构，同时降低成本 � 标准化业务流程可全局使用，但允许进行一定的本地化 2.2.2.3.2 关键挑战关键挑战关键挑战关键挑战 此阶段的关键挑战包括： � 完成业务和IT转换 � 建立合适的治理和组织模型 � 实现打包的应用程序以便获得一定的短期收益。 2.2.2.3.3 成功因素成功因素成功因素成功因素 如果满足如下条件，则此阶段是成功的： � 业务参与和赞助以及执行监管使得业务和IT转换成为可能 � 有一个专门的团队关注业务流程 � 业务流程是企业的主要关注对象 � 将松耦合的业务服务装配到自动业务流程，并且这些业务服务可以重新组合以提供新的业务功 能。 2.3 SOA参考架构参考架构参考架构参考架构 下图显示了SOA参考架构，其中包括Web应用层、服务层、应用层和基础架构层。 图6：SOA参考架构 15 并非所有IT组织都需要部署此SOA参考架构中标识的整个基础架构。一个SOA最佳试验是仅当需要 提供业务解决方案时才投资于基础架构。 2.3.1 Web 应用层应用层应用层应用层 此层的主要要求是所有业务系统和解决方案都可从任何支持的浏览器中访问。这一层是用户界面或 者表示层，包含企业基础架构服务和应用程序等组件的业务逻辑。 2.3.1.1 打包的应用程序 通常情况下，企业会批准满足其大多数业务要求的最佳的打包应用程序，然后让IT组织和系统集成 人员对打包的应用程序进行处理以便满足其需要。此类打包的应用程序的示例包括客户关系管理、 企业资源计划或特定行业的成套应用系统。 现在大多数打包的应用程序都是基于Internet协议的，这意味着用户可以使用任何支持的浏览器访问 许多功能。有些最新应用程序可以将有限的功能组作为离散的协作服务或外部控制的业务流程公开。 利用打包的应用程序的最佳实践包括： � 限制自定义开发的数量，使得维护和升级简单廉价 � 尝试获得世界级的标准实现，从而减少集成和维护成本 � 在可能的情况下使用打包的应用程序提供的UI和业务流程 � 利用发布的应用程序编程接口（API）而不是直接访问数据库。 下面是在SOA成熟度模型中采用打包的应用程序的规定方法： 2.3.1.1.1 开发开发开发开发Web应用程序应用程序应用程序应用程序 � 部署可由任何浏览器访问的应用程序的最新版本；最好是支持适当的门户标准（如WSRP）的 版本。 � 公开供自定义应用程序使用的应用程序服务，最好是作为Web服务。这可能要求适配器允许访 问应用程序。应用程序的一些最近版本能够通过集成网关或Web服务直接访问应用程序服务。 � 通过合并企业外观（模板、皮肤、骨架和CSS）以及集成企业单点登录解决方案以提供完美的 用户体验。 � 通过集成到企业标识和存取管理程序（通常是LDAP）将身份验证具体化。 2.3.1.1.2 开发复合应用程序开发复合应用程序开发复合应用程序开发复合应用程序 � 标识可以作为复合应用程序在企业之间共享的业务对象 � 将事件通知（触发器）发送到复合应用程序以启动特定操作 � 修改业务流程和用户界面以启用复合应用程序 � 公开附加业务服务以便复合应用程序能够与打包的应用程序同步。 2.3.1.1.3 自动化业务流程自动化业务流程自动化业务流程自动化业务流程 � 了解并建模业务流程以便标识重构机会 � 标识业务流程中可由业务流程引擎自动化的可重用部分 16 � 扩展公开的服务和业务流程的数目 � 减少和合并部署的应用程序的数目。 2.3.1.2 自定义应用程序 组织可以选择开发自定义应用程序以创建独一无二的品牌并为客户和合作伙伴提供独特的体验。这 要求为内部和外部用户提供一致的完美接口。公司通常倾向于开发自定义应用程序，而不是对打包 的应用程序进行自定义，因为： � 修改核心事务的用户导航和用户界面并非易事 � 大多数主要的打包应用程序并非基于公开的或标准技术，无法对其性能进行调整以适应业务需 要 � 专有开发模型使查找资源或快速部署新业务功能变得困难 � 与其他技术的集成不太容易实现，导致点对点的集成或者数据质量低下。 自定义应用程序的开发具有如下三个选项： 1、在应用程序服务器上开发和部署自定义应用程序 2、利用门户开发和部署自定义应用程序 3、使用基于开放标准的工具或者专用开发工具开发强大的客户端。 对于选项1和2，IT组织的第一个步骤是确定开发自定义应用程序的方法、基础架构和工具。此外， IT组织需要定义治理和组织模型以便开发自定义解决方案。 对于选项3，强大的客户端自定义应用程序通常是使用SWING、Visual Studio或类似工具开发的。 这些强大客户端中的大多数都需要与一些外部系统相连接，建议的方法是利用开发标准（如SOAP、 Web服务、XMPP或WebDAV），而不是直接访问外部资源。此方法使得IT组织可以方便地支持和 升级集成。 2.3.1.2.1 自定义应用程序业务自定义应用程序业务自定义应用程序业务自定义应用程序业务需求需求需求需求 大多数企业都已经部署了外部站点以及多个内部站点和应用程序，以支持各个业务单位的不同需要。 第一个步骤是在企业之间标准化这些站点的外观和基础架构，使得客户、合作伙伴或员工可以比较 方便地获得他们要查找的信息。 此阶段的业务要求包括： � 统一外部站点上的用户体验，使得潜在用户、合作伙伴、客户和分析人员能够方便地找到他们 想要查找的信息 � 跨所有内部和外部站点标准化外观，并标准化发布内容的过程和流程 � 为所有员工、承包商、合作伙伴和客户创建一个my站点以便提供个性化的服 务和内容 � 提供的所有内部和外部站点的保密信息的安全访问 � 提供具有高可靠性、可用性和可伸缩性的环境 � 通过公共门户帮助铭记（branding）和访问多个应用程序 � 允许用户在登录一次后访问所有服务 � 基于用户的角色和责任提供个性化服务 17 � 通过平台或环境的标准化降低维护多个系统和应用程序的维护成本 � 标准化外观以消除多种用户培训要求 � 降低操作和支持成本，允许IT将稀缺的资源部署在开发新功能上。 2.3.1.2.2 自定义应用程序架构方法自定义应用程序架构方法自定义应用程序架构方法自定义应用程序架构方法 由于门户提供了一组经验证的功能来支持表示层，大多数IT组织已经开始标准化门户以便开发自定 义应用程序。 图7：建议的自定义应用程序架构 这个建议的架构具有以下优点： � 遵循SOA原则以提高各个级别的重用性 � 提供在数周内而不是数月内提供产品或服务的能力（当具有了稳定的框架时） � 将产品用在它最擅长的领域，例如，使用门户进行基于权限的演示 � 允许业务将服务组合起来以便提供新功能 � 在域层提取数据源和相互关系，从而将更改源系统的影响降到最小 � 使用松耦合的表示和业务逻辑使其更可靠，更可伸缩。 拟用结构中的每一个层都扮演着特定的角色： 表示层表示层表示层表示层：：：：“门户”负责处理所有表示服务。Portlet可促进用户体验的提升，其中portlet充当应用程序 的一个视图。 业务委派层业务委派层业务委派层业务委派层：：：：业务委派层是负责表示层和业务层之间的通信的组件。它们可提取访问业务层时所包 含的通信细则和复杂性。此层包括一个模型视图控制器框架，可帮助用户浏览网站。 服务层服务层服务层服务层：：：：服务层包含应用程序服务器的功能。该层由公开高级业务功能性的无状态功能组成。它具 有一个