The important features of Tuxedo

June 28, 2013 - 12:00 am

1821

10 min read

(For more resources related to this topic, see here.)

Security

Security is one of biggest concerns for a Tuxedo administrator, and that is why Tuxedo provides mainly three levels of security features; in addition, Kerberos can be added for more.

First level: This is provided by the operating system. This security imposes restrictions on the clients and the administrator.
Second level: This is provided by Tuxedo. By default, any client program can join a Tuxedo application, but an application can be configured to ensure that all clients joining the application need to provide the password. There are many ways to restrict the client’s access to the application.
Third level: This is provided by an authentication service that checks for the combination of user identification, password, and client name, and it can connect to the Tuxedo application only if it passes this security.

There are mainly five types of incremental security provided by Tuxedo, which are as follows:

No authentication (NONE): This level might be used in a development environment or in physically secured environments, as the clients do not need to be authenticated to join the application.
Application password (APP-PW): This is a single password for the entire application; all the clients must provide this password to join the application.
End user authentication (USER_AUTH): In this level, the client needs to provide a username and password; this is to customize the security for applicationspecific users to ensure that they can access the Tuxedo application.
Optional access control (ACL): For all the previously mentioned levels, information needs to be provided by the client and the administrator so that access can be controlled to services, application queues, and events with access control lists. This level allows you to configure access only for those resources that need security; there is restricted access to a certain set of services while still allowing unprotected access to other services.
Mandatory access control (MANDATORY_ACL): This is very similar to the ACL level; the only difference is that the resources without an ACL are considered restricted, that is, access is not granted to resources that do not have an ACL permission.

In this section, we have discussed all the different types of security features that you may like to consider to secure your Tuxedo application.

Data-dependent routing (DDR)

Data-dependent routing (or context-based routing) is used to enable a client to send requests for a service to have multiple/distributed copies of it; this is determined by the data in the requested message. Once an administrator has set up data-dependent routing for an application, the client requests can be routed automatically to servers based on the data in the requests. This DDR can be used in three different ways; we will discuss this in the following sections.

Horizontally partitioned

When a Tuxedo service is associated with a horizontally partitioned database (which means the database has been divided into segments), each segment is used to store a different category of information. As an example, there are different sections in a hospital (for example, ENT and cardiology). So, the same service can be called from different clients, but the request will be routed to the service-particular department server as the database was designed as horizontally partitioned.

Rule-based servers

A rule-based server is a server that determines whether service requests meet certain application-specific criteria before forwarding them to service routines. For example, in Banking, they have a Primer customer and a Normal customer, a distinction made for certain business reasons (high-value transactions), and the same service is served using two different servers. So, the features of the rule-based servers can be used when you want to handle requests that are almost the same, by taking slightly different actions for business reasons.

Distributed applications

In a distributed application, you may have a mix of local and remote clients that communicate with multiple servers that could be distributed in multiple geographic locations or machines across organizations over the network. A request is sent for a particular service; it is determined by the data identifying the server that can fulfill the request. The Tuxedo system selects a server to receive the request by matching the data to the routing criteria provided in the Bulletin Board. The ROUTING section of the UBBCONFIG file provides information for data-dependent routing of service requests using the FML, XML, and VIEWS types of buffer. You can also use DDR as a load-balancing mechanism by routing certain requests to a specific server.

Data encryption

Data encryption means converting data into a coded format that is unintelligible to all users except the user for which the data is intended. When encrypted data arrives at its destination, it is decrypted to convert back to its original format. Encrypting does not increase the data size, but it adds to processing time as the system needs to encrypt and decrypt the data. The data is compressed during encryption, so you may gain some time as less data is being sent across the network. When data is compressed, it helps to increase data security because the data is somewhat scrambled during compression. In the UBBCONFIG file, ENCRYPTION_REQUIRED can be specified in any of the four sections in the configuration hierarchy: the RESOURCES, MACHINES, GROUPS, or SERVICES section. Setting ENCRYPTION_REQUIRED to Y at a particular level means that encryption is required for all the running processes at that level or below it.

Data compression

This option shrinks an application buffer so that it can be transmitted more quickly over a network to different machine(s). You can set a maximum threshold value for the buffer size to ensure that it automatically compresses the buffer when it crosses the mark. The buffer gets compressed, but it gets decompressed as it reaches the destination. Data compression happens before the data is transported between machines; it improves network performance and enhances the security to a limit as it involves coding/decoding the data. In the UBBCONFIG file, the parameter CMPLIMT under the MACHINES section helps you set the threshold message size for messages bound to remote processes and local processes respectively, on which the automatic data compression will take place.

Load balancing

