Component Model
Structure
As described in the Introduction, AOP is first of all a component model for service-oriented software design.
Here is a closer look at the components structure:
At the center is the AOP node, 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, 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 components, but together with the CID it can be uniquely identified.
Services
A component may offer:
Both are identified by a Symbol Path.
When we talk about a “service”, we mean a set of such related functions and notifications. Typically, a service consists of functions and notifications with the same prefix; for example, datapoint.Get, datapoint.Create, and datapoint.Created belong to the “datapoint” service, but in principle, a service may contain any functions.
The division into services is intended solely for documentation and structuring purposes and has no other function. A component can basically offer any named functions and notifications and may implement multiple services or only parts of a service.
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.
Skills and Versioning
A skill groups one or more services - and thus all the functions and notifications they contain. You could think of a skill also as sub-part of the API.
All versioning within AOP is based on Skills and follows Semantic Versioning 2.0.0.
A component that wants to establish a connection to the AOP node first communicates which skills it needs, along with their versions, and which skills it provides, along with their versions. A connection is possible only if this exchange confirms compatibility.
A list of currently available Skills can be found in the API reference, which is itself organized by skills.
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 Extensions are able to connect.
Components, that use the generic API Access may access using their CID together with the configured auth token, all other components need to provide a valid license file.
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 in that case 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.