关键字：soa 可访问性。如果有数百个服务，则需要定义一个可靠的方法，以便客户找到正确的服务并知道如何有效地使用这些服务。我通常不建议在初始 SOA 期间采用注册中心或统一描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）。确定开始使用注册中心的合适门槛是 50 个服务。并没有所谓“神奇”的数字，也没有用于选择哪个数字的基本原则，这需要您自己做出决定。
功能。由于构建的服务较多，因此务必对每个服务的功能进行分析。确保功能重合尽可能少。例如，正在构建的新服务是否可通过对现有服务进行组合得到？此服务是否真的是新服务，或者仅是某个现有服务的不同变体？
交互。此时您可能并不知道自己对哪些东西不了解。您无法预测别人会如何（使用何种技术）、何时、何地或为什么使用某个特定的服务。必须对您的服务交互进行仔细考虑，且必须最大限度地遵循各项标准。
信息。无论服务数量如何，这个领域都不会发生改变。只要记住，在服务增多的情况下，必须对通过其中的信息量加以管理。对公共词汇的使用就变得非常重要了，您需要开始考虑能够定义和采用的现有 XML 标准或新标准。
流程。您组织中的 50、100 或 200 个服务如何一起工作？这些流程如何更改，这些更改如何影响每个流程？
这些方面仍然适用于您将作为企业 SOA 的一部分推出的每个服务。不过，您需要在每种情况下考虑的事情的定义扩大了。本文指出了您需要捕获的其他信息——这并不能替代您在前一部分捕获的每个类别的信息。
企业 SOA 的其他需求
需要为真正的企业 SOA 收集哪些其他信息？请记住，企业 SOA 的概念着眼于“变化”。使用 SOA 的基本业务需求是支持业务敏捷性——也称为变化。开始收集这些需求时需明白一点，即没有人真正知道正确答案是什么。您需要为每个需求类别中的变化做出计划。成功的企业 SOA 始终处于不断变化的状态——它在不断发展，持续支持随时可能出现的改变。
此类需求的高级类别包括：
编排。现在已经从有少量与其他应用程序交互的状态过渡到了拥有与自己或其他企业构建的服务进行交互的服务的状态。这些服务之间的编排或建模至关重要。作为需求的一部分，您需要对这些交互进行一些假设，并针对其进行一定的计划。务必记录每个服务的异步交互、服务版本控制和退役计划等等。
安全。毫无疑问存在安全顾虑。确保您从 SOA 服务的角度认真地对待安全性问题。哪些人能够访问哪些服务？哪些人能够访问每个服务中的哪些数据？在服务间传递服务时，如何保护数据的安全？
文章来源于领测软件测试网 https://www.ltesting.net/
