Aeonics Technological Overview
Introduction
The Aeonics framework is geared towards extreme flexibility and configurability at runtime, with an emphasis on modularity. This enables quick iteration and the ability to adapt the system to evolving business requirements without significant downtime. It's a compelling architecture with much to offer, especially for businesses that need to adapt rapidly to changing conditions or requirements.
The inclusion of logging, monitoring, and security as cross-cutting concerns that are natively integrated into the Aeonics framework makes it even more powerful and versatile. The framework's capabilities for handling these cross-cutting concerns as configurable Items is remarkable and offers a solution for complex enterprise needs. It makes the system highly adaptive, though with great power comes the responsibility of managing complexity effectively.
Aeonics’ performance considerations are well-thought-out, aiming to optimize resource usage while maintaining low latency and high throughput. The specialized SEDA (Staged Event-Driven Architecture) approach is well-suited for this type of event-driven, highly configurable system. The architecture’s combination of dynamic configurability, modularity, and built-in cross-cutting concerns like logging, monitoring, and security is very innovative. The added focus on performance optimization and system resilience further rounds off Aeonics as a powerful solution for complex, high-demand scenarios.
Overview and Terminology
In order to fully grasp how the system is working, it is important to understand the following basic concepts.
Items
Aeonics is a dynamic system, meaning that it can be modified and reconfigured at runtime.
Items are the building blocks that can be assembled to process Data structures and form the business logic.
An Item is a Java class that can be created from a JSON representation or serialized back to JSON, this makes it very easy and convenient to create new class instances at runtime.
Items are thus elements that contain some logic (the code itself) and some parameters (the JSON to configure it), they can represent an entity such as a User or be Data processing units such as a Sum. The idea is that these Items are quite atomic and represent something very specific that can be reused within the system.
The Registry
Since Items are created at runtime, you cannot declare them in a variable, you have to store them in the Registry.
The registry is the location in memory where all Items are available.
So, at any point in time and anywhere in the code, you can ask the Registry for an Item given its unique ID or its friendly name.
The Factory
When you create a new Item instance, you just provide some JSON, you are not actually writing code to call the constructor.
This means that the system needs to figure out which Item you needed and then create it for you. This is the job of the Factory.
The Factory is thus the repository of the Item types that you can create, whereas the Registry is the repository of all the created instances themselves.
Since the system is dynamic, you have the possibility to add your own Item type in the Factory and enable new combinations, this requires coding. Meanwhile, the code for an Item is very succinct because it is just one simple class. So, from now on, you have the possibility to provide new types of Items and configure instances in the Registry... but how does it actually do anything?
Ingress, Regress, Egress
In Aeonics, processing always occurs as a response to an event that triggers some actions.
The chain is very basic and always starts with an Ingress Item that collects or receives somehow some Data.
This means that these Ingress items are the entry point of the system. Then, Data is carried through a chain of Regress Items that do some processing,
and end with an Egress Item that completes the flow.
But which Ingress sends data to what Regress and so on, how does the system know what needs to be done and in which order?
Queues
All these Ingress, Regress and Egress steps are usually the Items you will create and configure.
And on top of that, there is another Item (yes remember, everything is an Item that can be configured at runtime): a Queue.
The Queue is responsible for linking the steps together and pass Data from one Item to the next until it reaches the end.
Since a Queue is just another Item, you can also configure it using JSON and without actually programming, define what and how it will process
Data using existing Items that lie in the Registry.
Although it seems a bit convoluted at first, it is in fact very straightforward, and the web UI helps you configure it without hassle. You now have a completely customizable system that you can tailor and augment to your needs.
Cross-Cutting Concerns
Aeonics also has some built-in cross-cutting concerns that apply anywhere in the system: logging, monitoring and security.
The Logger
All Items may emit logs by simply sending it to the Logger. These logs are actually Data when you think about it,
and the fact to emit a log entry is an event we can react to... that's right, it means that the logging mechanism is itself
handled by a Queue and you can augment, filter and define what happens with these logs, even sending it to a live WebSocket
for real-time troubleshooting. And since the system is dynamic, you can change it back to normal once you are done.
The Monitor
The monitoring is constantly collecting metrics about the execution time, the system resources, and you can also ask it to
keep a record of your own metrics. From within your Item, you can call the Monitor and push some metrics to it.
Pushing metrics is an event generating Data... does it ring the bell? Once again, metrics can be processed and managed just
like any other Data, and you can configure what to do with it.
The Security
Last but not least, the security layer is safeguarding what can happen. Remember that all processing starts with an Ingress Item?
This is where the Security kicks in, it checks, given the current context, if the Data is allowed to enter the system
considering authentication or lack thereof. The default Security mechanism exhibits a Role-Based and Policy-Based filtering engine.
However, the Security itself is an Item too, this means that you can also provide your own implementation. Since the Security is an
Item stored in the Registry, at any point in time, you can fetch it and query for specific privileges.
You now have all the keys for a complete 360 solution that will exactly match your requirements no matter the environment you revolve in.
Performance Considerations
Performance-wise, Items in the Registry are instances of Java classes and reside in the heap. When Data processing happens, it comes down to calling a sequence of methods from heap objects and passing it a single heap Data structure with low latency. The system is multithreaded which implies that multiple processing can happen in parallel for higher throughput.
Overall, Aeonics is a form of specialized SEDA architecture that is implemented as a single process to decrease the overhead of the system itself and dedicate the processing power to Data processing. Internally, the system has the ability to configure and resize its thread pools to match the underlying hardware and load of the machine.
The queuing mechanism may also buffer and defer task processing to avoid detrimental over-utilization effects. Incoming Data is therefore held in heap memory until processing is complete. This is usually a very short transient period of time, however in case of buffering, the heap memory is at risk of saturation. This is why, at the Ingress step, a verification is performed about the available remaining memory of the system and new Data is only accepted if we can afford to store it in memory. This mechanism has the advantage to create a mechanical backpressure mechanism at the Ingress level which is usually the network.
Using this combination of techniques, the system runs at optimal capacity and is highly resilient even in case of DDoS attacks.
Next steps
Additional documentation and next steps are :
- Github: Some code samples and other material are publicly published on Github.
- Javadoc: The official Aeonics SDK javadoc.
- Developer Guide: The main documentation about the context and the global system principles.
- Tutorials: Some tutorials and code samples to get started quickly.
- Modules: Aeonics is a modular system and each module provides its own functionalities. This documentation lists the specific configuration parameters and detailed behavior of all officially supported module.
- Aeonics Frontend Framework (AFF): Aeonics uses its own lightweight frontend single page application framework. You can reuse this framework to build your own applications.