![]() |
![]() |
![]() |
![]() |
![]() |
• This feature supports FORWARD queue only for /Q. With Application Service Versioning enabled, when a client puts a message into FORWARD queue, the FORWARD queue forwards the queued message to the service that supports the client request version.To enable the application service versioning in UBB configuration file, add the APPVER option to the OPTIONS parameter in *RESOURCES section.To disable the application service version in UBB configuration file, remove the APPVER option from the OPTIONS parameter in *RESOURCES section.
Note: To enable the application service versioning in MIB, add the APPVER option to TA_OPTIONS in the T_DOMAIN class.To disable the application service versioning in MIB, remove the APPVER option from TA_OPTIONS in the T_DOMAIN class.
Note: Three attributes, REQUEST_VERSION, VERSION_POLICY, and VERSION_RANGE, are used in configuration files to specify the version and acceptable version range in a configured Tuxedo management entity. These three attributes can be configured in the *GROUPS and *RESOURCES section of the UBB configuration file, as shown in Listing 17‑1For more information, see UBBCONFIG(5)in Section 5 - File Formats, Data Descriptions, MIBs, and System Processes Reference in the Oracle Tuxedo Reference Guide.Take Listing 17‑1 for an example, application service version has the following rules:
• A server inherits the REQUEST_VERSION attribute from the group it belongs to. When a server advertises services, the services inherit version attributes from the group, to which the server belongs. If there is no version attribute value specified to the group, they will inherit upward from the attributes specified in *RESOURCES section. Based on this rule:
• When server1 advertises SVC2 and SVC3, the REQUEST_VERSION, VERSION_RANGE, and VERSION_POLICY of SVC2 and SVC3 are 2, “1-2”, and PROPAGATE, respectively.
• When server2 advertises SVC1, SVC2, and SVC3, the REQUEST_VERSION, VERSION_RANGE, and VERSION_POLICY of SVC1, SVC2, and SVC3 are 1, “3-4”, and non-PROPAGATE, respectively.
• When server3 advertises SVC1 and SVC2, the REQUEST_VERSION, VERSION_RANGE, and VERSION_POLICY of SVC1 and SVC2 are 3, "1-3", and non-PROPAGATE, respectively.
• If a native client joins the application without specifying the group name, its REQUEST_VERSION is 1.
• If a native client joins the application with a specific group name, such as GRP3, its REQUEST_VERSION is 3.
• If a /WS client joins the application, its REQUEST_VERSION is determined by the WSL, whose REQUEST_VERSION is 4 according to the UBB config file. So the REQUEST_VERSION of the /WS client is 4.
• If a JOLT client joins the application, its REQUEST_VERSION is determined by the JSL, whose REQUEST_VERSION is 3 according to the UBB config file. So the REQUEST_VERSION of the JOLT client is 3.Listing 17‑2 shows a domain configuration file application service version configuration example.From Listing 17‑2, the application service version are configured as follows:
• No REQUEST_VERSION is configured to REMOTEDOM1. Therefore the domain gateway will propagate the request version of all the requests come from REMOTEDOM1 without changing the incoming request version.
• The REQUEST_VERSION of the REMOTEDOM2 is configured to 4. Therefore the domain gateway will change the request version of all the requests come from REMOTEDOM2 to 4.
• The LOCALDOM imports R_SVC1 service from REMOTEDOM1 and specifies the VERSION_RANGE to "1-3". Therefore the VERSION_RANGE of the R_SVC1 service in the LOCALDOM is "1-3".
• The LOCALDOM imports R_SVC2 service from REMOTEDOM2 and specifies the VERSION_RANGE to "4-6". Therefore the VERSION_RANGE of the R_SVC2 service in the LOCALDOM is "4-6".
• The LOCALDOM imports R_SVC3 service without specifying VERSION_RANGE. Because the VERSION_RANGE of the imported service is still determined by VERSION_RANGE configuration of the *GROUPS and *RESOURCES, the VERSION_RANGE of the *RESOURCES is "1-2", and the VERSION_RANGE of R_SVC3 is "1-2".Using Listing 17‑1 as an illustration:
• Since the REQUEST_VERSION of server3 configured in Listing 17‑1 is 3, the server3 will call Server2:SVC2.
• Suppose the native client needs to call SVC3, so the candidate services are:Since the REQUEST_VERSION of the native client configured in Listing 17‑1 is 1, the native client will call Server1:SVC3
• Suppose the native client calls Server1:SVC1 and Server1:SVC1 needs to call SVC3, so the candidate services are:As configured in Listing 17‑1, the Server1:SVC1 will propagate the incoming REQUEST_VERSION which is 1, as a result the REQUEST_VERSION of Server1:SVC1 will become to 1, rather than its own REQUEST_VERSION 2, therefore the Server1:SVC1 will call Server3:SVC3
• If a request comes from REMOTEDOM2, suppose the original REQUEST_VERSION is 6, then the REQUEST_VERSION of the incoming request is changed to 4.
• If a request comes from REMOTEDOM1, suppose the original REQUEST_VERSION is 2, then the REQUEST_VERSION of the incoming request is still 2.You can configure REQUEST_VERSION, VERSION_RANGE, and VERSION_POLICY in the *GROUPS or *RESOURCES section of UBB config file. The low-level configuration overrides the high level-configuration.If there is no user-configured service version configuration at any level, the system uses the default value. That causes the result very different for the user configured configuration and default value. If you modify the REQUEST_VERSION, VERSION_RANGE or VERSION_POLICY using MIB, it is the user-configured service version configuration. It is necessary to provide a method to reset this modification to the default value using MIB, otherwise you cannot restore the UBB config file to its original state through MIB operation.To reset the REQUEST_VERSION, VERSION_RANGE, and VERSION_POLICY to default value, you just need to simply set value as DEFAULT.
• control the requests coming from JCA/WTC/old Tuxedo domain by setting the REQUEST_VERSION and VERSION_POLICY attributes in the DM_REMOTE section
• control the requests going to JCA/WTC/old Tuxedo domain by setting VERSION_RANGE in the DM_IMPORT section.If the request coming from the old Tuxedo domain enters in the Tuxedo 12c domain which has no REQUEST_VERSION configured for the corresponding remote domain, the request version is changed to 0.