|
|
|
|
|
|
Configuring Multiple Domains (BEA WebLogic Enterprise Systems)
BEA WebLogic Enterprise domains are an extension of BEA Tuxedo 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:
In the versions 4.0 and 4.1 releases of the BEA WebLogic Enterprise software, a domain was an administrative unit that was entirely self-contained and that described one application. The concept of application in those earlier versions is that of a "logical application" that covers the entire domain. The logical application might well be made up of several individual subapplications with little or no interactions. Only servers described in the domain were available to the applications. In this context, it is correct to say that BEA WebLogic Enterprise version 4.0 and 4.1 systems consisted of only one "local domain."
Since BEA WebLogic Enterprise software was capable of having only one domain, there was no reason to consider reasons for grouping services one way or another. There was only one way: everything goes into the (single) local domain. However, 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 WebLogic Enterprise domains."
Interdomain Communication
Figure 9-1 shows a simple multiple-domain configuration.
Figure 9-1 Multiple-domain Configuration
The following steps describe single-domain communication between Client X and 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 WebLogic Enterprise 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:
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 9-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 WebLogic Enterprise 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:
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.
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.
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.
The whole point of the "BEA WebLogic Enterprise Domains" feature is for a application in one domain to be able to make an invocation on an object in another 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.
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.
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.
Configuring Multiple Domains
You use the following three configuration files to configure multiple domains:
You must specify the following parameters in the UBBCONFIG file to configure multiple domains:
Though not required for single domains (that is, standalone domains), a domain that is connected to another domain must have a DOMAIN ID. You specify this parameter in the RESOURCES section of the UBBCONFIG file, as follows:
DOMAIN ID = <domain-name>
The <domain-name> must be 1 to13 characters long. For example:
DOMAIN ID = headquarters
<domain-name> is the name that will be referenced in the DM_REMOTE_SERVICES and DM_LOCAL_SERVICES sections of the related DMCONFIG file. In that file, the <domain-name> will be referenced as:
"//<domain-name>"
The quotes are part of the reference. The slashes (//) mean that the name applies to BEA WebLogic Enterprise domains, rather than to BEA Tuxedo domains. For example:
"//headquarters"
Note: Every domain in an enterprise must have a unique <domain-name>.
Gateway Group and Service
As with every other system service, there must be a group and a service name specified for a gateway. For example, the GROUPS section might contain:
LGWGRP GRPNO=4 LMID=LDOM
In this example, LGWGRP is a name chosen by a user (perhaps an abbreviation for "Local Gateway Group").
The service name for a domain gateway is GWTDOMAIN and must be associated, like every other group, with a server group and a server ID. You specify the service name in the SERVERS section associated with the server group name chosen. For example:
GWTDOMAIN SRVGRP=LGWGRP SRVID=1
This tells the BEA WebLogic Enterprise server that a domain gateway is to be used and that additional information is found in the DMCONFIG file.
The Domain Configuration (DMCONFIG) File
There is one DMCONFIG file per domain. It describes the relationship between the local domain (the domain in which the DMCONFIG file resides) and remote domains (any other domains). The DMCONFIG file contains domain information for BEA Tuxedo domains and for BEA WebLogic Enterprise domains.
The sections below concentrate on the information that applies to BEA WebLogic Enterprise domains. In other documentation for the DMCONFIG file, the communication between local and remote domains is based on BEA Tuxedo services, a concept not used in BEA WebLogic Enterprise. For BEA WebLogic Enterprise, the "service" name is the name of another BEA WebLogic Enterprise domain that can service BEA WebLogic Enterprise requests.
The DMCONFIG file consists of up to eight parts, but one part, DM_ROUTING, does not apply to BEA WebLogic Enterprise domains. The other seven parts refer to BEA WebLogic Enterprise domains, but many of the BEA Tuxedo parameters are not used. Those seven parts are: DM_RESOURCES, DM_LOCAL_DOMAINS, DM_REMOTE_DOMAINS, DM_LOCAL_SERVICES, DM_REMOTE_SERVICES, DM_ACCESS_CONTROL, and DM_TDOMAIN.
The following sections refer to the sample DMCONFIG file shown in Listing 9-1.
Listing 9-1 Sample DMCONFIG File
#
# BEA WebLogic Enterprise DOMAIN CONFIGURATION FILE
#
*DM_RESOURCES
VERSION=Experimental8.9
*DM_LOCAL_DOMAINS
LDOM GWGRP=LGWGRP TYPE=TDOMAIN DOMAINID="MUTT"
*DM_REMOTE_DOMAINS
TDOM1 TYPE=TDOMAIN DOMAINID="JEFF"
*DM_TDOMAIN
LDOM NWADDR="//MUTT:2507"
TDOM1 NWADDR="//JEFF:3186"
*DM_LOCAL_SERVICES
"//MUTT"
*DM_REMOTE_SERVICES
"//JEFF" RDOM=TDOM1
DM_RESOURCES
The DM_RESOURCES section can contain a single field, VERSION. It is not checked by software; it is provided simply as a place where users can enter a string that may have some documentation value to the application.
*DM_RESOURCES
VERSION=Experimental8.9
DM_LOCAL_DOMAINS
The DM_LOCAL_DOMAINS section specifies some attributes for gateways into the local domain from the outside. The section must have an entry for each gateway group defined in the UBBCONFIG fle that will provide access to the local domain from other domains. Each entry specifies the parameters required for the domain gateway processes running in that group.
Entries have the form:
LDOM required-parameters [optional-parameters]
where LDOM is an identifier used to refer to the gateway to the local domain. LDOM must be unique among all LDOM and RDOM entries across the enterprise (that is, among the set of domains connected to each other). Note that LDOM is not the same name as the <domain-name> or the gateway group that is specified in the UBBCONFIG file. Rather, LDOM is a name used only within the DMCONFIG file to provide an extra level of insulation from potential changes in the UBBCONFIG file (changes in UBBCONFIG will affect only this one part of DMCONFIG).
The following are required parameters:
GWGRP = identifier
This parameter specifies the name of a gateway server group (the name provided in the UBBCONFIG file) representing this local domain.
TYPE = TDOMAIN
The TYPE parameter is required to specify the use of domains for BEA WebLogic Enterprise.
DOMAINID = string
The DOMAINID parameter is used to identify the local domain for the purposes of security. The gateway server group in GWGRP uses this string during any security checks. It has no required relationship to the <domain-name> found in the RESOURCES section of the UBBCONFIG file. DOMAINID must be unique across both local and remote domains. The value of string can be a sequence of characters (for example, "BA.CENTRAL01"), or a sequence of hexadecimal digits preceded by 0x (for example, "0x0002FF98C0000B9D6"). DOMAINID must be 32 octets or fewer in length. If the value is a string, it must be 32 characters or fewer (counting the trailing null).
For example, the lines
*DM_LOCAL_DOMAINS
LDOM GWGRP=LGWGRP TYPE=TDOMAIN DOMAINID="MUTT"
identify LDOM as an access point to the local domain. It is associated with the service group LGWGRP (as specified in the UBBCONFIG file). If the gateway is ever involved in a domain-to-domain security check, it goes by the name MUTT.
Optional parameters describe resources and limits used in the operation of domain gateways. For a description of these parameters, refer the dmconfig(5) reference page in the BEA Tuxedo Reference Manual.
DM_REMOTE_DOMAINS
The DM_REMOTE_DOMAINS section specifies some attributes for gateways to remote domains. The section has an entry for each UBBCONFIG file-defined gateway group that will send requests to remote domains. Each entry specifies the parameters required for the domain gateway processes running in that group.
Entries have the form:
RDOM required-parameters
where RDOM is an identifier used to refer to the gateway providing access to the remote domain. RDOM must be unique among all LDOM and RDOM entries across the enterprise (that is, among the set of domains connected to each other). Note that RDOM is not the same name as the <domain-name> or the gateway group that is specified in the UBBCONFIG file. Rather, RDOM is a name used only within the DMCONFIG to provide an extra level of insulation from potential changes in UBBCONFIG (changes in UBBCONFIG will affect only this one part of DMCONFIG).
The required parameters are:
TDOM1 TYPE=TDOMAIN DOMAINID="JEFF"
DM_TDOMAIN
The DM_TDOMAIN section defines the network addressing information for gateways implementing BEA WebLogic Enterprise domains. There should be one entry for each domain gateway that accepts requests from remote domains, and one entry for each domain gateway that sends requests to remote domains.
The format of each entry is:
DOM required-parameters [optional-parameters]
where DOM is an identifier value used to identify either a local domain access point (LDOM in the DM_LOCAL_DOMAINS section) or a remote domain access point (RDOM in the DM_REMOTE_DOMAINS section).
The following parameter is required:
LDOM NWADDR="//MUTT:2507"
TDOM1 NWADDR="//JEFF:3186"
For a description of the optional parameters, refer to the dmconfig(5) reference page in the BEA Tuxedo Reference Manual.
DM_REMOTE_SERVICES
The DM_REMOTE_SERVICES section specifies additional attributes for gateways to remote domains. The format of each entry is:
service RDOM=<rdom-name>
[LDOM=<ldom-name>]
[TRAN_TIME=...]
where service is of the form:
"//<domain-name>"
This <domain-name> is the name that occurs RESOURCES section of the UBBCONFIG file as <domain-name>. Each entry specifies an rdom-name and, optionally, an ldom-name. The gateway uses the attributes for those entries for establishing a gateway pair for BEA WebLogic Enterprise domain communication. Gateways operate in pairs. At boot time, the local domain uses attributes of rdom-name (the address specified in the DM_TDOMAIN section) to establish a connection to a gateway in the other domain. If security is used, the other attributes of rdom-name and ldom-name are used for mutual authentication. At run time, when BEA WebLogic Enterprise determines that a request must travel to domain <domain-name>. It uses the gateway specified by rdom-name to send the request to another domain.
Most often, <domain-name> is the name of the domain specified in the address of the rdom-name. In that situation, when the request ends up at the other end of the gateway, it is served in that domain. For example:
*DM_REMOTE_SERVICES
"//JEFF" RDOM=TDOM1
In this case, the domain name JEFF is located at the address "//JEFF:3186". That address might or might not have a UBBCONFIG file that specifies its domain name as JEFF. If it does, the request can be serviced immediately.
It is possible to have entries that send requests for the specified domain-name to an intermediary domain that acts as a pass-through for routing purposes.
The remaining optional parameter, TRANTIME = integer, specifies the default timeout value, in seconds, for a transaction automatically started for the associated service. The value must be greater than or equal to 0 (zero) and less than 2147483648. The default is 30 seconds. A value of 0 (zero) implies the maximum timeout value for the machine.
DM_LOCAL_SERVICES
The DM_LOCAL_SERVICES section specifies additional attributes for gateways that accept requests into the local domain from the outside.
Lines within this section have the form:
service [LDOM=<ldom-name>]
[ACL=...]
where service is of the form:
"//<domain-name>"
This <domain-name> is the name that occurs in the RESOURCES section of the UBBCONFIG file as <domain-name>. Most likely this is the name of the domain in which the gateway resides, meaning that this (local) domain accepts BEA WebLogic Enterprise requests from other domains. It is also possible (but not necessary, except for purposes of security) to have an entry that accepts requests for a different domain name in the case where the local domain acts as a pass-through for routing purposes.
Notice that exported services inherit the properties specified for the service in an entry in the SERVICES section of the TUXCONFIG file, or their defaults. Some of the properties that may be inherited are LOAD, PRIO, AUTOTRAN, ROUTING, BUFTYPE, and TRANTIME.
The optional parameter, ACL = identifier, specifies the name of the access control list (ACL) to be used by the local domain to restrict requests made to this service by remote domains. The name of the ACL is defined in the DM_ACCESS_CONTROL section. If this parameter is not specified, access control is not performed for requests to this service.
For example, the lines:
*DM_LOCAL_SERVICES
"//MUTT"
state that this domain accepts requests destined for the domain with name MUTT.
DM_ACCESS_CONTROL
The DM_ACCESS_CONTROL section specifies the access control lists used by a local domain. Lines in this section are of the form:
ACL_NAME required parameters
where ACL_NAME is an (identifier) name used to identify a particular access control list; it must be 15 characters or less in length.
The only required parameter is:
ACLIST = identifier [,identifier]
where an ACLIST is composed of one or more remote domain names (RDOM) separated by commas. The wildcard character (*) can be used to specify that all the remote domains defined in the DM_REMOTE_DOMAINS section can access a local domain.
Note: The factory_finder.ini and DMCONFIG files must be coordinated; that is, if the factory_finder.ini file declares another domain to have accessible factories, there must be a way in DMCONFIG to get to that domain.
The factory_finder.ini File
Administrators are required to identify any factory objects that can be used in the current (local) /Domain, but that are resident in a different (remote) /Domain. You identify these factories in a FactoryFinder domain configuration file, also referred to as the factory_finder.ini file. This is an ASCII file that can be created and updated using a text editor.
The factory_finder.ini file can be used to identify remote CORBA factories and remote EJB Home interfaces that can be used in the local domain.
The format of the factory_finder.ini file is modeled after the syntax used to describe /Domains, and is shown below:
*DM_REMOTE_FACTORIES
"local_factory_id.factory_kind"
DOMAINID="domain_id"
RNAME="remote_factory_id.factory_kind"
...
[*DM_LOCAL_FACTORIES]
["factory_id.factory_kind"]
...
Sample syntax for CORBA factory objects is as follows:
*DM_REMOTE_FACTORIES
"AccountFactory.FactoryKind"
"DOMAINID="MyAccountFactoryDomain"
RNAME="MyAccountFactory.FactoryKind
where: AccountFactory is the name used to register the factory in the local domain's FactoryFinder, MyAccountFactoryDomain is the name of the remote domain, MyAccountFactory is the name used to register the factory in the remote domain's FactoryFinder.
Sample syntax for EJB Home interfaces in the Java Naming and Directory Interface (JNDI) is as follows:
*DM_REMOTE_FACTORIES
"AccountHome.FactoryKind"
DOMAINID="MyAccountHomeDomain"
RNAME="MyAccountHome.FactoryKind"
where: AccountHome is the name used to register the EJB Home interface in the local domain's JNDI, MyAccountHomeDomain is the name of the remote domain, and MyAccountHomeDomain is the name used to register the EJB Home interface in the remote domain's JNDI.
The Master NameManager reads the factory_finder.ini file when the process is started. The reason for starting the Master NameManager affects which portions of the factory_finder.ini file are processed. If the Master NameManager is being started as part of booting an application, the initialization mode, the entire contents of the file is processed. As a result, the information in the DM_REMOTE_FACTORIES section results in entries being added for the factory objects or EJB Home interfaces being imported.
On the other hand, if the Master NameManager is being restarted as a result of a process failure, only the DM_LOCAL_FACTORIES section of the file is read. This section of the factory_finder.ini file must be re-read to reload the information that is used to restrict the exportation of certain factory objects or EJB Home interfaces into another domain.
Note: Since the Master NameManager reads the factory_finder.ini file only when the process is started, there is no way to update the Master NameManager (for example, when a new domain with factory objects to be imported needs to be added) without shutting down the Master NameManager.
A factory_finder.ini file applies to the domain in which it resides. It contains two sections: the DM_REMOTE_FACTORIES section and the DM_LOCAL_FACTORIES section. Either section can be absent or contain nothing.
The following sections provide more information on how to use the DM_REMOTE_FACTORIES section and the DM_LOCAL_FACTORIES section.
DM_REMOTE_FACTORIES
The DM_REMOTE_FACTORIES section provides information about the factory objects or EJB Home interfaces that are available in remote domains and that are imported so that applications in the local domain can use them. Identifiers for remote factory objects or EJB Home interfaces are listed in this section. The identifier, under which the object is registered, including a kind value of "FactoryInterface", must be listed in this section. For example, the entry for a remote factory object to be registered by the TP Framework with the identifier Teller in domain "Norwest" would be specified as:
*DM_REMOTE_FACTORIES
"Teller.FactoryInterface"
DOMAINID="Norwest"
RNAME="BankTeller.FactoryInterface"
If the RNAME is not specified, the factory_kind must be specified in the factory name and the factory name must be enclosed in quotation marks; otherwise, the NameManager is not able to locate the appropriate factory. An entry that does not contain a factory_kind value is not defaulted with a value of "FactoryInterface". The following example shows a factory object to be registered with the identifier Teller in domain "Norwest". Note the absence of the RNAME specification, the specification of the factory_kind value, and the quotation marks around the factory name.
*DM_REMOTE_FACTORIES
"Teller.FactoryInterface"
DOMAINID="Norwest"
Because the identities of factories in a multidomain configuration may collide, the factory identifier and the RNAME parameters allow you to specify alternative identities, or "aliases," in the local domain for remote factories. Listing 9-2 shows two examples of a remote factory that is registered by the TP Framework with the identifier BankTeller in domain "Norwest". In both examples, the factory is made available in local domain with an alias of Teller.
Listing 9-2 Assigning an Alias to a Remote Factory
#EXAMPLE 1:
*DM_REMOTE_FACTORIES
Teller
DOMAINID="Norwest"
RNAME="BankTeller.FactoryInterface"
#EXAMPLE 2:
*DM_REMOTE_FACTORIES
"Teller.FactoryInterface"
DOMAINID="Norwest"
RNAME="BankTeller.FactoryInterface"
You can also assign multiple aliases to the same remote factory. In the example shown in Listing 9-3, the remote factory will be registered in the local domain with two aliases: Teller and BankTeller.
Listing 9-3 Assigning Multiple Aliases to a Remote Factory
*DM_REMOTE_FACTORIES
"Teller.FactoryInterface"
DOMAINID="Norwest"
RNAME="BankTeller.FactoryInterface"
"BankTeller.FactoryInterface"
DOMAINID="Norwest"
RNAME="BankTeller.FactoryInterface"
Usage Note: In multidomain configurations, factory object and ejb home interface identifiers must be unique across domains in the enterprise.
In a multidomain configuration, two different domains must not have a factory objects or EJB Home interfaces with the same factory_id.factory_kind identifier, for example: "Teller.FactoryInterface".
If the same identifier, or name, is used in two domains, the software behavior varies according to the version of the BEA WebLogic Enterprise software.
Note: In a single domain configuration, BEA WebLogic Enterprise supports multiple factories objects or EJB Home interfaces with the same name. This type of configuration is allowed so as to achieve load-balancing.
There are two ways to ensure that your identifiers, or names, are unique across domains and thus avoid this problem:
DM_LOCAL_FACTORIES
The DM_LOCAL_FACTORIES section specifies factory objects or EJB Home interfaces in the local domain that are available to be exported to other domains. This section can be used in the following ways:
The identifier, or name, under which the factory object or EJB Home interface is registered, including a kind value of "FactoryInterface", must be listed in this section. For example, the entry for a factory object to be registered by the TP Framework with the identifier Teller would be specified as:
*DM_LOCAL_FACTORIES
"Teller.FactoryInterface"
The factory_kind must be specified for the NameManager to locate the appropriate factory object or EJB Home interface. An entry that does not contain a factory_kind value is not defaulted with a value of "FactoryInterface". This allows for the use of the CORBA NamingService.
The factory_finder.ini file specifies that the process of finding a factory can be exported to a remote domain by including a section beginning with "*DM_REMOTE_FACTORIES". In other words, including this section means that the local domain can find factories in a remote domain.
An entry into the file for domain A might be:
*DM_REMOTE_FACTORIES
fA.FactoryInterface DOMAINID=B
This means that a request in domain A to find a factory with the identifier fA can be satisfied by the Factory Finder in domain B. Of course, the UBBCONFIG and DMCONFIG files for the two domains must also be set up so that there are connected domain gateways between the two domains.)
An alternate form of the entry is:
CDE.FactoryInterface DOMAINID=B RNAME=fA.FactoryInterface
This means that a request in domain A to find a factory with the identifier "CDE" will be satisfied by the FactoryFinder in domain B using the ID fA. This is sometimes called an alias.
Note: The factory ID must have ".FactoryInterface" at the end. For simplicity, when talking about test configurations, we will leave that off, but it should appear in the file.
For more information about the factory_finder.ini file, see description of the factory_finder.ini file in the Commands, System Processes, and MIB Reference.
Local Factories
A domain can specify which of its factories can be accessed by other domains. This is specified in a section beginning with *DM_LOCAL_FACTORIES. If the factory_finder.ini file does not exist, or if it exists and this section does not appear, or is empty, all local factories can be accessed by remote domains. If the section exists and contains the keyword None, none of the local factories are exportable; that is, none are allowed to be found by a remote Factory Finder. If the section exists, it can contain a list of factories available to remote domains. For example,
*DM_LOCAL_FACTORIES
fA.FactoryInterface
fB.FactoryInterface
This specifies that factories fA and fB are findable from other domains. All factories other than factories explicitly listed are not findable. Unlike remote factories, there is no provision for an alias with local factories.
Note: The factory_finder.ini and DMCONFIG files must be coordinated, that is, if the factory_finder.ini file declares another domain to have accessible factories, there must be a way in DMCONFIG to get to that domain.
Types of Domain Configurations
When using the multiple domains feature, you can configure two types of configurations: directly connected domains and indirectly connected domains. You, as the administrator, configure both types using the domain configuration file, DMCONFIG.
Directly Connected Domains
It is possible for every domain in an enterprise to have a gateway to every other domain it might use. Such a configuration has the advantage that a request goes directly to the target domain, with the minimum of delay. Such an "n-way" configuration is quite reasonable when the number of domains is small, but each new domain requires two new gateways. At some point, an administrator may consider a different configuration, giving up speed of delivery for ease of management of domain connections. This is when the ability to configure indirectly connected domains becomes advantageous.
Indirectly Connected Domains
An administrator should consider what the likely traffic patterns are. Domains that have only occasional interactions are candidates for gateway removal. Since there will still be interactions, it must still be possible to reach the other domain. The technique used is to route the request through an intermediate domain that does have direct access to the target domain. For example, we might have three domains, A, B, and C. Domains A and B are directly connected and domains B and C are directly connected, but A and C are not directly connected (See Figure 9-2). For domains A and C to communicate, they must use domain B as the intermediary. Therefore, the DMCONFIG file for domain A must state that it is possible to connect to domain C by going through domain B (and vice versa). That is, the connectivity is:
Domains A <-> B <-> C
Gateways GAB GBA GBC GCB
Domain A has a gateway process, GAB (the Gateway from A to B), that connects to domain B. The domain A DMCONFIG file states that GAB acts as a gateway to two domains, domains B and C. The DMCONFIG file for domain C has a similar configuration, stating that GCB is connected to B and A. The DMCONFIG file for domain B has two gateway processes, one which connects to A (GBA) and one which connects to C (GBC). This is called an indirect connection.
Given this indirect connection, when a server in A invokes a request on an object in C, BEA WebLogic Enterprise knows that it can send the request to gateway GAB. The BEA WebLogic Enterprise gateway does not know that its partner gateway in B cannot service the request itself, but that is acceptable. Once the request is in domain B, it is routed through GBC to C, which can service the request. Thus, the request is serviced with one extra hop.
It is even possible for the two gateways in domain B to be a single gateway, so that there is not an extra hop within B. In effect, the same processing occurs in domain B, but it all occurs within a single gateway process.
Figure 9-2 Indirectly Connected Domains
Examples: Configuring Multiple Domains
The following sections provide examples of how to configure directly connected domains.
Note: These examples are provided for informational purposes only. If you want to use these examples, you will have to change the APPDIR, TUXCONFIG, and TUXDIR variables to match your environment. Also, you will have to substitute appropriate information wherever text is enclosed by left (<) and right (>) angle brackets (for example, <App Server Name>) and delete the angle brackets.
Sample UBBCONFIG Files
Listing 9-4, Listing 9-5, and Listing 9-6 show the UBBCONFIG files for three directly connected domains: Here, There, and Yonder.
Note: To use these files, you must replace host with the name of the local machine.
Listing 9-4 UBBCONFIG File for the Here Domain
#
# Copyright (c) 1999 BEA Systems, Inc.
# All rights reserved
#
#
#
# RESOURCES
#
*RESOURCES
IPCKEY 123312
DOMAINID HereD
MASTER LAPP
MODEL SHM
LDBAL N
#
# MACHINES
#
*MACHINES
<host>
LMID=LAPP
APPDIR="/tst1/wle4.2/test_dom/t07:
/tst1/wle4.2/dec_unix/wlemdomai"
TUXCONFIG="/tst1/wle4.2/test_dom/tuxconfig"
TUXDIR="/lclobb/lc"
MAXWSCLIENTS=10
#
# GROUPS
#
*GROUPS
DEFAULT: LMID=LAPP
ICEGRP GRPNO=11 OPENINFO=NONE
GROUP1 GRPNO=21 OPENINFO=NONE
LDMGRP GRPNO=3
LGWGRP GRPNO=4
#
# SERVERS
#
*SERVERS
DEFAULT: CLOPT="-A"
DMADM SRVGRP=LDMGRP SRVID=1
GWADM SRVGRP=LGWGRP SRVID=1
GWTDOMAIN SRVGRP=LGWGRP SRVID=2
TMSYSEVT SRVGRP=ICEGRP SRVID=1
TMFFNAME SRVGRP=ICEGRP SRVID=2
CLOPT="-A -- -N -M -f <FF ini file for Here>"
TMFFNAME SRVGRP=ICEGRP SRVID=3 CLOPT="-A -- -N"
TMFFNAME SRVGRP=ICEGRP SRVID=4 CLOPT="-A -- -F"
<App Server Name> SRVGRP=GROUP1 SRVID=2
ISL SRVGRP=GROUP1 SRVID=1
CLOPT="-A -- -d /dev/tcp -n //<host>:<port>"
#
# SERVICES
#
*SERVICES
Listing 9-5 UBBCONFIG File for the There Domain
#
# Copyright (c) 1999 BEA Systems, Inc.
# All rights reserved
#
# RESOURCES
#
*RESOURCES
IPCKEY 133445
DOMAINID ThereD
MASTER LAPP1
MODEL SHM
LDBAL N
#
# MACHINES
#
*MACHINES
<host>
LMID=LAPP1
APPDIR="D:\test_dom\t07;D:\Iceberg\qa\orb\bld\wlemdomain"
TUXCONFIG="D:\test_dom\tuxconfig"
TUXDIR="D:\Iceberg"
MAXWSCLIENTS=10
#
# GROUPS
#
*GROUPS
DEFAULT LMID=LAPP1
ICEGRP GRPNO=11 OPENINFO=NONE
GROUP1 GRPNO=21 OPENINFO=NONE
LDMGRP GRPNO=3
LGWGRP GRPNO=4
#
# SERVERS
#
*SERVERS
DEFAULT: CLOPT="-A"
DMADM SRVGRP=LDMGRP SRVID=1
GWADM SRVGRP=LGWGRP SRVID=1
GWTDOMAIN SRVGRP=LGWGRP SRVID=2
TMSYSEV SRVGRP=ICEGRP SRVID=1
TMFFNAME SRVGRP=ICEGRP SRVID=2
CLOPT="-A -- -N -M -f <FF ini file for There>"
TMFFNAME SRVGRP=ICEGRP SRVID=3 CLOPT="-A -- -N"
TMFFNAME SRVGRP=ICEGRP SRVID=4 CLOPT="-A -- -F"
<App Server Name> SRVGRP=GROUP1 SRVID=2
ISL SRVGRP=GROUP1 SRVID=1
CLOPT="-A -- -d /dev/tcp -n //<host>:<port>"
#
# SERVICES
#
*SERVICES
Listing 9-6 UBBCONFIG File for the Yonder Domain
# Copyright (c) 1999 BEA Systems, Inc.
# All rights reserved
#
# RESOURCES
#
*RESOURCES
IPCKEY 123334
DOMAINID YonderD
MASTER LAPP
MODEL SHM
LDBAL N
#
# MACHINES
#
*MACHINES
<host>
LMID=LAPP
APPDIR="/tst1/wle4.2/test_dom/t07p:
/tst1/wle4.2/<host3>/wlemdomain"
TUXCONFIG="/tst1/wle4.2/test_dom/<host3>/tuxconfig"
TUXDIR="/lclobb/lc"
MAXWSCLIENTS=10
#
# GROUPS
#
*GROUPS
DEFAULT: LMID=LAPP
ICEGRP GRPNO=11 OPENINFO=NONE
GROUP1 GRPNO=21 OPENINFO=NONE
LDMGRP GRPNO=3
LGWGRP GRPNO=4
#
# SERVERS
#
*SERVERS
DEFAULT: CLOPT="-A"
DMADM SRVGRP=LDMGRP SRVID=1
GWADM SRVGRP=LGWGRP SRVID=1
GWTDOMAIN SRVGRP=LGWGRP SRVID=2
TMSYSEVT SRVGRP=ICEGRP SRVID=1
TMFFNAME SRVGRP=ICEGRP SRVID=2
CLOPT="-A -- -N -M"
TMFFNAME SRVGRP=ICEGRP SRVID=3 CLOPT="-A -- -N"
TMFFNAME SRVGRP=ICEGRP SRVID=4 CLOPT="-A -- -F"
<App Server Name> SRVGRP=GROUP1 SRVID=2
ISL SRVGRP=GROUP1 SRVID=1
CLOPT="-A -- -d /dev/tcp -n //<host>:<port>"
#
# SERVICES
#
*SERVICES
Sample DMCONFIG File
Listing 9-7, Listing 9-8, and Listing 9-10 show the DMCONFIG files for three directly connected domains: Here, There, and Yonder.
Note: To use Listing 9-7 in a multidomain configuration, you must replace host1 with the name of the local machine for the Here domain, replace host2 with the name of the local machine for the There domain, and replace host3 with the name of the local machine for the Yonder domain,
Listing 9-7 DMCONFIG File for the local machine in the Here Domain in a Three-Domain Configuration
#
#Copyright (c) 1999 BEA Systems, Inc.
# All rights reserved
#
#
# Tuxedo DOMAIN CONFIGURATION FILE
#
*DM_RESOURCES
VERSION=U22
#
# DM_LOCAL_DOMAINS
#
*DM_LOCAL_DOMAINS
LDOM1 GWGRP=LGWGRP TYPE=TDOMAIN DOMAINID="HereG"
#
# DM_REMOTE_DOMAINS
#
*DM_REMOTE_DOMAINS
TDOM1 TYPE=TDOMAIN DOMAINID="ThereG"
TDOM2 TYPE=TDOMAIN DOMAINID="YonderG"
#
# DM_TDOMAIN
#
*DM_TDOMAIN
LDOM1 NWADDR="//<host1>:<tcpport>"
TDOM1 NWADDR="//<host2>:<tcpport>"
TDOM2 NWADDR="//<host3>:<tcpport>"
#
# DM_LOCAL_SERVICES
#
*DM_LOCAL_SERVICES
"//HereD"
#
# DM_REMOTE_SERVICES
#
*DM_REMOTE_SERVICES
"//ThereD "RDOM=TDOM1
"//YonderD "RDOM=TDOM2
Note: To use Listing 9-8 in a multidomain configuration, you must replace host1 with the name of the local machine for the There domain, replace host2 with the name of the local machine for the Here domain, and replace host3 with the name of the local machine for the Yonder domain,
Listing 9-8 DMCONFIG File for the There Domain in a Three-Domain Configuration
Listing 9-9 #
#Copyright (c) 1999 BEA Systems, Inc.
# All rights reserved
#
#
# Tuxedo DOMAIN CONFIGURATION FILE
#
*DM_RESOURCES
VERSION=U22
#
# DM_LOCAL_DOMAINS
#
*DM_LOCAL_DOMAINS
LDOM1 GWGRP=LGWGRP TYPE=TDOMAIN DOMAINID="ThereG"
#
# DM_REMOTE_DOMAINS
#
*DM_REMOTE_DOMAINS
TDOM1 TYPE=TDOMAIN DOMAINID="HereG"
TDOM2 TYPE=TDOMAIN DOMAINID="YonderG"
#
# DM_TDOMAIN
#
*DM_TDOMAIN
LDOM1 NWADDR="//<host1>:<tcpport>"
TDOM1 NWADDR="//<host2>:<tcpport>"
TDOM2 NWADDR="//<host3>:<tcpport>"
#
# DM_LOCAL_SERVICES
#
*DM_LOCAL_SERVICES
"//ThereD"
#
# DM_REMOTE_SERVICES
#
*DM_REMOTE_SERVICES
"//HereD "RDOM=TDOM1
"//YonderD "RDOM=TDOM2
Note: To use Listing 9-10 in a multidomain configuration, you must replace host1 with the name of the local machine for the Yonder domain, replace host2 with the name of the local machine for the Here domain, and replace host3 with the name of the local machine for the There domain,
Listing 9-10 DMCONFIG File for the Yonder Domain in a Three-Domain Configuration
Listing 9-11 #
#Copyright (c) 1999 BEA Systems, Inc.
# All rights reserved
#
#
# Tuxedo DOMAIN CONFIGURATION FILE
#
*DM_RESOURCES
VERSION=U22
#
# DM_LOCAL_DOMAINS
#
*DM_LOCAL_DOMAINS
LDOM1 GWGRP=LGWGRP TYPE=TDOMAIN DOMAINID="YonderG"
#
# DM_REMOTE_DOMAINS
#
*DM_REMOTE_DOMAINS
TDOM1 TYPE=TDOMAIN DOMAINID="HereG"
TDOM2 TYPE=TDOMAIN DOMAINID="ThereG"
#
# DM_TDOMAIN
#
*DM_TDOMAIN
LDOM1 NWADDR="//<host1>:<tcpport>"
TDOM1 NWADDR="//<host2>:<tcpport>"
TDOM2 NWADDR="//<host3>:<tcpport>"
#
# DM_LOCAL_SERVICES
#
*DM_LOCAL_SERVICES
"//YonderG"
#
# DM_REMOTE_SERVICES
#
*DM_REMOTE_SERVICES
"//HereD "RDOM=TDOM1
"//ThereD "RDOM=TDOM2
Sample factory_finder.ini File
This section shows the factory_finder.ini files for the Here and There domains. The Yonder domain does not require a factory_finder.ini file.
Listing 9-12 factory_finder.ini File for the Here Local Domain
#Copyright (c) 1999 BEA Systems, Inc.
#All rights reserved
#
# Factory Finder Initialization file for Domain "Here".
# This is the local Domain.
#
# DM_LOCAL_FACTORIES
#
*DM_LOCAL_FACTORIES
"AFactory.FactoryInterface"
#
# DM_REMOTE_FACTORIES
#
*DM_REMOTE_FACTORIES
"AFacYonder.FactoryInterface"
DOMAINID="YonderD"
RNAME="AFactory.FactoryInterface"
"BFactory.FactoryInterface"
DOMAINID="YonderD"
Listing 9-13 factory_finder.ini File for the There Remote Domain
#
#Copyright (c) 1999 BEA Systems, Inc.
#All rights reserved
#
# Factory Finder Initialization file for Domain "There".
#This is a remote domain.
#
# DM_LOCAL_FACTORIES
#
*DM_LOCAL_FACTORIES
"AFactory.FactoryInterface"
#
# DM_REMOTE_FACTORIES
#
*DM_REMOTE_FACTORIES
"AFacYonder.FactoryInterface"
DOMAINID="YonderD"
RNAME="AFactory.FactoryInterface"
"BFactory.FactoryInterface"
DOMAINID="YonderD"
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|