Applications
KOS is an application-based platform and all developer functionality is delivered in the form of applications. Unlike mobile devices, KOS has a collaborative application model which allows applications to communicate directly and even share classes. KOS relies heavily on the application model, which developers can use for anything from dynamically loadable plugins to integrating third party functionality into their devices. The following sections cover many of the key capabilities of applications within KOS.
Basic Capabilities
The minimum requirement for an application within KOS is as follows:
-
A KAB of type kos.app with a properly formed kos.app section in the descriptor.json of the KAB.
-
The class referenced by descriptor.json must extend the Application base class.
-
The KAB must be in a manifest section with no other application KABs.
Once these requirements are met, the application can be loaded using AppService or even be automatically loaded by naming the manifest section with the kos.autostart.* pattern.
The loading process follows a specific lifecycle that transitions the application from loading to started state.
Once started, the application is fully accessible by other applications or endpoints and it is free to perform any function it is designed to perform.
Every application has the following inherent capabilities:
-
A custom BeanContext allows autowire access to beans within the application or even child applications.
-
Access to any beans in the BeanContext of the system application.
-
Automatic autowiring of any listener interfaces into parent contexts, allowing code free listener attachment with automatic cleanup on unload.
-
A base directory in the KOS virtual filesystem, which is used to serve content from the internal web server. This is rooted at a base directory based on the id of the application.
-
A private storage area allowing the application to store files.
-
A private database storage area allowing the application to create private databases with standard KOS migration infrastructure.
-
Access to the section the application was loaded from, including the ability to search the section for associated KABs.
-
A fuse mount of the application into the native Linux filesystem. This makes all files in the application KAB accessible to native code without exploding the contents of the application onto real storage.
-
A private key/value storage bucket for storing blob data, including support for automatic json conversion as well as encryption.
-
Auto mounting of all endpoints in the application to a namespaced url based on the application id.
-
Automatic configuration of the application and any associated application components as part of the lifecycle process.
In many cases, these basic features can eliminate substantial boilerplate code, making applications very quick and easy to write. Many of these base features have rich capabilities that are not covered here.
Application Collaboration
Embedded device development is commonly a monolithic process, with all code compiled into one large code base. This is typically easy when a project starts, but over time, this model starts to introduce friction and complexity. Consider the following common cases:
-
A new product is developed which shares many of the same features requiring the monolithic code base to be refactored and split.
-
Some functionality is provided by a partner, and it is only available in binary form, requiring an intake process to be created along with the friction of testing and iterating with the partner.
-
Over time, parts of the code base are abandoned yet are hard to remove from the code base.
-
Customers want customized deployments, including some features but excluding others based on deployment rules for a particular device, requiring every feature to be pushed to every device even though it is not needed.
By making strategic choices about where to split code into applications, products become faster to build and allow easier code reuse, but only if the application model makes it easy to collaborate.
KOS provides two ways for applications to collaborate:
-
SDK : One application exposes the java SDK and the other compiles using the SDK. At run time, KOS links the applications together so that they can share classes directly. This allows applications to share data, call shared methods, and so on.
-
Micro services : One application exposes functionality via endpoints and the other uses the KOS ApiClient to access them, bypassing all networking when both applications are running on the same node, but providing network transparency when running on different nodes. This allows class definitions to be decoupled as with standard micro-services patterns.
The SDK approach is facilitated by the KOS SDK annotations and maven plugin, which will generate an SDK from existing code without the need for refactoring into interfaces and base classes. This provides a very seamless integration between applications with the restriction that they run on the same node within the device. When using micro-services, there is no need to generate and share an SDK. In addition, the integration becomes network transparent and the applications can be running on different nodes in the device and still collaborate. KOS uses this extensively for distributed functionality when running KOS on multi-node devices.
Third Party Applications
The application model used by KOS is particularly powerful when working with applications provided by third parties. KOS Studio provides a market which allows different organizations to share artifacts seamlessly.
The consuming organization simply selects the KABs for inclusion from the market and KOS Studio will automatically download them for inclusion every time the developer hits the run button. KOS Studio provides support for selecting an exact version or a virtual version which floats against a specified version pattern.
Not only does KOS Studio eliminate the intake and build process, since all KABs in the market are production signed, every KAB is ready for testing even in a production environment. Organizations can even create preview artifacts that can be used for testing, but KOS Studio will prevent them from being used in an actual production release, eliminating the possibility of accidentally shipping non-release KABs.
