最后，需要强调的是RR的这一理念很好地符合了商业中面向服务的概念。RR满足了面向服务商业中的一个基础要求：“要想和对方做生意，就必须了解对方。”换句话说，在服务交互开始前，客户必须与供应商或者服务所有者建立起信任关系。在IDF中，需要建立起真正客户与相应作为服务代表的RR间，以及RR与另一身份域间关系，如图1所示。 （点击图片看大图）
图1.两个身份域的域代表 一个RR可以被看作是一个中介，以维系一个ESB系统。技术往往倾向于将ESB系统置于客户与服务中间来脱离它们直至互不认识。这是特别遗憾的，因为它不仅破坏了[7]商业交互要求，同时也破坏了SOA-RAF中定义的服务交互模型。如果ESB想隐藏某个服务，以及管理服务中任何除了信息路由或端点决策东西时，它本身都要变成一个服务或服务代理。它无法成为架构的一部分，这意味着它需要为客户处理并提供所有相关的商业责任，就像一个RR所做的那样。 一个实际例子假设我们有一个客户公司Ace Corporation和两个服务：Catering和FoodPro。其中Ace集团和Catering服务同属于身份域Town，而FoodPro属于身份域Vill。Ace已经和Catering建立起信任关系，并在相应合同条款内同意让Catering为Ace的小卖部提供服务。因此，Ace将启用Catering的某些功能和操作。Ace和Catering间的合同里说明了Ace有兴趣，而且也准备好按照合同价格只支付本地食品原料，而不包括Town以外的运输费。 Town和Vill的部分信息是公开的，并在两个域中相互知晓，但并不足以完成域间的商业操作，还须有对注册政策的服从。 显然，Catering必需依据Ace的订单大小添加一个类似与FoodPro所提供的附加功能。Catering意识到Vill，但是由于不是Vill的会员进而无法与其会员直接交互。与此同时，Town的卡车服务已拥有Vill域中的成员资格。该卡车服务提升它在Vill商业服务中运输产品的能力。 （点击图片看大图）
图2.跨安全边界的商业交互 因此Catering联系了Town里的卡车服务。该卡车曾经服务过FoodPro，并能在运输上提供一些优惠，比如，它可以使用FoodPro中只对Vill居民开放的部分功能。另外，卡车服务可以联系Vill中其他食品供应商，并在与本地服务竞争对手竞争时获取优势。该附加商业价值吸引了Catering，使他决定使用Truck的服务，而非成为Vill域中一成员，为了其市场份额而努力。 当Ace与Catering建立起服务合同时，Cattering与卡车服务也建立起了附加服务合同，这反过来，建立起一个如图2所示的与FoodPro相关联的服务合同。很有可能客车公司在与FoodPro签订附加服务合同时，他就已经和Catering签订了服务合同。当FoodPro接受到卡车服务的合同请求时，因为该请求是从Vill发过来的，FoodPro并不会问它是如何发起的。因此，如果FoodPro意外接收到来自卡车的Ace身份，FoodPro将无从处理。 附加想法在现实世界的SO生态系统和云中，对终端用户身份的渗透是无效的，甚至是不安全的（一个商业服务可以学习到谁是另一商业的客户）。我们已经建立了以下事实：不同认证或身份域，连同不同服务或商业所有者在云里由于他们相对立的利益，都是竞争关系。因此，越过直接交互实体范畴，对终端用户身份渗透进行投资在资源和资金上都是一种浪费。 我们知到服务只考虑与它直接交互的客户和供应商，它并不处理来自其他服务的客户。服务或客户可能需要来自外部身份域服务所提供的功能，以及交叉域边界上一个良好的商业解决方案（连同所有权边界）都是推荐的基于RR的身份联合模式。在该模式中，所有服务和客户都在注册认证权威的控制和保护下，停留在他们身份域的同时，通过后者共享的域代表相互联合起来 |
