　　企业 SOA(此术语在本文所述的上下文中使用)指代具有数十或数百服务的组织。这包括内部服务(供企业内的客户使用)、合作伙伴服务(供企业客户使用)和客户服务(供 B2B 客户以及最终客户或使用者使用)。您的 SOA 项目已从试点开始向广泛部署过渡。您开始将公司视为一个成熟的 SOA 组织——或者正在逐渐成熟的 SOA 组织。

　　在此阶段，您可能已经回答了是否应该实施 SOA 的问题。资金投入不是问题——已经证明了 SOA 的价值。当然，您可能将仍然面临单个服务或一组服务的资金投入问题，但将不会有人对 SOA 的整体价值提出质疑了。

　　企业 SOA 的技术需求

　　尽管本文的大部分都关注的是业务问题，但我们仍然需要首先讨论一些基本技术问题。

　　初始 SOA 的需求

　　首批 SOA 服务的需求关注五个主要方面。

　　可访问性。如果有数百个服务，则需要定义一个可靠的方法，以便客户找到正确的服务并知道如何有效地使用这些服务。我通常不建议在初始 SOA 期间采用注册中心或统一描述、发现和集成(Universal Description, Discovery, and Integration，UDDI)。确定开始使用注册中心的合适门槛是 50 个服务。并没有所谓“神奇”的数字，也没有用于选择哪个数字的基本原则，这需要您自己做出决定。

　　功能。由于构建的服务较多，因此务必对每个服务的功能进行分析。确保功能重合尽可能少。例如，正在构建的新服务是否可通过对现有服务进行组合得到?此服务是否真的是新服务，或者仅是某个现有服务的不同变体?

　　交互。此时您可能并不知道自己对哪些东西不了解。您无法预测别人会如何(使用何种技术)、何时、何地或为什么使用某个特定的服务。必须对您的服务交互进行仔细考虑，且必须最大限度地遵循各项标准。

　　信息。无论服务数量如何，这个领域都不会发生改变。只要记住，在服务增多的情况下，必须对通过其中的信息量加以管理。对公共词汇的使用就变得非常重要了，您需要开始考虑能够定义和采用的现有 XML 标准或新标准。

　　流程。您组织中的 50、100 或 200 个服务如何一起工作?这些流程如何更改，这些更改如何影响每个流程?

　　这些方面仍然适用于您将作为企业 SOA 的一部分推出的每个服务。不过，您需要在每种情况下考虑的事情的定义扩大了。本文指出了您需要捕获的其他信息——这并不能替代您在前一部分捕获的每个类别的信息。

　　企业 SOA 的其他需求

　　需要为真正的企业 SOA 收集哪些其他信息?请记住，企业 SOA 的概念着眼于“变化”。使用 SOA 的基本业务需求是支持业务敏捷性——也称为变化。开始收集这些需求时需明白一点，即没有人真正知道正确答案是什么。您需要为每个需求类别中的变化做出计划。成功的企业 SOA 始终处于不断变化的状态——它在不断发展，持续支持随时可能出现的改变。

　　此类需求的高级类别包括：

　　编排。现在已经从有少量与其他应用程序交互的状态过渡到了拥有与自己或其他企业构建的服务进行交互的服务的状态。这些服务之间的编排或建模至关重要。作为需求的一部分，您需要对这些交互进行一些假设，并针对其进行一定的计划。务必记录每个服务的异步交互、服务版本控制和退役计划等等。

　　安全。毫无疑问存在安全顾虑。确保您从 SOA 服务的角度认真地对待安全性问题。哪些人能够访问哪些服务?哪些人能够访问每个服务中的哪些数据?在服务间传递服务时，如何保护数据的安全?

　　尽量保持简单(keep it simple, stupid，KISS)。对于任何希望使用该服务的人而言，实际使用该服务的过程是否足够简单?此需求既是业务需求，也是技术需求，必须认真加以分析。尽可能少地对服务的任何潜在使用者的业务和技术成熟度进行假设。服务应该方便调用，能正常工作，具有良好的错误报告能力，且通常能够与其他服务进行集成。成熟度较低的企业应该能够使用您的服务，而且不需要在技术方面进行大量资金投入，也不需要对其业务流程进行较大的更改。

[1] [2] 下一页

上一篇:国外资深记者：我喜欢Vista的11大理由

下一篇:惊爆 Vista光盘中竟有3个神秘隐藏人物