面向服务的面向业务基础.doc

面向服务的面向业务基础 发布日期： 2007-07-12 | 更新日期： 2007-07-12 Ulrich Homann Microsoft Corporation 适用于： 企业体系结构 面向服务的体系结构(SOA) 摘要：通过结合Web服务使用面向服务，有效、高效地实现业务活动的自动化。 “它不是存在的物种中最强大的，也不是最智能的，但是它能够对变化做出最迅速的反应。”Charles Darwin (查尔斯·达尔文) 本页内容 简介 进入业务功能映射图 业务功能 – 一个更稳定的基础 功能模型概览 结论 简介 随着Web服务的出现，面向服务成为必威体育精装版推出的技术解决方案，其目的是实现业务活动的自动化。(如要全面地了解Microsoft连接系统策略中SOA及相关概念的信息，请参阅《面向服务及其在连接系统策略中的角色》。)面向服务体现的概念是通过长期的努力发展演变而成的，它们可对复杂的计算机系统进行模块化处理和分布，这些计算机系统能够反映和支持分布式业务世界的实体。 依照面向服务目前的定义，这些服务通过标准的、已发布的、可发现的接口提供了可访问网络的功能。这些核心的特征至少保证了协议(在语法方面)的互操作性，而无须考虑平台、提供者和位置的限制。 然而，在目前，解决技术集成问题本身并不足以证明面向服务投资的正确性。为了强化它的论据，针对面向服务对于业务灵活性的支持，正在做出各种不同的声明，这是因为此论据存在于面向服务的环境中，在此环境中，通过公开服务、重新配置服务、重新使用服务等措施，更容易创建解决方案。也许如此，但是根据面向服务的上述定义，许多业务在某种程度上都已经实现了面向服务，可它们仍然要努力提供业务需要或要求的IT支持。 为了证明面向服务投资的正确性，我们需要解决以下问题，它们在新体系结构原则的每个部署项目中都会出现： ? 我们如何防止面向服务在今后将要进行的相似计划中出现与过去相同的体系结构错误？ ? 我们如何确保选定的实现体系结构与业务要求相关联？ ? 我们如何在不断变化的环境中最大限度地延长期望的实现周期？ 就像我们将要看到的，这些问题的答案是相互联系的。面向服务仅仅体现了系统的一个特定方面；它并不是系统的起始点，而且有缺陷的基础将导致不完善的实现。此基础是解决实现问题所缺少的一个重要环节，实现的难点在于，如何通过正式化的、可重复的、创新的方式提出上述的业务要求并将它们与面向服务的模型相关联。 通常，在描述或模拟业务要求所使用的方法与它们的最终技术实现之间并没有明确定义的关系。目前，大多数获取和体现业务要求的工作都使用了业务流程建模方法和技术。对于任何将业务要求及策略与IT策略和实现相关联的尝试，正式的业务流程建模都是必不可少的一部分，但它并不能满足需要。 业务流程需要以实现业务目标所需的活动为核心，而无须考虑传统的“砖瓦泥灰(实体)”筑成的边界——你今天内部进行的工作明天也许就会外包。通过灵活的业务模型，我们的设计必须能够支持这些协作要求，并考虑到边界、网络的作用、不断变化的责任等因素，同时还要顺利地穿越这些边界，而不会受到系统、公司或其它边界的影响。传统的业务流程建模没有将业务要求与技术结构和投资相结合。它并没有边界、部署、封装等问题的概念。 换句话说，除了具有活动表现功能之外，一个较好的模型必须支持业务之间的依赖性以及对它提供支持的服务的独立性。 返回页首 进入业务功能映射图 为了实现这些目标，我们建议将业务设想为功能网络。功能模拟了业务功能的行为(指它的外部可以看到的行为，相对于它的行为方式和内部行为)和期望的性能标准。Pay Employees(向员工支付薪水)和Ship Product(发送产品)就是两个功能实例。这些功能一般具有“所有者”和“客户”，它们被要求按照一定的标准(比如每个时间段的工作单位，或某些质量度量标准)进行工作。这指的是做了“什么”(行为)以及行为的期望或约定的标准。功能的内部包含了此功能的详细信息，介绍了它是如何在指定的时间点针对人、过程步骤、技术等因素而实现的。在这种虚拟的标准下，我们仅关注外部情况，它们是如何实现的并不重要。这种功能在本质上是一个“黑盒”。 功能具有充分的描述性，可以说明某个功能是如何满足业务要求的以及与它交互需要什么，另外它们也进行了充分的概括，从而能够提供所需的稳定性，并藉此提供稳定、持久的基础。网络方面则描述了各项功能在执行业务所需的工作时是如何互连的。 我们已经着重强调了可观察、可度量的外部行为以及它们与其它功能的联系，现在我们可以立刻看到功能和面向服务之间的平行关系。在它们大多数的抽象含义中，业务功能和Web服务都是黑盒，它们的联系非常重要，它们与内部工作相关联，但又与其相分离。直观上，这种平行性对二者之间的紧密结合进行了充