SOA 专业人员指南


1 SOA 专业人员指南专业人员指南专业人员指南专业人员指南 第第第第1部分部分部分部分 为何使用面向服务的架构为何使用面向服务的架构为何使用面向服务的架构为何使用面向服务的架构???? 作者: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,首席电子商务架构师 审校审校审校审校人员人员人员人员 Prasanna Deshmukh ,WebEx Communications ,架构主管 Noam Fraenkel ,Mercury Interactive ,首席IT 技术官 Steve Jones ,Capgemini Group 的Application Development Transformation 部门,首席技术官 Brenda Michelson ,Elemental Links, Inc. ,首席顾问及分析师 Ashok Nair ,关于EAI 和信息技术服务的管理系统分析师,卡尔加里城 George Paolini ,Georgepaolini.com ,顾问 Jeff Pendelton ,SOA Alliance ,执行主管 Annie Shum ,BEA,SOA 战略副总裁 作者十分感谢为本文档做出贡献的组织和个人,他们撰写了部分文档,进行了大量编辑工作,还帮 助审校了文档并提供反馈。此外,作者还要特别感谢BEA Systems, Inc. ,是这个公司提供了本文档 中的开发和演示所需的基础架构和平台。 3 目目目目 录录录录 . 1 关于本文档...................................................................................................................................4 1.1 摘要............................................................................................................................................4 1.2 目标受众....................................................................................................................................4 1.3 《SOA 专业人员指南》的优点.................................................................................................4 1.4 SOA 专业人员指南:章节 .........................................................................................................5 2 执行摘要.......................................................................................................................................5 2.1 行业背景....................................................................................................................................5 2.2 业务系统的当前状态.................................................................................................................5 2.2.1 影响 IT 的业务问题 ................................................................................................................6 2.2.1.1 全球化..................................................................................................................................7 2.2.1.2 经济压力 ..............................................................................................................................7 2.2.1.3 业务流程外包.......................................................................................................................7 2.2.1.4 法规遵从性...........................................................................................................................7 2.2.1.5 技术......................................................................................................................................7 2.2.1.6 缺乏聚合性业务信息战略...................................................................................................7 2.2.1.7 标准......................................................................................................................................8 2.2.2 必要的转化 .............................................................................................................................8 2.2.3 建议的方法 .............................................................................................................................9 2.3 SOA 生命周期方法...................................................................................................................10 2.3.1 SOA 定义 ...............................................................................................................................10 2.3.2 SOA 生命周期阶段................................................................................................................11 2.3.2.1 启动 SOA...........................................................................................................................11 2.3.2.2 开发路线图.........................................................................................................................14 2.3.2.3 SOA 执行计划.....................................................................................................................14 2.4 如何避免从 SOA 进入 DOA....................................................................................................15 4 1 关于本文档关于本文档关于本文档关于本文档 1.1 摘要摘要摘要摘要 SOA是一门相对较新的技术,所以很多致力于实现它的公司无法获得良好的实践专业指导。如果没有 基于共同经历的通用语言和行业词汇,SOA技术很可能最终只会为IT基础架构带来更多自定义逻辑并 提高其复杂度,而无法实现其提供企业内和企业间服务重用和流程互操作性的承诺目标。为了帮助 开发共享语言和有关SOA的知识集,一群SOA专业人员创建了《SOA专业人员指南》这个文档系列。在 这个文档系列中,这些SOA专家描述并评注了一些与SOA相关的最佳实践和关键知识,以帮助其他公 司迎接SOA的挑战。他们对《SOA 专业人员指南》的期望是,这个分为多个部分的知识集在出版之后, 能够作为所有SOA相关人员的标准参考百科全书。 1.2 目标受众目标受众目标受众目标受众 本文档的目标受众为:  需要跨企业/LOB 启动和管理SOA 战略的业务和IT 领导  需要促进实现SOA 计划的理想和路线图以及其中包含的每个实现的架构的企业架构师  需要管理SOA 整体业务战略中的子项目组合的程序管理员  需要映射依赖关系并开发满足业务期望的时间线的项目团队成员  为业务和IT 提供新业务能力的解决方案和工具的供应商  需要更好地了解业务和IT 计划如何利用技术实现其目标的使用案例的标准机构。 1.3 《《《《SOA 专业人员指南专业人员指南专业人员指南专业人员指南》》》》的优点的优点的优点的优点 本文档可帮助读者:  向他人学习:很早就开始使用SOA 的用户可共享其有关跨行业采用SOA 的最佳实践、看法以及 观点  比较替代产品:识别和定义SOA 的关键技术组件,建立对选项比较的基线参考点  改进合作:使用一种通用语言澄清本文档中定义的SOA 组件的性质  加速实现:本指南定义了其服务生命周期和需求、建议的工具以及每个阶段的最佳实践。  了解标准的价值:本文档建议了用于SOA 的各个方面的标准  避免潜在风险:本指南指出了供应商社区尚未指出的一些问题领域。 5 1.4 SOA 专业人员指南专业人员指南专业人员指南专业人员指南::::章节章节章节章节 《SOA 专业人员指南》包含三个单独的部分。 本文档(《为何使用面向服务的架构?》)是第1部分,它为SOA 提供了一个高级摘要。 第2部分《SOA 参考架构》提供企业级SOA 实现的工作设计,包括详细的架构图、组件描述、详细 要求、设计模式、有关标准的观点、法规遵从性模式、标准模板以及成员的潜在代码资产。 第3部分《服务生命周期简介》提供了在整个服务生命周期(从项目初期到完成或重新定位服务)中 提供服务管理的详细过程。该文档还包含一个附录,其中包含组织和治理最佳实践、模板、对关键 SOA 标准的评论以及建议的到详细信息的链接。 2 执行摘要执行摘要执行摘要执行摘要 2.1 行业背景行业背景行业背景行业背景 经过多年的发展,面向服务的架构(SOA)已经可以通过定义一种使用和重用软件组件和业务流程 的方法为IT 提供空前的灵活性和成本节约。不过,SOA 仍然是一种新的技术,组织仍然需要学习如 何实现这种技术从而实现企业间和企业内的服务重用和流程的互操作性。同时,潜在的SOA 专业 人员遇到一些典型挑战,就是其软件方法目前还不受完全成熟的行业的支持。例如:  几个大的供应商全部声称采用了SOA 并发布了自己的观点和SOA 参考架构。SOA 启动技术为较 大供应商所掌握,导致系统更加不稳定  IT 通常无法与业务部门有效地沟通,他们无法了解如何投资于SOA 技术使得业务功能自动化 以及提供更便宜、更好更快的解决方案  每个主要标准机构都组成多个团队尝试对SOA 进行定义,使得情况更加混乱,也延缓了SOA 的 采用。  开发和管理工具不足  行业之间通用词汇的缺乏使得最佳实践的共享变得困难。 2.2 业务系统的当前状态业务系统的当前状态业务系统的当前状态业务系统的当前状态 传统情况下,IT 与业务所有者一起工作,后者受到应用程序供应商的影响。这就使得IT 战略更加关 注应用程序或集成。此外,管理方式和资金模型促使业务和IT 涉众尽一切可能满足特定业务单位或 部门的需要。这就导致产生许多可以或者不可以集成到现有架构中的“一次性”应用程序。兼并和 收购导致在本已支离破碎的架构中加入新的软件平台和方法,而IT 很少有足够的资源来完成业务系 统集成。其结果是,IT 最终通常在企业或业务单位内部署多个执行相同任务的系统。身份验证、单 6 点登录和数据集市的冗余基础架构解决方案以及(打包或自定义的)应用程序(例如销售自动化 (SFA)、引用和订单管理)加剧了IT 的复杂性,也使其成本剧增。因此,通过修改此组合对业务 流程更改进行响应或者调节获取成本变得几乎不可能,自然也无法实现。 在许多组织中,IT 小组使用点对点或EAI 方法将这些独立的系统集成起来,这些方法可以将应用程序 连接到上行和下行系统。为了跨业务流程跟踪事务,IT 跨应用程序传播一些关键值(有时候是不一 致的),并为每个业务单位创建不同的操作数据存储以便跟踪关键的性能指标。这样,为了提供完 美的用户体验,IT 经常构建门户应用程序以便连接到多个后端应用程序、数据集市和主要数据。 图1:目前最佳的企业架构案例 从架构的观点来看,这种架构非常有效,但维护或扩展起来十分复杂和昂贵。这些解决方案难以修 改,因此需要更改业务时IT 很难快速响应。这就带来冲突的感觉。 2.2.1 影响影响影响影响 IT 的业务问题的业务问题的业务问题的业务问题 企业的IT小组对于企业迎接挑战的能力至关重要,挑战包括竞争性定价、离岸供应商以及目前不断 变化的全球市场中出现的其他问题。 7 2.2.1.1 全球化 企业要想在全球化环境中存活下来必须具有良好的灵活性。如果竞争对手能够制造更廉价的相同产 品,企业就需要更具创造性并且更快速地进行响应,IT 很少有机会影响期望和替代产品。 2.2.1.2 经济压力 虽然各个公司的记录中都存在现金余额,但是市场仍然不见增长。于是各公司尝试通过兼并和收购 获得增长。合并和精简各地分散员工、流程和系统的要求给业务和IT小组施加了额外的压力。 由于增长减缓,企业更加关注成本削减。为了减少预算,IT 将非核心功能外包,并采取离岸式开发 模型。这种方式不算理想,但这使得IT 能够在有限的预算中释放出一部分资金,用于开发新的业务 功能。 2.2.1.3 业务流程外包 这种倾向在接下来的几年还将呈指数级别增长。外包方式使得企业能够关注其核心业务,而将非差 异性服务(如人力资源、呼叫中心和数据中心管理)外包出去。不过,这样IT 又必须应对将第三方 业务流程和数据集成到核心业务中的挑战。 2.2.1.4 法规遵从性 企业必须遵从政府法规才能长盛不衰。最近公布的一些法规(特别是Sarbanes-Oxley )要求IT 组织 检查(有时候还要改进)所有业务系统。这又要从新业务功能开发中挪用本已不算充裕的IT 资源和 资金。未来法规更改时也会要求系统进行相应的更改。 2.2.1.5 技术 通过使用新技术能够创建新的业务能力。通过抓住新的机遇也可以带来新的挑战,对于IT 来说更是 如此,因为这通常必须向企业指出如何销售和提供新产品或服务以及如何收费。 由于资源的缺乏,IT 必须在维护和升级现有IT 系统与投资于新系统以便创造新的业务机遇之间进行 艰难的抉择。 2.2.1.6 缺乏聚合性业务信息战略 在大多数情况下,LOB 决策人员并不清楚共享基础架构和业务逻辑的优点。他们更关注其直接需要 以及IT 响应,通常开发多个功能几乎相同但算法冲突的系统,使集成和合并变得非常复杂。许多公 司通过多个不兼容的解决方案实现身份验证、单点登录和数据集市,并通过多个(打包的和自定义 的)应用程序实现销售自动化(SFA)、报价和订单管理 公司结构通常也能促进共享和跨团队协作。这可导致对IT 的项目关注,而不是一致的业务信息战略 和基于业务的IT 基础架构。 8 2.2.1.7 标准 最近的统计表明目前存在超过56 个涉及SOA 的各个方面的标准机构。他们的工作未能协调一致,因 此标准众多实际上等于没有标准。要遵循哪个“标准”完全由各个IT 小组自行决定。 2.2.2 必必必必要的转化要的转化要的转化要的转化 企业希望IT 组织能够更加灵活,但又不愿意支付更多的费用。而IT 组织需要使用资源来使旧的应用 程序能够更好地运行,开发更灵活更有效率的基础架构以及增加需要的业务功能。传统的治理、组 织和项目管理模型无法解决这种冲突。迎接这种不断加剧的业务挑战的唯一办法就是合并业务和IT 转化。 大多数业务和IT 执行人员都赞同下面的基础业务原则:业务流程能够使企业在竞争中脱颖而出。对 有些人来说,这指的是处理供应链的方式,而对其他的一些人来说,这可能是指他们将新的创新性 产品推向市场的能力。关注业务流程对企业更理智地对待更灵活的面向目标的模型来说非常重要。 不过,业务和IT 运营团队采用的方法经常存在差异。例如,有些业务运营团队倾向于通过演示“速 效方案”验证方法,而IT 操作团队倾向于构建基础架构。幸运的是,SOA 提供了上述两种方法。 图2:业务价值与复杂性 图3:存在冲突的业务与IT 优先事项 9 2.2.3 建议的方法建议的方法建议的方法建议的方法 有经验的SOA 专业人员建议使用下面的方法开发路线图以便解决业务和IT 目标之间的冲突:  了解业务服务:这是成功采用SOA 的关键的第一步  开发识别关键性能指标的信息战略,这些指标包括“产品缺陷减少x% ”或“在24 小时内响应所 有按揭申请”  开发一个能够清晰地描述业务优点的SOA 蓝图,在其中包括业务原则、参考架构、路线图,以 及治理和组织方针  识别“速效方案”,说明IT 通过采用SOA 可改进目前需要15-18 个月的提供新功能的时间。 一旦专业人员采用了这些步骤,IT 组织就需要识别提供业务解决方案所需的基础架构服务。设计和 构建基础架构服务以支持粗粒度、松耦合的和基于标准的服务使得IT能够将自身转化为业务需 求。然后IT 就可以预测性或响应性地提供全局解决方案,同时降低应用程序和基础架构复杂性,提 高业务服务的重用性以及服务编排能力。 蓝色蓝色蓝色蓝色::::业务解决方案业务解决方案业务解决方案业务解决方案 红色红色红色红色::::服务基础架构服务基础架构服务基础架构服务基础架构 灰色灰色灰色灰色::::业务流程业务流程业务流程业务流程 上图显示了要提供这些解决方案需要的业务解决方案和服务基础架构。SOA 专业人员建议根据需要 开发这些服务基础架构。IT 需要映射服务基础架构并开发SOA 路线图,因为这种映射使得IT 可以显 示重用的优点,并演示开发新的或者修改现有业务解决方案的灵活性。下面的示例说明了一个团队 应该如何将业务解决方案映射到服务基础架构以便应对目前的典型业务挑战。 业务解决方案业务解决方案业务解决方案业务解决方案 服务基础架构服务基础架构服务基础架构服务基础架构 员工自助服务员工自助服务员工自助服务员工自助服务 门户门户门户门户 10 提供一个单一的门户供员工执行 所有个人管理任务,例如地址更 改、优点登记、时间和费用报告 以及员工安置  身份验证、授权和单点登录  一致外观的皮肤/骨骼 EAI  与后端应用程序的集成  跨多个系统运行的业务流程 单个客户视图单个客户视图单个客户视图单个客户视图((((SVC)))) 根据客户的角色和信息需要跨所 有业务孤岛提供SVC 门户门户门户门户  身份验证、授权和单点登录  一致外观的皮肤/骨骼  与业务智能(BI)仪表板的集成 共享数据服务共享数据服务共享数据服务共享数据服务  来自多个源的数据的聚合  从源系统提取数据以及填充操作数据存储(ODS)或数据仓库  在数据存储之间进行简单的数据移动  公开共享数据服务以便访问客户信息 企业服务总线企业服务总线企业服务总线企业服务总线  从事务系统捕获事件,以便填充客户注册表、ODS、同步数据,等等。  为超过150 个共享服务提供服务基础架构 服务注册服务注册服务注册服务注册  发现所有共享业务和数据服务 法规遵从性法规遵从性法规遵从性法规遵从性 要求业务流程编排 业务流程管理业务流程管理业务流程管理业务流程管理  执行业务流程以识别异常情况(基于外部事件)  批准/拒绝所有或者大部分跨企业的自动流程 2.3 SOA 生命周期方法生命周期方法生命周期方法生命周期方法 SOA 的生命周期类似于企业架构的生命周期,都强调业务流程。不过,与企业架构方法不同的是, SOA 需要业务和IT 转化,使用提供了较大灵活性的方法替换传统的治理和组织模型。业务和IT 涉众 需要透过响应与合作伙伴的直接领域定义战略和路线图才能完成他们的目标。 2.3.1 SOA 定义定义定义定义 SOA 是一种用于利用信息实现组织目标的业务操作战略,可实现的目标包括提高总收入,提高客户 满意度,改进产品质量和增强操作灵活性。 在实际工作中,SOA 意味着为不同的人员提供不同的产品或服务。对于IT 架构师而言,这意味着允 许IT 快速开发和部署业务功能的整体企业架构定义和流程。查找信息时架构师通常会访问供应商网 站了解产品详细信息、案例研究以及最佳实践,然后与其他出版物和标准网站进行比较,例如Server Side 、W3C 、java.net 和OASIS。 对于LOB-IT 联络人,SOA 则意味着项目/程序管理的治理、组织和流程,以及可能可以重用以节约成 本的各种业务构建块。LOB-IT 和CIO 通常会参加CIO 论坛或订阅提供来自供应商或分析人员的信息 的杂志。 11 对于合法团队,SOA 是一个潜在的责任:他们想要知道服务是否将信息提供给合作伙伴、客户以及 公司防火墙外的其他人,并且想要知道会导致哪些法规问题以及会暴露哪些信息。 最后,对于CIO,SOA 是用于提供业务能力的IT 战略。哪些业务功能将要自动化:期待提供哪些服 务、成熟程度、成本和SLA? 2.3.2 SOA 生命周期阶段生命周期阶段生命周期阶段生命周期阶段 SOA 生命周期包含在企业或LOB 内实现SOA的阶段,它与服务生命周期存在一定差异,后者是管理 单个服务的过程。SOA 生命周期包含三个阶段:启动、开发路线图和执行计划。 图4:SOA 生命周期 2.3.2.1 启动 SOA 首先,IT 和业务必须确定SOA 将要启动、增强甚至替换哪些业务功能和基础流程。其形式通常是IT 为业务涉众“修补”项目,并指出建议的基于SOA 的战略将解决的业务和/或技术事件,以及这种新 的方法所带来的优势。 在这个阶段,公司要建立一个项目团队并确定目标、时间线和可交付性。其目标是创建一个业务和 IT工作保持一致的路线图,这将由IT 董事会批准。 下面是这个提议的一些示例: 2.3.2.1.1 项目里程碑 下面是启动SOA 的高级项目的一个示例。提议的项目预计历时11 周,每个组织都要根据其需要修改 12 时间线。相关工作和任务可能是相同的。 图5:“启动SOA”的高级项目计划 启动SOA 的最佳实践包括:  创建一个可操作路线图,业务和IT 领导都将致力于此目标  让企业架构团队领导这项工作  使项目团队协同工作,包括业务和IT 领导、LOB-IT、运营部门以及合作伙伴(系统集成商和ISV) 的所有关键工作人员  清晰记录业务目标、计划和财务信息  确保系统集成商在识别业务优势和开发ROI 方面持有平衡的和无偏见的观点  利用ISV 的资源,包括产品路线图和最佳实践  设置合理的项目时间框架,通常介于8到24 周之间。 2.3.2.1.2 项目团队 CIO 频繁地发起SOA 计划,并以IT 董事会为筹划指导委员会。业务团队中应该包含以下业务人员:  业务团队成员业务团队成员业务团队成员业务团队成员  IT/ 业务战略VP  业务运营VP  每个业务运营团队的代表。 13 其责任包括识别、定义业务流程和优势并确定各自的优先级。 业务团队中还应该包含以下IT人员:  IT 团队成员团队成员团队成员团队成员  IT 应用程序开发VP  VP PMO  技术/架构VP  CIO/LOB-IT 分部主管。 他们的责任是将业务战略转化为IT 战略,开发与业务优先级对应的IT 执行计划,开发参考架构,识 别架构组件以及估计成本。 2.3.2.1.3 项目目标  定义IT 与业务的对应关系  开发可实现理想的执行计划  创建治理和组织模型以便执行该理想  估计进行投资预期可获得的业务优势(ROI) 2.3.2.1.4 项目可交付性  涉及到业务、应用程序、技术和数据时的SOA原则声明(有关详细信息,请访问 http://www.opengroup.org/togaf/ )  当前状态报表,包括业务应用程序、业务和IT 中的所有者、功能、支持联系人、技术提供人员、 数据流以及当前人员的技能  建议的目标状态,包括参考架构、差异分析、路线图以及需要的技术  执行计划,包括应用程序组合、基于业务优先级的实现顺序,以及用于提供业务功能的基础架 构需要的映射 14 2.3.2.2 开发路线图 团队需要创建一个路线图,它应该详细说明了为公司执行SOA 评估、开发SOA 原则、定义参考架构 (未来状态)以及进行从当前情况到未来状态的转换的过程。 下面是SOA 的这个阶段的三个关键可交付性因素:  开发开发开发开发SOA 原则原则原则原则::::清晰简洁地定义SOA 原则。  SOA 参考架构参考架构参考架构参考架构::::描述IT 组织的“未来状态”。SOA 参考架构制订了技术的“最终状态”,而且, 作为此阶段的一部分,团队需要定义业务的“最终状态”。这有助于为企业/LOB 开发SOA 路线 图。  SOA 路线图路线图路线图路线图::::路线图应该清晰地定义了部署业务解决方案以及支持它们所需的基础架构的阶段 它还要识别快速成功地验证SOA 的优点的机会。 2.3.2.3 SOA 执行计划 执行计划描述了如何执行SOA 路线图。可通过两个方向执行该路线图:  项目项目项目项目::::团队根据路线图中描述的顺序执行项目并根据需要构建基础架构以提供业务功能  治治治治理理理理和组织和组织和组织和组织::::团队并行实现这两个目标以便基于SOA有效地执行项目。 团队需要定期查看SOA 执行计划并在任何时候计划发生了重大变化时更新路线图。 15 2.4 如何避免从如何避免从如何避免从如何避免从 SOA 进入进入进入进入 DOA 有些公司因为仓促使用SOA 而出现了问题。下面是一些最为常见而又很容易避免的SOA 错误:  认为Web 服务是SOA。Web 服务是SOA 的重要基础,但SOA 是一种架构性方法,而不是粒度服 务的集合。  将SOA 用作所有集成挑战的解决方案。公司必须首先确定哪些应用程序或集成工作是适合SOA 的。  认为简单的“SOA 解决方案”可以快速启动SOA计划。并不存在“开箱即用”的SOA 解决方案。 公司必须仔细选择具有可操作性与基于行业标准和架构框架的产品。  忽略业务需要。如果团队将SOA 视为IT 项目并通过提供具有所需的性能、可重用性和成本有效 性的功能创建不符合业务期望的服务,则项目将会失败。SOA 并非IT 项目;它是一种企业级方 法,需要企业级支持。  致力于平台。采用模型驱动的适用于任何平台的方法可在相当长时间内提供更好的ROI 和灵活 性。 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 提供新业务能力的解决方案和工具的供应商  需要更好地了解业务和IT 计划如何利用技术实现其目标的使用案例的标准机构。 1.3 《《《《SOA 专业人员指南专业人员指南专业人员指南专业人员指南》》》》的优点的优点的优点的优点 本文档可帮助读者:  向他人学习:很早就开始使用SOA 的用户可共享其有关跨行业采用SOA 的最佳实践、看法以及 观点  比较替代产品:标识和定义SOA 的关键技术组件,建立对选项比较的基线参考  改进合作:使用一种通用语言澄清本文档中定义的SOA 组件的性质  加速实现:本指南定义了其服务生命周期和需求、建议的工具以及每个阶段的最佳实践。  了解标准的价值:本文档建议了用于SOA 的各个方面的标准  避免潜在风险:本指南指出了供应商社区尚未指出的一些问题领域。 1.4 SOA 专业人员指南专业人员指南专业人员指南专业人员指南::::章节章节章节章节 《SOA 专业人员指南》包含三个单独的部分。 第1部分(《为何使用面向服务的架构?》)提供了一个高层次的SOA 摘要。 5 本文档(《SOA 参考架构》)是第二部分。它提供企业级SOA 实现的工作设计,包括详细的架构图、 组件描述、详细要求、设计模式、有关标准的观点、法规遵从性模式、标准模板以及成员的潜在代 码资产。 第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:业务架构的关注领域 开发业务架构的最佳实践包括:  审查当前系统规范和基础技术  将这些映射到业务战略以便找出差异  审查水平(业务流程)和垂直(基于角色的视角)要求  确定应用程序(服务)组合的优先顺序以便提供这些功能  跨应用程序标准化用户体验  定义有关关键方面的业务策略,例如应用程序和数据访问和法规遵从性 附加参考:开发业务架构视图(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 的价值进行了评价。下面的链接提供了有关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 充当应用程序 的一个视图。 业务委派层业务委派层业务委派层业务委派层::::业务委派层是负责表示层和业务层之间的通信的组件。它们可提取访问业务层时所包 含的通信细则和复杂性。此层包括一个模型视图控制器框架,可帮助用户浏览网站。 服务层服务层服务层服务层::::服务层包含应用程序服务器的功能。该层由公开高级业务功能性的无状态功能组成。它具 有一个会话表面,这是到业务层的入口点,可提取处理来自表示层的细粒度业务实体的详细信息。 大多数业务逻辑都可以直接在会话表面或应用程序对象的子层上实现。 18 域层域层域层域层::::域层也使用核心应用程序服务器。它是定义一致业务概念的业务实体集合。由于这些组件表 示不变状态,此层中需要使用处理数据库存储的技术。Entity Bean 可用于实现对象模型的一些组件。 或者,简单传统Java 对象(POJO)在数据访问对象(DAO)的帮助下提供一致性。Entity Bean 是 实现此层的最佳机制,但是,如果对象模型比较复杂,则需要将此技术进行组合。 2.3.1.2.3 自定义应用程序框架组件自定义应用程序框架组件自定义应用程序框架组件自定义应用程序框架组件 自定义应用程序框架组件可扩展应用程序服务平台中固有的服务。框架组件包括: 数据服务数据服务数据服务数据服务::::为应用程序提供的持久层。容器管理足够健壮,可以利用CMP 完成大多数简单的事务, 但作为处理复杂事务的选则应该提供DAO。 记录服务记录服务记录服务记录服务::::应用程序用来记录和跟踪错误和活动的服务。要记录的消息类型包括要跟踪为进行诊断 而记录的所有问题、错误或故障以及为审计跟踪和用法分析而记录的活动的调试消息。每个企业都 应该标准化应用程序使用的记录服务,最理想的是利用JDK 1.4 提供的功能。如果记录服务在整个企 业都一致,则允许工作人员更有效地确定性能或事务瓶颈。记录服务应标准化机制,使其与企业内 的整个开发社区进行通信,并确保与标准的兼容。不需要为此服务开发特定代码。 异常处理异常处理异常处理异常处理::::管理和传达异常的机制。它与记录服务的类似之处在于团队应该利用标准应用程序服务 器功能。团队需要确定使用哪个机制并传达给企业内的整个开发社区。无需为此服务开发特定代码, 但如果团队提供了处理异常的示例的话也会十分有用。 部署部署部署部署/应用程序配置应用程序配置应用程序配置应用程序配置::::记录配置详细信息的文档。这涉及标准化在各种环境下构建和部署应用程序的 机制,包括开发、QA、UAT、阶段划分和生产。 监控监控监控监控::::监控过程的标准化和文档记录。由于操作人员必须监控平台和应用程序并预测性地解决问题, IT 内的大多数部门都已经标识和部署了监控工具。问题在于要标准化并集成监控过程和技术,以确 保所有系统中的数据的一致性。企业可能需要购买或开发并部署附加的专业监控工具。 搜索框架搜索框架搜索框架搜索框架::::搜索数据的共享功能。大多数门户应用程序都需要以表格形式向用户显示数据。团队不 应让每个开发人员都试图解决此问题,而应开发一个可应用于全部应用程序和门户的“搜索框架”。 下图演示了一个用作搜索框架的基础架构。 图8:搜索框架 搜索框架提供:  基于用户输入的动态查询生成  排序次序、合并,等等  用于显示的全部搜索结果 19  一致的搜索处理机制  字符转义和通配符解释  标记页数  从应用程序提取所有数据库访问代码  用作输入的标准  java.util.List 等标准中需要的搜索结果  外部文件上的查询  处理公共UI 任务的实用程序  标记页数  标准一致性。 通知框架通知框架通知框架通知框架::::到所有应用程序的单个通知客户端。它应该支持到通知引擎的同步和异步接口,还应提 供通过多个通道发送通知的能力。 图9:通知框架 到不同通道的接口应该根据业务要求进行开发。 服务代理框架服务代理框架服务代理框架服务代理框架::::提取服务实现详细信息。团队可在本地或远程部署服务,而不一定要使用服务的实 现详细信息或位置对调用应用程序进行编程。相反,服务定位器会确定服务的位置并通过合适的方 式进行调用。这支持多种代理,例如EJB、Web 服务和服务总线代理;也可根据要求开发附加代理 类型。这也可由业务委派层用于将表示层从服务层分离开来。 20 图10 :服务代理 安全安全安全安全框架框架框架框架::::提供安全功能的企业级层。由于当前企业安全解决方案无法满足他们全部的业务需要, 大多数应用程序项目团队都开发了自己的安全层。支持客户端的安全框架可减少(如果不能消除) 为每个应用程序开发自定义安全代码的需要。下面是安全框架应该提供的一些功能:  单点登录(SSO):登录一次后无需再次登录就可以在应用程序之间来回切换的功能  访问控制:用于三个主要领域的一组安全功能:  身份验证:确定与应用程序交互的用户的身份  授权:确定用户是否允许执行特定操作  审计:跟踪用户执行的操作。 此外还需要几个辅助业务,例如注册、权限授予以及权限查询。这些功能应作为可由不同的应用程 序使用和重用的一般框架提供,每个功能都具有稍有不同的需要,但其基本要求都相同,包括:  身份管理:具有多个用于管理一组应用程序或服务的访问控制信息的存储区可能会导致严重的 管理问题。身份管理可通过集中访问控制管理功能以及跨企业供应用户提供帮助。  整合用户配置文件:门户提供这个功能的目的是允许应用程序扩展基本配置文件。此功能从多 个数据源提取用户配置文件,例如从应用程序特定的储存库提取基本配置文件和应用程序特定 的配置文件。  注册、委派管理、供应和储存库:这些都是在访问控制顶部构建的,用于满足应用程序特定的 业务需要的安全扩展功能。或者,也可能是与访问控制集成的打包的解决方案。 门户产品可提供这些非自有功能的一大部分。如果不具有自己的开发自定义应用程序的门户,IT 组 织将必须开发和支持此功能。 2.3.1.3 门户服务 门户服务管理应用程序的表示层。表示层通常都是基于权限的,因此需要支持此功能。 表示表示表示表示::::门户表示功能为每个应用程序组提供外观、模板、构架和样式表。它还包括一些示例应用程 序,来帮助开始开发和利用门户导航功能,包括用于垂直导航条和水平选项卡。 个性化个性化个性化个性化::::门户提供个性化服务,例如portlet 布局和背景模板选择。本文将在“企业安全”的配置文 件管理部分介绍应用程序环境下的附加个性化。 21 身份验证身份验证身份验证身份验证::::所有门户产品都提供此功能。最佳实践就是使这项服务具体化。大多数企业都在其内部 实现了全局目录服务(如LDAP)。自定义应用程序框架应提供一个身份验证界面并使服务具体化。 单点登录单点登录单点登录单点登录((((SSO):):):):企业应该不需要多次登录就能提供完美的用户体验。此框架组件不仅要支持自 定义应用程序,还应该支持打包的应用程序和企业服务。 2.3.1.4 企业基础架构服务 这些是基于应用程序的服务,该服务可供整个外部和内部用户群使用。大多数企业服务都是基础架 构组件,用户可将其中的一些组件提供的功能作为应用程序使用。下面是企业服务的一些示例。 目录服务目录服务目录服务目录服务::::这是在全企业范围内提供的标准目录服务,通常与电子邮件服务结合使用。大多数企业 都实现了元目录,以便跨企业管理身份。 个人信息管理个人信息管理个人信息管理个人信息管理::::这是标准的电子邮件、日历和地址簿功能,其中包括从任何通道访问这些信息的功 能。 协作协作协作协作::::这提供了白板、电话会议、即时消息传递、论坛、新闻组和工作区等功能。 企业内容管理系统企业内容管理系统企业内容管理系统企业内容管理系统::::这是驱动自定义应用程序如知识管理、资产或合同管理以及协作的基础架构服 务。规定方法是利用门户或内容管理提供商提供的API。所有领先的内容管理系统都提供了开发用于 上传和编写内容的模板以及用于管理批准流程的工作流的功能。 下面是实现企业内容管理系统的最佳实践:  首先定义分类信息,理想情况是创建企业级分类信息。  创建单个文件基础或储存库或企业级基础。这可能不太实用,但想法很好。  将所有内容发布到生产环境中的单个位置,并将所有应用程序配置为从该位置检索内容,以便 降低TCO。  培训作者和内容审批人以使用该系统。  通过让提供商的架构师参与每个项目 与内容管理系统提供商紧密合作,尤其是在项目的设计阶 段。  利用预先构建的portlet 编写、审查和管理内容。  在SI 或内容管理系统(CMS)提供商的专业人员的帮助下将业务流程映射到CMS 工作流。 搜索服务搜索服务搜索服务搜索服务::::这就使得所有外部或内部用户都可以找到他们有权访问的信息。存在多个搜索解决方案: 1. 关键字搜索,大多数用户都习惯的标准搜索功能 2. 自然语言搜索,通常用于刚刚使用该技术,想要通过使用自己当地的语言询问问题来查找 信息的非技术用户或Internet 用户 3. 联合搜索,允许搜索结构化和非结构化的数据类型。 搜索引擎的集成非常简单直观。搜索引擎按请求的顺序处理XML 或HTTP 请求并返回结果。 搜索引擎与内容管理系统紧密协作。下面是最大程度地利用搜索引擎的一些最佳实践。  为内容管理系统创建企业级分类信息。  为内容定义元标记,并将其用于门户以便根据用户权限向用户显示内容  使用搜索引擎根据需要crawl 和创建多个集合和子集合  根据需要在不同业务单位之间进行联合搜索 22  利用门户标记和权限保护安全内容  在应用程序服务器级别存储安全内容。 对于大型站点,crawl 整个内容储存库的时间很成问题。根据业务需要,公司可以通过如下方式解决 这个问题:创建多个集合并在搜索条件中包含所有集合,周期性执行部分crawl ,设置多个搜索引擎, 以及利用联合搜索。这有助于与搜索解决方案提供商协作开发架构和流程。 2.3.1.5 企业(基于角色的)门户 通过实现本文档中定义的网络层组件,企业可获得下图中描述的“当前状态”。 图11 :企业(基于角色的)门户 在这种状态下,IT 组织可以以客户应用程序、打包的应用程序、企业服务或这些组件的组合的形式 快速部署业务解决方案。自定义应用程序框架允许业务提供格外好的用户体验。不过,它也具有如 下缺点:  重新树立品牌(re-branding)用户体验可能会要求对所有站点进行更改。  用户仍然需要知道每个站点的URL。通过采用一些最佳实践可以将这个缺点的程度减轻,但无 法完全消除。  此模型可能会导致每个点解决方案的硬件和软件冗余。这是因为每个业务单位都想要调度自己 的维护窗口,而实现这个目标的唯一方式就是为每个点解决方案提供专用的基础架构。 目标状态是利用联合门户的概念创建基于角色的企业级门户。此方法的优点如下所示:  为所有员工、客户、合作伙伴和其他用户提供一个入口点。  基于用户角色的应用程序(Portlet )访问  硬件和软件基础架构的整合  总是打开的功能  更简单的站点重新冠名  联合门户通过利用服务提供的多通道交付。 23 2.3.2 服务层服务层服务层服务层 服务层是SOA 的主要启用程序,包括本节中描述的组件。 它允许在企业之间进行集成与业务流程自动化。此层基于粗粒度、松耦合的和基于标准的服务的 SOA 原则。它通过为减少的应用程序和基础架构复杂性,业务服务增加的重用性,以及服务编排能 力,来帮助IT响应不断变化的业务需要。 2.3.2.1 服务总线 服务总线是为IT 灵活性和与业务需求的调整提供面向服务的基础架构的关键组件。它应该与服务注 册表和服务管理组件进行完美集成,以便加速配置和部署管理并简化企业之间共享服务的管理。 该服务总线应该能够通过任何协议接受任何同步或异步消息,并根据配置规则将其路由到目的地。 此外,它应该能够将消息转换为目标要求的格式。由于这控制消费者和生产者之间的消息流,服务 总线在管理、监控和实施服务级别方面具有独特的地位。 图12 :企业服务总线架构 上图表示企业服务总线(ESB)。ESB 充当动态可配置的消息和服务代理。它提供了以下功能:  异构环境之间的消息代理  支持异步、同步、发布和订阅消息传递  支持同步和异步桥接  支持多种消息格式,包括SOAP、带附件的SOAP、XML、结构化非XML 数据、原始数据、 文本以及带附件的电子邮件  服务端点之间的异构传输  支持多种协议,例如文件、FTP、HTTP(s) 、多JMS 提供商、RMI、Web 服务、CORBA、 DCOM 以及电子邮件(POP、SMTP 和IMAP)和SIP。  允许消费者与生产者交谈的消息转换,但不提供完全成熟的转换引擎  配置驱动的路由  基于策略进行消息路由,或者调用外部服务以支持复杂路由  支持点对点和一对多路由方案,允许请求-响应和发布-订阅模型  监控 24  带搜索功能的服务监控、记录和审计功能  捕获消息和传输属性的关键统计数据,包括消息调用、错误、性能、容量和SLA 违反情况  高可用性  支持集群并跨集群收集统计信息以审查违反SLA 的情况  简化服务供应  通过配置动态部署新的服务版本  在设计、阶段划分和生产之间迁移配置的服务和资源  支持消息资源的多个版本,通过灵活路由进行选择性的服务访问来配置这些版本。  可配置的策略驱动安全  支持用于进行身份验证、加密-解密和数字签名的最新的安全标准  支持用于HTTP 和JMS 传输的SSL  支持多个身份验证模型  策略驱动的SLA 执行  根据各种属性建立SLA,包括吞吐时间、处理容量、消息处理的成功/失败比率、错误数、 安全违反情况和模式验证问题  使用灵活的机制启动自动警告或启用操作人员启动的对规则违反情况的响应,这些机制包 括电子邮件通知、触发的JMS 消息、触发的带JMS 消息的集成过程,带JMS 消息的Web 服 务调用或者管理控制台警告。 下面是服务总线的一些最佳实践:  在任何时候服务数目超过50 时采用服务总线。如果服务数目超过150 则必须使用服务总线。  从小型规模开始,例如将目标定位单个复合应用程序或为跨越多个系统的分部业务流程。  考虑让多个LOB 根据自己的策略管理自己的服务总线,并使用一个跨不同的业务单元共享服务 的可充当代理的企业级服务总线。  确定是部署供应商提供的服务总线还是内部开发的抽象层。 2.3.2.2 服务注册表 SOA 要求服务是粗粒度、松耦合的和基于标准的服务。开发和部署服务后,必须为架构师、开发人 员、操作人员和业务经理提供可用的服务目录。 25 图13 :服务注册表 上图演示了服务注册表的架构。服务生产商为服务消费者用于运行时绑定的服务注册表发布了服务。 注册表还可充当业务策略在运行时执行的记录系统。 服务注册表应该提供下面的功能:  核心服务,包括复制、UDDI 数据存储和安全  信息服务,包括数据验证、SOA 映射、高级分类以及业务数据访问服务  生命周期服务,包括批准和更改管理、更改通知、业务服务发现和QoS 管理  配置的基于Web 的业务服务控制台  与领先的启用、管理和安全产品连接的独立于平台的开放架构。 服务注册表的最佳实践包括:  从小规模开始并逐步增长  将服务注册表的每次实现复制到企业服务注册表  为架构师、开发人员和操作人员提供服务浏览功能以帮助实现重用和标识服务依赖关系  维护服务合同信息以及服务定义  对所有服务进行版本控制。 2.3.2.3 SOA 储存库 SOA 储存库是在服务生命周期(从项目初期到完成)中管理元数据的关键组件。其主要目的是存储 详细元数据以便在部署前管理和治理资产。SOA 储存库存储服务定义,以便团队可以检查企业内定 义了哪些服务。SOA 储存库还存储了其他类型的元数据,包括过程映射、业务规则、实体和关系、 编排、转换、参考数据模型、业务活动和事件、审计要求、角色和授权映射,以及治理规则和策略。 储存库还可通过标识和管理依赖关系以最大化重用率来帮助减少“服务sprawl ”。如果储存库中包 含来自组织的所有产品的元数据,则可为架构师和IT 决策人员提供有关服务、系统和数据依赖关系 的有价值的总体观点。为了帮助业务、IT 和操作人员进行正确的决策,SOA 储存库应该将有价值的 资产存储为标准化治理流程、供销业务和技术最佳实践以及开发方针。 SOA 存储库可在设计阶段帮助治理SOA 资产。他们允许在SOA 生命周期的不同阶段共享元数据,并 在资产填充到储存库中时提供一个理想的位置以触发批准工作流。储存库可帮助确保在资产在其生 命周期中得到合适的批准,同时降低服务的“独立开发”并支持进行较高程度的重用。 SOA 储存库还提供了一个中心位置,用于管理与运行时执行(如路由、安全和SLA)的服务关联的 策略。储存库的依赖关系跟踪和影响分析功能可帮助团队管理对策略或其他资产的更改,并预测性 地分析更改对其他资产的影响。 SOA 储存库应提供如下内容:  发布和发现元数据(服务、业务流程、用户交互等)的能力  按类别、复合应用程序名称、服务描述、范围(如分部或部门)或者储存库内跟踪的任何其他 元数据类型进行的复杂的元数据搜索  服务依赖关系映射,用于跟踪服务依赖的资产以及依赖于此服务的资产  元数据更改的通知  可扩展元数据分类信息,以便业务可以根据自己的要求自定义分类信息 26  授权过程,用于控制哪些人可以创建和操作储存库中包含的元数据  所有资产的版本信息的维护  影响分析,用于在进行更改前预测性地测量更改的影响  与开发环境同步的开放的可扩展界面  与其他外部存储的同步,例如注册表或其他储存库  基于设计时策略的元数据的设计时语义验证  批准工作流,用于提升或拒绝元数据  多个同步储存库的联合和分区。 根据服务及其依赖关系的数目,为三个以上的项目采用SOA 的IT 组织可能会需要SOA 储存库,尤其 当他们具有多个分布式开发团队以及许多服务时。如果组织成熟到可以重用服务来开发复合应用程 序、流程或服务,就需要使用储存库以便管理和治理重用性。 2.3.2.4 服务管理器 企业内的SOA 实现变得越成熟,对总体服务管理器的需要就越发强烈。此服务管理器的主要功能在 于管理、监控和报告整个企业内的所有服务。下面是服务管理器需要提供的一些功能:  管理和维护整个企业的服务级别  跨企业映射和管理服务层次结构,并为操作提供依赖关系指标  检测和管理异常情况  审查和监控业务事务,并提供审查动态事务的功能  管理服务生命周期并在部署前进行验证  跨不同的系统提供非插入式服务发现功能  管理多个服务总线和服务注册基础架构并与之集成  利用现有监控基础架构。 2.3.2.5 共享数据服务 共享数据服务提供了多项关键功能:  电子数据互换电子数据互换电子数据互换电子数据互换((((EDI)))),使用网络在不同公司之间传输数据  数据操作数据操作数据操作数据操作  提取、转换和加载(ETL)  企业信息集成(EII)  数据质量数据质量数据质量数据质量  数据匹配引擎  数据工作  工作流。 EDI 和ETL 是传统的方法,对于以批量模式处理大量数据尤其有用。不过,SOA 有一个要求,就是能 27 够将一些EDI/ETL 功能作为服务调用。例如,电子基金转帐必须从事件触发的源系统填充操作数据 存储。 2.3.2.5.1 企业企业企业企业信息集成信息集成信息集成信息集成((((EII)))) EII 引用软件系统,此软件系统可从各种内部和外部源获取不同格式的数据并将其看作单个数据源。 图14 :企业信息集成(EII) EII 应该提供以下功能:  跨多个源的数据建模  查询(读写)开发以便从多个数据源提取信息。  支持多种数据源,例如数据库、文件、应用程序适配器、LDAP 和Web 服务  数据转换  数据验证  使用RMI 或Web 服务将数据服务公开到客户应用程序。  坚持SQL、XQuery 、XML、Web 服务、JDBC 以及J2EE 等标准。 虽然定义了服务数据对象(SDO)标准以简化和统一应用程序处理数据的方式,但业界尚未清楚地 定义EII 的标准。所有供应商都具有自己扩展,来处理对于每个数据存储的数据读取、数据更新以及 数据插入操作。 图15 :将EII 用作数据集市 28 最佳实践是使用业务智能(BI)工具从数据仓库、ODS 或数据集市提供分析报告。ETL 是面向批处 理的,因此业务通常得到的是延迟的报告,不总是能够表示企业的当前状态。为了提供实时信息, IT 组织开始利用EII 工具直接从源系统将数据实时提取到BI 工具中。所有主要的BI 供应商都支持此方 法,这还可以促进ETL 和EII 工具之间的会合。 这种会合不会影响组织的文化,尤其当大多数数据架构师、数据分析师和DBA 更熟悉ETL 工具而不 是EII 工具时。在进行此类项目前,IT 组织应该计划培训人员和引进EII 专家。 2.3.2.5.2 数据质量数据质量数据质量数据质量 企业需要关注数据质量,因为:  数据质量直接影响信息质量  数据质量低下会导致依赖该数据的业务流程效率低下  根据低质量数据进行重要决策会导致非常严重的后果  低数据质量又会反过来影响组织,降低客户信任度  如果数据错误,公司会浪费时间、金钱甚至是损害其名声。 图16 :改进数据质量的过程 要改进数据质量,组织需要关注:  数据分析数据分析数据分析数据分析::::创建高质量数据环境的第一个步骤就是了解当前环境下的数据质量水平。度量数据 质量改进计划是否成功就在于在项目开始时是否正确评估数据质量状态。  数据标准化数据标准化数据标准化数据标准化::::组织必须定义和应用数据标准化的业务规则。  数据匹配和加载数据数据匹配和加载数据数据匹配和加载数据数据匹配和加载数据::::IT 必须使标准化数据与现有的经过清理的数据匹配,并创建或更新现有 数据。此外,IT 必须公开共享服务以便客户应用程序利用数据匹配。 除了数据质量基础架构,企业还需要一个主数据管理(MDM)功能。由于使用了这么多不同的应用 程序,组织会发现企业内外存在许多种对实体的表示方法。MDM 合并和合理化关键实体(例如客户 和产品)的表示方法,以确保得到精确一致的信息。 29 图17 :主数据管理 MDM 由数据服务和数据工作组成。  数据工作数据工作数据工作数据工作是允许用户审查异常数据,管理数据并创建多个层次结构以进行报告的应用程序。  数据审查数据审查数据审查数据审查提供审查链接的和未链接的数据并进行校正操作的功能  数据管理数据管理数据管理数据管理允许工作人员修改或手动覆盖匹配项,修改匹配项和数据生存规则,并管理用户。 此外,它还允许团队利用第三方源的数据优化规则,例如Dun & Bradstreet 。  层次结构管理层次结构管理层次结构管理层次结构管理允许工作人员根据行业、地理位置、收入和组织创建主数据层次结构。  数据服务数据服务数据服务数据服务是为MDM 提供基础架构的一组可配置规则。其功能包括:  匹配匹配匹配匹配,,,,使用模糊逻辑根据业务的预先定义的匹配规则匹配和标准化主要数据。  操作操作操作操作,用于数据移动和微调。此外,它还提供用于匹配、清理和标准化数据以及实施数据 生存规则的基本工作流  建模和检索建模和检索建模和检索建模和检索,,,,使业务组织可在IT 有限参与或不参与的情况下修改MDM。传统情况下,ETL 或自定义工具提供了检索功能,但现在各公司通常使用EII 工具实现此目标。 2.3.2.5.3 最佳实践最佳实践最佳实践最佳实践 下面是共享数据服务的一些最佳实践。 2.3.2.5.3.1 实现主数据管理实现主数据管理实现主数据管理实现主数据管理 公司需要关注总体业务流程才能获得SOA 的全部优点。由于企业要使用数据获得事实真相,因此将 企业数据流映射到与其相关的业务流程十分重要。下图是将关键数据元素映射到业务流程的重要性 的示意图。 30 图18 :集成数据 在采用SOA 之前,开发集成数据模型并非易事。建议的方法是在实现SOA 时分阶段实现数据模型, 每次完成一个业务流程。业务需要区分业务流程的优先次序,而IT 则并行工作以开发一个将数据流 映射到业务流程的企业数据模型。 各公司很快意识到,在存在许多流程和子流程的同时,还存在一组有限的企业数据对象,例如客户、 合同和产品,这些对象是大多数公司都需要的。数据模型的普及对于组织来说是一个威胁,这个威 胁需要通过实现MDM 解决方案解除。 图19 :标识企业数据对象 正在实现MDM 的组织发现:  从来就不存在什么捷径。进行高级别业务流程映射可帮助标识企业公共对象或实体。  业务定义流程  解决MDM(公共对象)是优先级最高的任务。  业务定义企业的数据需要  ODS 和数据仓库可通过使用公共对象/模型派生。  团队根据需要开发合适的基础架构 31  业务项目团队必须开发填充ODS/ 数据仓库的功能或MDM 解决方案。 2.3.2.5.4 结构化和非结构化数据结构化和非结构化数据结构化和非结构化数据结构化和非结构化数据的会合的会合的会合的会合 “结构化数据”指数据库中存储的企业数据,而“非结构化数据”是指存储在不同文档中的企业数 据。目前大多数企业都具有搜索非结构化数据的解决方案,也可以利用应用程序访问结构化数据。 不过,用户可能希望能够在相同的页面上同时审阅结构化和非结构化数据。 图20 :聚合结构化和非结构化数据 会合要求有三个组件:  向用户显示信息的门户  联合门户利用WSRP 来显示结构化和非结构化信息  搜索引擎  将非结构化内容提供给门户  共享数据服务  访问结构化数据,最好是使用EII  利用MDM 搜索企业数据对象。 每个企业搜索组件都扮演了一个不同的角色:  联合搜索联合搜索联合搜索联合搜索::::将搜索请求提交给外部服务提供商  关键字搜索关键字搜索关键字搜索关键字搜索::::根据关键字进行搜索  模糊搜索模糊搜索模糊搜索模糊搜索::::根据自然语言或模式搜索  上下文搜索上下文搜索上下文搜索上下文搜索::::维护搜索的上下文,而不一定包含操作符  非结构化搜索非结构化搜索非结构化搜索非结构化搜索::::搜索不同类型的内容,包括200 个以上的文档类型  结构化搜索结构化搜索结构化搜索结构化搜索::::搜索数据库 2.3.2.6 业务流程管理 BPM 用于管理长期运行的同步和异步业务流程。服务总线执行轻量级服务编排,而BPM 执行下面的 32 功能:  可视流程建模,以修改视图和业务流程模型  开放标准兼容,最好是BPEL  私有流程、公共流程、人员任务和错误处理之间的业务流程编排和自动化  支持高级建模的嵌套的并发流程以及启用快速自定义需要的自定义逻辑  优化的流程性能以提供配置全状态(长期运行)和无状态(短期运行)流程设计模式以及同步 和异步流程执行的灵活性  状态监控功能,以便以图形化方式显示用户端到端流程并根据服务级别协议测量性能  流程实例监控,以提供有关运行流程的统计数据,找出单个的详细信息,并终止、删除或延迟 有问题的流程实例  允许任务创建人、工作人员和管理员与运行中的业务流程交互,以便处理流程异常、批准和状 态跟踪  用户和组管理,以集中分配集成项目的角色、用户和组  通过使用领先的标准协议(如RosettaNet 、ebXML 和EDI),安全的消息传递、数字签名和加 密,可恢复和可跟踪的消息以及动态配置升级,B2B 协议支持与供应商和客户的快速安全的在 线连接。 2.3.3 SOA 框架框架框架框架 SOA 框架是作为SOA 主干的可重用服务。这些可重用服务必须是企业级服务,具有良好的设计以至 于可根据负载进行伸缩,并可满足各种消耗很大的应用程序和涉众的需要。 通过帮助开发团队快速设计、开发和部署设计良好的、模块化的、灵活的、可伸缩的和可支持的Web 服务、Web 应用程序和portlet ,SOA 框架支持到SOA 的移动。在公司开始采用SOA 原则转换IT 架构 时,必须创建这些基础服务以作为企业级资产。 框架可定义为可重用的主干应用程序,团队可对其进行扩展以构建特定服务或应用程序。框架可改 进提交的软件的一致性。框架可控制本身以及以其为基础创建的应用程序或服务。 框架通常提供一组高级编程提取以及创建企业级服务的强有力的起点。他们通常为合并多个设计模 式和软件工程最佳实践的服务指定一个分层架构。该架构还指定各个层中组件的责任以及它们之间 的协作。 服务继承内置到框架中的有效架构和最佳实践。通过使用框架,一组中等水平的开发人员就可以开 发架构良好的、能够利用设计模式和最佳实践的服务。服务创建框架可提供的典型的层包括:  转换层转换层转换层转换层::::支持协议和数据类型转换以支持多个访问协议,同时又保持大多数(如果不是全部) 服务实现协议和访问机制的广泛适应性。  业务逻辑层业务逻辑层业务逻辑层业务逻辑层::::保存系统中的所有业务逻辑。这包括如请求、结果、UseCaseController 和 BusinessPolicy 对象等的提取。  业务数据层业务数据层业务数据层业务数据层::::域对象的层,所谓域对象是指在企业中的许多应用程序中都具有一致定义的对象。 业务数据层应该提供位置透明性,这样域对象的用户就不需要知道基础一致数据的确切物理位 置。此层应该能够管理企业中的各种持久性储存库的持久性,并可对这些储存库进行检索。  集成层集成层集成层集成层::::从JDBC 到JNI 到Java 连接器的连接技术实现的占位符。访问扩展企业系统(例如ERP 系统和内容储存库)所需的所有基础架构代码都放入此层。 33 SOA 框架可同时为开发人员和公司带来好处。当开发人员使用框架时,他们:  获得创建服务、Web 应用程序和portlet 的坚实基础  通过合并设计模式和最佳实践提高生产力  利用框架的现有功能并编写少量代码  不需要了解J2EE 标准和规范的具体细节  不是面向对象的设计和设计模式的专家也可以从中受益。 对于IT 组织和公司这个整体,SOA 框架提供了:  快速并以低廉成本实现SOA 的催化剂  项目之间设计和开发一致性  重复性以及保证架构和设计的严格程度最低的能力。  通过很容易更改(通常是通过配置更改)的模块化解决方案得到的改进的业务灵活性。  在不同技术水平的开发人员中利用软件工程最佳实践  更一致的、可预测的和得到更好测试的解决方案  项目中开发人员更好的可动性 IT 组织正在使用SOA 原则积极创建封装和公开关键业务流程的可重用服务。通过把分层架构、易用 性、以及对良好架构和重用性的重视结合起来 ,SOA 将各公司组织起来以便创建供应商中立的和可 移植的任务重要的企业级服务。 2.3.4 应用程序层应用程序层应用程序层应用程序层 IT 组织的最大投资在于应用程序。企业在SOA 方面的投资不断增长,但应用程序层不会很快发展。 2.3.4.1 旧应用程序 这些是强大的客户端应用程序。它们可能是打包的应用程序的尚未升级的旧版本。这些应用程序可 能最适合用于客户端/服务器模式。 这些应用程序通常具有一些发布了的API 或逻辑模型以进行集成。 2.3.4.2 大型机应用程序 运行于专有的大型机系统之上的业务解决方案可以通过消息传递或数据库网关与其他系统集成。大 型机软件供应商正在致力于将所有API 作为Web 服务公开。不过,在大多数情况下,最好的方法是通 过利用中间件开发抽象层并公开合适级别的服务来支持业务要求。 2.3.4.3 企业应用程序集成 企业应用程序集成(EAI)通常使用中间件提供下面的功能:  消息传递消息传递消息传递消息传递::::面向消息的中间件(MOM),用于允许资源发布和订阅消息  业务流程管理器业务流程管理器业务流程管理器业务流程管理器((((BPM):):):):自动化业务流程的专有功能  应用程序适配器应用程序适配器应用程序适配器应用程序适配器::::预先配置的到各种打包应用程序的连接器,允许访问应用程序视图或者其他 34 技术的技术适配器(如数据库、消息传递(MQ 和JMS)和Web 服务)。 EAI 的最佳实践是利用集成集线器。不过,如果没有合适的支持方法,这会在集线器上导致点对点的 解决方案。虽然服务层提供了服务总线和BPM,允许企业采用SOA 并从EAI 迁移出来,这种迁移也 需要花费很长的时间,尤其当IT 组织在EAI 方面进行了大量投资时。 2.3.5 企业安全企业安全企业安全企业安全 目前大多数打包的或自定义应用程序都实现了自己的安全解决方案。不过,每个企业都具有多个应 用程序,每个应用程序都具有自己的身份验证实现,这样在不同的时间更新不同的身份验证实现时 就有可能会引发问题。 这个问题可以通过将企业安全划分为三个主要组件得到简化: 图21 :企业安全组件 委托管理委托管理委托管理委托管理::::用户和资源管理应用程序允许管理员根据用户角色相应地创建、修改和删除用户特权。 此应用程序更新与企业安全服务器所使用的相同的存储库。 客户端应用程序客户端应用程序客户端应用程序客户端应用程序::::具体化和利用企业安全服务。 企业安全服务器企业安全服务器企业安全服务器企业安全服务器::::提供安全服务,例如用户身份验证、用户身份管理、授权、审计、用户配置文件 管理和用户供应。  身份验证通过多种身份验证机制验证用户身份。可以根据密码或者通过数字证书或智能卡验证 身份。为了提高生产力,用户需要能够通过一次登录访问多个资源,但企业需要实现正确的控 制和策略,因此进行一次身份验证后用户只能访问得到使用授权的资源。  身份管理将多个身份映射到单个用户,或者跨应用程序链接身份以支持多个用户身份的共存。  授权涉及控制用户对整个企业内的多种资源的访问。  审计涉及跟踪用户活动。  配置文件管理及管理用户的配置文件。  供应自动完成管理账户及其生命周期的费时过程。它允许跨企业内的多个应用程序集中激活、 修改或取消账户。用户供应应该包括显式授权或调用用户对资源的访问以及建立用户授权策略。 2.3.6 业务服务管理业务服务管理业务服务管理业务服务管理 业务服务管理主要关注监控和报告网络、基础架构、应用程序或业务流程的操作。 35 图22 :业务服务管理 操作部门通常有专门的团队来架构、设计和监控此网络,其中大部分广域网是从电信网络提供商那 里购买的。 基础架构基础架构基础架构基础架构::::所有硬件、操作系统和中间件,如应用程序、服务器、数据库和LDAP。IT 操作部门负责 为基础架构层监控和提供第1层支持,基础架构层有时也称为数据中心监控。 应用程序应用程序应用程序应用程序::::监控应用程序和企业服务,如电子邮件、搜索和内容管理系统。IT 操作部门提供第1层支 持,而有一个专门的团队提供应用程序支持。 业务服务管理业务服务管理业务服务管理业务服务管理::::监控业务流程、策略、活动和IT 服务级别的协议。 2.3.6.1 监控的典型当前状态 大多数企业不具有综合性监控功能,从而导致:  功能相似的多个监控系统  计划的人员配备无法达到需要的水平,导致软件仍然各自为政  仅有有限的或者不存在跨业务或产品silo关联事件的机制  缺乏统一的IT 配置视图来帮助进行关联  仅具有有限的或者不存在将配置元素映射到SLA 管理的业务流程的服务模型视图  仅具有有限的跟踪历史可用性和服务性能的机制  仅具有有限的返回关联关系以便防止重复通知的集成。 下面是支持BSM 所需的功能的完整列表。IT 操作部门需要审查当前状态并开发一个路线图以部署这 些功能。不幸的是,IT 组织的最大挑战是获得筹资批准,尤其当业务想要使业务功能的优先级高于 监控和管理功能的优先级时。  票务票务票务票务::::跟踪已经标识的由事故导致的问题  事件事件事件事件::::通过监控系统或服务台接收的任何警报(不一定是问题)  通知通知通知通知::::将票证(ticket)转发到服务台或负责的操作工作组;这可能包括以前的为分页标识的 要求  诊断和诊断和诊断和诊断和根源分析根源分析根源分析根源分析::::诊断问题以标识根本原因的工具;诊断过程通常包括已知问题解决方案或变 36 通方法的数据库  事件控制台事件控制台事件控制台事件控制台::::提供存储在监控数据存储中的可用性和性能管理数据的视图  关联引擎关联引擎关联引擎关联引擎::::用于解释和使用来自不同的源的数据的软件  决策引擎决策引擎决策引擎决策引擎::::根据关联结果,此软件决定需要执行什么操作,例如记录票证,警告负责的部门, 运行脚本,或者不执行任何操作  监控数据存储监控数据存储监控数据存储监控数据存储::::包含事件数据和配置信息的中央数据库,也称CMDB  服务级目标服务级目标服务级目标服务级目标::::与应用程序或业务流程关联的可用性和性能目标的中央储存库  服务级报告服务级报告服务级报告服务级报告::::针对服务级别目标测量实际性能和可用性的能力  自动化引擎自动化引擎自动化引擎自动化引擎::::允许针对已知问题自动执行操作,如记录票证,运行脚本或启动其他恢复流程  目标方法目标方法目标方法目标方法::::用于管理已知问题的流程和工作流。  自动脚本自动脚本自动脚本自动脚本::::测试或响应已知问题的预定义操作  容量计划容量计划容量计划容量计划::::配置项目的当前的或预测的利用率  系统建模系统建模系统建模系统建模::::组成系统的配置项目的表示形式  工作负载模拟工作负载模拟工作负载模拟工作负载模拟::::使用根据测试基础架构生成综合事务的自动化工具进行的性能和容量测试。  探测器探测器探测器探测器::::收集有关设备的故障或性能信息,但未安装在设备上的软件  系统监控器系统监控器系统监控器系统监控器::::安装在计算机和网络设备上,收集可用性信息的软件  最终用户监控器最终用户监控器最终用户监控器最终用户监控器::::通过综合性事务或监控实际的用户活动测量最终用户体验的软件  业务可用性控制台业务可用性控制台业务可用性控制台业务可用性控制台::::从业务的角度提供可用性管理数据如何影响业务的信息 2.3.6.2 业务服务管理的未来状态 SOA 允许业务通过业务服务管理来监控和管理其业务流程。业务必须在要求阶段定义和捕获业务流 程策略并将其实现。为了支持这个目标,IT 组织需要投资于附加软件并保证附加资金的安全,无论 是用于基础架构还是人数。 2.3.7 面向服务的基础架构面向服务的基础架构面向服务的基础架构面向服务的基础架构((((SOI)))) 由于基础架构需要支持SOA,面向服务的基础架构(SOI)要求资源计算、联网和存储数据:网络、 路由器、网络设备、服务器、存储、数据中心、VoIP 和无线功能。 目前,存储产品通过SNIA SMI-S标准整合了可管理型模型和操作过程。SOI 将该标准作为SOI 架构 的一部分使用。相反,SOI 网络集成主要依赖于专有协议。除了过时的简单网络管理协议(SNMP), 目前尚不存在可用的行业级可操作管理标准。 对于计算资源,存在两个由DMTF 开发的过程产品的标准。DMTF 服务器管理工作组(SMWG)定 义的服务器可管理性标准关注单个系统级别,以便在预启动前定义服务资源建模。实用计算工作组 (UCWG)定义处理虚拟的服务器池管理建模的标准。架构师可将这些阶段产品标准用作基础,并 建议进行附加扩展以便利用技术获得更好的性能和其他功能。 SOI 计算资源存在两个主要组件。第一个是基础架构管理器,这是一个聚合计算资源并将其提取到虚 拟计算池中的软件。第二个是计算资源本身,它可以组合启用计算资源虚拟化的自动功能的软件和 硬件模块。 37 一旦基础架构管理器聚合和提取了计算资源,IT 就可以选择分区功能,例如传统的一个服务器一个 操作系统的分区,在一个计算系统中提供多个操作系统分区,以及跨多个系统提供的操作系统分区。 基础架构管理器中的软件功能允许IT 实现SOI 服务: 图23 :面向服务的基础架构  资源聚合和提取的数据库资源聚合和提取的数据库资源聚合和提取的数据库资源聚合和提取的数据库::::此储存库是SOI 架构的信息基础。根据DMTF 的公共信息模型(CIM) 将计算、网络和存储资源提取到逻辑模型中后,它就会存储这些资源。根据实现,储存库可能 仅提供简单的资源配置,也可能包含计算、存储和网络资源及其操作流程的依赖关系。 一旦IT 定义了资源及相关性的公共提取,此储存库就可在内部和外部应用程序之间共享和同步这些 信息,以确保资源管理的互操作性和一致性。该数据库还包括操作过程,即充当标准化IT 流程的构 建块的泛型IT微操作。例如,服务器供应可使用跨服务器操作系统安装、网络转接VLAN 设置和SAN 存储分区编排配置过程的泛型操作进行简化。目前,DMTF 实用计算工作组正在关注这些用于服务 器虚拟化的泛型微操作流程。随着范围的扩展,UCWG 或其他标准团体将标准化更多的资源操作流 程。 IT 工作人员可利用这些构建块为自己的环境开发更复杂的自定义流程。产品供应商可以扩展操作流 程以更好地利用其产品功能。供应商应该通过根据活动管理技术(AMT)扩展“裸机供应”的操作 流程将自己与竞争对手区分开来。  基础架构管理模块基础架构管理模块基础架构管理模块基础架构管理模块::::这些软件模块提供了服务的执行。服务可以包括自动资源发现、操作系统 虚拟分区的供应、资源运行状况监控及其事件通知以及资源池管理。SOI SDK 可以通过提供软 件示例和库帮助加速这些管理模块的开发,这些示例和库显示了开发人员是如何与提取和聚合 资源数据库进行交互以及如何注册WSDL 服务以及将这些服务应用于外部应用程序的。  基础架构管理协议基础架构管理协议基础架构管理协议基础架构管理协议::::这一组XML 协议允许上层业务或系统管理应用程序(基于Web 服务的应用 程序或旧应用程序)以便与基础资源交互。SOI 管理模块封装其复杂性,将其与业务或系统管 理应用程序隔离,并在内部维护运行时详细信息。此管理协议规范定义了管理交互的资源对象 处理程序的详细信息。 例如,J2EE 应用程序服务器可能会达到性能阈值,需要更多的资源才能遵循其SLA。这样,它会根 据需要的jAppServer SPEC 基准向SOI 发送一个XML 资源请求以要求提供附加计算资源。该请求可能 会指定应用程序配置和操作流程以加入J2EE 应用程序服务器集群。不过,此XML 请求中并不需要指 38 定详细的系统和操作系统配置,因为SOI 将自动验证可用的J2EE 应用程序服务器平台并以SOI 中的 可用选项进行回应。这可能基于使用指定jAppServer SPEC 基准和可用的操作系统和可用性的专用 Xeon 服务器或共享的Itanium 24 路服务器。J2EE 应用程序可根据资源的可用性和成本选择一个选 项。SOI 将跨计算、网络和存储资源维护配置上下文,并封装来自业务应用程序的信息。这仅仅是资 源性能指标的一个起点。当前的SPEC 基准指标还需要进行大量改进和扩展才能完成SOI 的最终目 标。 除了上述基础架构管理器,计算资源本身的许多关键硬件和软件功能都允许实现SOI 服务。  资产标识符资产标识符资产标识符资产标识符::::提供一种可靠的方式远程唯一地标识附加到网络的物理资源并提供相关目录。这 就允许企业管理控制台发现和计算连接到公司网络的所有IT 资源,包括无线设备。  带外带外带外带外((((OOB))))可访问性可访问性可访问性可访问性::::允许网络访问平台管理功能,即使平台因为尚未加载操作系统或应用 程序软件或者由于软件bug 、系统故障、恶意攻击或其他问题而无法工作。这不会要求另外提 供网络电缆,但在平台本身内提供了替代路径和智能。此功能允许远程“逻辑”供应,重新加 载损坏的软件、运行远程诊断、远程重新配置以及其他的许多功能。  服务处理器服务处理器服务处理器服务处理器::::和OOB 功能一样,即便尚未为主要的平台处理器提供软件或者该处理器还无法正 常工作,专用的管理服务处理器也能够支持功能。一个分离的服务处理器还允许在任何平台系 统状态下提供更有效的监控、故障检测和诊断功能。它还允许平台执行自动功能(如周期性自 由检测和诊断功能)、自动硬件和软件配置发现和报告以及自我修复操作(例如将其自身从网 络中隔离开来以及在删除病毒时发出警报)。 为了在组成面向服务的企业的硬件和软件组件之间提供互操作性,SOI 必须基于定义公共功能、数据 结构和界面的开放业界标准。 2.3.7.1 面向服务的基础架构(SOI)的业务价值 SOI 为企业提供了一些基本优点。它为IT 自动化提供了更好的基础,从而能够提高IT 生产力并降低操 作成本。SOI 还能够从静态的“一个应用程序一个框”的方法改为动态的资源收集,根据需要为应用 程序分配虚拟处理、存储和网络资源。这样就可以通过提供更好的资源利用率降低资本成本。还可 以得到更高的可靠性,并减少服务宕机和延迟,因为不需干涉应用程序即可将其故障转移到可用的 资源。IT 可提供更一致的服务水平,因为随着应用程序工作负载的增加软件可以实时自动分配附加 资源。 就长期而言,更重要的是SOI 对排除“复杂性障碍”的贡献,这种障碍可以限制设计和实现新信息支 持的业务流程的组织能力。SOI 就位后,业务可以重新分配IT 开销方面的资金,用于可创建真实的业 务差异性的新的创新性系统。例如,SOI 可帮助企业在数据可用时实时地完全利用自动数据源(如 RFID 或eForms )。在公司防火墙内部和外部,SOI 增强了实现和管理事件驱动的、基于消息的服务 和应用程序的能力。更好地管理移动无线设备使得业务能够将服务分布在网络边缘,使得员工能够 提高生产力,并可以为移动客户提供增值服务。SOI 还能提供更好的业务可靠性,例如,在精确减值 计划的IT 资产储存库的领域改进Sarbanes-Oxley 遵从性,以及提供及时的软件版本和许可证管理。 这些都是高性能功能:通过使用自动IT 资产储存库技术,一个高科技公司在五个季度内可以节省 40,000 小时的人力资源。 从纯IT 管理的角度来看,SOI 提供了许多优点:  降低操作工作负载,通过降低硬件和软件的手动配置可达到这个目的。  高生产力,通过从单个标准化管理控制台执行企业级平台、网络、数据和应用程序管理可达到 这个目的。  更好的资源利用率,降低资本支出以实现IT 目标。  更好的灵活性,通过动态资源分配以及关注核心竞争力和跨防火墙将商品IT 服务(如公司电子 39 邮件)移动到第三方提供商的选项可达到这个目标。SOI 跨防火墙进行操作的能力意味着IT 可以 一致地管理服务,无论这些服务是来自公司内部还是通过telco 或ISP 连接性外包给外部提供商。  简单和成本有效的升级,来自模块化的松耦合SOI 架构。这允许IT 刷新其基础架构以利用新技术, 而排除由硬件实现管理依赖项导致的复杂性。这就消除了令人痛苦的“删除并替换”(“forklift ”) 升级,允许IT对于快速而优美的改变进行相应,减少导致IT由于预期中断而拒绝并入新技术的 惯性。  支持随需应变的使用模型,允许通过“使用付费”的退款方法使得成本与利益更准确地对应。  支持管理所有客户机平台,从台式机到手持移动设备,作为具有公共平台功能和访问界面的基 础架构的主要部分。 开发人员还可以从面向服务的基础架构的演变中直接获益:  SOI 从应用程序代码中删除了资源管理和安全责任。通过自上而下、自内而外、标准的一致的 方式,基础架构管理协议确保将这些功能包含在启用了Web 服务的硬件、SOI 中间件和应用程 序构建块的架构中。开发人员不需要作出总是一成不变的假设,也不需要在应用程序中嵌入逻 辑,而只需要指定虚拟应用程序要求。然后他们就可以依靠SOI 来确保动态满足这些要求。  开发人员可以将预先构建的服务用于分布式的、实时的、事件驱动的多平台应用程序,因为架 构中已经包含了这些元素以便使其与标准化SOI 一致并运用它。由于开发人员可以方便地重用 为其他服务和应用程序构建的组件,因此他们能够更快速地构建和修改应用程序,从而可以提 供更多的新方法和业务价值。  开发人员可以更有效地在异构环境中工作,包括跨企业的Internet/Web 应用程序,因为他们使 用基于Web 的、面向服务的和虚拟化的构建块,意味着他们符合产业标准功能和界面 2.3.8 将将将将 SOA 参考架构映射到企业参考架构映射到企业参考架构映射到企业参考架构映射到企业 SOA 成熟度模型成熟度模型成熟度模型成熟度模型 下图表示采用SOA 的常见模式。每个IT 组织都应该使用适合其特定需要的方式引入技术组件。 40 图24 :将SOA 参考架构映射到企业SOA 成熟度模型 SOA 专业人员指南专业人员指南专业人员指南专业人员指南 第第第第3部分部分部分部分 服务生命周期简介服务生命周期简介服务生命周期简介服务生命周期简介 作者:Surekha Durvasula 参与本书参与本书参与本书参与本书的的的的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,首席电子商务架构师 审校审校审校审校人员人员人员人员 Prasanna Deshmukh ,WebEx Communications ,架构主管 Noam Fraenkel ,Mercury Interactive ,首席IT 技术官 Steve Jones ,Capgemini Group 的,Application Development Transformation 部门,首席技术官 Brenda Michelson ,Elemental Links, Inc. ,首席顾问及分析师 Ashok Nair ,关于EAI 和信息技术服务的管理系统分析师,卡尔加里城 George Paolini ,Georgepaolini.com ,顾问 Jeff Pendelton ,SOA Alliance ,执行主管 Annie Shum ,BEA,SOA 战略副总裁 作者十分感谢为本文档做出贡献的组织和个人,他们撰写了部分文档,进行了大量编辑工作,还帮 助审校了文档并提供反馈。此外,作者还要特别感谢BEA Systems, Inc. ,是这个公司提供了本文档 中的开发和演示所需的基础架构和平台。 目目目目 录录录录 1 关于本文档...................................................................................................................................6 1.1 摘要............................................................................................................................................6 1.2 目标受众....................................................................................................................................6 1.3 《SOA 专业人员指南》的优点.................................................................................................6 1.4 SOA 专业人员指南:部分 .........................................................................................................7 2 服务生命周期简介........................................................................................................................7 2.1 简介............................................................................................................................................7 2.2 定义............................................................................................................................................7 2.3 服务生命周期治理.....................................................................................................................9 2.3.1 需求和分析 ...........................................................................................................................10 2.3.2 设计.......................................................................................................................................10 2.3.3 服务开发 ...............................................................................................................................11 2.3.4 IT 操作团队............................................................................................................................11 2.3.5 业务仪表板 ...........................................................................................................................11 3 服务生命周期阶段......................................................................................................................11 3.1 需求和分析 ..............................................................................................................................12 3.1.1 参与人员 ...............................................................................................................................12 3.1.2 使用的工具 ...........................................................................................................................12 3.1.3 工件(可交付对象) ............................................................................................................12 3.1.3.1 工件描述 ............................................................................................................................12 3.1.4 服务生命周期阶段的关键考虑事项 .....................................................................................13 3.1.4.1 业务动机 ............................................................................................................................13 3.1.4.2 业务生命周期的差异 .........................................................................................................13 3.1.5 服务生命周期阶段的建议的流程.........................................................................................13 3.1.5.1 项目初始化请求.................................................................................................................13 3.1.5.2 工作的架构声明.................................................................................................................13 3.1.6 最佳实践和需求....................................................................................................................13 3.1.6.1 组合管理 ............................................................................................................................13 3.1.6.2 需求捕获 ............................................................................................................................14 3.1.6.3 用户体验模拟.....................................................................................................................14 3.1.6.4 业务流程建模.....................................................................................................................15 3.1.6.5 SOA 储存库.........................................................................................................................16 3.2 复合应用程序设计...................................................................................................................17 3.2.1 参与人员 ...............................................................................................................................17 3.2.2 使用的工具 ...........................................................................................................................17 3.2.3 工件(可交付对象) ............................................................................................................17 3.2.3.1 工件描述 ............................................................................................................................17 3.2.4 服务生命周期阶段的关键考虑事项 .....................................................................................18 3.2.4.1 企业架构框架.....................................................................................................................18 3.2.4.2 服务分类框架.....................................................................................................................18 3.2.4.3 服务粒度 ............................................................................................................................18 3.2.4.4 重用策略 ............................................................................................................................18 3.2.5 服务生命周期阶段的建议的流程.........................................................................................19 3.2.6 最佳实践和要求....................................................................................................................19 3.2.6.1 服务编排(建模).............................................................................................................19 3.2.6.2 服务组合 ............................................................................................................................19 3.2.6.3 SOA 储存库.........................................................................................................................21 3.2.6.4 服务注册表.........................................................................................................................21 3.2.6.5 信息建模 ............................................................................................................................21 3.2.6.6 应用程序建模.....................................................................................................................22 3.3 服务开发..................................................................................................................................22 3.3.1 参与人员 ...............................................................................................................................22 3.3.2 使用的工具 ...........................................................................................................................22 3.3.3 工件(可交付对象) ...........................................................................................................22 3.3.3.1 工件描述 ............................................................................................................................23 3.3.4 服务生命周期阶段的关键考虑事项 ....................................................................................23 3.3.5 服务生命周期阶段的建议的流程 ........................................................................................23 3.3.6 最佳实践和需求....................................................................................................................24 3.3.6.1 开发工具 ............................................................................................................................24 3.3.6.2 测试工具 ............................................................................................................................24 3.3.6.3 SOA 储存库.........................................................................................................................25 3.4 IT 操作团队 ..............................................................................................................................25 3.4.1 参与人员 ...............................................................................................................................25 3.4.2 使用的工具 ...........................................................................................................................25 3.4.3 工件(可交付对象) ...........................................................................................................25 3.4.3.1 工件描述 ............................................................................................................................25 3.4.4 服务生命周期阶段的关键考虑事项 ....................................................................................26 3.4.4.1 服务部署 ............................................................................................................................26 3.4.4.2 服务管理和监控.................................................................................................................26 3.4.5 服务生命周期阶段的建议的流程 ........................................................................................26 3.4.6 最佳实践和需求....................................................................................................................27 3.4.6.1 版本管理工具.....................................................................................................................27 3.4.6.2 部署工具 ............................................................................................................................27 3.4.6.3 企业管理系统.....................................................................................................................27 3.4.6.4 SOA 储存库.........................................................................................................................28 3.5 业务仪表板 ..............................................................................................................................28 3.5.1 参与人员 ...............................................................................................................................28 3.5.2 使用的工具 ...........................................................................................................................28 3.5.3 工件(可交付对象) ...........................................................................................................29 3.5.3.1 工件描述 ............................................................................................................................29 3.5.4 服务生命周期阶段的关键考虑事项 ....................................................................................29 3.5.5 服务生命周期阶段的建议的流程 ........................................................................................29 3.5.6 最佳实践和要求....................................................................................................................30 3.5.6.1 业务智能 ............................................................................................................................30 3.5.6.2 门户....................................................................................................................................30 3.5.6.3 IT 服务的服务质量监控指标和服务 SLA 需要的相互关系..............................................30 4 附录 ............................................................................................................................................30 4.1 IT 涉众......................................................................................................................................30 4.1.1 IT“董事会”.............................................................................................................................31 4.1.2 首席信息官 ...........................................................................................................................31 4.1.3 程序管理办公室(PMO)....................................................................................................31 4.1.4 业务发起人 ...........................................................................................................................31 4.1.5 项目团队 ...............................................................................................................................31 4.1.6 架构师...................................................................................................................................31 4.1.6.1 企业架构师.........................................................................................................................31 4.1.6.2 项目架构师.........................................................................................................................32 4.1.6.3 信息/数据架构师................................................................................................................32 4.1.7 业务分析师 ...........................................................................................................................32 4.1.8 架构筹划指导委员会 ...........................................................................................................32 4.1.9 IT 操作团队............................................................................................................................32 4.1.10 业务操作团队......................................................................................................................32 4.1.11 首席技术官(CTO) ..........................................................................................................32 4.1.12 企业共享服务团队..............................................................................................................32 4.1.13 首席流程官(CPO) ..........................................................................................................33 4.1.14 首席安全官(CSO) ..........................................................................................................33 4.1.15 项目经理 .............................................................................................................................33 4.1.16 应用程序支持团队..............................................................................................................33 4.2 SOA 治理和组织.......................................................................................................................33 4.2.1 SOA 开发组织........................................................................................................................33 4.2.1.1 简介....................................................................................................................................33 4.2.1.2 传统开发方法.....................................................................................................................33 4.2.1.3 建议的方法.........................................................................................................................35 4.2.1.4 摘要....................................................................................................................................36 4.2.2 企业架构:角色和责任........................................................................................................36 4.2.2.1 任务声明 ............................................................................................................................36 4.2.2.2 企业架构责任.....................................................................................................................36 4.2.3 IT 企业资源管理流程 ............................................................................................................37 4.2.4 项目初始化请求格式 ...........................................................................................................38 4.2.5 请求架构工作........................................................................................................................39 4.3 简化的公共词汇......................................................................................................................41 4.4 相关 SOA 标准.........................................................................................................................42 4.5 服务组件架构和服务日期对象 ...............................................................................................42 4.5.1 SCA 扩展 ...............................................................................................................................43 4.6 Java 业务集成 ...........................................................................................................................43 4.7 传统数据移动技术 ..................................................................................................................43 4.7.1 电子数据交换(EDI)..........................................................................................................43 4.7.2 提取、转换和加载(ETL).................................................................................................44 4.8 推荐的读物 ..............................................................................................................................45 4.8.1 架构框架 ...............................................................................................................................45 4.8.2 关联标准 ...............................................................................................................................45 4.8.3 行业论坛 ...............................................................................................................................46 4.8.4 关注 SOA 的分析师网站 ......................................................................................................46 4.8.5 模板.......................................................................................................................................46 1 关于本文档关于本文档关于本文档关于本文档 1.1 摘要摘要摘要摘要 SOA是一门相对较新的技术,所以很多致力于实现它的公司无法获得良好的实践专业指导。如果没有 基于共同经历的通用语言和行业词汇,SOA技术很可能最终只会为IT基础架构带来更多自定义逻辑并 提高其复杂度,而无法实现其提供企业内和企业间服务重用和流程互操作性的承诺目标。为了帮助 开发共享语言和有关SOA的知识集,一群SOA专业人员创建了《SOA专业人员指南》这个文档系列。在 这个文档系列中,这些SOA专家描述并评注了一些与SOA相关的最佳实践和关键知识,以帮助其他公 司迎接SOA的挑战。他们对《SOA 专业人员指南》的期望是,这个分为多个部分的知识集在出版之后, 能够作为所有SOA相关人员的标准参考百科全书。 1.2 目标受众目标受众目标受众目标受众 本文档的目标受众为:  需要跨企业/LOB 启动和管理SOA 战略的业务和IT 领导  需要促进实现SOA 计划的理想和路线图以及其中包含的每个实现的架构的企业架构师  需要管理SOA 整体业务战略中的子项目组合的程序管理员  需要映射依赖关系并开发满足业务期望的时间线的项目团队成员  为业务和IT 提供新业务能力的解决方案和工具的供应商  需要更好地了解业务和IT 计划如何利用技术实现其目标的用例的标准机构。 1.3 《《《《SOA 专业人员指南专业人员指南专业人员指南专业人员指南》》》》的优点的优点的优点的优点 本文档可帮助读者:  向他人学习:很早就开始使用SOA 的用户可共享其有关跨行业采用SOA 的最佳实践、看法以及 观点  比较替代产品:识别和定义SOA 的关键技术组件,建立对选项比较的基线参考  改进合作:使用一种通用语言澄清本文档中定义的SOA 组件的性质  加速实现:本指南定义了其服务生命周期和需求、建议的工具以及每个阶段的最佳实践。  了解标准的价值:本文档建议了用于SOA 的各个方面的标准  避免潜在风险:本指南指出了供应商社区尚未指出的一些问题领域。 1.4 SOA 专业人员指南专业人员指南专业人员指南专业人员指南::::部分部分部分部分 《SOA 专业人员指南》包含三个单独的章节。 第1部分(《为何使用面向服务的架构?》)提供了一个SOA 高级摘要。 第2章《SOA 参考架构》提供企业级SOA 实现的工作设计,包括详细的架构图、组件描述、详细要 求、设计模式、有关标准的观点、法规遵从性模式、标准模板以及成员的潜在代码资产。 本文档是第3章,标题为《服务生命周期简介》,它提供了在整个服务生命周期(从项目初期到完成 或重新定位服务)中提供服务管理的详细过程。该文档还包含一个附录,其中包含组织和治理最佳 实践、模板、对关键SOA 标准的评论以及建议的到详细信息的链接。 2 服务生命周期简介服务生命周期简介服务生命周期简介服务生命周期简介 2.1 简介简介简介简介 根据SOA 参考架构建立架构基线后,专业人员就可以审查服务生命周期。本节简要描述服务生命周 期,并标识与其生命周期的每个阶段关联的操作人员、潜在工具和工件。本文档不会介绍要想成功 地使用SOA 所需的全部文化、治理和组织更改;相反,本文关注为服务生命周期定义最佳实践。服 务生命周期属于SOA 生命周期中的执行阶段,如下图所示。 图1:SOA 生命周期 2.2 定义定义定义定义 服务生命周期从项目初期(定义)开始,到完成(退出或者重新确定目标)时结束。服务生命周期 允许跨三个阶段的服务治理:要求和分析、设计和开发,以及IT 操作。 图2:服务生命周期的三个阶段 上图演示了服务生命周期的三个阶段,并说明了要启用服务治理需要企业服务储存库。  需求需求需求需求和分析和分析和分析和分析::::业务开始要标识业务需求并确定业务需求的优先级。根据标识的优先级,非技术 人员可以与业务分析师紧密协作,以记录业务流程、规则和需求。高级需求包括:  从级别0开始向下可视化映射业务流程  定义每个业务流程  标识每个流程的业务所有者  标识目标和当前业务服务的差异  映射输入和输出数据元素  确定业务流程和业务服务的优先级  捕获业务服务定义的所有方面  模拟用户界面和/或业务流程。  设计和开发设计和开发设计和开发设计和开发::::在设计阶段,业务分析师与架构师紧密协作,转换业务需求。架构师负责高级估 计、设计并移交给开发团队。开发团队负责开发、装配、测试复合应用程序,并将其移交给IT 操作团队。下面是一些高级设计需求:  审查需求并标识每个业务流程的备选方案  设计和估计每个服务的组件,例如门户、集成、基础架构、数据、策略和业务(逻辑)服 务  标识业务服务的重用机会  开发和执行详细的项目计划  跟踪和报告业务和IT 管理的进展  在提交每个业务服务时获得业务的签收。  IT 操作团队操作团队操作团队操作团队::::此团队负责测试环境、分级(staging)环境和生产环境,其中生产环境具有最高的 优先级。IT 操作团队负责调整网络和数据中心的大小。此外,IT 操作团队还负责部署和监控IT 支持的所有应用程序,并为其提供第1层支持。下面是一些高级需求:  审查要求并标识基础架构需要  建立系统环境,包括开发、系统集成测试、性能测试、用户验收和生产环境  帮助解决方案开发团队进行系统和应用程序配置、定期构建和容量计划  跟踪和管理服务和资产之间的依赖关系  部署和管理生产环境中的业务服务  根据业务优先级为业务服务提供应用程序支持 每个阶段的详细信息在本节的后面部分提供。下面是一些用于为业务提供复合应用程序的高级IT 流 程。 图3:提供业务复合应用程序的IT 流程 此流程还标识三个组织中的每一个在提供业务应用程序方面的角色。 2.3 服务生命周期治理服务生命周期治理服务生命周期治理服务生命周期治理 治理是要实现SOA 必须提供的一组流程、工具和组织结构。只有当组织在整个服务生命周期中坚持 遵循标准并且遵循正确的过程时才能有效重用服务。服务是在应用程序之间共享的,因此组织必须 谨慎地设计、开发和部署服务才能确保不影响服务的现有消费者。 存在优先级冲突的各种组织silo 之间共享服务。有效的治理可帮助确保实现最大程度的复用性并使中 断降到最少。SOA 治理功能的主要责任是:  发布SOA 标准和最佳实践  定义和执行流程以便在项目级别改进服务的使用和重用  管理企业或LOB 的所有共享服务  跨组织传播标准和最佳实践  在组织内宣传SOA 的成绩 服务治理是整个服务生命周期的基础。 图4:服务生命周期治理 上图演示高级别的服务生命周期,并观察下面的阶段。 2.3.1 需求需求需求需求和分析和分析和分析和分析 业务分析师需要分析业务以捕获业务需求,以业务流程的形式更可取。对于最初的SOA 项目,团队 通常关注非企业级或LOB 级业务流程,但仅限于领导团队在批准项目资金时标识的范围。团队捕获 正在交付的复合应用程序的业务逻辑。 一旦团队捕获了业务流程,业务分析师就可以标识跨企业或LOB 的所有流程副本。业务分析师为团 队可以重用的业务流程搜索SOA 储存库。一旦完成了此阶段,业务分析师就可以将工件上传到SOA 储存库,来依次触发治理流程。 该治理流程应该特定于该组织和项目。在得到所有批准(尤其是业务所有者的批准)前,团队不应 认为此阶段已经完成。 2.3.2 设计设计设计设计 业务分析师应将需求和业务流程传递给架构师来设计应用程序。每个IT 组织通常都具有自己的应用 程序设计方法和框架。 在此阶段,架构师标识服务及其实现。然后架构师会搜索SOA 储存库以进行再次使用。架构师不需 要将搜索限制于生产环境中当前部署的服务;搜索应该扩展到其他团队目前正在开发的服务。 在此流程的最后,架构师可能已经标识了产品中已经部署的可以进行重用的服务、需要进行修改以 创建新版本的服务、需要进行开发的服务以及需要退出的服务。 架构师将所有设计工件上传到SOA 储存库,触发得到了企业架构审查委员会、项目经理和操作团队 的批准的治理流程。项目经理还应该使用这些信息分配服务开发任务。 2.3.3 服务开发服务开发服务开发服务开发 架构师最好是从SOA 储存库将设计详细信息发送给开发团队。开发团队可能在地理上分散分布,每 个团队都可能有业务或产品领域的专家。 开发团队以迭代方式开发和测试复合应用程序,并将工件上传到企业服务储存库。当开发团队指示 准备好部署服务时,他们就会触发治理流程。 2.3.4 IT 操作团队操作团队操作团队操作团队 此团队通常负责提供开发环境、QA环境、分级(staging)环境和生产环境。当服务开发组织从架构 师处接收到设计详细信息时,IT 操作团队就会建立开发环境。IT 操作团队通常还要管理QA 环境,因 为此环境与生产环境是相同的。 开发团队通常为操作团队提供基础。对于由服务组成的复合应用程序,开发团队为IT 操作团队提供 服务装配。建议的最佳实践是根据SOA 储存库中的信息装配服务。 一旦IT 操作团队装配了服务,团队就会将这些服务部署到目标节点。业务分析师和架构师应该在初 期阶段定义了业务、安全和管理策略。现在IT 操作团队需要负责监控并提供业务指标以跟踪业务KPI 以及审查IT-SLA。建议的最佳实践是让IT 操作团队将产品实例(包括硬件、节点名称、产品版本和 应用程序版本)映射回SOA 储存库。 2.3.5 业务仪表板业务仪表板业务仪表板业务仪表板 业务可能想要查看各种不同类型的信息,包括通过监控系统、操作数据存储和BPM 工具得到的数据。 这些信息分为如下几个类别:  IT-SLA  业务活动监控  策略管理  服务成熟度模型(监控服务生命周期的指标,以及企业服务储存库的一个可搜索属性)。 3 服务生命周期阶段服务生命周期阶段服务生命周期阶段服务生命周期阶段 本节标识参与人员、使用的工具、可交付对象、生命周期阶段建议、生命周期阶段流程、最终用户 工具描述以及服务生命周期的各个阶段的最佳实践。 3.1 需求需求需求需求和分析和分析和分析和分析 3.1.1 参与人员参与人员参与人员参与人员  业务工作人员(通常是来自LOB 的业务操作团队)  项目经理(业务和IT)  业务分析师  架构师(可选) 3.1.2 使用的工具使用的工具使用的工具使用的工具  业务需求工具包括办公室、业务流程建模工具和需求捕获工具  业务流程建模工具包括BPMN、Visio 和Pro*Activity  业务规则工具包括产品规则引擎和Word  用户界面工具包括门户模拟工具、Macromedia 、Visual Studio 、Eclipse ,以及JSP 和HTML 编 辑器 3.1.3 工件工件工件工件((((可交付对象可交付对象可交付对象可交付对象))))  设计模型,如UML、BPM(业务流程模型),数据流模型  绑定,例如JMS、RMI、IIOP 和HTTP(s) 3.1.3.1 工件描述 每个LOB 都定义了自己的业务流程,业务流程是在服务生命周期的这个阶段捕获的。有些LOB 可能 有类似的流程或者稍有差异的子流程。例如,消费贷款部和抵押贷款部可以是在大型企业中具有公 共业务流程的两个单独的LOB。这两个LOB 都可以通过记录并共享他们的业务流程和关键知识中受 益。 LOB 可能还可以运行模拟以优化业务流程,也可以使用监控和管理系统捕获和比较实际的和模拟的 结果。业务活动监控器提供了比较业务结果与已制定目标的仪表板。 较低级别的业务流程定义通常可用于开发复合应用程序。在这个级别,服务要被标识出来并映射到 每个业务服务(活动)。SOA 储存库是所有这些服务定义和依赖关系以及外部消耗的记录系统(均 为外部使用),并帮助IT 操作团队部署、监控和管理服务。 3.1.4 服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项 下面是在服务生命周期需求和分析阶段业务应该关注的一些关键考虑事项。 3.1.4.1 业务动机 记录业务动机可帮助将业务流程映射到服务。这允许业务和IT 就如何开发服务组合以及相关资金计 划进行富有成效的对话。这种映射有助于为服务开发的资金筹集制作业务案例,因为这可以帮助业 务了解服务如何从中获益。 3.1.4.2 业务生命周期的差异 即使服务生命周期是迭代的,它还是与应用程序生命周期相似。不过,服务生命周期的一个最佳实 践是标识可能提供要求的功能的现有服务。设计人员首先审查现有服务,查看其是否适用;这可增 加现有服务的重用并节约时间。 3.1.5 服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程 下面是启动项目的一些建议的模板业务。 3.1.5.1 项目初始化请求 业务使用此模板为项目提交请求。在这个阶段,项目的业务发起人评估项目是否可行,并联系LOB-IT 或PMO 以帮助完成此工作。 3.1.5.2 工作的架构声明 一旦业务将PIR 提交到LOB-IT 或PMO,IT 领导团队就会让业务参与进去,评估其是否满足所有初始 条件。然后IT 组织可以建立一个包括项目经理、业务分析师和架构师的项目团队来处理业务以估算 需要的工作量。根据业务优先级情况,团队可能专职进行估算,也可能不是这样。 3.1.6 最佳实践和最佳实践和最佳实践和最佳实践和需求需求需求需求 只要项目资金到位,并且组织好核心团队,此阶段就会开始。下面是服务生命周期此阶段的高级别 最佳实践和要求。 3.1.6.1 组合管理 业务和IT 共同利用组合管理工具管理SOA 项目的组合。这些工具允许业务用户提交自己的项目请求。 工具将请求映射到IT 治理模型,并帮助IT 管理应用程序、集成、数据中心和网络。根据IT 组织的特定 工具和目标,工具还可用于资源计划、技能映射和监控项目资金。 组合管理软件可通过将业务战略转换为高级别业务优先级计划帮助IT 定义与业务紧密对应的路线 图。然后IT 组织就可以执行此计划,同时进行监控以确保不存在任何偏差。此类工具支持的功能包 括:  将所有项目映射到原始业务案例以帮助确保与业务目标对应。  留意单个储存库(不同于SOA 储存库)中的所有这些资产,并能够突出重复的业务逻辑、依赖 关系和资源约束  映射所有依赖关系,并能够在更改违反了业务规则时发送警报  管理所有更改请求和错误跟踪,包括对其他项目的影响  将任务和项目导出到第三方工具,例如企业服务储存库、项目管理和开发工具。 通常只有大型IT 组织才要求组合管理工具,因为许可和管理开销成本与这样的工具有关。此工具的 单个实例可用于整个企业或特定LOB,除非法规要求IT 组织部署此类工具的多个实例。利用此类工 具的最大挑战在于鼓励采用;IT 领导团队需要对此类工具的使用进行强制执行。 所有IT 组织的首要任务就是为管理项目请求记录并传达流程和生命周期。此任务通常是程序管理办 公室(PMO)或应用程序开发团队的责任。 启动此项目通常要完成两个步骤。业务管理者向IT 提交一个请求以启动一个项目,然后IT 与技术团 队协作估算项目所需的工作量。 根据估计,IT 董事会可能批准或拒绝该项目。如果批准,则会在项目经理的领导下组织一个团队, 以便为业务提供应用程序。最佳实践是使用此工具映射整个应用程序生命周期管理。 3.1.6.2 需求捕获 这些工具可帮助捕获所有业务需求,确定其优先顺序,并跟踪相关的开发工作。下面是这些工具应 该提供的一些功能:  为给定项目创建业务需求的储存库  为所有项目提供单个储存库  提供根据成本、资源和收益确定需求的优先级的功能  标识和跟踪跨项目的依赖关系  实施假设分析方案并提供影响分析报告  将所有者分配给需求和任务并跟踪状态。 业务分析师捕获这些信息时使用的是需求捕获工具还是类似Microsoft Office 的产品并不重要。重要 的是需求是使用业务术语捕获的,而不使用技术词汇,SQL 语句,或者打包的应用程序参考文献。 此 外,项目团队可根据业务功能对需求加以分类,并在不同的阶段批准这些需求。 3.1.6.3 用户体验模拟 有了基于文本的应用程序规范,业务人员在应用程序完成之前不需要查看和影响它。在这个阶段进 行更改会导致成本超出预期,面市时间延迟,并可能导致业务和IT 之间的劣质通信。原型(静态屏 幕图像或低保真度的编码线框)很难解决这样的问题,因为业务人员和最终用户必须“填平鸿沟” 才能提供应用程序的全部功能。原型通常要挤走本就十分珍贵的资源,从而导致成本增加和面市时 间延迟。 新工具可模拟所有业务应用程序的用户界面。这些工具提供了一个简单的拖放范例,可在开发前装 配丰富的、高保真度的应用程序模拟,包括业务逻辑和数据交互。这种模拟提供了最终产品的真实 “试验驾驶”,使业务人员和最终用户很容易理解。输出用于确定构建什么,排除混淆,削减成本 和提高用户采用率的可视化蓝图。最好的是,构建模拟时不需要任何IT 资源,而是可以由业务分析 师、用户体验设计人员、项目经理和架构师快速完成。 此类模拟工具可提供以下功能:  高保真度或低保真度的模拟屏幕的拖放组合  将数据和业务逻辑链接到模拟中的能力  基于团队的协作定义环境  在模拟环境中对需求的捕获和记录  对用户案例方案和工作流的内部支持  可重用的定义资产  将模拟封装到可通过电子邮件发送的文档中的能力。 人们只会使用易于使用的业务应用程序——至少应该比用户以前使用的应用程序更易使用。但团队 一般不会让最终用户测试应用程序,直到已经准备好进行部署。如果用户需要变更,就会导致代价 昂贵的后果。一种新的工具通过在开发前让可用性专家快速创建并与用户迭代地快速测试高保真度 模拟解决这个问题。 对于想要将可用性测试流程移动到软件开发生命周期(SDLC)流程前面的开发团队,目前的最佳实 践就是模拟。通过在定义应用程序的流程早期与业务分析师和开发人员紧密协作,团队可快速廉价 地修复许多与低可用性相关的常见问题。集中的用户体验团队可提供以下优点:  有关可用性和用户测试的标准化最佳实践  设计和开发团队中其他人员的教育背景、培训情况和指导关系  创建和维护反映公司的最佳实践的可重用模拟(定义)资产  SDLC 中的早期反馈和指导  流程指南,样式指南。 3.1.6.4 业务流程建模 BPM 工具用于在要求阶段捕获业务流程。该工具应该提供下面的功能:  业务流业务流业务流业务流程建模程建模程建模程建模::::业务用户的功能是方便地建模流程、定义业务规则和关键性能指标(KPI), 以及模拟、测试和开发端到端过程流。  业务活动监控业务活动监控业务活动监控业务活动监控::::实时和历史分析以及报告功能。实时流程监控、升级和管理可帮助快速标识业 务流程中的任何问题并帮助快速解决问题。  业务流程执行业务流程执行业务流程执行业务流程执行::::业务自动组件的执行。这包括编排所有资源(人员、组织、应用程序和系统) 以确保完美的执行和异常管理。 业务流程建模工具可在需求阶段帮助捕获业务流程。此工具通常由业务分析师基于BPMN 和UML 等 标准使用工具中提供的通用行业表示法建模业务流程。业务流程建模通常从级别0开始,此后会根据 需要对流程进一步定义以用于较低的级别。可以对业务流程建模,以便达到以下目标之一:  在致力于执行新流程的资源前,通过多个方案模拟新流程。例如,业务线要关注业务优化,因 为它正进入新的市场,推出新产品,或开始市场营销战役。  使IT 与业务更紧密地对应。在此情况下,业务流程建模工具帮助捕获并共享业务流程(可能甚 至是屏幕流)以帮助跨多个团队和地区构建讨论。 图5:业务流程建模 上图演示了需求阶段建模的一个典型的业务流程。业务分析师与业务进行交互,以捕获事件、手动 和自动活动以及业务规则。架构师可以作为观察员参与这些会议,以便更好地了解促进业务流程的 基本原理。 业务分析师与架构师进行交互,以便在分析阶段定义和改进下一个级别的详细信息。一旦业务分析 师和架构师对最低级别的业务流程进行了建模,使得业务能够在不涉及技术细节的情况下进行定义, 他们就可以合作审查企业服务储存库中的业务流程,以确定服务是已经存在还是需要进行构建。在 此流程中,BPM 工具可帮助他们:  以业务流程的形式捕获所有的业务需求,例如活动、规则和策略  模拟端到端业务流程以标识瓶颈并改进整体流程  全局审查业务流程并邀请其他LOB 参与这些讨论  捕获本地和地区需求  捕获手动和自动化流程。 3.1.6.5 SOA 储存库 这是一个允许跨所有产品自动化治理流程的储存库。它可以存储定义业务流程、需求和模拟参数的 所有相关产品元数据。此外,企业架构师还可以向此储存库上传包含模式和架构框架的企业标准文 档。SOA 储存库还应允许IT 和业务修改业务流程,以使二者的内部治理匹配。 3.2 复合应用程序设计复合应用程序设计复合应用程序设计复合应用程序设计 3.2.1 参与人员参与人员参与人员参与人员  项目经理(IT)  业务分析师  企业架构师  项目架构师  设计人员  技术领导或开发人员领导 3.2.2 使用的工具使用的工具使用的工具使用的工具  设计:Rational 、Together Architecture 、Eclipse 及其他 3.2.3 工件工件工件工件((((可交付对象可交付对象可交付对象可交付对象))))  设计模型:UML、SCA 服务装配模型及其他  绑定:JMS、RMI、IIOP、HTTP(s) 及其他 3.2.3.1 工件描述 服务生命周期的这个阶段生成表示系统流、数据流、企业数据模型(以实体关系图(ERD)的形式 表示)、应用程序设计(以UML 表示)、活动图和序列图的模型。在这个阶段,团队还生成高级别 部署模型,标识服务器、操作系统、中间件、数据库、防火墙和负载平衡器。 应用程序设计人员可能是架构师、技术领导或开发人员领导,他们可能会决定使用市场中的一些工 具。此工具通常基于RUP 或各种RUP,可能包含活动图、用例、类图、ERD 和部署模型。架构师可 以与团队共享这些工件以进行审查和批准,并可为开发团队提供指导。 3.2.4 服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项 3.2.4.1 企业架构框架 IT 组织应该将定义架构标准、开发流程、设计模式和工具的架构框架标准化。大多数IT 组织已经采 用标准应用程序生命周期管理流程中的一个,并对其进行修改以满足自己的需要。此外还存在许多 其他的著名架构框架,例如Zachman 、联邦企业架构(FEA)和开放组织架构框架(TOGAF)。IT 必须采用一种企业级架构框架才能成功实现SOA。 3.2.4.2 服务分类框架 服务分类框架可帮助为服务提供设计开发基础,为获得灵活性架构所必需。服务可以分类为多个类 别,如:  SOA 参考架构,包括共享数据服务、业务流程和门户服务  服务组合,包括询价到现金服务和抵押批准服务  LOB 服务,包括销售和支持服务。 标识了服务后,团队可根据定义的标准对其进行分类。分类可帮助业务经理、项目经理和开发团队 标识即将开发的服务以及开发目的。这样项目经理可以更容易地将开发任务分发给合适的团队。 3.2.4.3 服务粒度 服务粒度指抽象级别或者服务包含的功能。团队还可以将粒度的概念应用于服务本身或服务方法。 确定服务粒度时,架构师需要考虑性能需求。细粒度服务(例如Enterprise Java Bean ,EJB) 通常更容易了解和实现,因为许多情况下大多数工作都已经完成。不过,考虑到性能,对齐服务与 现有EJB 可能“不是”最优的解决方案。依赖多个请求和响应对的细粒度架构(“饶舌”协议)提供 的性能可能较低。为了降低网络延迟、系统I/O 和线程/进程等待状态的影响,最好创建一个在内部 组合多个业务域服务并且使用的消息较少的粗粒度服务。 服务粒度必须考虑到旧系统接口并未注意到(而且必需保持)新协议。架构师必须仔细地进行计划, 以避免在以Web 服务的形式添加新数据通道时更改旧系统。 最后,在确定粒度时,架构师必须考虑未来可能进行的更改对基础实现的影响。通常情况下,使用 粗粒度表面或模式来隐藏其中的细粒度服务对业务十分有用。这样做的目的是将服务与对基础实现 的更改隔离开来,方法是考虑到未来的扩展不影响客户的粒度级别进行设计。 3.2.4.4 重用策略 组件的重用始于设计层。架构师应该设计组件,以便使用组件的客户只需执行或继承完成给定任务 所需的方法。共享组件作为执行任务同时隐藏其复杂度的独立元素写入。架构师应该考虑使用表面 模式,因为它倾向于封装通用接口中的相关任务或类的每一个成员以使客户端代码可以交换使用这 些任务。因为任务通常编码为一个或少数几个隔离的方法,封装强调执行单个任务的方法重用。重 用单个任务比重用包含代码和数据的对象容易,后者可能需要执行多个任务。 3.2.5 服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程 此阶段在项目经理或业务分析师将要求移交给技术团队后立即开始。然后该团队开始复合应用程序 的设计,通常包括以下步骤: 1. 架构师从SCM/SOA 储存库下载需求,审查这些需求,并在必要时将其提交给业务分析师以获 得进一步说明 2. 架构师选择工具以对应用程序进行建模和设计 3. 架构师标识服务,还可能搜索SOA 储存库以标识潜在的重用 4. 架构师定义服务、实现、绑定和依赖关系 5. 一旦设计完成,架构师将所有设计工件上传到SOA 储存库以获得批准 6. 架构师审查委员会(由企业架构、项目架构师、业务分析师和项目经理组成)审查设计,以确 保架构能够满足业务要求,并且使其在整个企业内保持一致。 SOA 储存库应该提供根据企业架构师定义的模式为每个服务类别生成服务模板的功能。 3.2.6 最佳最佳最佳最佳实践和要求实践和要求实践和要求实践和要求 一旦复合应用程序的需求得到批准,此阶段就会开始。本节描述服务生命周期的这个阶段的高级别 最佳实践和需求。 3.2.6.1 服务编排(建模) 在服务生命周期的需求和分析阶段,团队应该以业务流程形式捕获所有要求,包括业务规则和策略。 这允许业务流程和服务级别的重用。大多数BPM 工具都提供了两种分离工具:一个由业务分析师用 来捕获需求的BPM 工具,以及一个用于架构师的服务编排建模工具。服务编排建模工具通常包括这 个BPM 工具,并允许架构师为每个业务服务或活动开发服务编排或流程模型。这些工具中的大多数 都生成代码或创建元数据以执行逻辑。 服务编排建模的最佳实践包括:  利用BPM 工具进行服务编排建模  采用用于建模(如BPMN)和编排(BPEL)的基于开放标准的工具  让业务分析师关注业务流程建模,让架构师关注服务编排建模  让架构师开发用于复合应用程序的服务编排模型,即便业务分析师尚未使用BPM 工具定义业务 要求  将所有服务编排模型上传到SOA 储存库。 3.2.6.2 服务组合 大多数领先的软件供应商都遵循一个名为服务组合架构(SCA)的新标准。SCA 标准定义服务、服 务依赖关系、服务实现、服务组合以及复合应用程序开发的部署和运行时方面。此外,开源项目正 在开发用于SCA 的Java 和C++ 运行时,例如Apache 的Tuscany 项目。 SCA 标准进行了如下定义:  如何通过字节码增强、依赖注入和面向方面编程的机制(AOP)自动生成基于元数据的代码  扩展注释的机制(控件框架)  用于Java “简单传统Java 对象(POJO)”、业务流程执行语言(BPEL)、Web 服务,以及.NET 或J2EE 组件的注释  服务的配置参数和部署选项  测量和监控服务的机制列表。 有关这个建议的标准的附加信息可在http://www.osoa.org 中找到 图6:服务组合架构 上图演示了高级别服务装配模型,其中应用程序由多个服务组合组成。服务组合由组件服务组成。 图7:服务组合架构 架构师可以使用多种工具组合服务。架构师需要下面的功能:  将每个服务映射到业务活动。这称为服务编排,是服务流程的最低的级别。  基于SCA 组合服务。架构师根据SCA 定义服务、实现、属性、接口和绑定。然后开发团队就可 以利用此服务模型开发和修改服务。  标识哪些业务规则应该具体化并嵌入到代码中以获得更好的性能。这仅仅适合相对静态的规则; 规则必须经常更改以便满足业务的需要。规则引擎应该根据规则参数精确地解释规则。  定义与每个服务关联的业务、管理和安全策略  标识和定义启用业务组审查其KPI 的测量指标。 3.2.6.3 SOA 储存库 SOA 储存库是所有企业元数据、服务定义和依赖关系的记录系统。架构师/设计人员使用的工具生 成的所有元数据都要上传到SOA 储存库。它提供消费者要求的信息以及IT 操作团队管理服务所需的 附加详细信息。储存库不仅定义从支持的角度来看监控服务时需要捕获的指标,而且提供供应商提 供的技术服务。这些技术服务可为业务用户提供触发如服务警报等事件的仪表板。 团队还可以使用SOA 储存库进行服务治理,以便支持将设计的工件提交给合适的审查人员进行批准 的流程。要得到所有批准后项目经理才会将任务分配给开发人员和IT 操作团队。 目前不存在用于储存库的标准,但多个供应商都具有能够管理SOA 元数据的储存库。存在多个可用 于完整企业元数据管理的“集中”储存库,但有些供应商还是只关注存储元数据的子集的SOA 储存 库,例如SCA 模型、BPEL、XPDL、JPD 和WSRP。 下面是SOA 储存库的一些最佳实践:  搜索SOA 储存库的潜在重用,包括业务流程、策略和服务  在标识服务进行重用前先审查SLA 和服务详细信息  将所有架构框架文档、企业和应用程序模型以及标准上传到SOA 储存库  定义SOA 储存库工作流,以便跨企业实施设计时和运行时治理  利用服务注册表(UDDI)将SOA 储存库与企业中的其他储存库集成起来。 3.2.6.4 服务注册表 服务注册表基于UDDI,是所有部署服务的记录系统。它包含的元数据包括服务定义、服务依赖关系 和服务接口。服务注册表现在已经扩展为可以充当储存库,虽然它们自身并不存储资产而更被运行 时元数据所关注,后者是SOA 储存库中元数据的子集。 服务注册表的最佳实践是搜索其中的服务的潜在重用,并在标识进行重用的服务前先审查SLA 和服 务详细信息。 3.2.6.5 信息建模 存在许多与信息建模相关的建模类型  参考数据建模  主要数据管理(如CDI 和PIM)  共享数据服务  在合适的情况下使用域标准(用于基于标准的服务负载的HR-XML、XBRL、ACORD、MDDL 和RIXML)。 IT 组织很少建模参考数据,常见的数据有国家或地区名称、州名和地区代码。不过,参考数据的部 分标准化可能要求跨企业提供一致的用户体验。 下面是一些用于信息建模的最佳实践  在系统、业务所有者和记录系统之间标识所有系统、数据流和属性,然后强制每个项目团队必 须更新此模型  在捕获业务要求的同时标识数据流  标识共享数据服务和主要数据实体,同时审查应用程序设计  为每个自定义应用程序开发ERD  在任何时候修改打包的或自定义应用程序时更新ERD。 有关主要数据管理和共享数据服务的信息,请参见《SOA 专业人员指南》的第2部分《SOA 参考架 构》。 3.2.6.6 应用程序建模 大多数团队都使用基于UML 的建模工具,以及允许架构师建模序列图、活动图、数据流、系统流和 网络图的工具。 打包的应用程序供应商提供了设计和建模其产品的功能,并且可能建议IT 组织采用与这些应用程序 关联的记录的最佳实践。 3.3 服务开发服务开发服务开发服务开发 3.3.1 参与人员参与人员参与人员参与人员  项目经理  架构师  开发团队  版本管理团队  IT 操作团队 3.3.2 使用的工具使用的工具使用的工具使用的工具  IDE (例如Visual Studio 、Eclipse 、JBuilder 、JDeveloper 和BEA Workshop )  打包的应用程序开发工具  回归和性能测试工具  构建工具(例如Maven 、Cruise Control 、ANT 和shell 脚本)  源控制管理系统 3.3.3 工件工件工件工件((((可交付对象可交付对象可交付对象可交付对象))))  源代码  用于配置和服务执行的产品特定的元数据  Java 文档  版本信息 3.3.3.1 工件描述 此阶段生成的工件包括服务定义、配置、合同和应用程序配置,以及服务、应用程序、部门和企业 级别的管理、安全和业务策略。应用程序配置还包括实现配置。 3.3.4 服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项 服务生命周期的此阶段的任务包括:  定义有关在何时外包服务开发的条件  在IT 使用新技术前执行技术审查流程  在服务开发前评估整个服务生命周期所需的技术  将每个服务映射回业务需求  评估现有服务以消除重复开发。 3.3.5 服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程 开发人员可在项目经理或架构师提供了设计文档后立即开始开发服务。这些文档可能是基于企业架 构标准的办公文档或模型。 开发人员也可以在业务或IT 操作团队打开变更请求(CR)后开始开发或修改服务。在这种情况下可 能不需要架构师。应用程序支持技术领导或开发人员将审查变更请求并进行变更。根据更改的级别 和IT PMO 流程,当开发人员将元数据变更上传到SOA 储存库后就会触发治理。 服务创建通常遵循下面的流程: 1. 应用程序设计或变更请求得到批准可以进行开发。 2. 对于新的开发,设计人员可能已经创建了服务模板并将其分配给了开发人员。开发人员下载服 务模板并完成模板。 3. 对于不存在模板的新开发,开发人员可以使用开发工具创建服务,或者在SOA 储存库中搜索类 似服务并将其作为模板复制。 4. 对于变更请求,开发人员应下载代码并进行修改。 5. 在所有这些情况下,开发人员还下载需求与设计工件进行审查,并在架构师、项目经理或业务 用户进行解释后进行修改。任何时候开发人员修改需求或设计工件时都会触发服务治理流程。 6. 如果架构师根据SCA 连接了服务,开发人员会利用基于SCA 的工具双击组件以确认创建了该服 务。 7. 如果创建的服务将用于其他团队开发的服务,则开发人员应该定义服务并开发和配置服务模拟。 服务生产商通过定义对示例请求的响应以及发布响应以供使用达到这个目的。这就允许使用服 务以便在实际开发服务前彻底检验合同。 8. 如果创建的服务要使用其他团队开发的服务,则开发人员可以利用其他团队生成的服务模拟。 9. 开发人员通过多种交互开发和测试服务。回归测试通常是端到端的,因此开发人员可以使用模 拟的测试环境进行单位级别的测试,也可以在不同的测试阶段之间移动服务。 10. 开发人员周期性地同步元数据与SOA 储存库。SOA 储存库在接受任何元数据前都需要进行验 证,需要时还会触发服务治理流程。 11. 开发人员生成与SOA 储存库同步的文档,例如Java 文档和版本信息。 这描述了传统的服务创建和维护流程。大多数软件供应商现在还为业务用户提供使用门户创建复合 应用程序的功能。业务用户可以通过松耦合的多种用户交互和交互流程以及根据服务定义动态创建 格式的方式来创建复合应用程序。业务用户可直接在生成过程中执行这里列出的大多数任务。使用 工具可开发、测试和部署服务,还可以将驱动这些复合应用程序的元数据与SOA 储存库同步。 3.3.6 最佳实践和最佳实践和最佳实践和最佳实践和需求需求需求需求 这些检查列表包括SOA 团队应该使用开发和测试工具中的哪些内容,以及如何利用SOA 储存库。 3.3.6.1 开发工具  基于标准  基于标准导入/导出元数据的能力  向后兼容性  来自供应商主要变更的提前通知  在任何合适的情况下根据模型生成代码的能力  集成的开发环境  方便地为配置提供工具以及运行配置的功能  调试功能  开发期间提示  基于注释和代码的文档生成(例如Javadoc )  与开发和测试架构的集成,例如:Junit 、Cactus 和SOA 框架组件  通过双击服务图标方便地创建、修改或审查服务  现有服务的独立于实现的服务组合模型。 3.3.6.2 测试工具  定义测试计划的能力  开发测试脚本、将其映射回测试计划以及为自动回归测试开发测试脚本的能力  为单位级别测试存储功能的功能  模拟服务的功能  回归和性能测试功能。 3.3.6.3 SOA 储存库  从SOA 储存库签入和签出元数据(SCM 是所有源代码的记录系统)  在每个开发里程碑的结尾将所有元数据上传到SOA 储存库  在各种开发阶段中利用SOA 储存库获得批准  利用SOA 储存库帮助进行重用、架构标准审查和设计模式采用。 3.4 IT 操作团队操作团队操作团队操作团队 3.4.1 参与人员参与人员参与人员参与人员  项目经理  架构师  版本管理团队  构建团队  IT 操作团队 3.4.2 使用的工具使用的工具使用的工具使用的工具 使用的工具包括产品部署工具(如Maven 、Cruise Control 、Ant 和shell 脚本)和基于IDE 的工具(例 如Eclipse 、Visual Studio 以及打包的应用程序部署工具)。 3.4.3 工件工件工件工件((((可交付对象可交付对象可交付对象可交付对象)))) 主要的可交付对象有产品域模型、打包的应用程序的配置、构建和服务依赖关系。 3.4.3.1 工件描述 此流程的主要输出是团队可用来装配每种服务的构建(如果需要),装配产品的所有元数据以及映 射运行服务的物理终点的URL 的产品域模型。各团队从逻辑模型(SCA)开发物理部署模型。一旦 团队装配了部署服务,就需要创建网络拓扑、服务器配置、服务配置,以及服务器和服务器资产管 理。此外,团队还需要创建运行时工件,例如用于今后的下行关联的监控和事件日志。 3.4.4 服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项 服务生命周期的这个阶段存在两个关键的考虑事项:服务部署以及服务管理和监控。 3.4.4.1 服务部署 复合应用程序包括可通过各种技术实现的服务或服务组合。版本管理要求服务级别的计划构建,还 要求提供为目标节点装配服务的功能。此外,IT 操作团队需要在装配和供应服务的的同时来组合修 改服务和实例配置参数的计划和流程。 IT 操作团队可能还需要一个服务装配管理服务来帮助管理各种构建、装配目标节点的服务以及管理 资产。市场上存在一些可以提供此功能的产品,但不幸的是并不存在任何有关服务打包或服务供应 的标准。这个领域可能需要SCA 标准解决。 3.4.4.2 服务管理和监控 服务管理和监控可细分为两个领域:  服务器管理服务器管理服务器管理服务器管理::::配置部署的服务和服务器实例,最好是使用通用的管理控制台。如果可能,最好 提供跨所有产品和所有供应商的一致性。  服务器监控服务器监控服务器监控服务器监控::::应用监控策略以捕获每个服务的要求的指标。此指标应该基于在服务生命周期的 需求和分析阶段定义的KPI 和管理策略。团队还需要收集和关联监控事件,以便确保遵循业务 服务级别协议(SLA),并将聚合的管理摘要信息发布到服务注册表和/或SOA 储存库。 3.4.5 服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程 此阶段在开发团队准备好处理性能集成测试、用户接受程度测试或性能测试,或者准备好将应用程 序部署到生产环境时开始。IT 操作应该遵循以下步骤: 1. 开发团队完成服务的开发和修改,并且使用模拟功能执行单位级别的测试和集成测试。 2. 开发团队标识服务,并将这些服务装配到准备好进行测试或到版本管理团队的部署的项目中。 3. 版本管理团队使用产品工具装配用于部署的版本。这会提示用户输入所有物理终点和应用程序 参数。在测试环境中,用户应该能够输入已经在QA 环境中运行的测试服务的URL,或者指向模 拟服务。服务准备好部署或生产后,用户就可以输入服务的URL。 4. 如果服务正在退出,团队会创建一个新的项目退出服务,然后以其为基础重新设计所有服务。 有些时候,并非所有依赖服务都在SOA 储存库中进行定义。下面是一个降低风险的流程。 a. 创建一个项目以重新设计和部署根据将要退出的服务的所有服务。 b. 使要退出的服务一直打开并运行,并监控以确认该服务未为其他服务使用。 c. 部署项目并创建新的项目以便退出旧服务。 5. IT 操作团队应使用部署工具装配部署的服务项目。 6. 一旦IT 操作团队将服务部署到生产环境中,团队就可以利用各种工具监控服务、应用程序、中 间件、操作系统、硬件和网络。 7. IT 操作负责使服务一直打开并运行。IT 操作团队将特殊应用问题导致的支持问题提交给应用程 序团队。 3.4.6 最佳实践和最佳实践和最佳实践和最佳实践和需求需求需求需求 当开发团队准备好将应用程序部署到QA、分级(staging)或生产环境时,他们可从了解服务生命 周期此阶段的这些高级别最佳实践和需求中获益。 3.4.6.1 版本管理工具  利用现有应用程序生命周期管理工具或源控制管理系统支持版本管理  利用开源工具(如ANT、Maven 或Cruise Control )进行定期构建  利用SOA 储存库进行服务治理  审查可帮助在单个服务级别构建和部署应用程序的新产品的市场  将版本管理团队集中在LOB 或企业级别  让版本管理团队从项目一开始即参与其中。 3.4.6.2 部署工具  利用现有部署工具和过程  搜索自动化应用程序服务配置和供应部署工具(如果IT 组织尚未具有此功能);企业管理系统 提供商可以提供这样的工具  利用部署工具跟踪对运行时环境的所有更改以满足遵从性要求  与程序管理办公室协调部署  使用部署工具将服务从一个网络拓扑重新装配到另一个网络拓扑。 3.4.6.3 企业管理系统 企业管理系统应该提供下面的功能:  应用程序管理  网络元素、操作系统、软件和修补程序的资产管理  业务服务管理  配置管理(服务和服务器)  监控  复合事件处理  关联引擎  自动操作  诊断和根源分析  统一控制台  业务仪表板  合同管理。 有关附加详细信息,请参见《SOA 参考架构》的“业务服务管理”部分。 3.4.6.4 SOA 储存库 组织应该利用其SOA 储存库的功能完成下面的操作:  管理网络拓扑  管理服务部署网络  为容量计划和网络拓扑开发审查服务依赖关系和SLA,以及CMDB  在每次部署结束后将所有元数据上传到SOA 储存库  在部署和管理阶段获得批准。 3.5 业务仪表板业务仪表板业务仪表板业务仪表板 3.5.1 参与人员参与人员参与人员参与人员  执行人员  业务操作团队  CIO 人员  LOB-IT 执行人员  业务分析师  项目经理  架构师  IT 操作团队 3.5.2 使用的工具使用的工具使用的工具使用的工具  数据集市  操作数据存储  业务智能工具  基于门户的仪表板 3.5.3 工件工件工件工件((((可交付对象可交付对象可交付对象可交付对象))))  星形模式与雪花模式  仪表板使用模型  记分卡指标定义  向上或向下分析规则和业务算法  用于审计和同步的数据血统和信息原点规则 3.5.3.1 工件描述 业务仪表板是共享的表示服务。工件捕获向上和向下分析业务规则所需的元数据。 CWM 是用于捕获数据仓库和数据市场的模型的元数据建模表示法和框架。XMI 是根据XML 标准构建 的建模交换表示法。同时,CWM 和XMI 都允许使用XML 跨多个供应商工具交换数据仓库和数据市场 模式中捕获的元数据,以便用于其他建模工具和基于EII 的服务。 该元数据储存库包括用于向上分析的业务规则以及用于派生指标的业务算法,以便用于大多数BI 工 具的语义转换层。这些指标形成了业务记分卡的基础,此记分卡报告关键业务驱动因素或价值链的 各个方面。业务仪表板将一个或多个记分卡组织在一起以便显示对业务驱动因素或价值链业务流程 的影响。例如,记分卡可以报告供应商关系的改进或者支持人员生产力的提高。单个仪表板可以并 入这两者以便监控客户满意度的业务驱动因素。此外,可能还存在一个有关重复销售的相关记分卡, 其中会记录客户满意度的增长。 大多数业务仪表板还提供向下分析的功能。BI 工具利用血统和信息来源路径提供更多有关记分卡的 某个方面的详细信息。 3.5.4 服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项服务生命周期阶段的关键考虑事项 构建业务仪表板要求标识放入其中的标准元数据和规则。基于仪表板的视图和记分卡会绑定到LOB 和用户角色,并且使用与用户角色链接的授权规则确保授权用户可以访问正确级别的信息。安全方 面、信息粒度和治理规则由SOX 定义,其他法规机构也可能影响仪表板设计。 仪表板设计人员需要进行计划以确保派生记分卡和指标虚拟化以及血统信息的精确度以提供精确的 向下分析功能。每个用户群可能都具有不同的向下分析需求,这些需求必须分解为可访问性和授权 级别规则。设计人员还必须确保粒度行级别数据始终能够备份向上分析数据和派生的信息。这支持 精确度和审计度。 3.5.5 服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程服务生命周期阶段的建议的流程 通常情况下,组织在一个或多个操作和分析服务已经可用并且已经与LOB 用户建立了信任时开发业 务仪表板。仪表板是一个用于归总所有记分卡并与影响实时报告的指标的价值链业务流程交互的复 合服务。有些向下分析可能会指向操作数据或操作数据存储。更数复杂的仪表板都会订阅实时业务 事件以提供每分钟更新的信息。业务仪表板可能还链接警报和异常报告服务,例如BAM 服务。 3.5.6 最佳实践和要求最佳实践和要求最佳实践和要求最佳实践和要求 3.5.6.1 业务智能 业务智能解决方案可能包括如下内容:  用于决策支持系统(DSS)的分析工具  警报引擎  业务事件分析  执行仪表板和业务记分卡。 3.5.6.2 门户 像JSR 168 portlet 和支持WSRP 的联合门户这样的技术可帮助嵌入或使用基于DSS 的分析视图和记 分卡。这些技术支持共享表示服务。 3.5.6.3 IT 服务的服务质量监控指标和服务 SLA 需要的相互关系 为了执行服务质量(QoS )的端到端监控和报告,组织需要将响应时间和可用性与服务周转时间的 SLA 相关的指标。换言之,服务合同规范必须考虑响应时间的服务运行时执行指标、可用性和性能 指标。 大多数组织最终都要以手动方式将业务流程和业务功能服务质量指标与SLA 期望和服务合同关联。 应用程序服务器实现和ESB 将服务质量指标报告到数据库中,以便映射回服务注册表或储存库中的 SLA。如果SLA 和运行时服务性能指标用XML 表示,则此映射可在数据库级别或者使用XQuery 完成。 要自动化此过程,组织需要使用通用语义语言和元数据指定SLA、服务质量和运行时性能指标。此 外,SLA 和运行时性能指标的捕获模式可能需要标准化,以便提供自动化的相互关系和映射。有了 这个级别的自动化映射,业务仪表板可以显示服务监控指标和SLA 的一个复合记分卡。这就允许业 务评估服务运行时影响服务周转时间的方式。 4 附录附录附录附录 4.1 IT 涉众涉众涉众涉众 对于公司内的各个人员,由于角色不同,对SOA 的定义也存在差异。这样,详细说明SOA 中可能涉 及的IT 涉众的角色就非常重要。 4.1.1 IT ““““董事会董事会董事会董事会”””” 和所有大型公司一样,IT 也需要一个“董事会”。此功能通常由关键执行人员或其代表执行。董事 会的目标是设定方向,批准计划和项目以及解决冲突。有些组织将这些董事会称为信息服务筹划指 导委员会(ISSC)、信息技术审查会员会(ITRB)或信息技术领导团体。 4.1.2 首席信息官首席信息官首席信息官首席信息官 CIO 负责IT 的所有方面。有些组织设置了多个向总CIO 报告的分部CIO。在有些组织内,分部CIO 具 有相当的自治权,但目前的趋势是将企业架构和企业共享服务团队整合至总CIO 的管辖之下,以便 快速采用SOA 并允许在整个企业内采用一致的方法。 4.1.3 程序管理办公室程序管理办公室程序管理办公室程序管理办公室((((PMO)))) PMO 负责跨企业或LOB 编排项目。它充当所有跨功能活动的联系人,并确保每个项目团队都遵循企 业架构师定义的标准流程。 4.1.4 业务发起人业务发起人业务发起人业务发起人 业务发起人在业务范围内支持应用程序,并最终负责确保成功采用项目。通常情况下,业务发起人 应该是公司的高级管理人员(副总裁或更高级的人员),通常负责确保业务转化的资金及其完成。 4.1.5 项目团队项目团队项目团队项目团队 项目团队的任务是提供业务功能。该团队开发用于提供功能的策略,并调查可用的选项。通常情况 下每个项目团队都有一个项目经理。项目管理责任通常由LOB 和IT 各推举一个人共同承担。 4.1.6 架构师架构师架构师架构师 架构师可分为多个类别。 4.1.6.1 企业架构师 企业架构师定义标准、流程和设计模式,并标识新的技术。 4.1.6.2 项目架构师 项目架构师设计业务解决方案或应用程序。 4.1.6.3 信息/数据架构师 信息或数据架构师确保在企业间处理信息和数据的一致方法和模型。 4.1.7 业务业务业务业务分析师分析师分析师分析师 业务分析师捕获业务需求、策略和规则。 4.1.8 架构筹划指导委员会架构筹划指导委员会架构筹划指导委员会架构筹划指导委员会 几乎每个项目或程序都具有一个筹划指导委员会。尤其是SOA 还需要负责企业架构的筹划指导委员 会。此委员会的成员包括IT 领导团队和来自业务操作团队的关键涉众。 4.1.9 IT 操作团队操作团队操作团队操作团队 IT 操作团队通常负责数据中心、安全、网络和第1层支持,使它们保持正常运行状态。此团队通常不 负责特殊应用的问题。 4.1.10 业务操作团队业务操作团队业务操作团队业务操作团队 业务操作团队定义和记录操作流程。该团队中的每个成员都负责业务的一个领域,例如,销售操作 团队确保对所有销售请求进行审查,并在条件合适时接受请求。 4.1.11 首席技术官首席技术官首席技术官首席技术官((((CTO)))) 有些组织中,CTO 负责IT 中的企业架构。CTO 也可充当CIO。 4.1.12 企业共享服务团队企业共享服务团队企业共享服务团队企业共享服务团队 企业共享服务团队为企业开发共享服务。有时候,这是专门的共享服务团队,有时候又是架构团队 的一部分,或者,有些时候每个项目团队都开发自己的共享服务。 4.1.13 首席流程官首席流程官首席流程官首席流程官((((CPO)))) CPO 通常与CIO 对应,他们可能向COO 或公司总裁报告,负责定义跨企业业务流程。 4.1.14 首席安全官首席安全官首席安全官首席安全官((((CSO)))) CSO 负责企业安全策略和实现。CSO 通常向CIO 报告。 4.1.15 项目经理项目经理项目经理项目经理 项目经理负责在一定的预算范围内按时交付项目。项目经理可能来自LOB,也可能来自IT。标准最 佳实践是让一个人负责项目交付,不过,更好的情况是公司让一个业务项目经理和一个IT 项目经理 共同负责交付项目。 4.1.16 应用程序支持团队应用程序支持团队应用程序支持团队应用程序支持团队 组织可以选择让专门的集中的团队、LOB 的应用程序支持团队、有开发人员承担应用程序支持角色 的永久性项目团队支持应用程序,也可以选择将应用程序支持外包。 4.2 SOA 治理和组织治理和组织治理和组织治理和组织 SOA 治理和组织最佳实践非常复杂。本节仅关注观察到的一些最佳实践。 4.2.1 SOA 开发组织开发组织开发组织开发组织 4.2.1.1 简介 最佳实践建议通过定义目标状态、开发路线图以及标识需要构建的组件和构建方式开发组织模型。 治理和组织最终将成为本练习的自然结果。 替代的方法是根据任务构建组织模型而不是需要构建的组件。本节简要描述一些允许较快采用SOA 的组织模型。 4.2.1.2 传统开发方法 大多数IT 项目都属于如下类别:  电子商务解决方案电子商务解决方案电子商务解决方案电子商务解决方案::::用于内部和外部用户的门户应用程序  打包的应用程序打包的应用程序打包的应用程序打包的应用程序::::最佳的点解决方案  集成集成集成集成::::跨企业或LOB 集成应用程序、门户和数据  基础架构基础架构基础架构基础架构::::数据中心、网络、服务器和软件平台。 业务发起人和IT 领导团队会定期确定项目的优先顺序和监控进度。 图8:典型的IT 路线图 传统的开发生命周期可一致地应用于所有计划,如下图所示,而资源分配随计划类别的不同而不同。 下图演示了一个典型的开发生命周期。 图9:典型的IT 开发生命周期 通常情况下,由业务操作团队、PMO、项目经理以及业务分析师和架构师中的IT 人员组成的团队审 查每个计划的高级别业务需求。根据他们的分析,IT 工作人员为联合领导团队提供建议的方法并评 估资金批准。虽然各种类型的计划的生命周期都相同,但方法却各不相同。  打包的应用程序打包的应用程序打包的应用程序打包的应用程序::::典型的方法是将开发外包给系统集成商或产品供应商,然后远程支持这些打 包的应用程序,已达到降低成本的目的。这被认为是最佳实践的原因在于,打包的应用程序是 专有的,在公司内部将这些技能集作为打包的应用程序开发并不能为公司带来策略价值。企业 可能会针对一个打包的应用程序的供应商进行标准化并构建内部团队,但对于大型的公司,这 并不是实用的解决方案。这样公司就会向供应商的业务问题过度公开。并且,大多数LOB 希望 使用特定于自身的需要的打包的应用程序。  电子商务解决方案电子商务解决方案电子商务解决方案电子商务解决方案::::大多数企业将电子商务解决方案视为战略投资,因为这是客户、合作伙伴、 提供商和员工之间进行交互和协作的增长最为迅速的渠道。首选方法是让公司内最佳的架构师 和开发人员创建和支持这些解决方案,并在组织内构建这些技能集。开发内部专业技能很有意 义,对于关注消费者的组织来说更是如此,因为这可以帮助快速更改面向客户的解决方案以帮 助组织保持其竞争优势。对于一些较低层次的业务功能,可以将其支持外包或者通过远程方法 提供。  集成集成集成集成::::电子商务解决方案与打包的应用程序的集成以及以后与BPM 平台的集成非常复杂。其执 行取决于各个团队之间交互的质量,因此外包不是最合适的方法。相反,行业的最佳实践是将 所有自定义嵌入到中间件中。LOB 应该坚持提供业务流程和规则并解决与业务定义相关的开放 问题。企业架构团队应该负责进行集成决策。  基础架构基础架构基础架构基础架构::::基础架构的最佳方法随组织的大小而变化。组织应该自行完成基础架构,除非其收 入超过10 亿美元。较大企业可以将基础架构外包给第三方,这样就可以更容易地评估基础架构 的真实成本。在内部完成基础架构会使IT 操作人员的负担过重,导致延长周转时间并降低效率。 图10 :当前生命周期方法的结果 传统的生命周期方法的主要缺点之一是,当IT 提供新的功能时,资源会转而支持这些功能,导致功 能的成本增加。IT 可能需要引入附加资源来开发新服务或者对现有服务提供支持。IT 组织无法中止 这种发展倾向,但可以通过外包然后以远程方式支持功能降低新开发的成本。不过,这种方法对IT 组织的作用也仅限于此。企业需要采用不同的方法为其开发组织配备人员。 4.2.1.3 建议的方法 建议的方法是根据技术功能创建团队,如下所示:  组合团队组合团队组合团队组合团队::::根据业务流程和需求将服务联系在一起。服务之间的连接不仅能够标识每个服务要 求的功能,还能够标识部署、配置和管理模型。此团队应由架构师和技术领导组成。  UI 团队团队团队团队::::开发由连接框架、用户交互流、导航和类型验证组成的业务交互层。此层的开发可以 外包,只要拥有良好过程来捕获和记录需求。  服务团队服务团队服务团队服务团队::::设计和开发业务逻辑。建议是配备在公司内担任重要职务的人员,尤其是架构师和 主要开发人员。开发本身可以外包,只要是基于架构方针并由内部人员管理和审查。  数据团队数据团队数据团队数据团队::::为其他团队开发共享的或特定的数据服务。信息和数据架构师是该团队的主要成员, 也应该是公司员工。他们定义企业的数据模型、数据质量和公共对象(如客户、订单和产品)。 开发本身可以在任何位置完成,但必须基于架构方针并由内部人员管理和审查。其他团队可从 此团队接收服务,但他们不需要了解企业数据模型。 图11 :基于功能的组织 4.2.1.4 摘要 这个建议的方法根据其功能组织开发团队。这可以降低成本,因为不需要为每个项目团队配备具有 类似技能集的人员。 4.2.2 企业架构企业架构企业架构企业架构::::角色和责任角色和责任角色和责任角色和责任 4.2.2.1 任务声明 企业架构的目的是开发IT 策略并通过理论指导、流程、结构和价值交付提供与不断变化的业务优先 级对应的技术理想。 4.2.2.2 企业架构责任 下面是企业架构师的一些高级别责任: 4.2.2.2.1 开发开发开发开发IT 策略策略策略策略和技术理想和技术理想和技术理想和技术理想  审查IT 处理企业业务流程、信息、技术和应用程序的方式的目标(未来)状态,以便达到允许 业务执行公司任务的阶段性业务目标  审查当前状态以标识差距,并开发一个可操作的实现目标状态的路线图,包括业务流程、组织、 信息、技术和应用程序  评估替代方式,并根据与每个替代方式关联的成本、收益和依赖关系的整体视图提供建议。 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 集成架构集成架构集成架构集成架构 企业架构团队的角色类似于城市规划。他们可能不会定义每一个建筑,但会定义连接与基础架构, 以及在这种连接和基础架构下的主要系统、模型、组件以及IT 基础架构的主要组件之间的关系。 4.2.3 IT 企业资源管理流程企业资源管理流程企业资源管理流程企业资源管理流程 下面是高级别IT企业资源管理流程流的一个示例。 4.2.4 项目初始化请求格式项目初始化请求格式项目初始化请求格式项目初始化请求格式 请求请求请求请求——名称名称名称名称:::: 请求数据请求数据请求数据请求数据:::: 项目项目项目项目——名称名称名称名称:::: 附加涉众附加涉众附加涉众附加涉众/优点优点优点优点:::: 业务发起人名称: 请求编号(LOB-IT 使用): 业务发起人组织: 请求状态(LOB-IT 使用): 审查和批准审查和批准审查和批准审查和批准((((LOB-IT 使用使用使用使用)))) 业务程序办公室业务程序办公室业务程序办公室业务程序办公室:::: 审查数审查数审查数审查数据据据据:::: LOB IT 工作人员工作人员工作人员工作人员:::: 审查数据审查数据审查数据审查数据:::: LOB IT 审查委员会审查委员会审查委员会审查委员会 审查数据审查数据审查数据审查数据:::: 业务问题定义和合理性业务问题定义和合理性业务问题定义和合理性业务问题定义和合理性 业务问题业务问题业务问题业务问题:::: 描述此项目或工具增强请求可能可以解决的当前业务问题。请包含它可以支持的业务流程的描述。 业务合理性业务合理性业务合理性业务合理性:::: 提供定性和定量信息以支持投资。包括受影响的组织;用户数目、生产力提高、收入增长、成本节省, 等等。 业务目标业务目标业务目标业务目标:::: 列出想要达到的目标;包括合适的位置及其与公司或组织目标的关系 背景信息背景信息背景信息背景信息:::: 提供任何有关此请求的附加信息,包括以前为解决问题所付出的努力;涉及的人员;考虑的新的解决 方案或软件;潜在流程或组织变更影响,等等。 LOB IT 信息信息信息信息:::: 提供此请求与IT 有关的任何相关信息。 4.2.5 请求架构工作请求架构工作请求架构工作请求架构工作 业务分析师会在从LOB 捕获高级别要求后向架构师提交对架构工作的请求(或估算请求)。此请求 应包含工作声明以及来自项目启动文档的信息。 工作声明工作声明工作声明工作声明 要求的工作的简短描述。 项目请求和背景项目请求和背景项目请求和背景项目请求和背景 业务要提供详细描述请求的信息以及可帮助架构师估算工作量的附加背景信息。 工作架构声明工作架构声明工作架构声明工作架构声明 工作的架构声明包含对提议的阶段、时间线、里程碑和成本的估计。 项目请求和背景项目请求和背景项目请求和背景项目请求和背景 项目范围项目范围项目范围项目范围、、、、收益和成本收益和成本收益和成本收益和成本 范围范围范围范围:::: 定义此项目或者此项目的各个阶段的范围。包括: a. 任何业务流程变更 b. 支持或自动化上述变更流程的系统功能。 阶段阶段阶段阶段1 □□□□ □□□□ □□□□ 超出范围超出范围超出范围超出范围——边界边界边界边界:::: 标识超出超出超出超出此项目或此项目的各个阶段的范围的工作。包括: a. 任何业务流程变更 b. 系统功能。 超出阶段超出阶段超出阶段超出阶段1 □□□□ □□□□ □□□□ ROIROIROIROI((((投资回报投资回报投资回报投资回报))))————————收益和成本收益和成本收益和成本收益和成本 收益收益收益收益:::: 直接收益直接收益直接收益直接收益—— 列出完成此项目时为BEA 提供的以及成为项目ROI 的可测量直接收益。主要收益通过 以下形式表示:操作成本降低、收入获得、生产力提高以及客户满意度。 □□□□ □□□□ □□□□ 间接收益间接收益间接收益间接收益—— 标识此项目将提供的其他间接或无形收益以及优势。 □□□□ □□□□ □□□□ 成本成本成本成本 资源资源资源资源—— 估算要成功地实现此项目以及正在进行的系统操作和支持所需要的资源,如下表所示。 已有预算已有预算已有预算已有预算  永久和合同总人数:  软件和硬件:  IT 基础架构——网络和电信:  总预算: 未预算未预算未预算未预算  永久和合同总人数:  软件和硬件:  IT 基础架构——网络和电信:  估计的总预算: 风险管理风险管理风险管理风险管理 对其他项目的依赖对其他项目的依赖对其他项目的依赖对其他项目的依赖 性性性性:::: 列出要开始和完成此项目对其他项目的依赖关系。 □□□□ □□□□ 重要成功因素重要成功因素重要成功因素重要成功因素:::: 标识从此项目开始就需要考虑的所有重要成功因素。 □□□□ □□□□ □□□□ 接受条件接受条件接受条件接受条件 列出项目的接受条件 风险风险风险风险:::: 标识可能对此项目产生负面影响的所有潜在风险。 □□□□ □□□□ 角色和责任角色和责任角色和责任角色和责任 定义业务涉众定义业务涉众定义业务涉众定义业务涉众 列出所有业务涉众及其在项目中的角色 □□□□ □□□□ 定义定义定义定义IT 涉众涉众涉众涉众 列出所有IT 涉众及其在项目中的角色。  IT 发起人  项目经理  架构师  PMO  系统管理员/DBA  应用程序支持团队 架构方法架构方法架构方法架构方法((((映射到理想映射到理想映射到理想映射到理想)))) 架构描述,映射回参考架构的模型 高级别项目计划和调度高级别项目计划和调度高级别项目计划和调度高级别项目计划和调度 为使其不断运行和支持应用程序所需要的后续部署工作(业务逻辑更改) 4.3 简化的公共词汇简化的公共词汇简化的公共词汇简化的公共词汇 下面是公共词汇的一个简短列表,可供业务团队、业务分析师、架构师、项目经理、开发人员、QA 和操作人员使用。 术语术语术语术语 定义定义定义定义 业务流程建模 建模、捕获和模拟业务流程要求 业务事件 调用业务流程的外部变更 业务概念 企业对象,例如客户或产品 业务应用程序 作为打包的应用程序、自定义应用程序和业务流程实现的业务应用程序 逻辑 业务服务 业务应用程序中的每一项离散的业务活动 逻辑服务模型 物理服务到业务服务的一对一映射,用于促进业务服务级别而不是物理 服务级别的重用 物理服务 按功能分类的离散型粗粒度服务 4.4 相关相关相关相关 SOA 标准标准标准标准 4.5 服务服务服务服务组件组件组件组件架构和服务日期对象架构和服务日期对象架构和服务日期对象架构和服务日期对象  业务逻辑(嵌入在组成服务的组件中)与需要访问服务组件所需的传输和协议绑定的隔离。  服务组件的核心业务逻辑以及组件要与外部服务交互或者参考外部服务要使用的协议的完全隔 离。  使用依赖注入技术的运行时服务装配  服务装配的配置和部署元数据的定义  服务实现层组件的注释驱动并自动生成的实现的容器方针  使用元数据入口点的客户端与服务的运行时绑定,以及使用元数据外部服务参考的组件与外部 服务的绑定  定义服务访问和服务依赖关系的元数据配置策略,由入口点和外部服务参考定义。  使用SDO 作为参数和返回值的文档样式信息交换  定义安全、事务和可靠消息策略等服务策略(用于许多互操作性功能的WS 策略)的元数据  一致服务实现:提供的业务服务是固定的,但提供的服务可使用SCA 外部参考和属性进行更改。  使用不同的属性值并且使用到两个分离的目标服务的不同绑定(只要服务接口相同)来对来自 相同基实现的两个不同的组件的装配  通过将实现连接到目标服务的参考配置  通过设置不同属性值完成的属性配置  通过Web 服务、JMS 消息传递、EJB、数据库存储过程和EIS 绑定,多种方式的运行时访问绑定 来访问相同实现代码基底  使用相同服务接口支持不同类型实现的SCA 注释,例如  有关容器提供商如何解释注释以提供对并非SCA 内置的实现的实现支持的SCA 定义  要实现BPEL,以便BPEL 流程与服务和服务活动协调,同时SCA 提供服务与其实现的连接的 SCA  通过支持 注释实现的SCA 容器的WS-BPEL 实现  SCA 定义以及对BPEL 样式的长期运行的同步事务的支持,允许非阻塞调用服务、回调、以及 补偿性事务支持和可靠性功能  对提供业务功能的对话服务和服务序列的支持  在运行时使用外部服务参考绑定连接地理上分散的服务和合作伙伴服务消费的模型定义  用于装配所有无需更改核心实现基础即可独立配置、部署、管理和监控的复杂服务的层集定义。 4.5.1 SCA 扩展扩展扩展扩展  本地接口定义的规范的接口级别扩展(Java 和WSDL 接口是SCA 提供的基础级别的接口)  用于使用SMTP 或会话初始化协议(SIP)访问服务组件提供绑定的绑定级别扩展 4.6 Java 业务集成业务集成业务集成业务集成  根据行业标准服务提供者接口(SPI)固有的容器和插件的概念定义集成环境  定义用于集成服务引擎和协议绑定组件的SPI  定义如何一次构建服务引擎然后使用供应商绑定组件将其绑定到多个通信协议  将服务引擎(业务功能如流程引擎和纵向行业转换数据包如AS/2 或eb-XML 或HIPPA 转换)和 通信协议(如SMTP、WS-I和JMS)隔离开来  默认情况下构建绑定组件,以便从服务引擎中部署的服务读取WSDL,或者帮助在服务消费者 和服务提供商之间交换“标准化消息”  让服务使用不透明的“标准化消息服务”在服务引擎和JBI 容器中部署的绑定组件之间传输基于 文件的信息或工作负载  让协议特定的绑定组件与“标准化消息路由器”交互,以便与具有“正确的服务提供商”的服 务通信,然后传输消息负载  允许专门研究创建纵向行业业务流程的供应商使用现有服务组件构建服务,然后只要其接口一 直使用服务引擎SPI 就使其处于相同的JBI 容器中 4.7 传统数据移动技术传统数据移动技术传统数据移动技术传统数据移动技术 4.7.1 电子数据交换电子数据交换电子数据交换电子数据交换((((EDI)))) 电子数据交换(EDI)是指业务数据在计算机间的交换。在EDI 中,信息是根据双方一致的格式进行 组织的,因此允许“提交”不需要在两端进行人员干预或密钥更新的计算机事务。在大部分情况下, EDI 事务中包含的所有信息都与传统的打印文档相同。 组织已经采用了EDI 以便增强有效性和提高利润。EDI 的优点包括:  周转时间降低  库存管理更好  生产力提高  成本降低  精确度得到改进  业务关系得到改进  客户服务得到加强  销售提高  纸张使用和存储达到最小  现金流增加。 EDI 标准由公认标准委员会(ASC)X12 开发和维护。这些标准旨在跨行业和公司边界使用。标准的 更改和更新通过讨论决定,可反映整个标准用户群的需要,而不是单个组织或业务部门的需要。目 前已经有超过300,000 个组织使用300+ EDI 事务集来管理业务。 来源:http://www.x12.org 4.7.2 提取提取提取提取、、、、转换和加载转换和加载转换和加载转换和加载((((ETL)))) ETL 完成提取、转换和加载。“提取”是指从多种源移动数据。“转换”是指公司清除并重新设置 为目标要求的格式。然后就会将其加载到其他数据库、数据集市或数据仓库以进行分析,或者记载 到其他操作系统以支持业务流程。 图12 :提取、转换和加载(ETL) 虽然大多数ETL 脚本都是批处理的,但是大多数ETL 供应商现在都提供了作为Web 服务调用这些脚 本的功能。 图13 :数据仓库和数据集市的DTL 的传统用法 上图演示了ETL 系统的典型用法。数据要从多个源提取出来以便创建操作数据存储(ODS)或数据 仓库。从下行方向看,数据集市可能利用ODS 或数据仓库。这是建议的方法,不过有些时候组织可 以在不首先创建ODS 或数据仓库的情况下构建数据集市来节约时间和资金。 传统方法是利用EAI 基础架构填充ODS 或数据仓库,但越来越多的公司已经开始使用EDA 填充ODS/ 数据仓库。他们使用ESB 和EII 工具而不是传统的EAI 和ETL 工具。这是ETL 和EII 工具之间的驱动聚 合,以便使用EII 工具提供数据操作和移动功能,以及使用ETL 工具提供实时事务功能。 4.8 推荐的读物推荐的读物推荐的读物推荐的读物 下面是一些与SOA 最佳实践相关的附加信息源的链接。 4.8.1 架构框架架构框架架构框架架构框架 联邦企业架构(FEA) http://www.whitehouse.gov/omb/egov/a-1-fea.html 开放组织架构框架(TOGAF) http://www.opengroup.org/togaf/ Zackman Institute for Framework Advancement http://www.zifa.com/ 4.8.2 关联标准关联标准关联标准关联标准 服务组件架构(SCA) http://www.osoa.org Web 服务互操作性组织 http://www.ws-i.org 结构信息标准化促进组织(OASIS) http://www.oasis-open.org 对象管理组(OMG) http://www.omg.org 4.8.3 行业论坛行业论坛行业论坛行业论坛 SOA 协会 http://www.soainstitute.org/index.php Financial Services Technical Conference (金融服务技术会议) http://www.fstc.org 用于SOA 的面向一致性的架构(COA) http://www.s-ox.com/Feature/detail.cfm?articleID=1202 4.8.4 关注关注关注关注 SOA 的分析师网站的分析师网站的分析师网站的分析师网站 ZapThink http://www.zapthink.com/ CBDI 论坛 http://www.cbdiforum.com/ 4.8.5 模板模板模板模板 捕获业务方案(用例) http://www.ws-i.org/Requirements/SubmittingScenarios-1.0-2004-09-27.html
还剩100页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

lhwyflyl01

贡献于2014-06-21

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf