Jain SLEE

Over the time I was responsible for the implementation of a few projects for telecommunications in the areas near to real-time, and I needed to choose the technology which allows quickly to create new teleco grade services. After some time spent on analysis it seems there is only one choice :) - and this is the first article of the series hopefully related to JAIN SLEE.

As I am working on several projects in the telecommunication area , in the near future I plan to publish articles the technology, for example: How to use Mobicents Diameter Resource Adapter, how to write your own Resource Adapter, creation of the services quering different components for data over Diameter interface) How to create a service based on Mobicents SS7 stack How to create Web Services on Mobicents platform Setting up configuration management service for other services IMO the key features of the technology are: Basically two types of modules - Service Building Blocks or Resource Adapter - the first with a great variety of services from the application server, the latter is more or less a standard Java code Orientation on processing event, which may be generated by SLEE, SBB or RA Prioriterisation of the events Soft-time context orientation thanks to timers facility Specific handling of multithreading - via Activities and Events Support for persistence mechanisms - very fast one-dimensional arrays (Profile Tables) as well as through JPA Communication between services possible in synchronous (Local Objects) or asynchronous way (Events) Scalability and the ability to distribute the application logic - including clustering of applications Availability of application server software, both commercial and rock solid (OpenCloud Rhino) or OpenSource (Mobicents) Based on my experience - SLEE is more difficult to use than J2EE - due to fact that the majority of Java developers (especially after switching from Windows and. NET) has problems with multi-threading and asynchronous services. However, I think it's worth it - thanks to this architecture it can be possible to support a throughput of hundreds of events per second on a single server without worrying about performance degradation, if it occurs - adding a servers to the cluster should do the rest :)