Package com.tccc.kos.commons.core.context
Devices have several use cases that stand out from typical web applications that make typical context based systems hard to use:
Hardware systems typically have a need for strictly ordered boot sequences. During these phases it may be
the case that not all beans in the context are ready to be wired and some beans may not be available yet,
causing typical contexts to fail to initialize. The BeanContext in kOS supports phased startup
during which the context will ignore certain beans and errors as well as generate lifecycle events to
provide fine grained control over the initialization process without dependency graphs in the data
impacting startup order.
It is common for beans, once autowired, to still require code execution before they are ready for use. Typical contexts do not have infrastructure to support additional asynchronous initialization post-context setup. The context in kOS provides a mechanism by which post context initialization is tracked as a separate dependency graph which effectively eliminates startup race conditions and / or manual coordination of beans startup sequences. For example, consider a bean that can only be used after it reads data from a second bean, but the second bean is not usable until is first performs an optional database migration, which also depends on a third bean that is only ready once some underlying hardware is initialized. This requires an implicit understanding of the dependencies and coordination to avoid issues. A kOS context will manage this post autowiring sequencing by analyzing bean dependencies.
Embedded systems don't tend to follow the common web pattern of transforming stored state from a database.
Most of the internal state of an embedded system tends to be related to the hardware or the control systems
managing the hardware. This leads to complex graphs of objects that exist for the duration of the application.
There are many instances where child beans in these graphs should be part of the context, such as a pump that
is part of a board that was dynamically created by probing the hardware. BeanContext allows dynamically
created POJO's to be added to the context at any time which means that a kOS context is not purely a tool to
startup a system, but can also be leveraged during runtime.
Given that embedded systems contain large graphs of POJO's, it creates two distinct pools of objects: context managed and POJO's. Context manged beans can use features like @Autowired while POJO's need to resort to service lookup patterns to get access to managed beans. The kOS context supports a concept of connecting beans to a context. This allows any POJO outside of the context to leverage autowiring features without making the beans fully managed. This makes it trivial to create a bean deep in a graph of POJO's yet autowired access to system components without needing to pass references down the graph or perform a system lookup.
Unlike a web application where services tend to be silos, embedded systems tend to operate extensively on cross-cutting events to coordinate complex control systems. Decoupling in this environment is typically implemented through listener interfaces. While most context systems allow for a one time autowire of interfaces from the context, kOS supports transparent listener list integration and will automatically add and remove listeners as beans are added and removed from the system which drastically reduces the need for boilerplate setup code as well eliminates cleanup code.
In short, BeanContext is highly optimized for the typical workloads that are common within kOS and
a solid understanding of the capabilities of this infrastructure can result in drastically simplified code.
- Since:
- 1.0
- Version:
- 2022-10-21
-
ClassDescriptionSystem component that provides a very lightweight IOC-style context.Base class for all context exceptions.Interface that allows a bean to accept callbacks from BeanContext when a child context is destroyed.Interface that allows a bean to accept callbacks from BeanContext when the context is destroyed.Interface that allows a bean to accept callbacks from the kOS BeanContext after certain autowiring steps have completed.Base interface for all context listeners.