| UML软件工程组织 | |||
| |
|||
|
|||
避免在 SOA 采用过程中遇到的常见失误
作者：Tilak Mitra 来源：IBM
讨论采用面向服务的体系结构（Service-Oriented Architecture，SOA）可能出现的障碍，并了解用于避免这些问题所采取的措施。 引言IT 体系结构已非常成熟，它是一种成功处理典型 IT 问题的方法。体系结构中一个受到很大重视的相对较新的分支是面向服务的体系结构 (SOA)。SOA 经常被吹捧为企业用于解决应用程序灵活性和高维护成本问题的万能药，常常被视为帮助企业提高其 IT 投资回报（Return On Investment，ROI）的方法。SOA 是用于进行 IT 系统设计以确保业务目标与 IT 一致的主要体系结构样式，允许构建具有弹性的 IT 系统来满足新的和不断变化的业务需求。 SOA 的优点（如提高灵活性、互操作性以及降低维护成本）得到了广泛的宣传，且经受住了时间的考验。这个成功记录让越来越多的企业开始跟着采用 SOA，努力想获得这些好处。企业宣布启用 SOA 将导致 SOA 活动的增加，如对遗留应用程序进行转换和现代化工作，从而实现以服务为中心，并遵循 SOA 的原则和最佳实践。但 SOA 倡导者和采用者在应用 SOA 时需要保持警惕，因为采用 SOA 的过程并不总是一帆风顺或完全不出问题。 在本文中，您将了解各种常见问题，如果架构师和开发团队在未进行全面而细致的前期工作的情况下贸然尝试采用 SOA就可能遇到这些问题。 正如模式是获得反复成功的明确选择，反模式会带来很容易导致失败的失误。在开发人员和架构师尝试全面了解 SOA 最佳实践时，同样要重视 SOA 采用过程中的常见失误。 最常见的失误包括：
供应商专有服务产品SOA 的基本原则之一是，它能跨各种异类功能和基础设施环境提供服务互操作性。尽管 SOA 产品供应商正在进行大量的开发工作，以提供功能和基础设施服务组件，但这些产品经常会采用其提供的服务的专有形式。购买这些产品并将这些产品作为其 SOA 的基础的企业可能很快就发现自己被限制在了供应商服务组件的专有特性内。 SOA 是基于业务需求定义的，具有突出的互操作性和灵活的服务即插即用功能。绝不应该使用其服务并不基于稳定的开放标准的专有供应商产品来损害这种灵活性。请注意，除非供应商的 SOA 产品符合制定得非常完善的开放标准，以此作为其提供的服务实现的基础，否则，在使用这些产品时就应该格外小心。为了实现基于 SOA 的过渡的长期成功，必须为其实现支持、采用和实施开放标准。 开放标准的稳定性那么，为了真正获得服务间互操作性的好处，您的 SOA 实现必须遵循被广泛接受的现有开放标准（例如 WS-* 规范），而不管是对服务从头开发、重用还是从供应商购买。 任何基于 SOA 的开发工作都必须仔细地分析已确定要遵循和采用的开放标准集。如果确定的开放标准仅处于设计或规范级别，而更为成熟稳定的版本尚未发布和广泛采用，则 SOA 可能会遭遇传统的维护困境。随着每个标准规范的新版本的发布，业务应用程序还将需要进行恰当的更改，以与标准保持一致。如果标准没有得到广泛接受，或仅由一个供应商提出且尚未得到行业内大幅度的认可，同样的问题可能会变得更为关键。 不过，市场上被看好的最新开放标准并不一定是可采用的最佳标准。它仍然要经历自己逐渐成熟并被主流供应商采用的过程。至少，它必须具有定义良好的路线图，以过渡到稳定成熟的版本。 遗留资产现代化遗留资产现代化是企业采用 SOA 时的一个重要方面。任何过去数十年使用 IT 系统的企业都一定具有帮助其开展业务的遗留应用程序。遗留系统可以存在于基础设施级别，也可以存在于操作级别；例如，运行企业人力资源（Human Resource，HR）系统的 IBM CICS? 大型机。遗留系统还可能以特定基础设施组件和操作环境上运行的过时软件或编写质量较差的软件应用程序的形式存在。 当企业采取行动对其 IT 基础设施进行现代化工作并使其与业务要求保持一致时，IT 团队需在为过渡到基于 SOA 的投资组合构建业务用例前对现有的遗留系统进行更为深入的分析。此类分析经常采用竖井方式执行，而这意味着将选取特定的独立业务域进行临时性的遗留资产现代化工作。 如果在没有全面考虑整个企业的情况下或在没有考虑依赖关系和相关业务域或能力的情况下进行遗留资产现代化工作，则可能创建重复的服务和应用程序编程接口（Application Program Interface，API）。这种重复的情况源自缺乏对现有服务投资组合的详细分析。必须使用 80-20 原则对现有服务进行仔细分析：如果可满足当前现代化要求至少 80% 的所需功能的现有服务仅需要 20% 的工作就能完全从头构建，则最好通过以现有服务为基础实现新要求。 如果企业 IT 组织的操作方法是通过采用竖井 SOA 遗留资产现代化工作进行的，则能从 SOA 得到的潜在好处可能就会大打折扣。即，如果在没有评估整个系统的情况下进行自动化工作，很可能无法得到真正的 SOA。在这些业务模型类型中，SOA 并不是适合采用的好方法。尽管进行了相关的工作，但 SOA 的业务价值将很难得到业务涉众的认可。 “瀑布”式开发和缺少服务版本控制采用瀑布式方法可能是在进行 SOA 工作的过程中的常见问题之一。瀑布方法应用于传统应用程序开发时，就意味着存在严格的开发序列（如解决方案概要、宏观设计、微观设计），要依次进行开发、编码和单元测试（Develop, Code, and Unit Test，DCUT）。对 SOA 采用这种方法可能导致创建仅能部署一次的服务，而无法在以后对其进行重用。 SOA 不能一蹴而就。企业应该以迭代的方式过渡到 SOA，要进行阶段划分，并创建计划良好的转换路线图。路线图确定最活跃的业务领域，SOA 采用工作可以在其中对业务和 IT 的需求进行结合。此过渡可以在业务域级别上进行；经过标识并随后采用类似方式开发的服务可从迭代开发获益。 根据迭代方法的要求，服务必须具有定义良好的生命周期，如图 1 中所示。 图 1. SOA 中服务的生命周期
此生命周期的一部分涉及到对您开发的每个服务进行版本控制。有版本控制的服务可确保该服务的升级并不需要重新测试应用程序使用的所有其他服务。服务版本控制能为服务的不同使用者提供服务水平协议（Service-Level Agreement，SLA）的不同级别支持，另外还具有其他很多好处。服务版本控制还允许对服务进行迭代开发，并能基于业务功能需求进行持续的改进和增强。 对于大型的面向服务的企业，服务版本控制应该成为服务管理生命周期不可或缺的一部分。因此，企业的 IT 环境的操作功能要具有可靠的 SOA 管理基础设施这一点非常重要。如果不能满足此要求，则会对面向服务的企业的增长造成严重的限制。 服务版本控制也属于 SOA 治理的讨论范畴之内，我们稍后将对 SOA 治理进行讨论。不过，对于刚刚开始进行 SOA 开发的人员而言，常常会忽略对版本控制加以考虑，因此我们将这个问题在此单独列出。 了解遗留系统的技术限制大量 SOA 工作都非常依赖驻留在遗留系统内的现有数据和应用程序。 遗留系统的某些功能通常并不能适应基于 SOA 的应用程序中的实时特性。这种问题的一个典型例子就是单线程遗留应用程序，在此类应用程序中，业务功能的实现仅允许进行单线程访问。遗留系统限制的另一个例子是仅在固定时间运行的计划批处理。目前，竞争型企业的实时事务需求相对较多。 决定将遗留应用程序或数据作为 SOA 系统的一部分时，务必理解这可能会给整个 SOA 带来的限制。如刚刚提到的，遗留应用程序的单线程特性就是遗留系统技术限制的一个例子。现代企业的业务功能经常可保证提供远远超过现有系统的功能之外的基础设施事务功能。在此类情况下，可以构建以现代基础设施组合为基础的基于 SOA 的解决方案来逐步淘汰遗留系统。为此，组织需要选择对业务最重要的功能，并使用基于技术先进的基础设施的解决方案来替换其现有遗留实现。完成此阶段工作后，可以随后对其他业务功能进行现代化。此方法提供了用于逐步淘汰遗留系统的可行选择。 将 SOA 与 Web 服务划等号将 Web 服务实现等同于 SOA 是一个典型的 SOA 反模式，这种情况通常发生在企业希望快速实现 SOA 但并未评估其 IT 系统（包括应用程序和基础设施）的成熟度时。此类企业会将所有内容都作为 Web 服务实现。集成开发环境（Integrated Development Environment，IDE）的发展已确保进行 Web 服务创建的技术部分得到无缝支持，并不要求进行大量的学习，从而使得 IT 部门能非常方便地创建 Web 服务，而不会过多考虑是否与企业的业务目标一致。Web 服务的大量增加带来了管理困难，并为基础设施操作带来了不必要的成本。因此，如果企业的远景仅是实现一组 Web 服务，然后尝试获得 SOA 所带来的好处，最好后退一步，重新对此进行考虑。 如果企业希望充分利用 SOA，则需要彻底了解体系结构和实现之间的差异，并对这一事实加以尊重。Web 服务是用于实现 SOA 的最流行的实现，SOA 是一种体系结构样式，允许 IT 服务与业务需求保持一致，从而确保 IT 的业务价值。为了获得 SOA 的好处，企业 IT 团队需要完全了解 SOA 和 Web 服务间的区别。即，IT 团队需要认识到，SOA 是一个体系结构规程，而 Web 服务是目前最流行的 SOA 实现 技术。 建模和设计 SOA 时，强烈建议 IT 团队采用标准方法。IBM 的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）提供了用于进行建模和设计的规定性详细方法。从最高的抽象级别而言，SOMA 提供了包含三个步骤的流程，用于进行服务标识、规范制订和实现，可帮助创建能用于 SOA 实现的输出。另外，还建议在设计 SOA 前对各个领域（如业务角度、组织、应用程序、体系结构）的企业服务集成成熟度进行评估。通过评估这些领域的成熟度水平，可对企业的当前状态进行评估；您可以随后创建增量转换路线图，以达到更高的服务集成成熟度水平。为了帮助您完成此任务，IBM 提供了称为服务集成成熟度模型（Service Integration Maturity Model，SIMM）技术。此 SOA 评估工作对以认真态度对待其 SOA 过渡的企业非常有帮助。 采用竖井方法处理服务创建和所有关系SOA 是一个相对较新的体系结构概念，可帮助弥合 IT 解决方案和业务目标之间的差距。SOA 还代表了从传统应用程序体系结构的概念和范畴进行的范式转换。应用程序体系结构通常作为独立的工作创建，此类工作通常属于特定组织域或实体。通常构建应用程序来实现单个组织域中的业务应用程序的自动化。这些单一域应用程序也称为“竖井”应用程序。顾名思义，竖井应用程序的原则和实现不能直接应用到 SOA。 当企业开始采用 SOA 时，从竖井开发进行范式转换并未得到良好的制度化。服务可能会基于独立应用程序进行标识，从而导致服务的标识和实现（由相同企业中的不同组织进行）在语义上类似，但却具有不同的名称。这种重复不仅会妨碍得到 SOA 所承诺的真正好处，而且还会增加开发和操作基础设施成本。 共享服务的概念应该在企业内得到制度化，必须对其好处有足够的认识。服务应该被视为整个组织内的实体，而真正的业务流程是通过使用多个服务来编排业务而实现的。流中的服务可以属于企业内不同的业务部门。 服务必须全面发布，以供整个组织内部使用，或在多个企业参与的服务生态系统中供外部使用。必须放松组织边界和约束的限定，以便实现共享服务的真正好处。 必须形成一个工作机构，其主要负责标识服务和建立治理框架来帮助定义作为实现候选的服务的所有关系、资金投入和生命周期。如果没有此类治理机构，企业就很难阻止竖井服务的增多，也很难实现 SOA 的好处。 竖井问题是 SOA 采用中的一个常见问题；将在稍后讨论更大的 SOA 治理问题，但务必认识到，治理是用于减少竖井方法的缺点的重要解决方案。 细粒度服务甚至在开始 SOA 活动前，业务信息（数据）和应用程序功能也通常存在于当前的企业 IT 投资组合中。这些传统的企业应用程序通常是基于 API 的。用于访问客户信息的典型 API 的示例有 getFirstName()、getLastName() 或 getCelPhone()。这些 API 本质上通常是非常细粒度的。 一个常见的 SOA 错误做法是，使用服务接口包装这种细粒度 API，并将其通过 Web 服务描述语言（Web Services Description Language，WSDL）定义对外公开。这会导致错误地将服务概念看作不过是“使用昂贵的服务 Facade 包装的漂亮 API”。不仅得到的“服务”仅传递很少的业务数据，而且这种做法也会导致服务数量剧增。从而导致使用者要负责按照正确的顺序聚合服务，以便实现任何高级业务功能。 请记住，服务并不是免费的：对于调用每个服务，应用程序都将以损失一定性能为代价。刚刚提到的失误将导致服务间频繁通信，从而导致系统开销增加，所带来的性能损失将对 SOA 采用造成极大的阻碍。 正如我们多次提到的，服务必须与业务保持一致，并能为企业提供真正的收益潜力（无论通过减少成本和节约，还是通过产生收入）。创建仅模拟 API 实现的细粒度服务将不能为 SOA 或企业提供任何帮助。 服务可以通过聚合多个低级细粒度 API 实现的功能来实现。不要将每个细粒度 API 都作为服务公开；应该从 API 抽象出粗粒度的、与业务一致的接口，然后将此接口作为服务公开。这不仅能减少网络开销和各个应用程序层次间的通信量，而且还向与业务保持一致的服务接口迈进了一大步。 点到点调用服务提供者和服务使用者的概念对 SOA 非常重要。使用者对服务的使用可以通过多种方法实现。在此领域最常见的失误是采用点到点调用。这种方法会导致公开 SOA 系统中服务使用者和提供者间的连接。这种点到点连接被公开的糟糕情况如图 2 中所示。或许您可以让此类系统投入运行，但又如何长期对其进行维护，并同时跟踪所有连接，而且在其中任意一个服务或应用程序被替换或重写时进行必要的更改呢？ 图 2. 应用程序间的点到点服务调用
当企业在应用程序间采用复杂的紧密耦合时（特别在投资组合中存在大量应用程序时），需要配备恰当的服务调用体系结构。IT 系统设计需要创建逻辑体系结构层，以封装和执行（数据）转换、（服务调用）路由和（可能的不同服务的异类实现间的）协议中介。通过这样进行分解，可以在服务提供者和使用者间实现松散耦合。图 3 描述了一个这样的逻辑体系结构，其中的服务提供者和服务使用者通过逻辑总线进行通信。 图 3. 服务调用的轮辐式通信模式
该图显示了服务使用者如何通过中间层同服务提供者分离。使用者与逻辑总线进行通信，而后者跟踪来自提供者的可用服务，并负责调用恰当的提供者。这就减少了具有大量服务的系统中的点到点通信导致的问题。在进行服务实现前，如果尚未定义，应该对体系结构（如图 3 中所示的体系结构）进行概念化。这个规则特别适用于包含大量需要面向服务和进行集成的应用程序和遗留系统的企业。 不遵循标准采用 SOA 时，务必遵循开放标准，而不要尝试忽略这些标准或自己创建替代解决方案。例如，最好创建企业基础设施来使用统一描述、发现和集成（Universal Description, Discovery and Integration，UDDI）作为将来的联合注册中心生态系统，而不要使用服务发现标准或构建服务发现自定义解决方案（如使用服务名称与 URL 数据库）。 在 SOA 中的服务规范制订期间，尤为重要的是，要遵循行业特定的标准 XML 规范。此类行业特定标准定义消息的格式和业务实体，必须将其作为定义构建服务时使用的消息格式和数据类型的基础使用。 现在亟待针对整个行业提出 XML 规范来定义企业信息模型及用于与模型一起使用的一组标准服务操作。很多垂直行业正在朝着这个目标快速发展。例如，Agent-Company Organization for Research and Development (ACORD) 是针对保险行业的基于 XML 的标准，Justice XML Data Dictionary (JXDD) 是针对美国国土安全部使用的事故管理规程的基于 XML 的标准，而 OpenTravel Alliance (OTA) 则是旅行和运输行业的标准。这些标准均已作为稳定规范发布，越来越多的基于 SOA 的工作正在采用这些标准。 通过遵循公共消息格式词汇进行消息交换来采用并遵循此类标准，可以使得 SOA 足够灵活，能在生态系统中的合作伙伴之间进行共享。它还允许对符合并实现这些标准的供应商 SOA 产品进行即插即用。此灵活性是定义和结构设计良好的 SOA 的关键元素之一，可支持成功创建大型 SOA 生态系统。 在没有此类意识且不进行专门的行业标准分析和采用工作的企业中，开发团队需要考虑标准的重要性，并将其制度化。恰当的控制框架在向涉众说明此消息时将非常有用，可帮助确保遵从性和成功采用。在对标准没有足够重视但仍然需要 SOA 的情况下，组织将不能得到 SOA 的很多主要好处。 使用冗余数据存储在包含具有多年应用程序处理经验的 IT 部门的典型大型企业中，经常会发现包含重复信息的多个数据存储和数据库系统。之所以这样做的主要原因是采用了典型的竖井方法，在这种方法中，应用程序必须分离，各个应用程序的重点都是企业内的单个组织单位。 当企业开始向 SOA 过渡时，抛开所有现有系统并重新从头构建所有内容的做法并不实际。不过，在此类环境中，针对不同数据源（即使这些数据源中包含完全相同的数据）构建 IT 服务的做法并不少见。 更为有效的方法是对数据进行整合，以便异类数据系统能形成单个数据视图（例如，创建单个经过整合的数据库来存储客户信息）。处理此问题的另一个方法是创建虚拟数据服务，以将数据冗余封装在企业信息系统中，并通过高级服务或业务流程使用此数据服务。 为每个数据系统分别创建服务并不是使用 SOA 对企业信息系统的信息进行聚合的好方法，因此必须避免这样做。 “大爆炸”式 SOASOA 的定义并不完全相同，具体取决于您在组织中的角色。对于业务执行人员，SOA 创建了企业希望向其客户和合作伙伴或组织的其他部分公开的一组服务。对于架构师，SOA 是一种体系结构样式，此样式至少需要有服务提供者、请求者和服务描述。对于程序员，SOA 是一个由标准、工具和 Web 服务等技术加以补充的编程模型。要理解和认识 SOA 过渡是整个企业（涉及 IT 和业务部门一直到相关涉众）的范式转换并不难。此类范式转换最好通过迭代模型实现，在此类模型中，将标识一组对业务非常关键且价值高的功能来进行服务支持工作。此模型可随后供后续服务支持项目和活动使用。如果采用“大爆炸”方法，计划一次性对整个企业投资组合全面启用服务，将给整个组织带来太多的业务风险。 SOA 与其他体系结构不同，因为它显式地处理了企业很多的非技术约束。其中一个约束就是，大型组织往往采用增量方式逐步发展。组织的 IT 基础设施应该支持类似的发展方式。这样的迭代式发展路线可解决以下问题：
由于 SOA 具有两个重要的特征，因此非常适合采用迭代方式逐步过渡到其最终状态：
想进行“大爆炸”式过渡的企业可能并不适合使用 SOA，更不用说实现 SOA 的真正好处了。 服务所有关系业务服务的需求在部门或组织级别标识，其中的每个业务部门都具有特定的业务功能需求。其中一些业务功能直接与企业的业务目标保持一致，而这意味着可能会将其作为通过外部化服务定义说明的服务接口公开。 没有恰当地指明服务所有关系模型时，会出现一个问题。很多企业强调提供大量服务，将这些服务用于进行组合。而这些服务的所有关系需求通常却被忽略了。 每个业务服务必须具有其所属的、进行了恰当记录并被一致认可的 LOB。伴随所有关系的是满足服务的非功能要求（NonFunctional Requirement，NFR）和负责处理不遵从情况的责任。孤立业务服务的一个典型结果是不遵从服务 SLA，而这可能使得服务成为企业级服务组合中最弱的联系。这个最弱的联系甚至可能会破坏此孤立服务参与的业务流程的总体 SLA 要求，从而造成企业级的负面影响。 虽然对给定服务的 LOB 所有者而言，此类要求可能很高，但 LOB 所有者可以提供服务来创建积极的影响。假定 LOB 所有者将向其他部门的服务使用者收取一小笔费用。反过来，她将严格遵循指定的服务水平 SLA 和 NFR。这可以帮助她所在的业务单位补偿服务的开发成本。 业务域所有关系也同样重要，因为企业服务投资组合不应该交给 IT 部门进行开发和维护工作。如果 IT 驱动企业的 SOA 开发，他们通常会首先以最方便开发服务为目标（这也是可以理解的），而不会太多注意服务的业务价值。这个方法将导致业务目标和所开发的服务间的不一致。在这种情况下，SOA 的好处就不能实现。 服务的业务单位所有关系对企业 SOA 活动的成功至关重要。当未实现业务所有关系模型时，SOA 可能成为企业 SOA 成功的拌脚石。 SOA 治理治理是一个决策权限和管理框架，可确保在正确时间由经过授权的正确人员进行正确处理。 企业进行 SOA 转换时，由于服务所有关系通常分布在各个 LOB 中，因此需要认真对待治理问题。必须由企业内外各个组织进行维护的移动部件正在快速地增加，这使得有必要进行相应的治理。当且仅当服务得到有效的治理，严格遵循 SLA 和 NFR（如安全性、可靠性、性能等方面）时，业务服务的这种跨组织特性和潜在的跨组织边界的服务组合才能正确而有效地发挥作用。 为了标识、指定、创建和部署企业服务，需要通过能够监督企业的服务投资组合的整个服务生命周期的强大而有效的组织进行有效的面向服务的治理。为了保证策略规则和决策及其执行和组织良好的服务生命周期管理要求，需要将 SOA 治理的实现作为企业 SOA 转换的策略和计划阶段的一部分，而不是一个事后再添加的东西。 在 SOA 的早期，治理仅是一个不错的可选规程。但随着在具有复杂、集成的价值链的实际企业中 SOA 实现的不断成熟和复杂性的不断提高，SOA 治理如今在整个 SOA 过渡策略中扮演着不可或缺的角色。 未认识到有效治理结构的重要性的企业可能不会从 SOA 得到太多的好处。事实上，此类企业中的 SOA 实现会被证明实际上具有破坏性，而且缺乏正确的组织结构来有效地遵循恰当的 SOA 原则和获得其好处。 其他注意事项企业应该避免为了创建软件组件、基础设施解决方案和服务来解决单个具体业务问题而购买中间件产品、数据库系统和管理解决方案。此类具体的一对一的产品到解决方案映射可能会带来冗余，或被证明成本太高，不适合 SOA 实现。相反，应该将重点放在确定问题间的共性，然后将这些共性反映到技术解决方案中。 不应强制要求在 SOA 开发的过程中进行问题域间的过度分离。细粒度问题空间之间的此类过度分离可能导致基于服务的总体解决方案过度零碎。这样可能会导致解决方案非常低效，特别在延迟和性能非常关键的情况下更是如此。 如果没有恰当的 SOA 远景，SOA 设计人员和实现人员将无法确定企业应该达到的最终状态。服务必须能追溯到一个或多个业务目标，以证明其存在的必要性。如果无法根据某种业务度量标准测定 SOA 的好处，则 SOA 过渡的整个目的就值得商榷了。显然，在没有恰当标识、定义和记录 SOA 远景、业务目标和业务灵活性度量标准的情况下就着手进行 SOA 活动并不明智。 最后，企业需要了解自己对灵活性的需求。每个企业的业务灵活性需求并不相同。它们是由竞争和差异化策略、上市时间及各种其他因素驱动的。灵活性需要通过 SOA 实际实现；灵活性的总体工程工作可能会影响企业的 IT 系统性能。 总结SOA 无论如何都不是魔术，无法立即解决每个企业 IT 体系结构的问题。采用 SOA 时，企业应该充分了解各方面的信息，采取注重实效的方法，从而使得 SOA 的业务价值主张理论能与其实现的实际复杂性相符。不过，如果正确实现，且能避免此处讨论的种种失误，您将发现采用 SOA 的很多优势。 在本文中，您了解了在 SOA 采用过程中全面了解各种常见障碍与了解其好处和最佳实践一样重要。我们在文中讨论了一些实际情况，说明了未遵循 SOA 指导原则使用 SOA 的情况，并指出了典型的 SOA 反模式和错误使用。通过列出这些常见失误，您和您的团队可以更容易地加以避免，从而将与 SOA 采用工作相关的风险降低到最低限度。 最常见 SOA 失误简要列表下表对到真正 SOA 的平稳过渡过程中最常见的障碍进行了回顾。通过单击每个链接，可回到文中相应的部分。
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
