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 that 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 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.

Applications come with significant built-in functionality that developers can leverage out of the box. The list below summarizes much of this base functionality:

  • Base directory in the KOS virtual filesystem: A base directory in the web server filesystem that can be used to mount web content.
  • Private storage area on disk: Access to the local disk in a private directory specific to the application.
  • Private database access: Support for creating databases that are automatically located in the application’s private storage area.
  • Access to related KABs: The ability to access any KABs in the manifest section from which the application was loaded.
  • Private key/value storage: Access to simple key-value storage, including automatic JSON conversion and encryption support.

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 this model introduces friction and complexity over time. Consider the following typical cases:

  • A new product is developed that 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 unnecessary.

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:

  1. 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, etc.
  2. Microservices: 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 refactoring into interfaces and base classes. This provides a 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 run on different nodes in the device while still collaborating. 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 that allows different organizations to share artifacts seamlessly. The consuming organization selects the KABs for inclusion from the market, and KOS Studio will automatically download them every time the developer hits the run button. KOS Studio provides support for selecting an exact or virtual version that floats against a specified version pattern.

Not only does KOS Studio eliminate the intake and build process, but 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.