The load-balancing technique is used to distribute service requests evenly among servers that offer the same service(s) to ensure that some servers will not be overburdened while some are idle or infrequently used. The LDBAL parameter in the RESOURCES section of the UBBCONFIG file can be used to set the load balancing with Y. Also, the LOAD parameter under the SERVICES section refers to a number; this is very much a relative number you need to come up with according to the time required to execute that service. The statistics are generated based on this weightage for each server, and the Bulletin Board preserves this for each machine. Each Bulletin Board keeps a track of the increasing load associated with each of its servers; this is to ensure that when all the servers are busy, the Tuxedo system can select the one with the minimum load. You do need to do this if you have only a single service in one server, or servers in a single-queue (MSSQ) configuration.

In this section, we have discussed various important features of Tuxedo – security, routing, encryption, compression, and load balancing. Each of these features should be considered more carefully during the application, design, and deployment stage to make your application run more efficiently and to address your various business needs without any custom code.

Administering the Tuxedo queue (/Q)

Tuxedo provides a reliable queue based on the XA-compliant resource manager (TMS – Transaction Manager Server), which provides the framework to store messages in a reliable storage and forward it to different components. These could be services, clients, or components within different Tuxedo processes. The purpose of a queue is to perform time-independent communication. Any client or server can store onto (enqueue) and retrieve (dequeue) a message from the queue. Tuxedo provides the TMQUEUE server, which provides this enqeuing and dequing service.

Tuxedo also provides a server called TMQFORWARD, which dequeues a message and forwards it to other services. Messages can be retrieved in any of several ordering schemes, including Last In, First Out (LIFO), First In, First Out (FIFO), priority order, and time-based order. More than one client or server can access the same queue.

There are three primary tasks for a Tuxedo administrator to carry out. They are configuring, maintaining, and monitoring the Tuxedo queue.

Configuration of resources for /Q

There are three servers (TMS, TMQUEUE, and TMQFORWARD) provided by the Tuxedo system that need to be configured in the SERVER section of the UBBCONFIG file.

Also, there must be a server group defined for each queue space as per the application usage or design. The TMSNAME and OPENINFO parameters need to be set accordingly; please see the following example in the UBBCONFIG file:

*GROUPS
TMQUEUE-G1    GRPNO=1 TMSNAME=TMS_QM
                         OPENINFO="TUXEDO/QM:/dev/deviceONE:QueueSpace1"
*SERVERS
TMQUEUE         SRVGRP="TMQUEUE-G1" SRVID=1550 RESTART=Y GRACE=0 
                       CLOPT="-s CUSTOMER:TMQUEUE"

In this example, the -s flag of the CLOPT parameter is used to name the queue space served by a given instance of the server.

We mentioned that the environment variable for the queue (/Q) is QMCONFIG, which needs to be set in the environment.

Creation of queue space and queues

To use a queue, we need to create the queue devices, queue space, and queues, in that order; qmadmin is the tool provided by the Tuxedo system to do this for us.

%UnixPromt%> qmadmin
> crdl /home/applicationQ/CustomerQdev 0 500

At this point, your device is created with a size of 500 physical pages beginning/ offset at block 0; you need to create the queue space next.

> qspacecreate
Queue space name: QueueSpace1
IPC Key for queue space: 12345
Size of queue space in disk pages: 300
Number of queues in queue space: 3
Number of concurrent transactions in queue space: 4
Number of concurrent processes in queue space: 4
Number of messages in queue space: 20
Error queue name: ErrorQ
Initialize extents (y, n [default=n]): y
Blocking factor [default=16]: 16

You have created the queue space and now you need to create a queue using the same qmadmin command.

> qcreate
Queue name: Customer
Queue order (priority, time, fifo, lifo): fifo
Out-of-ordering enqueuing (top, msgid, [default=none]): none
Retries [default=0]: 2
Retry delay in seconds [default=0]: 30
High limit for queue capacity warning (b for bytes used, B for blocks
used,
% for percent used, m for messages [default=100%]): 80%
Reset (low) limit for queue capacity warning [default=0%]: 0%
Queue capacity command:
No default queue capacity command
Queue Customer created

You have created the Customer queue; use the same steps to create ErrorQ before you exit out of this tool.

Note that if you need more space for the queue space, you can do that by using the qaddext command.

Monitoring /Q

Using qmadmin as the command-line tool or using the Tuxedo console, you can configure, monitor, and change queues in a Tuxedo application. It has a rich set of options (30+) to choose from.

In this section, we discussed Tuxedo /Q, which is one of the most important components of Tuxedo for reliable messaging. Tuxedo itself uses /Q for its internal process communication. The Tuxedo administrator is responsible for defining servers and creating queue spaces and queues using qmadmin, as described, and must define at least one queue server group with TMS_QM as the transaction manager server for the group.

Summary

In this article, we have discussed various important features of Tuxedo – security, routing, encryption, compression, and load balancing. Each of these features should be considered more carefully during the application, design, and deployment stage to make your application run more efficiently and to address your various business needs without any custom code. Also, we discussed responsibilities of Tuxedo administrator for administering the Tuxedo queue.