Previous | Table of Contents | Next |
An assumption made through most of this specification is that the existence of domain boundaries should be transparent to
requests: that the goal of interoperability is to hide such boundaries. However, if this were always the goal, then there
would be no real need for those boundaries in the first place.
Realistically, administrative domain boundaries exist because they reflect ongoing differences in organizational policies
or goals. Bridging the domains will in such cases require policy mediation. That is, inter-domain traffic will need to be
constrained, controlled, or monitored; fully transparent bridging may be highly undesirable. Resource management policies
may even need to be applied, restricting some kinds of traffic during certain periods.
Security policies are a particularly rich source of examples: a domain may need to audit external access, or to provide domain-based
access control. Only a very few objects, types of objects, or classifications of data might be externally accessible through
a “firewall.?
Such policy-mediated bridging requires a bridge that knows something about the traffic being bridged. It could in general
be an application-specific policy, and many policy-mediated bridges could be parts of applications. Those might be organization-specific,
off-the-shelf, or anywhere in between.
Request-level bridges, which use only public ORB APIs, easily support the addition of policy mediation components, without
loss of access to any other system infrastructure that may be needed to identify or enforce the appropriate policies.