Kaa releases
Skip to end of metadata
Go to start of metadata

The Kaa Events subsystem is designed to facilitate near real time events origination from endpoints, handling those events in a Kaa server, and relaying them to other endpoints that belong to the same user (potentially across different applications).

The Kaa event structure is determined by the schema that is configurable. The framework automatically performs:

  • generation of the event object model and related API calls in the endpoint SDK;
  • enforcement of data integrity and validity;
  • efficient targeting of event recipients;
  • efficient and compact serialization.

It is the responsibility of the framework user to design the event schema and make the client application interpret event data supplied by the endpoint library. The Kaa administrator, in turn, can provision the schema into the Kaa server and generate the endpoint SDK.

Event classes

Events are characterized by an Event Class (EC) that is defined by a data schema. An EC is uniquely identified by a fully qualified name (FQN) and a tenant. In other words, there cannot be two EC with the same FQN within a single tenant.

The Event data schema format is based on the Avro schema with an additional attribute classType that supports two values: event and object. Kaa uses the classType attribute to distinguish actual events from objects that are reusable parts of Events. This is useful for avoiding redundant methods in SDK API.

See below examples that illustrate basic event class schemas.

  • The simplest definition of an event with com.company.project.SimpleEvent FQN and no data fields:

  • Definition of event with com.company.project.SimpleEvent2 FQN and two data fields (field1 and field2):

  • Definition of event with com.company.project.ComplexEvent FQN with complex fields com.company.project.SimpleRecordObject and com.company.project.SimpleEnumObject

Event class families

ECs are grouped into event class families (ECF) by subject areas. ECFs are registered within the Kaa tenant together with an associated data schema.

An ECF is uniquely identified by a name and/or class name and tenant. In other words, there cannot be two ECFs with the same name or same class name within a single tenant. Although this is quite a strict requirement, it helps preventing naming collisions during the SDK generation.

In order to simplify the process of EC and ECF setup, Kaa Web UI automatically creates ECF and corresponding EC entities based on the ECF name, class name and schema.

See below examples that illustrate basic event class schemas.

  • Schema that contains two events with FQNs com.company.project.family1.SimpleEvent1 and com.company.project.family1.SimpleEvent2

  • Schema that contains two events with FQNs com.company.project.family2.ComplexEvent1 and com.company.project.family2.ComplexEvent2 that reuse the same complex field type com.company.project.family2.SimpleObject

Once the event schema is loaded into the Kaa application, the Control server automatically assigns the version number. User is able to define new versions of ECF schema. Each version of ECF schema may contain different event classes.

Application mapping

One Application can use multiple ECFs, and the same ECF can be used in multiple applications. In other words, a user can define ECFs that would be used by multiple applications. This is useful for controlling sources and sinks of particular events. For example, a user may want to implement the following rules:

  • Application A is able to send events with class E1 but is not interested in receiving them. Thus, application A is a source of E1.
  • Application B is interested in receiving events of class E1 but would not send them. Thus, application B is a sink of E1.
  • Application C is able to both receive and send events of class E1. Thus, application C is both a source and a sink of E1.

Once the application and ECF are created, the tenant administrator can create a mapping between these two entities by assigning a certain version of the ECF to the application. Multiple ECF versions can be mapped to a single application.

By default, each event of an ECF is mapped as both source and sink, however, administrator can overwrite this mapping. Once defined, a mapping cannot be changed in the future.

Event routing

Events can be sent to a single endpoint (unicast) or to all endpoints of the given user (multicast).

In case of a multicast event, the Kaa server relays the event to all endpoints registered as EC sinks during the ECF mapping. Events are routed across the Operation servers in case the user's endpoints are distributed across the servers. Until they expire, events remain deliverable to the endpoints that were offline at the moment of the event generation.

The Kaa server delivers a unicast event to the target endpoint only if the endpoint is registered as an EC sink during the ECF mapping. The EP SDK supplies API to query the list of endpoints currently registered as EC sinks within the scope of the user.

Event sequence number

Sequence numbers are used to avoid duplication of events sent by endpoints. Each endpoint has its own sequence number, which is incremented by one with every event sent by this endpoint.

With the first sync request, the endpoint attempts to synchronize its event sequence number with the one stored on the Operation server. The server answers with either the sequence number of the latest event received from the endpoint or the number zero (if no events were received so far). If the number provided by the server differs from the number stored on the endpoint, the endpoint accepts the former and uses it as a starting number for new events.

SDK generation

During the SDK generation the Control server generates the event object model and extends APIs to support methods for sending events and registering event listeners. An application SDK can support multiple ECFs, However, it cannot simultaneously support multiple versions of the same ECF.

Copyright © 2014, CyberVision, Inc.

  • No labels