| Skip Navigation Links | |
| Exit Print View | |
|
ToolTalk User's Guide |
1. Introducing the ToolTalk Service
2. An Overview of the ToolTalk Service
4. Setting Up and Maintaining the ToolTalk Processes
5. Maintaining Application Information
6. Maintaining Files and Objects Referenced in ToolTalk Messages
7. Participating in ToolTalk Sessions
File-based Scoping in Patterns
File-based Scoping in Messages
Serialization of Structured Data
ToolTalk Message Delivery Algorithm
Process-Oriented Message Delivery
Object-Oriented Message Delivery
Modifying Applications to Send ToolTalk Messages
Using the General-Purpose Function to Create ToolTalk Messages
Creating Process-Oriented Messages
Creating and Completing Object-Oriented Messages
13. Managing Information Storage
A. Migrating from the Classing Engine to the ToolTalk Types Database
B. A Simple Demonstration of How the ToolTalk Service Works
Applications can send two classes of ToolTalk messages, notices and requests. A notice is informational, a way for an application to announce an event. Applications that receive a notice absorb the message without returning results to the sender. A request is a call for an action, with the results of the action recorded in the message, and the message returned to the sender as a reply.
When you send an informational message, the notice takes a one-way trip, as shown in .
Figure 8-1 Notice Routing
The sending process creates a message, fills in attribute values, and sends it. The ToolTalk service matches message and pattern attribute values, then gives a copy of the message to one handler and to all matching observers. File-scoped messages are automatically transferred across session boundaries to processes that have declared interest in the file.
When you send a message that is a request, the request takes a round-trip from sender to handler and back; copies of the message take a one-way trip to interested observers. illustrates the request routing procedure.
Figure 8-2 Request Routing
The ToolTalk service delivers a request to only one handler. The handler adds results to the message and sends it back. Other processes can observe a request before or after it is handled, or at both times; observers absorb a request without sending it back.
Offers are messages similar to Requests. However, responses are not expected when data are sent. Also, you can tell how many potential recipients there are for the message at the time it is sent. You can also tell whether those recipients have accepted, rejected, or “abstained” the message. Consequently, Offers is less general than Notices and Requests.
To allow you to track the progress of a request you sent, you will receive a message every time the request changes state. You will receive these state change messages even if no patterns have been registered, or no message callbacks have been specified.
|