Select a Persistence Store - learn-tibco-cep/tutorials GitHub Wiki

The BusinessEvents platform supports the following 3 types of data persistence solutions.

  • Clustered BE inference engines using Apache Ignite cache with a supported persistent store
  • Unclustered BE inference engines using ActiveSpaces 4.x as a managed data store
  • In-memory BE inference engines using a standalone data store

There are a few other supported options, e.g., cluster of legacy AS 2.x, cluster of FTL, and Cassandra as managed data store. These options are either out-dated, or hard to manage, or lack of performance, and thus they are not included in my list of recommendations.

Based on typical use-cases of BE applications, I consider the ActiveSpaces data-grid and a RDBMS the 2 most suitable data stores, and thus I further narrow down my list of recommendations to the following deployment configurations.

  1. Cluster of Apache Ignite with persistent store of PostgreSQL or similar RDBMS
  2. Unclustered BE engines with managed store of ActiveSpaces 4.x data-grid
  3. In-memory BE engines interacting with standalone ActiveSpaces 4.x data-grid or PostgreSQL/RDBMS database

This tutorial contains examples for the first 2 options and you can follow the above links for more details about their configuration. The third option may be covered by a future tutorial.

The following sections will summarize the benefits of each of the options and describe which option may be the most suitable for your application.

Apache Ignite Cluster

In this configuration, BE inference and and cache nodes form an Apache Ignite cluster. Inference engines are Ignite client nodes, and cache engines are Ignite server nodes. The cluster can be configured to use various types of persistence data stores. I would pick a PostgreSQL or similar RDBMS for persistence in this configuration.

This configuration has a few benefits:

  • Easy to manage
    • Database schema can be easily generated from the CDD and EAR files of the BE application
    • Cluster nodes can be started as native BE engines
  • Supports all BE application features, including
    • Cluster-wide object locks
    • Cluster-wide event scheduler
    • Query agent and features, such as continuous query
  • Ease of development and migration
    • All APIs map directly to that of previous BE versions that use a legacy AS 2.x cache

This option would be the most suitable configuration if your application requires the performance of a cache by an in-memory data-grid, and the deployment environment has enough memory resources for the data-grid, or if you want to migrate an existing BE application that uses the legacy AS 2.x cache.

ActiveSpaces Managed Store

This configuration is introduced by the recent version 6.x of BusinessEvents. In this configuration, you need to start only a set of inference engines. Data persistence are automatically managed by the PostRTC process.

It has a few benefits:

  • Easy to manage and scale up or down
    • Database schema can be easily generated from the CDD and EAR files of the BE application
    • Inference engines are the only runtime processes that can be started/shutdown independently
  • Ease of development
    • Core BE application features are supported and compatible with previous BE versions
    • CEP Store catalog functions can be used to implement CRUD operations for persistent data

However, since it does not manage a runtime cluster, this configuration will not support the following BE features:

  • Global object locks across multiple inference engines
  • Global event scheduler for multiple inference engines

These features may be supported by a future release, but at present, you will have to implement your own solution if your application requires such capabilities. In practice, you may manage global locks and schedule events in the managed ActiveSpaces store, and thus it should not be too difficult to create your own solution for these capabilities.

Therefore, if your application does not require the extra effort to maintain an Apache Ignite cache cluster and a third-party database, this option using a managed ActiveSpaces data-grid would be a perfectly suitable solution that actually provides the maximal flexibility to scale the production environment on premise or in cloud.

Standalone Data Store

In this configuration, BE inference engines will run as in-memory processes, and they interact with a standalone data-grid or database in exactly the same way as what a common multi-tiered application does. In this configuration, I would pick either ActiveSpaces 4.x data-grid or a PostgreSQL/RDBMS as the data store because the BE platform provides catalog functions for accessing data in these data stores.

The key benefits of this configuration are

  • Simplest deployment architecture
    • Inference engines are completely de-coupled from data persistence, and thus can be scaled independently;
    • Data in the standalone data-grid or database can be shared with other third-party applications.
  • Ease of development
    • Core BE features are all available in this configuration
    • For ActiveSpaces, the CEP Store catalog functions can be used to implement data CRUD operations
    • For PostgreSQL or other RDBMS with JDBC support, the RDBMS catalog functions can be used to implement data CRUD operations
    • BE concept definitions do not have to match database schema exactly, because the catalog functions support free-form SQL statements
    • You also have the option to generate BE concepts that match database tables/views by using DBConcepts as described in the Data Modeling Developer's Guide.

However, similar to the other unclustered options, you also need to implement your own solution for global locks and schedulers if your application requires so.

Therefore, this option should be your best choice if you are migrating a BE application that does not use the legacy AS 2.x cache, or if your new application requires data sharing across multiple third-party applications.