10
In this architecture a domain is a distinct scope, within which certain common characteristics are exhibited and common rules are observed: over which a distribution transparency is preserved. Thus, interoperability is fundamentally involved with transparently crossing such domain boundaries.
Domains tend to be either administrative or technological in nature, and need not correspond to the boundaries of an ORB installation. Administrative domains include naming domains, trust groups, resource management domains and other \Qrun-time' characteristics of a system. Technology domains identify common protocols, syntaxes and similar \Qbuild-time' characteristics. In many cases, the need for technology domains derives from basic requirements of administrative domains.
Within a single ORB, most domains are likely to have similar scope to that of the ORB itself: common object references, network addresses, security mechanisms, and more. However, it is possible for there to be multiple domains of the same type supported by a given ORB: internal representation on different machine types, or security domains. Conversely, a domain may span several ORBs: similar network addresses may be used by different ORBs, type identifiers may be shared.
The concrete architecture identifies two approaches to inter-ORB bridging:
An object request may have implicit attributes which affect the way in which it is communicated - though not the way in which a client makes the request. These attributes include security, transactional capabilities, recovery and replication. These features are provided by "ORB Services", which will in some ORBs be layered as internal services over the core, or in other cases incorporated directly into an ORB's core. It is an aim of this specification to allow for new ORB Services to be defined in the future, without the need to modify or enhance this architecture.
Within a single ORB, ORB services required to communicate a request will be implemented and (implicitly) invoked in a private manner. For interoperability between ORBs, the ORB services used in the ORBs, and the correspondence between them, must be identified.
An ORB Service is often related to a particular transparency. For example, message encoding - the marshaling and unmarshaling of the components of a request into and out of message buffers - provides transparency of the representation of the request. Similarly, reference resolution supports location transparency. Some transparencies, such as security, are supported by a combination of ORB Services and Object Services whilst others, such as replication, may involve interactions between ORB Services themselves.
ORB Services differ from Object Services in that they are positioned below the application and are invoked transparently to the application code. However, many ORB Services include components which correspond to conventional Object Services in that they are invoked explicitly by the application.
Security is an example of service with both ORB Service and normal Object Service components, the ORB components being those associated with transparently authenticating messages and controlling access to objects while the necessary administration and management functions resemble conventional Object Services.
In order to discuss how the relationships between ORB Services are established, it is necessary to describe an abstract view of how an operation invocation is communicated from client to server object.
In other cases, such as security, client-side or server-side ORB Services may interact with Object Services such as authentication servers.
In principle, agreement on the use of each ORB Service can be independent of the others and, in appropriately constructed ORBs, services could be layered in any order or in any grouping. This potentially allows applications to specify selective transparencies according to their requirements, although at this time CORBA provides no ways to penetrate its transparencies.
A client ORB must be able to determine which ORB Services must be used in order to invoke operations on a server object. Correspondingly, where a client requires dynamic attributes to be associated with specific invocations, or administrative policies dictate, it must be possible to cause the appropriate ORB Services to be used on client and server sides of the invocation path. Where this is not possible - because, for example, one ORB does not support the full set of services required - either the interaction cannot proceed or it can only do so with reduced facilities or transparencies.
Figure 10-1 Different Kinds of Domains can Coexist.
Interoperability, by definition, introduces further distinctions, notably between the scopes associated with each ORB. To describe both the requirements for interoperability and some of the solutions, this architecture introduces the concept of domains to describe the scopes and their implications.
Informally, a domain is a set of objects sharing a common characteristic or abiding by common rules. It is a powerful modelling concept which can simplify the analysis and description of complex systems. There may be many types of domains, for example, management domains, naming domains, language domains, technology domains.
It is the scopes themselves and the object associations or bindings defined within them which characterize a domain.This information is disjoint between domains. However, an object may be a member of several domains, of similar kinds as well as of different kinds, and so the sets of members of domains may overlap.
The concept of a domain boundary is defined as the limit of the scope in which a particular characteristic is valid or meaningful. When a characteristic in one domain is translated to an equivalent in another domain, it is convenient to consider it as traversing the boundary between the two domains.
Domains are generally either administrative or technological in nature. Examples of domains related to ORB interoperability issues are:
For full interoperability, it is essential that all the concepts used in one domain are transformable into concepts in other domains with which interoperability is required, or that if the bridge mechanism filters such a concept out, nothing is lost as far as the supported objects are concerned. In other words, one domain may support a superior service to others, but such a superior functionality will not be available to an application system spanning those domains.
A special case of this requirement is that the object models of the two domains need to be compatible. This specification assumes that both domains are strictly compliant with the CORBA Object Model and the CORBA V2.0 Core specifications. This includes the use of OMG IDL when defining interfaces, the use of the CORBA Core Interface Repository, and other modifications that were made to CORBA V1.2. Variances from this model could easily compromise some aspects of interoperability.
Note that a direct consequence of this transparency requirement is that bridging must be bidirectional: that is, it must work as effectively for object references passed as parameters as for the target of an object invocation. Were bridging unidirectional (e.g. if one ORB could only be a client to another) then transparency would not have been provided, because object references passed as parameters would not work correctly: ones passed as "callback objects", for example, could not be used.
Without loss of generality, most of this specification focuses on bridging in only one direction. This is purely to simplify discussions, and does not imply that unidirectional connectivity satisfies basic interoperability requirements.
1. The simplest model, for interoperability, is to treat all objects supported by one ORB (or, alternatively, all ORBs of a given type) as comprising one domain. Interoperability between any pair of different domains (or domain types) is then achieved by a specific all-encompassing bridge between the domains. (This is all CORBA V2.0 implies.)
2. More detailed decompositions would identify particular domain types - such as referencing, representation, security and networking. A core set of domain types would be pre-determined and allowance made for additional domain types to be defined as future requirements dictate (e.g. for new ORB Services).
These observations suggest that the concept of an ORB (instance) is too coarse or superficial to allow detailed analysis of interoperability issues between ORBs. Indeed, it becomes clear that an ORB instance is an elusive notion: it can perhaps best be characterized as the intersection or coincidence of ORB Service domains.
Figure 10-2 Two bridging techniques, different uses of an intermediate form agreed on between the two domains.
Observations on mediated bridging are as follows:
Observations on immediate bridging are as follows:
· This approach has the potential to be optimal (in that the interaction is not mediated via a third party, and can be specifically engineered for each pair of domains) but sacrifices flexibility and generality of interoperability to achieve this;
· This approach is often applicable when crossing domain boundaries which are purely administrative (i.e. there is no change of technology). For example, when crossing security administration domains between similar ORBs, it is not necessary to use a common intermediate standard.
As a general observation, the two approaches can become almost indistinguishable when private mechanisms are used between ORB/domain implementations.
For example, if a single ORB encompasses two security domains, the inter-domain bridge could be implemented wholly within the ORB and thus be invisible as far as ORB interoperability is concerned. A similar situation arises when a bridge between two ORBs or domains is implemented wholly within a process or system which has access to both. In such cases, the engineering issues of inter-domain bridging are confined, possibly to a single system or process. If it were practical to implement all bridging in this way, then interactions between systems or processes would be solely within a single domain or ORB.
Request level bridges use the CORBA APIs, including the Dynamic Skeleton Interface, to receive and issue requests. However, there is an emerging class of "implicit context" which may be associated with some invocations, holding ORB Service information such as transaction and security context information, which is not at this time exposed through general purpose public APIs. (Those APIs expose only OMG IDL-defined operation parameters, not implicit ones.) Rather, the precedent set with the Transaction Service is that special purpose APIs are defined to allow bridging of each kind of context. This means that request level bridges must be built to specifically understand the implications of bridging such ORB Service domains, and to make the appropriate API calls.
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.
Figure 10-3 An ORB chosen as a backbone will connect other ORBs through bridges, both full-bridges and half-bridges.
Adopting a backbone style architecture is a standard administrative technique for managing networks. It has the consequence of minimizing the number of bridges needed, while at the same time making the ORB topology match typical network organizations. (That is, it allows the number of bridges to be proportional to the number of protocols, rather than combinatorial.)
In large configurations, it will be common to notice that adding ORB bridges doesn't even add any new "hops" to network routes, because the bridges naturally fit in locations where connectivity was already indirect, and augment or supplant the existing network firewalls.
The fundamental ORB interoperability requirement is to allow clients to use such object names to invoke operations on objects in other ORBs. Clients do not need to distinguish between references to objects in a local ORB or in a remote one. Providing this transparency can be quite involved, and naming models are fundamental to it.
10.5.1 Domain-relative Object Referencing
Since CORBA does not require ORBs to understand object references from other ORBs, when discussing object references from multiple ORBs one must always associate the object reference's domain (ORB) with the object reference. We use the notation D0.R0 to denote an object reference R0 from domain D0; this is itself an object reference. This is called "domain-relative" referencing (or addressing), and need not reflect the implementation of object references within any ORB. 10.5.2 Handling of Referencing Between Domains
When a bridge hands an object reference to an ORB, it must do so in a form understood by that ORB: the object reference must be in the recipient ORB's native format. Also, in cases where that object originated from some other ORB, the bridge must associate each newly created "proxy" object reference with (what it sees as) the original object reference.
10.6.1 What Information do Bridges Need?
The following potential information about object references has been identified as critical for use in bridging technologies:
This data structure is designed to be efficient in typical single-protocol configurations, while not penalizing multiprotocol ones.
module IOP{ // IDL
//
// Standard Protocol Profile tag values
//
typedef unsigned long ProfileId;
const ProfileId TAG_INTERNET_IOP = 0;
const ProfileId TAG_MULTIPLE_COMPONENTS = 1;
struct TaggedProfile {
ProfileId tag;
sequence <octet> profile_data;
};
//
// an Interoperable Object Reference is a sequence of
// object-specific protocol profiles, plus a type ID.
//
struct IOR {
string type_id;
sequence <TaggedProfile> profiles;
};
//
// Standard way of representing multicomponent profiles.
// This would be encapsulated in a TaggedProfile.
//
typedef unsigned long ComponentId;
struct TaggedComponent {
ComponentId tag;
sequence <octet> component_data;
};
typedef sequence <TaggedComponent> MultipleComponentProfile;};
Object references have at least one tagged profile per protocol supported. Those profiles encapsulate all the basic information that protocol needs to identify an object. Any single profile holds enough information to drive a complete invocation using that protocol; the content and structure of those profile entries are wholly specified by that protocol. A bridge between two domains may need to know the detailed content of the profile for those domains' profiles, depending on the technique it uses to bridge the domains1.
Each profile has a unique numeric tag, assigned by OMG. The ones defined here are for the IIOP (see Chapter 12, "General Inter-ORB Protocol") and for use in "multi component protocol profiles."
The TAG_MULTIPLE_COMPONENTS tag indicates that the value encapsulated is of type MultipleComponentProfile. In this case, the profile consists of a list of protocol components, indicating ORB services accessible using that protocol. ORB services are assigned component identifiers in a namespace that is distinct from the profile identifiers. Note that protocols may use the MultipleComponentProfile data structure to hold profile components even without using TAG_MULTIPLE_COMPONENTS to indicate that particular protocol profile, and need not use a MultipleComponentProfile to hold sets of profile components.
10.6.3 Profile and Component Composition in IORs
The following rules augment the preceding discussion: 10.6.4 IOR Creation and Scope
IORs are created from object references when required to cross some kind of referencing domain boundary. ORBs will implement object references in whatever form they find appropriate, including possibly using the IOR structure. Bridges will normally use IORs to mediate transfers where that standard is appropriate. 10.6.5 Stringified Object References
Object references can be "stringified" (turned into an external string form) by the ORB::object_to_string operation, and then "destringified" (turned back into a programming environment's object reference representation) using the ORB::string_to_object operation.
To allow a stringified object reference to be internalized by what may be a different ORB, a stringified IOR representation is specified. This representation instead establishes that ORBs could parse stringified object references using that format. This helps address the problem of bootstrapping, allowing programs to obtain and use object references, even from different ORBs.
The following is the representation of the stringified (externalized) IOR:
<oref> ::= <prefix> <hex_Octets>
<prefix> ::= "IOR:"
<hex_Octets> ::= <hex_Octet> {<hex_Octet>}*
<hex_Octet> ::= <hexDigit> <hexDigit>
<hexDigit> ::= <digit> | <a> | <b> | <c> | <d> | <e> | <f>
<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" |
"6" | "7" | "8" | "9"
<a> ::= "a" | "A"
<b> ::= "b" | "B"
<c> ::= "c" | "C"
<d> ::= "d" | "D"
<e> ::= "e" | "E"
<f> ::= "f" | "F"The hexadecimal strings are generated by first turning an object reference into an IOR, and then encapsulating the IOR using the encoding rules of CDR. (See "CDR Transfer Syntax" on page 12-4 for more information.) The content of the encapsulated IOR is then turned into hexadecimal digit pairs, starting with the first octet in the encapsulation and going until the end. The high four bits of each octet are encoded as a hexadecimal digit, then the low four bits.
10.6.6 Object Service Context
Emerging specifications for Object Services occasionally require service-specific context information to be passed implicitly with requests and replies. (Specifications for OMG's Object Services are contained in CORBAservices:Common Object Service Specifications.) The Interoperability specifications define a mechanism for identifying and passing this service-specific context information as "hidden" parameters. The specification makes the following assumptions:
Each Object Service requiring implicit service-specific context to be passed through GIOP will be allocated a unique service context ID value by OMG. Service context ID values are of type unsigned long. Object service specifications are responsible for describing their context information as single OMG IDL data types, one data type associated with each service context ID.
The marshaling of Object Service data is described by the following OMG IDL:
module IOP
{ // IDL
typedef unsigned long ServiceID;
struct ServiceContext {
ServiceID context_id;
sequence <octet> context_data;
};
typedef sequence <ServiceContext> ServiceContextList;
const ServiceID TransactionService = 0;};
The context data for a particular service will be encoded as specified for its service-specific OMG IDL definition, and that encoded representation will be encapsulated in the context_data member of IOP::ServiceContext. (See Section 12.3.3, "Encapsulation," on page 12-9.) The context_id member contains the service ID value identifying the service and data format. Context data is encapsulated in octet sequences to permit ORBs to handle context data without unmarshaling, and to handle unknown context data types.
During request and reply marshaling, ORBs will collect all service context data associated with the Request or Reply in a ServiceContextList, and include it in the generated messages. No ordering is specified for service context data within the list. The list is placed at the beginning of those messages to support security policies that may need to apply to the majority of the data in a request (including the message headers).
pubs@omg.org Copyright © 1995, Object Management Group. All rights reserved.