Version 2
Created by emmartins on Apr 8, 2011 6:08 AM. Last modified by vilpan on Apr 8, 2011 1:15 PM.

    This article explains what are the options for datasource needs by JAIN SLEE Resource Adaptors and Applications, deployed in Mobicents JAIN SLEE. It should be worked out by the community and its content should be integrated in Mobicents JAIN SLEE User Guide, once it reaches a stable status.

     

    Introduction

     

    The vast majority of JAIN SLEE components needs data, and data is managed by datasources. Datasources can be very different in design, to fulfill different "client" requirements:

     

    • high performance
    • data persistence
    • high availability

     

    Typically all applications would want a high performance and available persistent datasource, but data persistence and high availability have a performance overhead, so different solutions are taylored for different needs. For instance, some applications may just need a fast temporary datasource (usually called cache), others may need a highly available persistent datasource. A key value when using Mobicents JAIN SLEE is that all kind of datasource solutions are available and are easy to integrate.

     

    Common Datasource Designs

    There are different needs for datasources, but a few designs are common, which in turn solve most common needs. 

     

    • Temporary Data Cache - A fast non-persistent datasource, which can replicate data across the Mobicents Cluster. Key feature is performance.

     

    • Internal Persistent Datasource - A persistent datasource that is local to each Mobicents JAIN SLEE node. Performance is average.

     

    • External Shared Persistent Datasource - Similar to the internal persistent datasource, but in this case the datasource is external to Mobicents JAIN SLEE, and thus shared by all Mobicents JAIN SLEE nodes. It may provide high availability.

     

    Datasource APIs 

    Datasources must be accessed through an API, and besides convenient high level or raw low level code type, these APIs may greatly affect performance.

     

    • SLEE Profiles - A datasource API defined by the JAIN SLEE specification, which then benefits from a tight integration with other JAIN SLEE components, such as SBBs and Resource Adaptors. Data is structured similarly to a SQL database, with tables and profiles (similar to SQL rows). Key features are the events when data is managed (add/update/remove), managent interfaces through JMX, routing of events depending on data present in the datasource (filtering) and the ability to attach Java code to each Profile.

     

    • Java Persistence API (JPA) - A very popular API nowadays, it "objectizes" a Java datasource, providing the most high level API, at least for usage, because proper data schema design is sometimes a bit difficult. It is a specification present in current JDK, thus available in every SLEE vendor that supports current JDK. Due to being so high level it may be difficult, if not impossible, to extract best performance possible.

     

    • JDBC - Also present in JDK is the "old" JDBC API, which provides a low level API to interact with a Java Datasource. Key feature is performance, if fine tuned it should provide best performance possible for a persistent datasource, mostly because there is no middleware involved, just the datasource "driver".

     

    • JCache JSR 107 - A relatively "easy to work" with datasource API designed for temporary data caches. It provides a data schema very similar to java.util.Map, which is a class commonly dominated by Java developers.

     

    • Replicated Data (Mobicents JAIN SLEE Fault Tolerant Resource Adaptor API) - Mobicents JAIN SLEE exposes a custom API for Resource Adaptors to store data in Mobicents Cluster. It provides a very simple (some may call it dumb) API, data schema is similar to java.util.Map too. Key features are high availability, the ability to attach fault tolerance recovery Java code, and the integration with the FT RA API, no additional setup is needed. 

     

    Datasource Implementations

    There are several options for concrete datasource implementations, some are already available in Mobicents JAIN SLEE Core, others may be integrated through Resource Adaptors. All are JTA aware, which is good for integration with JAIN SLEE, where all service logic is executed within a Java Transaction:

     

    • Hibernate - Hibernate was the foundation for JPA, it is a high quality and popular JPA implementation, with added value such as data caches of different levels, which should provide a better performance when working with commonly requested data. Unfortunately performance is still far away from what would be expected in a telco app server, with good concurrency support but high latency when interacting with data. Hibernate support is provided by JBoss AS, the underlying Java EE server which Mobicents JAIN SLEE uses in its core, and when combined with OSGi type framework as is JBoss Microcontainer, makes a great choice when performance is not critical.

     

    • SLEE Profiles - Mobicents JAIN SLEE 2.x uses Hibernate and JPA to implement the SLEE Profiles datasource. Performance is not great, but at least it's easy to work with, and it's as easy to config it with the internal persistent datasource present in JBoss AS (Hypersonic), as with an external shared persistent datasource. SLEE Profiles have another issue, the events warning data changes do not use a desirable fine grain activity, which is the profile table, and that means that it's dificult to design an app logic working with profile events that don't deliver events to sbb entities which are not actually interested in such information... Mobicents JAIN SLEE 3.x may introduce alternative implementations, such as JDBC, and maybe JCache, allowing SLEE Profiles to be used in all datasource common designs, but the team's opinion probably won't change - there are much better choices.

     

    • JDBC Resource Adaptor - A resource adaptor which should provide best performance possible for interaction with a JDBC datasource, in an asynchronous "fashion".

     

    • JCache Resource Adaptor - Does not exist, but the concept is similar to JDBC RA - provide the best adaptation of JCache implementations, such as JBoss Cache or Infinispan to SLEE development model, maximizing performance.

     

    • Replicated Data (Mobicents JAIN SLEE Fault Tolerant Resource Adaptor API) - Replicated Data is implemented on top of Mobicents Cluster framework, thus reusing all the cluster features and configuration of the Mobicents JAIN SLEE core. If a RA needs temporary data, is cluster aware, and doesn't mind to get a small vendor lock (easily replaced due to very dumb and simple API), then it would probably be the best choice. Replicated Data is the reason there is no JCache RA, it is so easy to work with and covers most needs, while keeping the same level of performance. 

     

    Selecting Datasources for JAIN SLEE Applications

     

    • Temporary Cache - Putting it simply, needing a temporary cache in a SBB usually means a bad application design. The JAIN SLEE application model is designed to promote that logic design is very tight to the concept of service instance, the SBB entity, and for that SLEE provides CMP Fields, which are managed by SLEE (no need to clear data on it). Note that SLEE also allows storing data in Activity Contexts, which may even be shared by different JAIN SLEE services, and means one could use Null Activities + AC Data Fields to design an akward temporary cache, not really best solution. In case it is not possible to avoid a SBB temporary cache, then the really best solution is probably to develop a Resource Adaptor, which uses ReplicatedData as datasource. The team may provide an example of such RA in the future (want to contribute?). Note, if there is no need for ACID or JTA integration, one could use a static ConcurrentHashMap in the SBB class, but beware these are "killer" features since events are delivered in the context of a transaction...

     

    • Persistent Datasource - Shared among SLEE nodes or not, there is not much to discuss, just use the JDBC RA, or even better, start with its sources and tune it for your data schema.

     

    Mobicents JAIN SLEE Core Datasources


    Not only JAIN SLEE Applications and RAs need datasources, Mobicents JAIN SLEE Core needs these too, and of different requirements, specifically the SLEE container needs datasources for managing:

     

    • Activity Context (AC) state, managed by the Activity Context Factory module
    • SBB Entity state, such as CMP Fields, managed by the SBB Entity Factory module
    • Relationships among ACs, SBB entities and SLEE facilities, for instance, Timers and AC Names, managed by the following modules: Timer Facility, Activity Context Naming Facility, Activity Handle Reference Factory
    • SLEE Profiles, managed by the Profile Entity Framework in Profile Management module
    • Usage Parameters,  used by the Usage Parameters Management module
    • Replicated Data, managed by the FT RA API Implementation module

     

    Except SLEE Profiles (covered in sections above) and Usage Parameters (ConcurrentHashMap), the whole state, including Replicated Data, uses the Mobicents Cluster framework temporary cache, which is implemented in lowest level by JBoss Cache 3 (Mobicents JAIN SLEE 2.x), and Infinispan (Mobicents JAIN SLEE 3.x). It should be possible, with Mobicents JAIN SLEE 3.x, to easily replace and use the different datasources used within Mobicents JAIN SLEE, since there are much different needs for its usage and deployments.

     

    Other Resources

    • N/A