Planning and Configuring CORBA Domains

 

Domains in a BEA Tuxedo CORBA environment are an extension of the core ATMI BEA Tuxedo environment domains. A domain is a construct that is entirely administrative. There are no programming interfaces that refer to domains. Everything concerning domains is done by configuration files; only an administrator is aware of domains.

This topic includes the following sections:

• Configuring Multiple CORBA Domains

• Types of CORBA Domain Configurations

• Examples: Configuring Multiple CORBA Domains

Overview of Multiple CORBA Domains

Since an enterprise can have many different kinds of applications, be geographically dispersed, and be organized into different areas of responsibility, there might be many separate domains. Each domain is a separately administered unit. Perhaps it is organized for geographical considerations (all the machines in a given location). Perhaps it is organized on departmental grounds within an enterprise (accounting, manufacturing, shipping, and so on).

Eventually, an enterprise wants the different applications in those domains to be able to cooperate. It is often impossible to expand a single domain to encompass the enterprise. However, the size of an expanded domain in terms of the number of machines and services would be impractical. Since a single domain must be administered as a whole, the configuration would rapidly become huge and require more effort in administering than in developing and implementing applications.

Therefore, to keep a domain relatively compact for administration, there must be a way to separate applications into multiple domains and still allow applications in one domain to access services in other domains. This capability for interdomain communication is what is generically called "BEA Tuxedo domains."

Interdomain Communication

The following figure shows a simple multiple-domain configuration.

Multiple-domain Configuration

 

The following steps describe single-domain communication between Client X and Domain A:

1. Client X connects to Domain A using the Bootstrap object. The client application uses the Bootstrap object to locate a FactoryFinder and then uses the FactoryFinder to ask for a factory for objects of type Q. (The FactoryFinder call is itself an invocation on Domain A.)

2. When the FactoryFinder returns a factory, the client then invokes that factory in Domain A.

3. The factory returns a reference to an object of type Q, called Q1.

4. The client now invokes on object Q1 in Domain A.

Note: Throughout all of these steps, the client does not know where any of the objects are, or which domains they are in. It might not even know that there is something called a domain. The administrative actions for connecting a client to Domain A are relatively simple for a client, because the client is a simple machine and has very little infrastructure; it stands alone for the most part. Indeed, the connection to a BEA Tuxedo domain is the primary administration for a client. The actual administrative chore is setting the address of the ISL that is in Domain A.

For multiple-domain communication, Q1 needs the services of Object R1, which is in Domain C; therefore, object Q1 must execute operations similar to those described in steps 1 through 4 above, but across domain boundaries. The actual steps are as follows:

1. Object Q1 uses a Bootstrap object to locate a FactoryFinder and then uses the FactoryFinder to ask for a factory for objects of type R.

2. When the FactoryFinder returns a reference to a factory in Domain C, Object Q1 invokes that factory.

3. The factory returns a reference to an object of type R, called R1.

4. Object Q1 invokes on Object R1.

Note: As with Client X, there must be some administration to allow Object Q1 to get at the factories and objects in Domain C. As Figure 3-1 shows, the mechanism for communication between domains is a domain gateway. A domain gateway is a system server in a domain.

A system server is different than a user-written server because it is provided as part of the BEA Tuxedo product; other system servers are the name servers, FactoryFinders, and ISLs. A domain gateway is somewhat similar in concept to an ISL because it is the "contact" point for a domain. It is different from an ISL, however, because a domain gateway connects to another domain gateway, which is itself a contact point for a domain; that is, a domain gateway's job is to connect to another domain gateway. Thus, the pair of domain gateways cooperate to make sure that invocation on objects that inhabit different domains are routed to the correct domain.

For domain gateways to operate in this manner, they must be configured properly. That configuration is the subject of the following sections.

Functions of Multiple-domain Configuration Elements

The following elements work together to accomplish the configuration of multiple domains:

• BEA Tuxedo configuration file

  The UBBCONFIG file names a domain and identifies the group and service entry for a domain gateway server. No attributes of domain gateways are specified in the UBBCONFIG file; all such attributes are in the DMCONFIG file.

• Domain configuration file

  The domain configuration file (DMCONFIG) describes the remote domains that are connected to the local domain. If there is no DMCONFIG file, there are no connections.

• FactoryFinder domain configuration file

  One FactoryFinder domain configuration file (factory_finder.ini) is required for each domain that is connected to one or more other domains. If a domain is not connected to another domain, there is no need for this file.

  This file specifies which factories can be searched for or found across domain boundaries. You must carefully coordinate the factory_finder.ini file with the DMCONFIG so that they both have information about the same connected domains and provide the same connectivity.

• Invocation of an object in a remote domain

  The whole point of the BEA Tuxedo domains feature is for an application in one CORBA domain to be able to make an invocation on an object in another CORBA domain, without either the client or server applications being aware that domains are a factor. Configuration information is intended to allow such invocations to cross domain boundaries and to hide the fact of those boundaries from applications.

  Being able to make an invocation on a reference for an object in a remote domain depends on a satisfactory set of three configuration files—the UBBCONFIG, DMCONFIG, and factory_finder.ini files—for each domain and on the coordination of two of those configuration files—the DMCONFIG and factory_finder.ini files—between domains. As the number of domains grows, the coordination effort grows.

• References to objects in a remote domain

  Any object reference may specify a local domain or a remote domain. A reference to a remote domain typically happens when a FactoryFinder returns a reference to a factory in a remote domain. It also happens when that factory, in turn, creates and returns a reference to an object in that remote domain (although, of course, the reference is local to the domain of the factory).

Note: Applications are not aware of the domain of an object reference. Applications cannot find out what domain an object reference refers to. Thus, invocations on an object reference for a remote domain are transparent to the application. This transparency allows administrators the freedom to configure services in individual domains and to spread resources across multiple domains. If applications were to include information about domains, changing configurations would require that the applications be rewritten as well.

• FactoryFinders

  For a server in a local domain to obtain an object reference to an object in another domain, the application uses the same FactoryFinder pattern as it does for objects in the local domain. The application uses the same pattern because it is not aware that the factory finder returns a reference to a factory in another domain. The configuration files hide this fact.

  Once an object reference has been obtained via a FactoryFinder or factory, the object reference can be passed anywhere; that is, passed to objects in the local domain, returned to a client, or passed to another domain.