The relationship between packages, modules, components and interfaces is summarised in this graph.
Gliffy Diagram | ||
---|---|---|
|
Package
A package consists of the files required for the package to function and a cryptographically signed manifest file and it's related physical files for one or more modules. For example, the package for the WinGate Data plugin consists of modules for both the UI and Engine side modules.which is used to validate package files. Typically a package represents an entire product or system of functionality such as Web Proxy Filter product, Script Engine or Logging. Packages typically contain executable module files (DLLs), help files, and/or other ancilliary files.
Module
A module is a set of functionality you wish to group together and provide as a single unit. Each module needs at least one DLL as it's entry point but can contain any number of supporting files. EG The WinGate HTTP Cache has a module for the engine side functionality and the UI side functionality.
Component
A conceptual set of functionality that you register with WinGate. For example, Data, Logging, Persistence, Permissions and Notifications all register themselves as components. The UI side and Engine side are considered different components.
Each module can register as many components as it wishesrefers to an executable DLL file within a package that represent distinct parts of your package/product. If you require engine side functionality you will have a module that is loaded and runs in the WinGate engine process. If you need to present a user interface then you may want to have a separate UI module that runs in the WinGate Management Console process. Each module shows up in the Modules panel of the WinGate Management Console and can be enabled or disabled by the administrator if the appropriate setting is in the manifest file for that module.
To expand on the example graph above, you may be providing a product called "Ultimate Monitoring System" that may consist of modules for:
- Malware scanning of HTTP and email traffic by the WinGate engine.
- Monitoring of chat protocols like MSN Messenger and Google Chat.
- Global threat assessment that coalesces information from around the globe on a schedule to warn administrators of trending threats.
- WinGate Management Console UI modules for all three of these that display information to the user.
In this example you would have a total of 6 modules in your package.
Modules can be loaded either in the WinGate Engine process (system service on Windows), or in the WinGate Management Console process, or both.
Info | ||||||
---|---|---|---|---|---|---|
|
Info |
---|
Modules can have dependency files which are specified in the Manifest file. Specifying a dependency in a manifest file does several things:
|
Component
Within a module you have components which are sets of common functionality that you register with WinGate. Although in practice there is normally only one component registered for each module, a module can register any number of components.
Components in turn register interfaces.
Interface
One or more groups of functionality that your components register with WinGate . For instance the Data UI module registers individual interfaces for managing data values and managing dashboards. Client code can bind to interfaces if they which to access their functionality.
via RegisterInterface, often to make it available for others to use. Using our "Ultimate Monitoring System" example, the Malware scanning engine component may decide to provide a couple of interfaces for client software to use.
- A general scanning interface that can scan a file or block of memory.
- Quarantine interface that other modules can use to quarantine their own data objects.
The global threat assessment module might expose interfaces for:
- Updating and inspecting the global threat information from it's configured servers
- Managing servers that the system uses so another WinGate module could register itself as a threat assessment server.