标识主体
在深入开展 HLD 的工作前，团队应该创建其必须加以保护的所有实体的列表。在安全领域中，必须保护的项目称为主体。以下是典型 SOA 系统的高级主体：
应用程序或服务
硬件
消息
编排
服务组件
SOA 组件（例如，企业服务总线（Enterprise Service Bus，ESB））
用户
实用工具
此外，SOA 安全团队应该生成高级图形表示形式，以说明团队成员将如何保护主体之间的交互。图 1 显示主体如何进一步划分为参与者 和资源，其中每个参与者可以为调用资源的功能的人员或计算应用程序，而每个资源则是服务功能、数据、组件或实际效果。主体之间的安全中间层可以进一步分解为执行点、决策点、契约和属性。
图 1. 受保护的主体交互
主体交互
由于上面列出的每个主体可能与其他主体交互，因此图 1 中所示的中间层要求为每个交互提供一个这样的关系图。对于具有表 1 中所示的聚合的 SOA 实现，大约可能会有 1000 x 1000 个交互。即需要考虑的（至少在 HLD 中如此）主体间的潜在交互数量为 1,000,000。
表 1. SOA 主体计数
SOA 主体 计数
应用程序或服务 50
硬件 50
消息 700
编排 50
服务组件 50
SOA 组件 (ESB) 1
用户 50
实用工具 49
共计 1000
保护主体交互
随着对主体间的交互的进一步细分，将出现特定的 SOA 安全服务来专门负责保护这些交互。在开始 SOA HLD 前，团队应该创建将服务与主体关联的表格。表 2 显示了一段需求文本摘录，其中的 identification 服务与所有主体关联。
表 2. SOA 安全需求
需求编号 服务 描述
1 Identification 所有主体必须能够唯一进行标识。
2 Identification 安全性必须提供分配给所有指定主体的唯一标识的机制。
3 Identification 安全性必须提供记录何时添加、删除或修改主体的标识。
4 Identification 安全性必须提供用于管理标识的管理接口。
可以通过主体/服务表对此关联关系进行进一步说明，此表在构造 HLD 时非常有用。表 3 所示的就是一个这样的表格。
表 3. SOA 安全主体/服务表
审核 身份验证 凭据 标识
应用程序或服务 X
硬件 X
消息 X
编排 X
服务组件 X
SOA 组件 (ESB) X
用户 X
实用工具 X
请注意，此流程不是静态的，而是动态的：收集了足够的需求后，团队就基本上准备好开始初级 HLD 的工作了。随着其他需求的添加，将继续影响 HLD。而且，随着 HLD 的不断充实，在达到稳定状态（一个文档中的更改不会对其他文档造成影响）前，也可能会出现其他意料之外的需求。
首先，团队不应太过于关注一个体系结构概念，因为创建 SOA HLD 的过程可能变化非常大，涉及到很多涉众。因此，最好使用有助于 HLD 设计和 HLD 设计管理流程的工具。SOA 安全团队成员应该熟悉“Developing a J2EE Architecture with Rational Software Architect Using the Rational Unified Process”之类在线教程。同样，HLD 的目的首先是向 SOA 安全团队进行清楚地说明。然后，应该与 EA 合作，确保文档与企业模型的总体体系结构概念一致。
