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.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 such as help, data and other DLLs. For instance, the WinGate HTTP Cache has a module for its engine side functionality and its UI side functionality.
Component
A conceptual set of refers 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 practical terms practice there is typically normally only one component registered for each module (UI and Engine side being separate components), a module can register more than one component if it wishes such as the Schema module which houses the components for both the engine and UI.any number of components.
Components in turn register interfaces.
Interface
One or more groups of functionality that your components registers register with WinGate via RegisterInterface, often to make it available for others to use. For instance the Data UI module registers individual interfaces for managing data values and managing dashboards. Client code can then bind to the interfaces they wish to use and gain access to the functionality provided.
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.