Should you use JAIN SLEE (JSLEE) or a to store and persist data?
This is probably one of the most common design questions among JSLEE architects. The answer depends on many variables, including: the amount of data, the complexity of the data model, the data usage, the performance requirements, and the cost restrictions.
Below is a suggested process for deciding which persistence resource to use — assuming a scenario without data, or only data that the SLEE cannot access directly (in other words, assuming no existing persistence resources). This includes:
a review of the options available for storing and persisting data with a JAIN SLEE
JSLEE components may also use external data-persistent mechanisms. Apart from a relational database using the Java Database Connectivity (JDBC) API, services may use any kind of external persistence mechanisms through resource adaptors. Typically, they use directories to store subscribers' profiles, usually providing a Lightweight Directory Access Protocol (LDAP) interface; and specific repositories with a protocol for dedicated access, such as a Home Subscriber Server (HSS) using Diameter Sh.
Any decision to use profiles or a relational database should also consider the implementation of each.
Implementation of profiles
Although profiles share the same API and features among JSLEE-compliant containers, each container has its own implementation — each of which allows the use of profiles.
For Rhino and JSLEE applications, OpenCloud developed MemDB, an in-memory database to store the runtime state of Rhino and component data — including profiles. MemDB and has a tight relationship with Rhino's clustering technology, to replicate data and perform distributed actions such as locking.
MemDB provides different forms of durability (memory-only, memory-only with synchronous replication, memory with synchronous replication and asynchronous replication to disk) and locking strategies (pessimistic and optimistic). For profiles, administrators can use the following persistent resources:
ProfilesDatabase — to replicate data among the nodes of a cluster, and store snapshots of the data in a traditional database
ReplicatedMemoryDatabase — to replicate data among the nodes of a cluster.
Implementation of relational database access
Access to a relational database is outside the scope of the JSLEE specification — any features a container provides for accessing a relational database are specific to that container. The specification does require, however, that the Java Database Connectivity (JDBC) API is available to SLEE components.
Rhino extends JDBC support by facilitating the use of the API and providing a configurable environment. Rhino may automatically manage JDBC data sources, connection pooling, and transactions. This means application developers can stay focused on the application logic and let the container (Rhino) manage the underlying connection to the database.
The recommended way for SBBs to access a relational database is to directly use a JDBC data source provided by Rhino.
Because this is a synchronous interface, SBB threads will block while waiting for the responses from the database. If the application performs slow queries or the database takes too long to respond to queries, use a resource adaptor to perform SQL queries and return the result asynchronously to the SBBs.
Below is a decision tree that illustrates the most important considerations when choosing a persistence resource.
The decision tree does not include all the possible considerations.
When to use profiles or relational databases In short, the decision tree suggests that with Rhino applications should use profiles if the data:
is relatively simple (not a complex data model, with many relationships); and
is not huge (not many gigabytes, as supported by the hardware and the JVM support); and
will be mainly read from the application (with optional writes from a management interface).
Otherwise, consider a relational database. The relational model (unlike using profiles) assures that the data maintains the referential consistency and integrity.
(For applications with very low latency requirements, database caching or a dedicated in-memory database should also be considered, to replace or complement the deployment of the traditional database.)
The deployment architecture of any persistence resource should take into account the performance, reliability, and availability of the data.
Two other notes about deployment architecture to bear in mind:
The amount of data in memory must be supported by the software (MemDB or other technologies).
In-memory databases should have a durable mechanism or master synchronization point.
With MemDB, profiles should be used to store the data or the subset of data required by the applications. In other words, profiles should not replace a dedicated provisioning system to store the subscribers' data (which contains data not directly related with the SLEE applications). If necessary, such data may be synchronized with profiles. (See section 10.2 of the JSLEE 1.1 specification for more information.) Furthermore, if the data must be durable, the administrator should use the persistent resource with asynchronous replication to a traditional database (the default for profiles).
With other in-memory database technologies, the vendor should already have methodologies in place to persist the data in a durable form. The most common deployment strategy is to deploy an instance of an in-memory database in each machine that has a working Rhino node. Each instance is then synchronized with a master traditional database, or synchronized between each of its instances, and persisted to disk.
Other usages for profiles
One common — and recommended — approach is to use profiles to store runtime configuration. When runtime configuration data has a high performance requirement, and profiles are stored in MemDB, access to data is not affected by the failure of an external DB; and data may be changed by custom management clients or the management interfaces included with Rhino (the command-line console and web console).