What Kind of Work Problems Can the ToolTalk Service Solve?

This section describes some of the interoperability problems the ToolTalk service is designed to solve. The ToolTalk service is the appropriate technology to use if your application needs:

• Tool inter-changeability

• Control integration

• Network-transparent events that are not owned by any well-known server (for example, an X server) and that do not have any predictable set of listeners

• Automatic tool invocation

• A widely-available distributed object system

• Persistent objects

Of course, there are some interoperability problems for which the ToolTalk service may not be the appropriate technology to use. However, when your application needs to solve both sorts of problems (that is, a combination of those interoperability problems for which the ToolTalk service is designed to solve and those problems for which it is not designed), you can use the ToolTalk service in combination with other technologies.

Tool Interchangeability

Use the ToolTalk service when you want plug-and-play capability. The term plug-and-play means that any tool can be replaced by any other tool that follows the same protocol. That is, any tool that follows a given ToolTalk protocol can be placed (plugged) into your computing environment and perform (play) those functions indicated by the protocol. Tools can be mixed and matched, without modification and without having any specific built-in knowledge of each other.

Control Integration

Use the ToolTalk service when your application requires control integration. The term control integration indicates a group of tools working together toward a common end without direct user intervention. The ToolTalk service enables control integration through its easy and flexible facilities for issuing arbitrary requests, either to specific tool instances or to anonymous service providers.

Network-Transparent Events

Use the ToolTalk service when your application needs to generate or receive network-transparent events. To be useful, traditional event mechanisms (such as signals and window-system events) require special circumstances; for example, you must know a process or window ID. The ToolTalk service allows events to be expressed naturally: in terms of the file to which the event refers, or the group of processes on the network to which the event is applicable. The ToolTalk service delivers events (called notices) to any interested process anywhere on the network. ToolTalk notices are a flexible and easy way to provide extensibility for your system.

Automatic Tool Invocation

Use the ToolTalk service when your application needs network-transparent automatic invocation. The ToolTalk service lets you describe the messages that, when sent from any location on the network, should cause your tool to be invoked. The ToolTalk auto-start facility is easier to use and less host-specific than the conventional inetd(1) facility.

Distributed-Object System

Use ToolTalk when you need to build your application on a distributed-object system that is available across a wide variety of platforms. ToolTalk's object system can be used by any application on all the popular UNIX platforms, regardless of whether the application

• Is single- or multi-threaded

• Has a command-line or graphical user interface

• Uses its own event loop, or that of a window-system toolkit

Programs coded to the ToolTalk object-oriented messaging interface are not portable to CORBA-compliant systems without source changes.

Persistent Objects

Use the ToolTalk service when your application needs to place objects unobtrusively in the UNIX file system.