Documente Academic
Documente Profesional
Documente Cultură
, and
TIBCO BusinessEvents
. The examples
presented here include specifc
industry scenarios, but use cases can
apply to many industries.
S O L U T I O N B R I E F
5
Caching + Dynamic Load
A variation on the caching example is to have the data dynamically loaded into
ActiveSpaces when the data is frst accessed by a client application. A service is provided
that frst looks in ActiveSpaces for the data. If found, the data is directly returned. If the
service does not fnd the data in ActiveSpaces, it queries a backend data store. If the data
is found in the backend data store, it is returned to the client application and stored into
ActiveSpaces. If desired, time to live (TTL) can be confgured for the data in ActiveSpaces
so that it is automatically purged. One beneft of this approach is that the service can
present a standard interface and the client applications are not required to implement
any ActiveSpaces code.
Service
ActiveSpaces
Client Client Client Client
Data
S O L U T I O N B R I E F
6
Accelerating Services
Broad Performance Improvements
There are many ways that ActiveSpaces can be used to speed services. It can
cache information from back-end applications or cache common lookup, index, or
transformation information. Any service that retrieves data from an external data
store, application, or fle system has the potential for performance improvement using
ActiveSpaces.
Ultra-Fast Data Store
ActiveSpaces can also be used as a very fast data store. In this case, it allows updates to
the data and persists the new data values. It provides two options for persisting data:
shared all (database) and shared nothing (distributed fle system). The shared nothing
approach is illustrated below. With shared nothing, each ActiveSpaces node maintains
a fle with only the subset of data that is managed by the node. The system volume and
speed is scaled by adding more nodes on different servers.
ActiveSpaces
Client Client Client Client
File File File
Non-Stop Data Store
While possible, it can be expensive to achieve 24x7x365 availibility with database
technologies because they are frequently deployed on separate, potentially expensive
hardware platforms. This hardware can add more failure points and reduce calculated
reliability numbers. Further, databases often require planned outages for routine
maintenance.
With ActiveSpaces it is often possible to remove the database and the associated failure
points from these implementations. ActiveSpaces persistence is distributed across
multiple commodity servers, providing a high availability system at a fraction of the cost
of other approaches.
Distributed,
NotCentralized
Databases are central to many
enterprise applications, but also
struggle to handle high volumes,
rapidly changing values, and large
numbers of concurrent client
applications. ActiveSpaces can be
used to improve their performance;
However, it is rarely a drop-in, no-
code replacement because the
application/database interchange
can be complicated, involving SQL,
business logic, and data spread across
architectural tiers.
Because ActiveSpaces uses a
distributed architecture to achieve
its performance and fault tolerance,
some database features are not
directly supported. For example, the
ActiveSpaces JDBC driver does not
support all SQL language syntax
but there are ways to provide the
samefunctionality.
S O L U T I O N B R I E F
7
Fast Data Store with Separate Master Update
A more full-featured use case involves using ActiveSpaces to manage high volumes of
data reads and updates, and to also send and receive data updates from a separate
master system of record. This is especially useful when spikes of data access and data
updates overload the back offce system of record. An ActiveSpaces event listener gets
notifed whenever a data value is changed and sends updates through a message queue
(for example, TIBCO Enterprise Message Service