|
|
|
|
|
|
Using Features of the TPINIT Typed Buffer
The ATMI client must explicitly invoke the tpinit() function in order to take advantage of the following features of the TPINIT typed buffer:
Client Naming
When an ATMI client joins an application, the BEA Tuxedo system assigns a unique client identifier to it. The identifier is passed to each service called by the client. It can also be used for unsolicited notification.
You can also assign unique client and usernames of up to 30 characters each, by passing them to the tpinit() function via the tpinfo buffer argument. The BEA Tuxedo system establishes a unique identifier for each process by combining the client and usernames associated with it, with the logical machine identifier (LMID) of the machine on which the process is running. You may choose a method for acquiring the values for these fields.
Note: If a process is executing outside the administrative domain of the application (that is, if it is running on a workstation connected to the administrative domain), the LMID of the machine used by the Workstation client to access the application is assigned.
Once a unique identifier for a client process is created:
Refer to Writing Event-based Clients and Servers for information on sending and receiving unsolicited messages, and the BEA Tuxedo ATMI C Function Reference for more information on tmadmin(1).
The following figure shows how names might be associated with clients accessing an application. In the example, the application uses the cltname field to indicate a job function.
Client Naming
Unsolicited Notification Handling Unsolicited notification refers to any communication with an ATMI client that is not an expected response to a service request (or an error code). For example, an administrator may broadcast a message to indicate that the system will go down in five minutes. A client can be notified of an unsolicited message in a number of ways. For example, some operating systems might send a signal to the client and interrupt its current processing. By default, the BEA Tuxedo system checks for unsolicited messages each time an ATMI function is invoked. This approach, referred to as dip-in, is advantageous because it: 
As some time may elapse between "dip-ins," the application can call the tpchkunsol() function to check for any waiting unsolicited messages. Refer to Writing Event-based Clients and Servers for more information on the tpchkunsol()function.
When a client joins an application using the tpinit() function, it can control how to handle unsolicited notification messages by defining flags. For client notification, the possible values for flags are defined in the following table.
Client Notification Flags in a TPINIT Typed Buffer
Refer to tpinit(3c) in the BEA Tuxedo ATMI C Function Reference for more information on the TPINIT typed buffer flags. System Access Mode An application can access the BEA Tuxedo system through either of two modes: protected or fastpath. The ATMI client can request a mode when it joins an application using the tpinit() function. To specify a mode, a client passes one of the following values in the flags field of the TPINIT buffer to the tpinit() function. System Access Flags in a TPINIT Typed Buffer
Resource Manager Association An application administrator can configure groups for servers associated with a resource manager, including servers that provide administrative processes for coordinating transactions. Refer to Setting Up a BEA Tuxedo Application for information on defining groups. When joining the application, a client can join a particular group by specifying the name of that group in the grpname field of the TPINIT buffer. Client Authentication The BEA Tuxedo system provides security at incremental levels, including operating system security, application password, user authentication, optional access control lists, mandatory access control lists, and link-level encryption. Refer to Setting Up a BEA Tuxedo Application for information on setting security levels. The application password security level requires every client to provide an application password when it joins the application. The administrator can set or change the application password and must provide it to valid users. If this level of security is used, BEA Tuxedo system-supplied client programs, such as ud(), prompt for the application password. (Refer to Administering a BEA Tuxedo Application at Run Time for more information on ud, wud(1).) In turn, application-specific client programs must include code for obtaining the password from a user. The unencrypted password is placed in the TPINIT buffer and evaluated when the client calls tpinit() to join the application. Note: The password should not be displayed on the screen. You can use the tpchkauth(3c) function to determine:
Typically, a client should call the tpchkauth() function before tpinit() to identify any additional security information that must be provided during initialization.
Refer to Using Security in CORBA Applications for more information on security programming techniques.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|