The ToolTalk service allows an independent application to communicate with other applications without having direct knowledge of the other applications. To communicate, applications create and send ToolTalk messages. The ToolTalk service receives these messages, determines the recipients, and then delivers the messages to the appropriate applications (see Figure 1-1).
The two scenarios in this section illustrate how the ToolTalk service helps users solve their work problems. The message protocols used in these scenarios are hypothetical.
In computer-aided software engineering (CASE), the ToolTalk service provides a way to connect and coordinate individual programs in a programming environment.
In this scenario, Justine uses the following tools in her ToolTalk-based developer's environment:
a tool manager (a program to coordinate the development tools in the environment)
a graphical debugger
a call grapher
an editor
a source browser
These tools have been modified to use the ToolTalk service and implement the messages described in Table 1-1.
Table 1-1. CASE Message Protocol
Message | Description |
|---|---|
Started | Informs tool manager that this tool is started |
Stopped | Informs tool manager that this tool is stopped |
Launch | Requests a certain tool to start |
Quit | Requests a certain tool to stop |
Display | Requests an edit tool to load and scroll the file to a particular line number |
GetSelection | Requests that the tool with the current selection return the file name and line number |
To determine the cause of a particular error message,
Justine starts the tool manager.
From the tool manager, she double-clicks on the source browser and graphical debugger icons to start them.
The tool manager sends a Launch message to each tool.
As the tools start, they send a Started message to the tool manager with initialization information.
Justine loads a source code file in the source browser.
She finds where the error message is located in the source code and selects the text.
She selects the Set BreakPoint menu item on the graphical debugger tool.
The graphical debugger sends a GetSelection message to the tools currently running in the environment.
The source browser returns the file name and line number of the selected text.
The graphical debugger loads the file, moves to the specified line number, and sets the breakpoint.
Justine runs the program and locates the call which results in the error message.
She selects the Show Call Graph menu item on the graphical debugger tool.
The graphical debugger sends a CallGraphFunction message.
The ToolTalk service starts the installed call grapher and delivers the message.
The call grapher loads the call graph for the specified file and scrolls to the specified function.
Justine sees another suspicious function that is called just before the function that is producing the error.
She double-clicks on the suspicious function and the call grapher sends a Display message.
The ToolTalk service starts an editor and delivers the Display message.
The editor loads the file and scrolls to the specified line number.
Justine corrects the error and successfully runs her program.
From the tool manager, she shuts down all tools.
In the computer-aided design (CAD) of hardware components, tools that are able to communicate with each other help automate the design process for the hardware engineer.
In this scenario, Dustin uses a tool control program that orchestrates tool sequences and CAD tools that have been modified to use the ToolTalk service. All tools use a CAD message protocol that includes the messages described in Table 1-2.
Table 1-2. CAD Message Protocol
Message | Description |
|---|---|
ToolStarted | Informs interested tools that this tool has started |
ToolFinished | Informs interested tools that this tool has stopped |
DesignOpened | Informs interested tools that a particular design data set has been opened for access |
DesignWrite | Requests that a certain tool begins to write to a particular design data set |
DesignWriteDone | Informs interested tools that a particular design-write operation has been completed |
DesignRead | Requests that a certain tool begin to read a particular design data set |
DesignReadDone | Informs interested tools that a particular design-read operation has been completed |
Dustin starts the tool control program.
As a new tool is needed in the design sequence, he starts the required tool from the control program.
Each tool initializes with the ToolTalk service and sends out a ToolStarted message to notify the control program that it is now running.
Dustin loads a design into a PC layout tool for editing purposes.
When the tool has loaded the design, it sends out a DesignedOpened message, which notifies other tools in the environment that it has opened the file and begun to write design data.
When Dustin finishes editing the data, the layout tool sends a DesignWriteDone message, which signals the control program that the edit is complete.
The control program then sends a DesignRead message to the next tool required in the design sequence.
Applications create, send, and receive ToolTalk messages to communicate with other applications. Sending applications create, fill in, and send a message; the ToolTalk service determines the recipients and delivers the message to the receiving applications. 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.
ToolTalk messages are simple structures that contain fields for address, subject, and delivery information. To send a ToolTalk message, an application obtains an empty message, fills in the message attributes, and sends the message. The sending application needs to provide the following information:
Is the message a notice or a request? (that is, should the recipient respond to the message?)
What interest does the recipient share with the sender? (for example, is the recipient running in a specific user session or interested in a specific file?)
To narrow the focus of the message delivery, the sending application can provide more information in the message.
An important ToolTalk feature is that sending applications need to know little about the receiving applications because applications that want to receive messages explicitly state how these messages should appear. This information is registered with the ToolTalk service in the form of message patterns.
Applications can provide message patterns to the ToolTalk service at installation time and while the application is running. Message patterns are created similarly to the way a message is created; both use the same type of information. 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. These message patterns usually match the message protocols that applications have agreed to use. Applications can add more patterns for individual use.
When the ToolTalk service receives a message from a sending application, it compares the information in the message to the registed patterns. Once matches have been found, the ToolTalk service delivers copies of the message to all recipients.
For each pattern that describes a message an application wants to receive, the application declares whether it can handle or observe the message. Although many applications can observe a message, only one application can handle the message to ensure that a requested operation is performed only once. If the ToolTalk service cannot find a handler for a message, it returns the message to the sending application indicating that delivery failed.
When the ToolTalk service determines that a message needs to be delivered to a specific process, it creates a copy of the message and notifies the process that a message is waiting. If a receiving application is not running, the ToolTalk service looks for instructions (provided by the application at installation time) on how to start the application.
The process retrieves the message and examines its contents.
If the message contains a notice that an operation has been performed, the process reads the information and then discards the message.
If the message contains a request to perform an operation, the process performs the operation and returns the result of the operation in a reply to the original message. Once the reply has been sent, the process discards the original 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.
To determine which groups receive messages, you scope your messages. Scoping limits the delivery of messages to a particular session or file.
A group of processes running in the same X session or process tree session is called a session in this manual. A session also contains an instance of the ToolTalk communication program, ttsession.
When a process opens communication with the ToolTalk service, the session in which the action takes place becomes the default session for the process. The procid for the process in this case is provided by ttsession.
The concept of a session is important in the delivery of messages. Sending applications can scope a message to a session and the ToolTalk service will deliver it to all processes that have message patterns that reference 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. Senders can scope a message to a file and the ToolTalk service will deliver it to all processes that have message patterns that reference the file without regard to the process's default session. To update message patterns with the current file path name, applications join the file.
You can also scope a message to a file within a session. The ToolTalk service will deliver the message to all processes that reference both the file and session in their message patterns.
Before you modify your application to use the ToolTalk service you must define (or locate) a message protocol: a set of ToolTalk messages that describe operations applications agree to perform. The message protocol specification includes the set of messages and how applications should behave when they receive the messages.
To use the ToolTalk service, an application calls ToolTalk functions from the ToolTalk application programming interface (API). The ToolTalk API provides functions to register with the ToolTalk service, to create message patterns, to send messages, to receive messages, to examine message information, and so on. To modify your application to use the ToolTalk service, you must first include the ToolTalk API header file in your program. You also need to modify your application to:
Initialize and start a session with the ToolTalk service.
Register message patterns with the ToolTalk service.
Send and receive messages.
Unregister message patterns and close your ToolTalk session.
The following ToolTalk service components work together to provide interapplication communication and object information management:
One ttsession runs in an X server session or process tree session and communicates with other ttsession processes when a message needs to be delivered to an application in another session.
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 the Remote Procedure Call (RPC) to communicate between these ToolTalk components.
Applications provide the ToolTalk service with process and object type information in a type database in XDR format.
Figure 1-2 illustrates the ToolTalk service architecture.
The ToolTalk message server ttsession automatically starts when you open communication with the ToolTalk server. This background process must be running before any messages can be sent or received. Each message server defines a session.
To manually start a session, enter the following command on the command line:
ttsession [-A max_active_msgs][-a level][-d
display][-s][-t][-v][-h][-c command]
|
See Table 1-3 for a description of the ttsession parameters. (NOTE: If neither the -c or -d parameter is specified, the server specified in the $DISPLAY environment variable is used to start the X session.)
ttsession responds to two signals.
If it receives the USR1 signal, it toggles the trace mode on or off.
If it receives the USR2 signal, it rereads the types file.
Table 1-3. ttsession Parameters
Argument
Description
-A max_active_msgs
Specifies the maximum number of messages in-progress before a TT_ERR_OVERFLOW condition is returned. Default is 2000.
-a level
Sets the server authentication level.
The level must be unix or xauth .
-d display
Directs ttsession to start an X session for the given display.
Normally, ttsession uses the $DISPLAY environment variable.
-s
Enables silent operation; warning messages are not printed.
-t
Turns on trace mode. If trace mode is turned on while ttsession is running, messages appear on the console.
Use this mode to see how messages are dispatched and delivered. Trace mode displays the state of a message when it is first seen by ttsession. It also displays any attempt to send the message to a given process with the success of that attempt.
To toggle the trace mode on or off, use the USR1 signal.
-v
Prints the version number and exits.
-h
Prints help on how to invoke ttsession and exits.
-c command
Starts a process tree session and runs the given command.
The special environment variable _SUN_TT_SESSION will be set to the name of this session. Any process that was started with this environment variable will default to be in this session.
This parameter must be the last option on the command line; any characters placed after the -c parameter on the command line are taken as the command to be executed.
If command is omitted, the value of $SHELL is used instead.
Run your application as its own session if it runs as a background job, in a batch session, or in a session bound to a character terminal. To run your application in its own session, use the -c parameter with the ttsession command, as follows:
ttsession -c command-to-run-in-batch |
 | Note: The -c parameter must be the last option on the command line; any characters placed after the -c parameter on the command line are taken as the command to be executed |
To establish a session under the X Window System, execute ttsession either without arguments (which takes the display from the $DISPLAY environment variable) or specify the display with the -d parameter as follows:
ttsession -d :0 |
When ttsession is invoked, it immediately forks and the parent copy exits; the process managing the session executes in the background. The session is registered as a property, named by the atom _SUN_TT_SESSION on the root of screen 0; the host and port number is given for communication with the process managing the session.
The ToolTalk directories and files are described in the following table.
Table 1-4. Location of ToolTalk Service Files
A sample program called ttsample1_sgi is provided in the /usr/ToolTalk/examples directory, along with the makefile Makefile.sgi for building it. This program is used in a number of examples throughout this manual. It is similar to the ttsample1 program delivered in SunSoft™ ToolTalk, but has been modified to work in the X/Motif environment on SGI hosts. ttsample2_sgi_client and ttsample2_sgi_service combine to form the second example that runs on SGI hosts.
The following sample programs are also referred to in this manual. Although their code is provided, they will not run in the SGI environment and are for illustrative purposes only.