主体交互

    由于上面列出的每个主体可能与其他主体交互，因此图 1 中所示的中间层要求为每个交互提供一个这样的关系图。对于具有表 1 中所示的聚合的 SOA 实现，大约可能会有 1000 x 1000 个交互。即需要考虑的（至少在 HLD 中如此）主体间的潜在交互数量为 1,000,000。

表 1. SOA 主体计数

    保护主体交互

    随着对主体间的交互的进一步细分，将出现特定的 SOA 安全服务来专门负责保护这些交互。在开始 SOA HLD 前，团队应该创建将服务与主体关联的表格。表 2 显示了一段需求文本摘录，其中的 identification 服务与所有主体关联。

表 2. SOA 安全需求

    可以通过主体/服务表对此关联关系进行进一步说明，此表在构造 HLD 时非常有用。表 3 所示的就是一个这样的表格。

表 3. SOA 安全主体/服务表

    请注意，此流程不是静态的，而是动态的：收集了足够的需求后，团队就基本上准备好开始初级 HLD 的工作了。随着其他需求的添加，将继续影响 HLD。而且，随着 HLD 的不断充实，在达到稳定状态（一个文档中的更改不会对其他文档造成影响）前，也可能会出现其他意料之外的需求。

    首先，团队不应太过于关注一个体系结构概念，因为创建 SOA HLD 的过程可能变化非常大，涉及到很多涉众。因此，最好使用有助于 HLD 设计和 HLD 设计管理流程的工具。SOA 安全团队成员应该熟悉“Developing a J2EE Architecture with Rational Software Architect Using the Rational Unified Process”之类在线教程。同样，HLD 的目的首先是向 SOA 安全团队进行清楚地说明。然后，应该与 EA 合作，确保文档与企业模型的总体体系结构概念一致.