Introduction

ScaleOut Active Caching™ is a set of extensions to ScaleOut StateServer® that enable developers to embed application code in the distributed cache. Since this code runs in parallel on all caching servers, it scales application performance while reducing network delays and overhead.

ScaleOut Active Caching offers important benefits to both on-premises and cloud-hosted applications in a wide range of applications, including e-commerce, financial services, transportation, gaming, and many more. These benefits include:

  • faster, more scalable application execution

  • object-oriented access to cached objects

  • ability to deploy application-specific code to manage objects

  • dynamic deployment of application code to the distributed cache

  • ability to aggregate cached data to create charts and queries of cached data

Modules

Users can embed application code in modules written in either C# or Java. These modules access individual objects within a single namespace of the distributed cache. They treat these objects as strongly typed instances of the module’s class to aid in application design. They also handle deserialization and serialization of cached objects for use by application code defined in the module. ScaleOut Active Caching provides language-specific templates that simplify the creation of modules.

There are two types of modules: message modules and API modules. Modules run user-defined code written in either C# or Java. They access specific objects within a namespace in the distributed cache. All objects in the namespace are assumed to be of the same type, and a unique module is used for each namespace. Application code within a module is responsible for object serialization.

Message modules process incoming messages directed to specific objects within a namespace. They are typically used to process event messages arriving from messaging hubs like Kafka or Azure IoT Hub. When running in the cloud, they avoid the need to use serverless functions to handle events, and they run very fast because they access in-memory data in the distributed cache.

The following diagram shows a message hub sending messages to a message module in the distributed cache:

../_images/message_module.png

API modules implement strongly typed, user-defined data structures with cached objects. They define APIs that are called by client applications using client-side libraries defined for each module. They are typically used to implement application-specific data structures. Because API modules are implemented in C# or Java, they can take advantage of the object-oriented features of these languages. They also are deployed dynamically using the ScaleOut Active Caching Management UI, so they do not need to be linked into the caching server and they cannot cause the server to crash. API modules add flexibility for applications that goes well beyond the capabilities of simple data structure stores.

The following diagram shows a client application accessing the distributed cache using APIs defined by an API module running in the cache. The module receives API requests for a specific object, processes the request, and sends return values back to the client. The API module accesses object data and optionally updates the object when processing the request:

../_images/api_module.png

Connections

ScaleOut Active Caching provides connections to external messaging hubs for receiving messages. These messages are directed to message modules for the corresponding namespaces. Incoming messages specify both the namespace and an object within the namespace. Message serialization is determined by the application; messages are treated as byte arrays by the module infrastructure.

Connections are currently available for on-premises Kafka, Azure Kafka, Azure IoT Hub, and REST. The ScaleOut Active Caching UI lets users configure connections by providing connection-specific parameters when a connection is deployed. A built-in REST service deployed on the management console in this release handles incoming messages using an API key obtained from the UI for authentication.

To maximize throughput, connections other than REST run simultaneously on all ScaleOut StateServer hosts. They make multiple connections to the external messaging hub and partition the workload.

Persistence Providers

Both message modules and API modules can optionally be configured to connect to external persistence providers. These persistence providers can provide automatic long-term storage for objects accessed by modules. Currently supported persistence providers include SQLite, SQL Server, Azure Cosmos DB, and AWS Dynamo DB. The UI lets users create and configure connections to these persistence providers. Modules can then select a configured persistence provider when they are deployed.

Persistence providers can run in one of three modes:

  • read through: attempt to supply object data from the backing store when an object is accessed but does not exist in the distributed cache

  • write behind: periodically write object updates to the backing store at a five-second interval

  • both read through and write behind: perform both actions for accessed objects

Charts and Queries

The ScaleOut Active Caching Management UI provides comprehensive facilities for visualizing cached data that is serialized using JSON. These facilities let users combine object data within a namespace to explore trends or query objects for selected properties.

Charts aggregate a specified property and displays it in groups specified by another property using various chart types (bar, column, area, line). The chart updates every several seconds. For example, a chart could chart the maximum RPM of all wind turbines by region of the country. Multiple charts can be arranged in the UI for simultaneous display.

Queries display multiple properties for all selected objects within a namespace. Objects are selected by combining “where” clauses in the same manner as a database query. Query results can be displayed in tabular form or on a geospatial map in the UI. Mapping results requires JSON properties latitude and longitude to be defined for all objects. Selected properties are displayed when hovering over icons on the map. Query results automatically update every several seconds. Multiple queries can simultaneously be displayed on the map.

Details on Module Behavior

Both message and API modules are deployed on all hosts (servers) within the distributed cache, and multiple instances of the modules can simultaneously process requests to different objects. ScaleOut StateServer distributes requests to module instances based on the location of the primary object. This avoids network overhead in accessing objects. To minimize overhead and network usage, module requests can optionally update accessed objects when requests are completed.

Modules run as processes on each host and communicate with the local ScaleOut StateServer service using TCP connections. From the point of view of the service, they run as local clients. It is assumed that other application client processes might be accessing objects that are managed by modules. For this reason, modules can optionally lock objects when processing requests to avoid collisions with other clients.

Installation Options

The ScaleOut Active Caching Management UI is installed on a management system which connects to a ScaleOut StateServer cluster. The UI is accessed from a web browser that can run either on the management system or another networked system. The installer deploys three services (daemons) on the management system:

  • the ScaleOut Active Caching web service that hosts the UI

  • an authentication service for tracking user accounts

  • a REST service for receiving incoming messages for message modules

Note

For production use, it is intended that the system administrator install and configure a certificate for these services. This will avoid browser warnings that occur when using the built-in, self-signed certificate supplied by ScaleOut Software.

The following diagram shows the management UI running on a workstation that is connected to a ScaleOut StateServer cluster over the LAN. Note that the management UI lets the user specify the IP address and port of one of the ScaleOut StateServer hosts to establish the connection:

../_images/prod_install.png

To evaluate the feature set or aid in application development, users can install both the ScaleOut Active Caching Management UI and ScaleOut StateServer on a single workstation and run the UI on this workstation. This configuration is described in the Quickstart Guide and shown here:

../_images/quick_install.png

Development Process

Once the ScaleOut Active Caching Management UI has been installed and connected to a joined ScaleOut StateServer store (i.e., a running distributed cache), it can deploy modules to the cache, as illustrated in the following diagram for a message module:

../_images/msg_deploy.png

This diagram illustrates the deployment of an API module:

../_images/api_deploy.png

First, the user creates and builds a module using the provided templates. The result of building a module is a zip file which is ready for deployment. The next step is to deploy the zip file using the management UI. If this is a message module, the management UI can connect the distributed cache to a messaging hub. It also can connect to an optional persistence provider. Now the module can process requests (incoming messages or API invocations).

Modules can be restarted or deleted at any time using the management UI. They also can send messages to the management UI when significant events occur.