|
|
|
|
|
|
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.
In the versions 4.0 and 4.1 releases of the WLE 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 WLE version 4.0 and 4.1 systems consisted of only one "local domain."
Since WLE 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 "WLE domains."
Figure 9-1 shows a simple multiple-domain configuration.
The following steps describe single-domain communication between Client X and Domain A:
Benefits of Multiple Domains
Interdomain Communication
Figure 9-1 Multiple-domain Configuration
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.
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.
The whole point of the "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 for each domain and on the coordination of two of those configuration 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.
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.
You use three configuration files to configure multiple domains:
Configuring Multiple Domains
You must specify the following parameters in the UBBCONFIG
file to configure multiple domains:
The UBBCONFIG File
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
This is the name that will be referenced in a DMCONFIG
file. In that file, a WLE domain name will be referenced as:
"//<domain-name>"
The quotes are part of the reference and the slashes (//
) mean that the name applies to WLE domains, rather than to BEA TUXEDO domains. For example:
"//headquarters"
Note:
Every domain in an enterprise must have a unique domain name.
As with every other system service, there must be a group and a service name specified for a gateway. The service name is GWTDOMAIN
and must be associated, like every other group, with a server group and a server ID. The GROUPS
section might contain, for example:
LGWGRP GRPNO=4 LMID=LDOM
In this line, 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 you specify it in the SERVERS
section associated with the server group name chosen. For example:
GWTDOMAIN SRVGRP=LGWGRP SRVID=1
This tells the WebLogic Enterprise server that a domain gateway is to be used and that additional information is found in the 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 WLE domains.
The sections below concentrate on the information that applies to WLE 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 WLE. For WLE, the "service" name is the name of another WLE domain that can service WLE requests.
The DMCONFIG
file consists of up to eight parts, but one part, DM_ROUTING
, does not apply to WLE domains. The other seven parts refer to WLE 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
# *DM_LOCAL_DOMAINS *DM_REMOTE_DOMAINS *DM_TDOMAIN *DM_LOCAL_SERVICES *DM_REMOTE_SERVICES Domain Name
Gateway Group and Service
The Domain Configuration (DMCONFIG) File
#
WLE DOMAIN CONFIGURATION FILE
#
*DM_RESOURCES
VERSION=Experimental8.9
LDOM GWGRP=LGWGRP TYPE=TDOMAIN DOMAINID="MUTT"
TDOM1 TYPE=TDOMAIN DOMAINID="JEFF"
LDOM NWADDR="//MUTT:2507"
TDOM1 NWADDR="//JEFF:3186"
"//MUTT"
"//JEFF" RDOM=TDOM1
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
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 UBBCONFIG -defined gateway group 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 (it is not the domain ID) and it is not the same name as the gateway group. It 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.
DOMAINID = string
This 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 DOMAINID found in 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).
TYPE = TDOMAIN
This parameter is required to specify the use of domains for WLE.
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 BEA TUXEDO Reference.
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 (it is not the domain ID), and it is not the same name as the gateway group. It 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"
The DM_TDOMAIN section defines the network addressing information for gateways implementing WLE 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.
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 in a UBBCONFIG file RESOURCES section 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 WLE 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 WLE 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.
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 a UBBCONFIG file RESOURCES section as DOMAIN_NAME . Most likely this is the name of the domain in which the gateway resides, meaning that this (local) domain accepts WLE 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.
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.
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 Factory Finder domain configuration file (factory_finder.ini ). This is an ASCII file that can be created and updated using a text editor.
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"
RNAME="remote_factory_id.factory_kind"
DOMAINID="domain_id"
...
[*DM_LOCAL_FACTORIES]
["factory_id.factory_kind"]
...
The Master NameManager reads the FactoryFinder domain configuration 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 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 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, one that specifies those factories that the local domain can find in a remote domain (DM_REMOTE_FACTORIES ), and another that specifies which of the factories in the local domain are available to other domains (DM_LOCAL_FACTORIES) . Either section can be absent or contain nothing.
For more information about the factory_finder.ini file, see factory_finder.ini.
The DM_REMOTE_FACTORIES section provides information about the factories that are imported and are available in remote domains. It lists identifiers for factories in a remote domain that can be used by applications in the local domain. The identifier, under which the factory 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 in domain "Norwest" would be specified as:
*DM_REMOTE_FACTORIES
Teller.FactoryInterface
RNAME="BankTeller.FactoryInterface"
DOMAINID="Norwest"
If the RNAME is not specified, the factory_kind must be specified in the factory name; 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" . Also, the factory name must be enclosed in quotation marks. The following entry 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"
An entry for an imported factory must specify the identity of the factory in the remote domain using the keyword RNAME . The identifier of the remote factory must be enclosed within double quotation marks.
Because it is likely that the identities of factories in a remote domain may collide with the identity of factories in the local domain, the syntax supports the ability to specify alternative identities or "aliases" in the local domain for a factory. Specifying an alias can be accomplished by providing multiple entries for factories that have the same DOMAINID and RNAME values.
For example, the entry for a factory object to be registered by the TP Framework with the identifier BankTeller in domain "Norwest" , but made available in local domain as "Teller" and as "BankTeller" , would be specified as:
*DM_REMOTE_FACTORIES
Teller.FactoryInterface
RNAME="BankTeller.FactoryInterface"
DOMAINID="Norwest"
BankTeller.FactoryInterface
RNAME="BankTeller.FactoryInterface"
DOMAINID="Norwest"
The DM_LOCAL_FACTORIES section provides information about the factories that are exported by a local domain. Specification of factories can be used to restrict access to local factories from remote domains; that is, only factories specified are available to the remote domain.
This section contains the list of identifiers for factories that can be used by applications in a remote domain. The identifier, under which the factory 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. An entry that does not contain a factory_kind value is not defaulted with a value of "FactoryInterface" . This allows for future expansion when a Naming Service is available.
If the DM_LOCAL_FACTORIES section does not exist in a factory_finder.ini , or exists, but is empty, all factories in the local domain are available to remote domains. This allows administrators an easy means to provide this indication without having to provide an entry for every factory object in the local domain.
If the DM_LOCAL_FACTORIES section exists in a factory_finder.ini file, but contains the reserved keyword "NONE" , none of the factories in the local domain are available to remote domains.
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 .
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.
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, WLE knows that it can send the request to gateway GAB . The WLE 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.
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.
The listings in this section show the UBBCONFIG files for three directly connected domains: Here, There, and Yonder.
Listing 9-2 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-3 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-4 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
Listing 9-5 shows the DMCONFIG file for three directly connected domains: Here, There, and Yonder.
Listing 9-5 DMCONFIG File for 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
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-6 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-7 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 © 1999 BEA Systems, Inc. All rights reserved.
|