Figure 2 gives a more detailed view of Program A's operating environment. As in Figure 1, the bold black line shows the conversation Program A has established with its partner program. The new line between the program and CPI Communications represents Program A's use of program calls to communicate with CPI Communications. The different types of CPI Communications calls are discussed in "Program Calls".
Figure 2. Operating Environment of CPI Communications Program
In addition to the new line with CPI Communications, Figure 2 also shows Program A using several other generic elements:
These elements are further discussed within this chapter.
Node services represents a number of "utility" functions within the local system environment that are available for CPI Communications and other programming interfaces. These functions are not related to the actual sending and receiving of CPI Communications data, and specific implementations differ from product to product. Node services includes the following general functions:
This function is required to set up the initial values of the side information and allow subsequent modification. It does not refer to individual program modification of the program's copy of the side information using Set calls, as described in "Conversation Characteristics". (Refer to specific product information for details.)
Node services is used by programs requiring direct interaction with a distributed directory. For example, a program might need to perform a search of the directory in order to determine the correct destination information. Once the correct object has been determined by making calls to node services, the program can pass the program destination information to CPI Communications. Alternatively, the program may pass a DN or PFID to CPI Communications and CPI Communications will access the directory (using node services) to retrieve the destination information for the program. For more information, see "Distributed Directory".
A program is started either by receipt of notification that the remote program has issued an Allocate call for the conversation (discussed in greater detail in "Starter-Set Flows") or by local (operator) action. In either case, node services sets up the data paths and operating environment required by the program, validates and establishes security parameters under which the program will execute, and then allows the program to begin execution. In the former case, node services receives the notification, retrieves the name of the program to be started and any access security information included in the conversation startup request, and then proceeds as if starting a program by local action.
The program should terminate all conversations before the end of the program. However, if the program does not terminate all conversations, node services will abnormally deallocate any dangling conversations.
Please see the appropriate product chapter in "Part 3. CPI-C 2.1 Implementation Specifics" for details on how each operating environment detects and deallocates dangling conversations.
As is discussed in greater detail in "Multiple Conversations", some programs do work on behalf of multiple partners. Each partner is represented by a context, or collection of logical attributes. Node services provides the necessary function and support (through system interfaces) to allow the program to manage different partner contexts. See "Contexts and Context Management" for more information.
Node services provides interfaces for CRMs both to acquire and to validate access security information on behalf of a user. In a distributed system, node services may use a distributed security service that provides authentication services to create or validate the access security information. See "Conversation Security" for more information.
As was previously discussed in "Identifying the Partner Program", CPI Communications allows a program to identify its partner program with a sym_dest_name. The sym_dest_name is provided on the Initialize_Conversation call and corresponds to a side-information entry containing destination information for the partner program. The information that needs to be specified in the side-information entry depends on the type of CRM (LU 6.2 or OSI TP) required to contact the program. Each piece of information may have associated attributes such as length and format for AP_Title and AE_Qualifier.
The possible information specific to a LU 6.2 CRM is:
Indicates the name of the LU where the partner program is located. This LU name is any name for the remote LU recognized by the local LU for the purpose of allocating a conversation.
When combined with the AE_qualifier, the application-process-title indicates the name of the application-entity where the partner program is located. The AP_title combined with an AE_qualifier is equivalent to a fully qualified partner_LU_name in SNA.
Indicates the application-entity-qualifier, which is used to distinguish between application-entities having the same AP_title, if required.
Specifies the name of the application context being used on the conversation. An application context is a set of operating rules that two programs have agreed to follow.
In addition, the entry may contain the following information, which is not CRM-type dependent.
Specifies the name of the remote program. TP_name stands for "transaction program name". In this manual, transaction program, application program, and program are synonymous, all denoting a program using CPI Communications.
Used to designate the properties of the logical connection that will be established for the conversation. The properties include, for example, the class of service to be used on the conversation. The system administrator defines a set of mode names used by the local CRM to establish logical connections with its partners. An LU 6.2 CRM always has the following modes defined for application usage: #BATCH, #BATCHSC, #INTER, and #INTERSC.
Indicates a DN that can be used to access destination information in a distributed directory. The information retrieved from the distributed directory will be used to establish the conversation. Associated attributes of directory_syntax and directory_encoding may be present. If a distinguished_name is present, only the security information from the entry (conversation_security_type, security_user_ID, and security_password) will be used. All other destination information from this side information entry will be ignored.
Specifies the type of access security information to be included in the conversation startup request. See "Conversation Security" for more information.
Specifies the user ID to be used for validation of access to the remote program by the partner system.
Specifies the password to be used with the user ID for validation of access to the remote program by the partner system.
Programs not wanting to use side information can specify a sym_dest_name of blanks on the Initialize_Conversation call. For more information, see Initialize_Conversation (CMINIT).
On VM, if a corresponding entry is not found in the side information table, the name provided in sym_dest_name will be used as the partner TP_name.
A distributed directory is a service that enables information to be stored in a single location. It is referred to as "distributed" because the information can be accessed from multiple locations in a network using local directory interfaces. The local directory interface (part of node services) handles the communications and information flows required to retrieve the requested information from the directory. Information is stored in the directory by placing it in a directory object. Directory objects may contain many different pieces of information.
Figure 3 shows Program A interacting directly with a local directory interface. When Program A provides a name to node services ((1)), node services accesses the distributed directory ((2) and (3)). The retrieved object is then returned to the program ((4)).
Figure 3. Generic Program Interaction with a Distributed Directory
A directory object that contains the destination information for a single installation of a partner program is referred to as a program installation object. A program installation object includes the following information:
Note: On distributed directories supporting attribute types, the PFID attribute type is uniquely identified with a registered ISO object identifier of 1.3.18.0.2.4.13.
For LU 6.2:
For OSI TP:
Notes:
See "Program Binding" for guidelines on the specific structure and format of the PFID and program binding.
Figure 4. Program Interaction with CPI Communications and a Distributed Directory
Both these examples require the program to provide a DN directly, either to node services or to CPI Communications. There are, however, several other ways a program can access information contained in the distributed directory:
CPI Communications does not attempt to integrate destination information from the distributed directory with destination information obtained from Set calls or side information. The following rules apply:
Distributed security allows a user or system to be defined at a single trusted authentication server using principal names rather than user IDs. For example, a user or program accessing three different systems might require three separate sets of user IDs and passwords, one for each system. Using distributed security, a user or system could use a single principal name and password to access all three systems.
Figure 5 shows how a distributed security service works. In this example, the user has already signed on with a principal name and has been authenticated to the local security service interface. After this initial sign-on, the user is not required to provide any additional security information. When the user executes a program that requests a conversation from the CRM ((1)), the CRM communicates with the local security service interface ((2)) and retrieves the security information to be sent with the conversation startup request. The local security service communicates with the Authentication Server ((3)) to determine this information, also referred to as authentication tokens, and returns it to the CRM ((4)). The CRM then sends the security information to the partner CRM in the conversation startup request ((5)). When the partner CRM receives the conversation startup request, it accesses its local security service interface and validates the authentication tokens ((6) and (7)).
Figure 5. CRM Interaction with Distributed Security Service
CPI Communications depends on the operating system for the normal execution and operation of the program. Activities such as linking, invoking, and compiling programs are all described in product documentation. See the product chapters, "Part 3. CPI-C 2.1 Implementation Specifics", for more specific information.