The int library is built on top of the Tools.h++, Threads.h++, and net class libraries. These libraries must be installed before you can use the int library. Tools.h++, included in Tools.h++ Professional, provides low-level string manipulation and collection classes that simplify the implementation of the int library. Threads.h++, which is not included in Tools.h++ Professional, provides cross-platform, object-oriented thread management, synchronization, and inter-thread communication mechanisms. The net library, included in Tools.h++ Professional, encapsulates general socket interfaces, and serves as the underlying interprocess communication mechanism for the int library.
Figure 18 shows the basic relationship between the libraries:
The client/agent architecture of the int library allows complete flexibility. You can use the client classes for fine control over the details of an application, or the agent classes for simplicity and ease of use.
A client class is an interface to an Internet protocol that provides complete control of the underlying protocol. This allows you to create custom solutions that rely on specific low-level protocol features.
A client class uses object-oriented concepts and C++ language features to make the underlying system easier to use. For example:
Tools.h++ classes are used to simplify the interface and implementation.
Default arguments are used to make the most common cases easy to program.
Exceptions are used to provide a flexible, easy-to-use, error-handling system.
An agent class provides a higher level of abstraction to perform protocol transactions. It handles more details of a protocol for you (so you don't have to) than its respective client class, but as a result provides less flexibility than the client class.
The handle-body or interface/implementation idiom is used throughout the int library. Its purpose is to decouple the interface from its implementation. Along with reference counting, it also simplifies memory management, allows efficient body object sharing, and provides automatic object life-cycle control.
In the handle-body idiom, the handle class is an interface to an internal object representation, or body. The operations provided by an internal representation are typically accessed by calling member functions supplied by the handle class. These functions generally forward control to the corresponding function in the body class instance. For example, an RWIFtpAgent object is a handle to an RWIFtpAgentImpl instance that performs the protocol interaction. Figure 19 shows the architecture of RWIFtpAgent and its related classes. The classes, RWIHttpAgent, RWIPop3Agent, and RWISmtpAgent, use the same design pattern.
Protocol client classes available in the int library have a similar structure. Figure 20 shows the architecture of RWIFtpClient and its related class RWIFtpClientImpl.
Again, the RWIFtpClient object is a handle to an RWIFtpClientImpl instance that performs the protocol interaction. The classes RWIHttpClient, RWIPop3Client, and RWISmtpClient use the same design.
Reference counting allows multiple handles to refer to the same underlying body object. A handle instance is created by binding to a body instance, located on the heap. When a handle-body binding occurs, the reference counter is incremented. When a handle is detached from its body, the body's reference counter is decremented. When all the handles that refer to a particular body object have gone out of scope, the body object's destructor is invoked and the body object is deleted from the heap.
The protocol replyprotocols classes encapsulate protocol replies typical of common Internet protocols. Protocol replies are returned from calls to client protocol command methods. Protocol-specific portions of the reply hierarchy are explained in the sections on the individual protocols. Figure 21 shows the general reply hierarchy:
RWIReply is the abstract base class from which all protocol replies inherit. RWINumReply, which derives directly from RWIReply, is intended to encapsulate a numerical protocol reply. A numerical protocol reply is composed of single-line numerical replies contained in RWINumReplyLine objects. Specific protocol replies for FTP, HTTP, and SMTP are in the classes RWIFtpReply, RWIHttpReply, and RWISmtpReply respectively, which derive from RWINumReply. The RWIPop3Reply class inherits directly from RWIReply, because the POP3 protocol does not use numerical responses.
Agent and client classes in the int library are based largely on the Internet service that they provide. Like most network protocols, there is an expected command sequence permitted in protocols. The int library enforces this command sequence by using internal finite state machines. If a protocol command method is used out of order, an exception is thrown.
©Copyright 2000, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.