Component Model
As described in the Introduction, AOP is first of all a component model.
Here is a closer look at the components structure:
At the center is the AOP core, which provides the API via Websocket IPC and allows components to connect.
Components
Components are independent software modules running as separate processes. These can be executables (.exe) written in different programming languages like C#, C++ and others or simple JavaScript code executed in a browser.
Components that do not provide their own services are also called clients. If components use Websocket IPC to connect, they can use the full API, call functions and receive notifications.
Components in the proper sense, which offer their own services, must necessarily use IPC. With their services they in turn extend the available API. So these components at the same time use and form the API.
Each instance of a component or client, which connects to a AOP Node is locally identified by a Client ID (CID). This CID basically forms a namespace for its services. The same service can be offered by different Extensions, but together with the CID it can be uniquely identified.
Services
A component may offer as services:
Both are identified by a Symbol Path.
Usually, when we talk about a service, we mean the functions and notifications with the same prefix, e.g. datapoint.Get, datapoint.Create, datapoint.Created belong to the service “datapoint”.
The division into services is purely for documentary and structuring purposes and has no further function. A component can basically offer any named functions and notifications.
Functions
All function calls are asynchronous. A function is called with name and possibly parameters from a specific other component.
The calling component always receives a response with a result, error or return value if applicable.
Notifications
Notifications are triggered by the providing component similar to a function call with name and parameters. The notification is forwarded by AOP to all components which have registered for it.
Due to their broadcast character, notifications do not have any return values and the delivery of notifications is also not monitored.
Authentication and Licensing
Each instance of a component which should be able to connect to an AOP Node has to be configured as Extension first. The assigned Extension code will be used as CID for communication. Only such explicitely configured Extension are able to connect.
Additionally, within AOP a license file defines which functions components can access.
For that purpose each type of component is identified by a module code. Only if its module code is defined in the used AOP license, the component can connect.
During authentication, the component sends a LIC file with a list of services it will use. Only these services will be accessible by the component.
Optionally, access can also be licensed for different module editions. The LIC file in this case contains sections for each edition, indetified by an Edition ID, which has to be entered in the AOP license as well.
Each manufacturer will have its dedicated private key, which is used to sign messages during authentication. The corresponding public key is defined in the LIC file and also noted in the AOP license, so the component and the correctness of the authentication can be verified.