In object-oriented terminology, a child object is usually an instance of a class that derives from another class. In RPC Services, however, child objects have a more complex meaning, referring to dispatchers and callers that execute under the supervision of a parent dispatcher or caller (where the parent might not be a base class to the child).
Child objects support a particular type of client-server architecture, where the requests that the client issues and the server processes act on a set of objects that share a common protocol. In the server task, a parent dispatcher manages the incoming requests, creating child dispatchers and routing requests to them as needed. Each child dispatcher processes the requests for a specific type of object in the set. In the client task, a parent caller creates child callers that communicate with the child dispatcher for a specific request type.
Using a collection of child objects provides several benefits:
- Multiple caller-dispatcher pairs that share a single transport are more lightweight than the same caller-dispatcher pairs using separate transports.
- Each caller-dispatcher pair can manage distinct resources, with each child class corresponding to a different type of resource.
- When you use this model to manage distinct resources, you can easily extend the model to manage a new resource type.
Not all applications of remote procedure calls need or benefit from the added complexity of child objects. Cases that do benefit from servers that use child dispatchers include:
- Font servers that manage many fonts. The parent dispatcher defines the protocol for common font operations and passes calls to child dispatchers to handle individual fonts.
- Servers where extensibility is a key feature--for example, where you or another developer might want to add code to handle new object types sometime in the future.
To learn more about child objects, read "Introduction to child objects" on page 95.