The internal architecture of the iSeries™ Navigator product is intended to serve as an integration point for an extensible, broad-based operations interface for the iSeries server.
Each functional component of the interface is packaged as an ActiveX server DLL. iSeries Navigator uses Microsoft's Component Object Model (COM) technology to activate only the component implementations that currently are needed to service a user request. This avoids the problem of having to load the entire product at start up, thereby consuming the majority of Windows® resources, and impacting performance of the entire system. Multiple servers may register their request to add menu items and dialogs to a given object type in the Navigator hierarchy.
Plug-ins work by responding to method calls from iSeries Navigator that are generated in response to user actions. For example, when a user right-clicks on an object in the Navigator hierarchy, the Navigator constructs a context menu for the object, and displays the menu on the screen. The Navigator obtains the menu items by calling each plug-in that has registered its intention to supply context menu items for the selected object type.
The functions that are implemented by a plug-in logically are grouped into "interfaces." An interface is a set of logically related methods on a class that iSeries Navigator can call to perform a specific function. The Component Object Model supports the definition of interfaces in C++ through the declaration of an abstract class that defines a set of pure virtual functions. Classes that call the interface are known as implementation classes. Implementation classes subclass the abstract class definition and provide C++ code for each of the functions defined on the interface.
A given implementation class may implement as many interfaces as the developer chooses. When creating a new project workspace for an ActiveX server DLL in the Developer Studio, the AppWizard generates macros that facilitate interface implementation. Each interface is declared as a nested class on a containing implementation class. The nested class has no member data and does not use any functions other than those that are defined on its interface. Its methods typically call functions on the implementation class to get and set state data, and to perform the actual work that is defined by the interface specification.