It is common that the user wants to keep existing functionality but also want to add new functionality into a service as time goes by. To reduce the compatible risk, it is better to provide two different version services with the same service name, one for old functionality, and the other for new functionality. The old client can still use the existing functionality without changing any code while the new client can use the new functionality.

Application Service Versioning feature offer a configuration driven way which can be used by Tuxedo customers to plan, develop, test, scale, and deploy their Tuxedo applications in each stage. The user can use the version to partition current Tuxedo application into different virtual application domains, different virtual machines, and different virtual server groups on current Tuxedo management hierarchy, so as to respond to various of special business access logics and on the other hand satisfy upgrading requirements in non-stop mode.

This feature supports for COBOL application and programming environment without requiring special changes for COBOL environment.

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.

You can enable/disable the application service versioning feature using UBB configuration file or MIB.

• Enable/Disable Application Service Versioning Using UBB Config File
  
• Enable/Disable Application Service Versioning Using MIB
  

• UBB Config File Configuration
  
• Domain Config File Configuration
  

When the application service versioning feature is enabled, the system dispatches the requests to the service according to both the service name and service version range. We call this mechanism Version Based Routing (VBR). When a service entry matching the requested service name is found, VBR is used for further routing decision.

VBR only does a simple numeric comparison using the current request version number with two boundary values of version range. VBR returns "no entry is found" error to the caller when all the services with the matching name are not allowable for this versioned request.

As a routing mechanism, VBR functions the same as the existing routing mechanisms, like DDR (Data Dependent Routing), TAR (Transaction Affinity Routing), and RAR (Request Affinity Routing).

VBR can work with other routing mechanisms. Oracle Tuxedo chooses the services that match all criteria if there are multiple routing mechanisms. It is recommended you are clear about the interoperability among these routing mechanisms before using them together.

Using the following listing as an illustration:

• Suppose server3 needs to call SVC2 during the initializing period, so the candidate services are:

  Server1:SVC2 1-2
  Server2:SVC2 3-4

  Since the REQUEST_VERSION of server3 configured in the following Listing is 3, the server3 will call Server2:SVC2.
• Suppose the native client needs to call SVC3, so the candidate services are:

  Server1:SVC3 1-2
  Server2:SVC3 3-4

  Since the REQUEST_VERSION of the native client configured in the following Listing is 1, the native client will call Server1:SVC3
• Since the REQUEST_VERSION of the native client configured in the following Listing 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:

  Server2:SVC3 3-4
  Server3:SVC3 1-3

  As configured in the following Listing, 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.

For example, modify the REQUEST_VERSION in MIB as shown in the following Listing.

Listing Resetting the User Configured Service Version Information Using MIB

SRVCNM    .TMIB
TA_OPERATION    SET
TA_CLASS        T_GROUP
TA_SRVGRP       APPGRP1
TA_GRPNO        1
TA_CURLMID      SITE1
TA_REQUEST_VERSION       4
Then the user reset the REQUEST_VERSION to default value through MIB:
SRVCNM    .TMIB
TA_OPERATION    SET
TA_CLASS        T_GROUP
TA_SRVGRP       APPGRP1
TA_GRPNO        1
TA_CURLMID      SITE1
TA_REQUEST_VERSION       DEFAULT

You can control how the JCA/WTC/old Tuxedo domain interoperates with the new Tuxedo domain using the domain configuration file, as follows:

• 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.

The default request version is 0-65535, which means the new domain can call all the imported service from JCA/WTC/old Tuxedo domain by default.

In MP environment, if a local client runs on a machine that is installed the old version Tuxedo, the client can call any version service because there is no version control for the old version Tuxedo.

Likewise, for the /WS or Jolt client connecting to an old version WSL or JSL server, there is no version control for them.