Contents
The following table provides a list of best practices for writing EventFlow applications.
| Best Practice | ||
|---|---|---|
| ✔ | Summary | Description |
| Plan for modularization | ||
| Think about the functional areas of the application and how are they related before writing any EventFlow. |
Modularizing helps to ensure that troubleshooting and performance tuning can be done efficiently and easily. Keep adapters and connection logic in modules that are separate from the modules that define business logic. This makes it easier to test the application for correctness. Define modules based on clear functional boundaries. Use separate modules for functional areas of your application that have any of the following characteristics:
|
|
| Establish naming conventions | ||
| Follow a logical naming convention for application components such as modules, dynamic variables, and schemas. | For example, in a trading system you might define various algorithms in modules with names such as BollingerBand_Algo.sbapp, VWAP_Algo.sbapp, and so on.
|
|
| Use named schemas | ||
| Specify named schemas and import them from a common interface or module. |
Specify output schemas as well as input schemas. Pay attention to schema sizes. Schema sizes can affect application performance. Identify where certain data needs to be used in your application. There are many ways to define your schemas, and how you do so can make a difference in how well your application performs and how easily it can be debugged. |
|
| Use table schemas | ||
| Use table schemas when specifying Query Tables. | Using table schemas, you can quickly assign the same structure to Query Tables in several modules across a large application. | |
| Use module imports | ||
| Reuse definitions of constants, named schemas, table schemas, and other importable items. | Importing items from one module to another simplifies application design and improves productivity when creating application modules. | |
| Use interfaces | ||
| Define interfaces for frequently used design patterns. | Using StreamBase interfaces, you can create varying implementations of the same set of streams, tables, and schemas. | |
| Use a central imported interface | ||
| Define importable items in a single, central interface. | Define constants and schemas in a single, central interface whose only purpose is to maintain those definitions for other modules to use. You can use a central imported module for the same purpose; in this case,the definitions module should have a blank canvas with no tuple processing at all. | |
| Use incremental development | ||
| Incrementally introduce logic into the application. |
Do not put a huge system in place in one fell swoop. Assess the impact of additional business logic at each stage of development with unit tests. Analysis of performance metrics should provide you with the ability to identify hot spots in your application while you are still in the development phase, making it easier to make improvements. Once hot spots are identified, you can distribute the processing of hot spot operators into separate threads. |
|
| Use module parameters | ||
| Use module parameters to enhance reuse and flexibility. |
Using module parameters and constants helps to make your application more flexible as a reusable module. For example, you can use module parameters to vary the threshold for an alert based on trade volume. Design modules so that their parameters can be specified by a human or by another subsystem, depending on the requirements at your particular site. For complex applications with several layers of module references, use chaining to pass the same value to inner modules. |
|
| Avoid using wall-clock time | ||
| Avoid using wall-clock time in business logic. |
Using wall-clock time can have an unpredictable impact on latency and application correctness from machine to machine. StreamBase Server is fast because it processes incoming tuples as they arrive, not based on an internal or wall-clock timer. If you need to ensure that your processing always occurs by a certain time, use the Metronome or Heartbeat operators to send tuples through. |
|
| Complete business logic, then optimize for performance | ||
| Complete the core functionality of each section of an application before tuning for performance. | Do not optimize applications before the critical business logic has been completed. Premature optimization will make the development of the core functionality of an application unnecessarily complicated. | |