This chapter provides background information about the ToolTalk™ service. It also highlights the components that you, as a system administrator, should be familiar with in order to respond to user questions about ToolTalk messages. The remaining chapters of this manual contain detailed installation and maintenance instructions.
The ToolTalk service enables independent applications to communicate with each other without having direct knowledge of each other. Applications create and send ToolTalk messages to communicate with each other. The ToolTalk service receives these messages, determines the recipients, and then delivers the messages to the appropriate ToolTalk applications, as shown in Figure 1-1.
To use the ToolTalk service to communicate, applications agree on a message protocol. A message protocol is a set of ToolTalk messages that describe operations the applications agree to perform. The message protocol specification includes the set of messages and specifies how applications should behave when they receive each message.
The following ToolTalk service components work together to provide interapplication communication and object information management:
ttsession is the ToolTalk communication process.
One ttsession runs in an X server session or process tree session and communicates with other ttsessions when a message needs to be delivered to an application in another session.
rpc.ttdbserverd is the ToolTalk database server process.
One rpc.ttdbserverd is installed on each machine which contains a disk partition that stores files of interest to ToolTalk clients or files that contain ToolTalk objects.
File and ToolTalk object information is stored in a records database managed by rpc.ttdbserverd.
libtt is the ToolTalk application programming interface (API) library.
Applications include the API library in their program and call the ToolTalk functions in the library.
The ToolTalk service uses Remote Procedure Call (RPC) to communicate between these ToolTalk components.
Applications provide the ToolTalk service with process and object type information. This information is stored in an XDR formatted types database.
Figure 1-2 illustrates the ToolTalk service architecture.
An important ToolTalk feature is that sending applications need to know little about the receiving applications. Applications that want to receive messages register their interest in specific types of messages with the ToolTalk service.
To communicate, applications create, send, and receive ToolTalk messages. Sending applications create, fill in, and send a message; the ToolTalk service determines the recipient and delivers the message to the receiving application. Receiving applications retrieve messages, examine the information in the message, and then either discard the message or perform an operation and reply with the results.
Sending applications need to know little about the receiving application because applications that want to receive messages explicitly state how these messages should appear. This information is registered with ToolTalk in the form of message patterns. These message patterns usually match the message protocols that applications have agreed to use. Applications can add more patterns for individual use.
Message patterns are created similar to the way messages are created; the same type of information is used in both. For each type of message an application wants to receive, it obtains an empty message pattern, fills in the attributes, and registers the pattern with the ToolTalk service. Applications provide message patterns to the ToolTalk service at installation time or while the application is running.
When the ToolTalk service receives a message from a sending application, it compares the information in the message to the registered patterns. Once matches have been found, the ToolTalk service delivers copies of the message to all recipients with patterns that match the message.
The ToolTalk service provides two methods of addressing messages: process-oriented messages and object-oriented messages.
Process-oriented messages are addressed to processes. Applications that create a process-oriented message address the message to either a specific process or to a particular type of process. Process-oriented messages are a good way for existing applications to begin communication with other applications. Modifications to support process-oriented messages are straightforward and usually take a short time to implement.
Object-oriented messages are addressed to objects managed by applications. Applications that create an object-oriented message address the message to either a specific object or to a particular type of object. Object-oriented messages are particularly useful for applications that currently use objects or that are to be designed around objects. If an existing application is not object–oriented, the ToolTalk service allows applications to identify portions of application data as objects so that applications can begin to communicate about these objects.
Process-oriented messages provide a communication path between applications to deliver information to, or to request that an operation be performed by, the process receiving the message. Concepts used in process–oriented messages are described in the following subsections.
One execution of an application, tool, or program that uses the ToolTalk service is called a process in this manual. A process must have initialized and registered with the ToolTalk service.
Although no process may be running an application, the application can be considered as a potential receiving application by ToolTalk if message patterns and instructions for starting the application are provided in a process type (ptype) file. The instructions tell the ToolTalk service to perform one of the following operations:
Start the application and deliver the message
Queue the message until the application is running
Discard the message
To make the information available to the ToolTalk service, the ptype file is compiled with the ToolTalk type compiler tt_type_comp at application installation time. After the ptype file is compiled, the application instructs the ToolTalk service to retrieve the ptype information as part of the application installation script. If the application does not instruct the ToolTalk service to retrieve the ptype information (either by omission or because of an error condition), you can force the ToolTalk service to read the ptype information. See Chapter 3, “Maintaining Application Information,” for more information.
A group of processes running in the same X server session or process tree session is called a session in this manual. A session also contains an instance of the ToolTalk communication program ttsession.
The concept of a session is important in the delivery of messages. Sending applications can “scope” (that is, limit the delivery of) a message to a session and the ToolTalk service will only deliver the message to processes with matching message patterns that refer to the current session. To update message patterns with the current session identifier (sessid), applications join the session.
A container for data that is of interest to applications is called a file in this manual.
The concept of a file is important in the delivery of messages. Sending applications can scope a message to a file and the ToolTalk service will deliver the message to all processes with matching message patterns that refer to the file. To update message patterns with the current file path name, applications join the file.
The ToolTalk service stores location information about files in a ToolTalk database that is in the same disk partition as the file. This information needs to be up-to-date for the ToolTalk service to deliver messages. You may have to install the ToolTalk database program rpc.ttdbserverd on machines that contain files referenced in ToolTalk messages.
Object-oriented messages are addressed to objects managed by applications. If your installed applications use this method of messaging, you need to be familiar with process-oriented message concepts plus the ToolTalk concept of objects.
Object data is stored in two parts as shown in Figure 1-3.
One part is called the object content. The object content is managed by the application that creates or manages the object and is typically a piece, or pieces, of an ordinary file: a paragraph, a source code function, or a range of spreadsheet cells, for example.
The second part is called the object specification (spec). A spec contains standard properties such as the type of object, the name of the file in which the object contents are located, and the object owner. Applications can also add their own properties to a spec, for example, the location of the object content within a file. Applications create and write specs to the ToolTalk database managed by rpc.ttdbserverd.
A ToolTalk object is a portion of application data for which a ToolTalk spec has been created.
When a message is addressed to a specific object or a type of object, the ToolTalk service must be able to determine to which application the message is to be delivered. Applications provide this information in an object type (otype) file. An otype file includes the ptype name of the application that manages the object and message patterns that pertain to the object.
These message patterns also contain instructions that tell the ToolTalk service what to do if a message is available but the application is not running. In this case, ToolTalk performs one of the following instructions:
Start the application and deliver the message
Queue the message until the application is running
Discard the message
To make the information available to the ToolTalk service, the otype file is compiled with the ToolTalk type compiler tt_type_comp at application installation time. As with ptype files, if the application does not instruct the ToolTalk service to retrieve the otype information you can force the ToolTalk service to read otype information. See Chapter 3, “Maintaining Application Information,” for more information.
When object-oriented messages are used, a ToolTalk file includes the statement
can also contain ToolTalk objects |
As with files referenced in process-oriented messages, the ToolTalk service stores location information about these object-containing files in the ToolTalk database. It also includes information about the objects contained in a file.
The ToolTalk package contains a set of shell commands you can use to copy, move, and remove ToolTalk files (that is, files mentioned in messages and files that contain ToolTalk objects). After a standard shell command (such as cp, mv, or rm) is performed, the ToolTalk service is notified that a file location has changed.
The ToolTalk package also contains a database check and repair utility for the ToolTalk database, ttdbck, that you can use to check and repair your ToolTalk databases.