PDFWeb 服务：承诺与折衷
Web 服务最初承诺的大部分将通过企业内部的集成来实现。
Ali Arsanjani、Brent Hailpern、Joanne Martin 和 Peri Tarr
Web 服务最初承诺的大部分将通过企业内部的集成来实现，无论是与遗留应用程序集成，还是与跨组织孤岛的新业务流程集成。企业需要支持这种新模式的组织结构。
Web 服务是最新兴起的软件热潮：它承诺提供功能完备的应用程序软件，无需安装在您的本地计算机上，而是允许在不同环境中运行的系统通过 XML 和其他 Web 标准进行互操作。围绕 Web 服务的大肆宣传大多集中在组织间分布式计算的理想境界，即供应链可以跨越各大洲进行集成，应用程序由各个供应商按需提供的小部件构建而成。为了达到这个目标，我们需要精简当前的方法，构建一个基于组件的架构，该架构由粗粒度、消息感知、企业级和高度可重构的企业组件组成，并以 Web 服务的形式公开。
现在是开始采用的时候了，但要从防火墙内部、企业内部开始，然后向外扩展。这种智慧将使您免受与企业外部公开 Web 服务相关的尚未解决的安全、知识产权泄露和性能问题的困扰。它还为您提供了充足的时间来建立标准和最佳实践。在过去的两年中，我们为电信、抵押贷款、金融服务、政府和银行领域的多个基于组件的开发和集成 (CBDi) 项目做出了贡献 (5)。这些项目的关键成功因素之一（我们将在本文中讨论其中一个项目）是在以下五个 Web 服务领域应用 CBDi 最佳实践
- 组织方面，包括项目管理的影响和教育计划；
- 方法论方面，包括扩展方法以提供对基于组件的开发的完整生命周期支持；
- 架构方面，包括创建可扩展架构的最佳实践和问题；
- 技术实施方面，涉及将给定的设计映射到技术标准，例如 Enterprise JavaBeans 或 .NET。
- 基础设施方面，包括开发工具、网关服务器、API、中间件和浏览器。
遗留系统转型的必然性
随着我们转向分布式模型，数据、流程和应用程序代码的明确所有权概念将发生转变，在该模型中，我们可以重用组件来自动化业务流程。此外，固定的供应链概念将让位于更灵活的概念，即基于特定条件建立链接，以提供快速、廉价和丰富的交互。这种转变是不可避免的：可以不断重组和重新连接的流程的动态互连的商业潜力是巨大的。
虽然这种演变将最大限度地减少多次手动操作，并将批处理流程转变为高效的自助服务查询等，但它需要清楚地了解谁对各个部分负责，更重要的是，对整体负责。通过合并和收购引入的冗余系统和设计不匹配也需要在当前的 I/T 架构中进行集成。挑战在于隔离共性并外部化变异，以便可以配置并应用于应用程序。部门还需要学习信任其他组织部门，并且随着安全和身份验证功能支持向防火墙外部扩展，围绕信任的问题将变得更加复杂。
在电子商务环境中竞争的需要带来了来自客户、供应商和业务合作伙伴访问内部信息的需求。但据 Gartner Group 称，80% 的企业在 COBOL 应用程序上运行，这些应用程序往往需要批处理，并且由于它们不是以模块化方式设计的，因此灵活性很差。组织可以采用多种途径来摆脱不再满足最终用户需求的昂贵系统。其中包括与屏幕抓取相关的非侵入式技术、事务或应用程序级别的集成技术以及通过软件包解决方案进行的大规模替换。
每种技术都有优点和缺点。屏幕抓取是在用户界面级别使遗留应用程序可用的快速方法，但它不能解决业务流程修改问题，因此灵活性有限。集成技术可以借助市场上提供的众多产品，但同样不能捕获业务流程知识，可能依赖于供应商的实施，并且可能无法很好地扩展。可能最稳健的选择是将标准业务流程集成到环境中。此路径可以提供对新的和高级功能的访问，但它需要放弃对现有系统的投资，并且可能会造成破坏。此外，软件包支持 Web 交互的能力仍在发展中。
重点正在转向遗留系统转型，因为金融服务和保险等行业正在探索提取数据并使其可供用户访问的方法。该策略涉及使遗留系统能够在企业内部集成，并最终将核心业务功能转变为支持 Web 的环境。企业可以通过一系列操作转换遗留系统，从而保留其核心系统投资，将业务规则封装到灵活的独立组件中，这些组件作为单独的 Web 服务运行。
要了解将遗留代码重组为组件的价值，请考虑一家大型保险公司如何处理索赔。其索赔系统是一个战略性的 Cobol 程序，代码行数超过一百万行。该程序设计为在批处理模式下运行，数据馈送每天到达，平面文件合并到隔夜处理的事务文件中。此过程导致至少 24 小时的客户响应时间。为了缩短此时间，甚至缩短系统上的负载分配，该公司需要提取其索赔引擎的核心业务规则，并调整它们以持续处理索赔。
挖掘工具可以帮助进行遗留系统挖掘、集成和转型。这些日益流行的工具不仅是编程生产力工具，也是管理决策工具。如果在公认的最佳实践和遗留系统转型方法论中应用它们，它们使公司能够通过创建调用树和系统组件图来了解其系统，并执行分析以提取业务规则。通过仔细选择企业组件边界进行业务流程集成对于在扩展企业中提供流程扩展层至关重要，而不仅仅是数据或信息集成。
向 Web 服务迁移
遗留系统转型的挑战因需要集成由 n 层架构和应用服务器组成的新开发工作而变得更加复杂。在多个业务线上的企业内部集成服务最好通过组件化来完成，组件化涉及表征对应于业务目标的业务驱动功能块。此过程有助于识别可以被多个业务线使用的服务，而不是被锁定在信息或应用程序孤岛中。解锁这些嵌入式服务通常通过基于组件的开发和集成 (CBDi) 来完成，其中旧系统与在新兴的 n 层架构平台上运行的新系统集成 (3,5)。这种集成不仅仅涉及功能的“包装”，还可能包括重构未公开的遗留服务上的后端业务逻辑。
通常，诸如企业组件模式之类的通用概念最佳实践可以为开发团队提供开发粗粒度企业级业务组件的参考点。它们可以在部门或企业级别进行定制、重新配置或直接重用，并作为向扩展企业迁移的路径。
向面向服务的架构进行战略迁移的演变分为五个级别，如图 1 所示。首先，遗留“孤岛”系统之间的数据传输以批处理模式进行，除了为 ELT（提取、加载、转换）场景传输原始数据外，几乎不处理与其他孤岛相关的信息。下一个级别是信息流协调，其中企业架构被识别、表征和清点，以识别业务和产品线的功能领域，并建立企业应用程序集成中心辐射型架构。此架构将企业从数据传输带到信息协调。然后，根据业务流程和企业级组件的边界考虑信息协调，这些组件协同创建映射回业务目标的业务流程。
图 1
这种划分导致了关注点的自然分离。例如，一家金融服务公司可以通过考虑企业组件的划分（见图 2），例如客户、帐户、产品和安全管理以及计费和评级，来区分其各种产品和业务线。这些组件提供了创建粗粒度企业组件的边界，如图所示（见图 3），这些组件封装了一组松散耦合和中介的中到小粒度组件、对象或代理和适配器到遗留系统。
图 2
图 3
未来的目标是公开企业组件服务，以便在企业内部使用 WSDL 进行调用。此类服务描述通常在内部 UDDI 注册表中定义。向业务合作伙伴、供应商和客户的外部世界公开多少取决于业务需求、角色、规则和竞争分析。在此方案中，驻留在内部 UDDI 注册表中的 WSDL 逐渐迁移到公共或合作伙伴 UDDI 注册表，以获得更大的公共曝光。
一旦服务被定义和公开，就会出现应该使用什么协议来执行调用的问题。许多这些要求可以通过快速重新配置 EC 的可配置配置文件以可配置的方式定义，以确保组件具有自我描述、快速协作更改和动态配置的特性。但这并不是实现满足服务级别协议 (SLA) 的稳健而实用的架构的唯一手段。
Web 服务调用框架 (WSIF) (13) 或 Web 服务检查语言 (WSIL) 等技术有助于支持协议透明性，从而在不影响灵活性的情况下实现可接受的服务级别。WSIF 提供了一种直接描述底层服务的方式，并独立于底层协议或传输来调用它们。WSDL 的端口和绑定是可扩展的。WSIF 允许创建新的语法来描述如何作为 WSDL 扩展访问企业系统。这允许企业开发人员直接创建 CICS 事务、EJB 或其他服务的描述，并允许服务用户基于抽象描述构建应用程序。在部署或运行时，服务绑定到特定的端口和绑定。WSIF 的可扩展框架可以通过创建新的“提供程序”来增强，这些提供程序支持 WSDL 的特定可扩展性类型，例如 SOAP 或 Enterprise JavaBeans。提供程序是将开发人员的代码链接到实际实现的粘合剂。
WSIL 补充了 UDDI 的发现功能，UDDI 提供了一个大规模的服务目录。与其他大型 Web 内容目录（如开放目录项目）一样，UDDI 是查找和识别服务的关键。但是，了解哪些本地服务可用也很重要。检查标准使站点或服务器查询能够检索服务列表。此列表包括指向 WSDL 文档或 UDDI 服务条目的指针。WSIL 是一种轻量级的方式，可以在不访问 UDDI 服务器的情况下访问服务描述。
金融服务行业项目
我们与一个组织合作，该组织在不同的硬件和软件平台上运行五个后端遗留系统（见图 4）。每个应用程序都是作为孤岛零散构建的，许多是通过合并和收购添加的。这种冗余设置难以维护，并且添加功能通常意味着必须在所有系统上复制。该组织的大部分业务知识都锁定在这些五个遗留应用程序中嵌入的业务规则中。但是业务规则缺少访问点，并且无法从需要相同功能的其他应用程序调用（见图 5）。
图 4
图 5
该企业正面临来自规模较小、更了解 Web 的竞争对手的严峻竞争。他们需要通过 Web 访问后端遗留应用程序，但是每个系统的业务流程和规则都没有被架构化为协同工作或协调信息流，除了通过夜间批处理流程之外。
使用 CBDi 方法，后端遗留系统被清点、数据挖掘、消息启用和组件化，如图 6 所示。这样做是为了准备与在应用服务器上运行的 J2EE 风格程序进行交互，这些程序现在可以访问以前锁定在遗留系统中的业务功能和规则块。这促进了统一的用户体验，就好像一个后端系统处理所有事情一样。图 2 和图 3 中所示的企业组件被构建为封装后端遗留系统的中间层业务逻辑的功能。
图 6
技术挑战
当前一代 Web 服务基础设施和工具具有早期软件的典型问题。与二进制表示相比，XML 标记和文本表示都会导致数据大小爆炸式增长。当 XML 数据读入应用程序时，必须对其进行解析，以创建内部数据表示。进一步使性能复杂化的是需要读入和解析标记定义集。加密和解密也会增加开销。随着技术的成熟，这些性能问题将得到解决，但今天的开发人员可以预期与传统的分布式计算操作相比，速度会降低 10 到 100 倍。
随着 Web 服务超越 SOAP、WSDL 和 UDDI 的新型分布式计算基础设施，发展成为通过互联网交付给最终用户的电子实用程序 (eUtilities)，挑战将如雨后春笋般涌现。电子实用程序的 SLA 将包括功能、可用性、可扩展性、性能、资源和可靠性。使用条款可能因客户而异，并且可能会随着时间的推移而发生变化，因此需要动态监控客户需求和资源。SLA 不仅描述了服务的功能接口，还描述了不合规的法律后果以及支持和访问级别。为了满足 SLA，开发人员必须创建满足超出简单功能正确性约束的软件。Web 服务应用程序必须包括传统的 API 和用于计量、性能、可管理性、可审计性、复制和可靠性的集成接口。
为了进一步增加复杂性，Web 服务必须是动态可配置的。正如电话公司依赖电力公司一样，未来的 Web 服务应用程序也将依赖其他电子实用程序。由于此类服务可能会以某种方式发生变化，从而影响电子实用程序，因此它必须检测并响应变化，或者至少优雅地降级。这种按需特性使得使用具有正式定义方式的上下文感知组件变得更加重要 (2)。
面向对象的 Web 服务
面向对象 (OO) 技术（如多维关注点分离 (MDSOC) (6, 7)）将有助于定义 Web 服务。值得注意的是，MDSOC 和面向方面软件开发 (AOSD) (8) 的相关学科，特别是 Hyper/J™ 和 AspectJ™，为我们提供了使用具有清晰定义的自包含实体的方法。然而，从 Web 服务的角度来看，对象并非生来平等。避免以经典的教科书意义来思考对象。为了保持低开销，并在 Web 服务设计方法论的约束范围内工作，Web 服务需要更大粒度的对象，这些对象代表业务功能，例如客户帐户或采购服务，或大型 IT 组件，例如安全或身份验证服务。
MDSOC 有助于创建“横切”关注点，这些关注点影响整个 OO 系统中的许多模块。将不方便地适合主导层次结构的系统方面模块化可以最大限度地减少重复和实现错误，并在维护期间隔离更改。然后将各种方面编织到基本代码中以形成新程序。一个设计良好的 MDSOC 系统消除了“基本代码”和“方面代码”之间的区别。MDSOC 允许分离交互关注点（例如来自一个供应商的监控服务和来自另一个供应商的多级性能服务）的能力对于 Web 服务开发至关重要。
由于 Web 服务客户就他们将从服务中获得的具体信息进行协商，因此 Web 服务必须定义一个或多个功能 API，以及提供允许控制性能、可靠性、计量和服务级别的非功能接口。如图 7 所示，这些接口必须以基本方式相互交互。例如，获得高性能可能需要使用不同的通信协议、搜索算法和并发控制模型。此类深度交互接口的定义和支持对服务工程和部署提出了重大挑战。
图 7
面向对象的 Web 服务 (OOWS) 是一种构建在高度可靠的基础设施（可能包括其他 OOWS）之上的软件组件，它提供 API。与其他组件不同，OOWS 必须可以通过 SLA 动态控制，以便它们可以在构建时、集成时或运行时响应 SLA 更改而更改。这些组件还必须提供非功能管理接口，无论是作为直接编程接口（类似于 API），还是通过可配置的配置文件，使用通过方式和企业组件配置文件的可重新配置架构风格 (13)。这些非功能接口或配置文件允许控制诸如性能、可扩展性、服务级别以及潜在的 OOWS 功能等属性。
如图 8 所示，Web 服务的非功能管理接口中体现的功能可能横切功能 API 功能，使其成为 MDSOC 技术的良好目标。此外，某些功能和管理功能可能需要它们自己的类和接口层次结构来实现必要的域模型。当功能组合到特定的 OOWS 中时，必须集成这些层次结构。当 OOWS 组合在一起以构建新服务时，也会出现同样的问题。这很可能成为 OOWS 开发人员的关键问题，他们无法控制底层电子实用程序中使用的域模型。
图 8
虽然 MDSOC 技术很有前景，但它们目前并未解决功能和管理接口交互中的几个关键问题。其中之一是语义不匹配问题，当两个或多个功能具有相互不兼容的假设或要求时，就会发生语义不匹配。例如，客户端可能会协商无法通过给定的并发控制机制或用于实现某些功能的特定策略来实现的服务级别。对于 OOWS，必须在语义不匹配对客户端造成影响之前识别它们。必须知道客户端 SLA 中的特定需求集无法同时满足，或者这样做将需要新的组件、算法或基础设施。这必须在向客户端承诺这些功能之前确定。
干扰是并发软件中典型的语义不匹配问题，但当软件交互产生不良结果时，OOWS 中的管理和功能接口之间也可能发生干扰。当消息传递和事务同时存在时，可能会发生干扰。为了允许事务管理器保持原子性和可串行性，通常应在事务提交之前不发送消息。消息传递功能可能会轻松地独立发送消息，从而阻止事务管理器满足其要求。
正如本次讨论所表明的那样，始终不可能确定组合软件的外观。与非组合范例不同，在非组合范例中，通常不会在不编程的情况下获得行为，使用组合范例的开发人员会体验到不可预测的软件行为。这部分是因为组合器添加了逻辑，但也因为组合器打破了现有的封装以集成关注点。这些封装的开发人员对模块的行为做出了一些假设，并且当来自新关注点的代码插入到现有模块中时，这些假设很容易被违反。组合的不可预测效果往往要到它们在运行时表现为错误行为时才会被发现。这在 OOWS 上下文中是不可接受的。以下是使用 OOWS 的五个附加技巧
验证是否符合 SLA。 确保 SLA 合规性需要程序化接口来控制计量、性能和其他横切的非功能性功能。它还可能需要动态添加、删除和替换功能。这些管理功能与功能功能之间的交互再次显而易见，因为 OOWS 可能不会为请求较低服务级别的用户提供某些功能或性能。
在“组件”既非本地又无法本地控制时，找到构建服务的方法。 与所有软件一样，假设可以构建“组合”OOWS 是合理的，一个服务依赖于另一个服务，每个服务都有自己的 SLA。理想情况下，服务设计人员应该花费更多精力集成服务，而不是构建新服务，但服务可能不在他或她的直接控制之下，因为其他人可能拥有它们。在这种情况下，设计人员或构建人员无法使用传统的软件工程方法来开发组合服务，因为这些方法依赖于集中控制和静态部署假设。
限制变更的影响。 OOWS 可能会在没有通知的情况下发生更改，这可能会影响依赖于它的服务。因此，服务必须配备集成和运行时支持系统，这些系统可以识别服务更改并通过实时版本控制、配置管理、“热交换”服务位和片段以及优雅地升级和降级等操作来响应更改。
同样，更改会影响服务的功能和管理方面，并且此类更改具有法律含义。版本控制和配置管理问题比其传统的构建时类似物要复杂得多。在构建时，版本控制或配置管理系统只需要选择一组模块来组合在一起。在运行时，它可能必须替换更小粒度的片段，以确保更改对修改后的服务的影响最小。高级配置管理方法，如 (9)，可能在此处有用。
将 SLA 视为软件。 SLA 本身必须被视为服务工程中的关键组件，因为它们定义和配置了服务的功能和非功能方面。因此，它们是服务规范，并且必须静态和动态地满足它们。必须将它们视为独立的软件工件——也许作为服务的声明性规范，或作为某种操作语义。在任何一种情况下，它们都必须有自己的构建/集成/测试/部署周期，该周期必须与 OOWS 容量规划、设计和架构、服务监控/执行/控制以及提供商和最终用户的合规性检查和报告直接联系起来。鉴于第一代类 OOWS 供应商 (ASP) 的竞争性质，人们可以预期 SLA 会快速发展，至少在提供的服务选项成本方面是如此。因此，这些 SLA“程序”必须适应执行期间的更改。
结论
利用 Web 服务功能的企业架构正在快速发展，以将资产吸收到按需服务的动态结构中。新技术和方法正在成熟，以实现可接受的服务级别特性。实施 Web 服务的最佳方法之一是从大型企业组件的基于组件的架构开始，这些组件将业务流程级别服务公开为 Web 服务。从组织内部开始，而不是在外部公开它们。当您获得项目经验并发现最佳实践时，请准备好迁移到完全面向服务的架构，该架构外部化有用的业务服务。
问
参考文献
1. Arsanjani, A. 企业组件服务，《 通讯》，2002 年 10 月。
2. Arsanjani, A.，Alpigini.，J. 使用面向语法的对象设计将业务模型无缝映射到软件架构。载于 2001 年 IASTED 建模与仿真会议论文集，宾夕法尼亚州匹兹堡，2001 年。
3. Arsanjani, A. CBDI：基于组件的开发和集成的模式语言。2001 年欧洲编程模式语言会议。
4. Arsanjani, A. 面向语法的对象设计：使用自描述组件和服务创建自适应协作和动态配置。载于 2001 年面向对象语言和系统技术会议论文集 39。
5. Arsanjani, A. 一种领域语言方法，用于设计动态的基于企业组件的架构以支持业务服务。载于 2001 年面向对象语言和系统技术会议论文集 39。
6. Tarr, P.，Ossher, H.，Harrison, W. 和 Sutton, S.M. N 度分离：多维关注点分离。载于 ICSE 21 论文集，1999 年 5 月。
7. Ossher, H. 和 Tarr, P. 多维关注点分离和超空间方法。载于软件架构和组件技术研讨会论文集：软件开发的最新技术。Kluwer，2001 年。
8. Kiczales, G.，Hilsdale, E.，Hugunin, J.，Kersten, M. Palm, J. 和 Griswold, W. AspectJ 概述。载于 ECOOP 2001 论文集，2001 年 6 月。
9. Chu-Carroll, M.C. 和 Sprenkle, S. Coven：通过软件配置管理酿造更好的协作。第 8 届软件工程基础国际研讨会论文集，2000 年。
10. http://www.w3.org/TR/SOAP。
11. http://www.w3.org/TR/wsdl。
12. http://www.uddi.org/about.html。
13. Web 服务调用框架，http://www-06.ibm.com/developerworks/library/ws-wsif.html。
###
ALI ARSANJANI 是 IBM Global Services 的高级架构师，并且领导组件能力中心，专门从事基于组件和服务导向架构的实施。
BRENT HAILPERN 曾参与并管理过许多与并发和编程语言问题相关的项目。自 1999 年以来，他一直担任 IBM 研究院计算机科学副主任。
JOANNE MARTIN 目前是 IBM Global Services 的解决方案开发主管，专门从事通过 Web 服务改造遗留应用程序系统。
PERI TARR 是 IBM Thomas J. Watson 研究中心的 Research Staff Member，也是面向方面软件开发 (AOSD) 领域的先驱，她共同发明了多维关注点分离和 AOSD 的超空间方法，并且一直在探索整个软件生命周期中多维关注点分离的问题。
最初发表于 Queue vol. 1, no. 1—
在 数字图书馆 中评论本文
更多相关文章
Niklas Blum, Serge Lachapelle, Harald Alvestrand - WebRTC - 开放 Web 平台的实时通信
在这个疫情时期，世界比以往任何时候都更加转向基于互联网的 RTC（实时通信）。在过去十年中，RTC 产品的数量激增，这在很大程度上是由于更便宜的高速网络访问和更强大的设备，但也归功于一个名为 WebRTC 的开放、免版税的平台。WebRTC 正在从实现有用的体验发展成为至关重要的工具，使数十亿人能够继续他们的工作和教育，并在疫情期间保持重要的人际交往。WebRTC 未来的机遇和影响确实令人着迷。
Benjamin Treynor Sloss, Shylaja Nukala, Vivek Rau - 重要的指标
衡量您的站点可靠性指标，设定正确的目标，并努力准确地衡量这些指标。然后，您会发现您的服务运行得更好，停机时间更少，并且用户采用率更高。
Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - 跟踪和控制微服务依赖关系
如果您曾经将钥匙锁在房屋或汽车内，您会熟悉依赖循环。您无法在没有钥匙的情况下打开锁，但您无法在不打开锁的情况下获得钥匙。有些循环很明显，但更复杂的依赖循环可能难以在它们导致中断之前找到。跟踪和控制依赖关系的策略对于维护可靠的系统是必要的。
Diptanu Gon Choudhury, Timothy Perrett - 为互联网规模的服务设计集群调度器
希望构建调度系统的工程师应考虑他们使用的底层基础设施的所有故障模式，并考虑调度系统的运营商如何配置补救策略，同时帮助租户系统在租户系统的所有者进行故障排除期间尽可能保持稳定。
© 保留所有权利。