JAIN SLEE profiles (December 24, 2007)

I promised to write a separate post about JAIN SLEE profiles recently. Basically, a profile specification is a separate deployable entity in SLEE, dedicated to deal with the wrinkles of the data provisioning, administration and retrieval. Data itself is represented with profile tables and profiles — one can think about these as about database tables and rows in them. In JEE world nowadays, really few applications deal with the persistence directly (be this database-based or any other); most of the solutions rely on O/R-mapping frameworks, like Hibernate, or universal persistence layers, like JDO. SLEE goes even further in this direction.

When profile is deployed, SLEE generates the actual implementation of the CMP data access methods (actually, not only these, but we’ll leave these details out). This operation is similar to load/compile-time instrumentation in most Java persistence frameworks, however is not completely the same. This is the point where SLEE application server benefits from the fact that it does not have to be as generic as JEE application server: generated implementations tightly bound to the internals of the SLEE; generic approach of the JEE is sacrified to the performance and throughput. At the moment of execution, SLEE does not actually query the profile tables in the sense as JDBC-based software does this. The data is already there, in the memory of the JVM, preloaded. Profile specification contains, along with the the CMP interfaces, the interfaces for data management. They could be JMX-based, and may represent different slices of data in comparison with the CMP interface itself (have a look at the section 10.16 of JAIN SLEE 1.1 specification to see how this done). Before the SLEE service is being activated, this management interface is used to populate the profiles, and this task is similar to the routine SQL INSERTs execution before activating JEE application.

So, in SLEE everything is getting done by SLEE itself. Components lifecycle is managed by SLEE. Transactions are demarcated by SLEE. Persistence is maintained by SLEE. This hyperspecialization allows SLEE to be this effective as it is.

At the end the story about my experience with profiles. In different times we were using different models for persistence of provisioned data in different projects. In one of them this was achieved by using in-memory TimesTen backed by the Oracle server. Performance was acceptable (TimesTen is capable in keeping millions of records in the memory and performing thousands of queries per second, as well as good SLEE profiles implementation), however JDBC driver was not flawless: stopping and restarting TimesTen during operation caused all the threads performing queries to be blocked for 30 seconds. Incoming calls were silently rejected. This is the thing that could never happen with native mechanism like SLEE profiles, and this is why I like it.

This is the last entry in 2007, see you later in new year!