UMCache Key Concepts

The core of UMCache is the ability to customize the modules you need to archive and replay various message streams. Customization, however, does not complicate your development because you use the same API for every UMCache module you create. Your development team will become fast friends with UMCache's precise Module API.

UMCache can also adapt to your development team's style. Whether your team prefers to develop a small number of highly intelligent modules or many modules with distinct functions for more transparent analysis, UMCache can accommodate both styles and anything in between. For example, the same module can be initialized as a processing module for one purpose and as a CnC module in another instance.

More on UMCache Modules

  • Reception modules act like LBM receivers, but can be customized to receive data not only from usual message sources but also databases, files or any other conceivable source.
  • Processing modules do the actual processing work on messages and take actions based on that processing. They can be arrayed in a pipeline and be constructed to perform very specific actions. They can also change the content of messages.
  • Indexing modules can index messages in different ways from the normal UMCache methods. Indexing occurs after all processing completes, but can be done in parallel with message storage. Multiple Indexing modules may be executed in any order, and even concurrently.
  • Command and Control (CnC) modules handle requests (replay, UMCache management, information retrieval, etc.) that come from either the UMCache Web Monitor or through a unicast message from the Request Library. Normally, CnC modules do not interact directly with Reception, Processing, or Indexing modules.
  • Storage modules allow you to store messages in whatever form is beneficial (flat files, embedded databases, SQL databases, etc.) You also use their module database functions to store, access and manage the stored messages.

Configuring Your Cache

The UMCache XML configuration file is UMCache's organizing agent. It not only specifies operating parameters for UMCache itself, but also defines individual archives and what topics each archive stores, along with the modules that do the work. It also identifies the request handler modules. Archives, Topics, and Request Handlers are configuration entities that hold configuration data, but in a larger sense, also delineate all your intended caching operations.

Archives

One of the primary elements in a UMCache configuration file, Archives can be thought of as message paths that use primarily reception and storage modules to cache specified topic messages or patterns of topics. (Processing and Indexing modules are optional.)

  • You can configure as many archives as needed.
  • The ultimate size of a particular archive is only limited by processing load or storage load.
  • The decisions of what archives to create could be a reflection of your LBM topic space design. Many topics may lead to many archives, but not necessarily.
  • The types of data you want to cache could also influence archive creation. Some data may need to be cached to disk, some only to memory, which would dictate an archive for each.

Request Handlers

A Request Handler is a set of CnC modules that listen on a TCP port for incoming requests. A single UMCache process may have several Request Handlers. Applications that wish to send requests to a Request Handler within a UMCache process use the 29West UMCache Request Library. The Library uses LBM Request/Response as the method of sending requests and receiving direct replays or responses.

Web Monitor

Like other 29West products, you can run UMCache with a Web Monitor that provides current information on your caching operations. You can also send a request to UMCache from the Web Monitor.