JSLEE vs Erlang/OTP

In the past years I've been involved in standardization and implementation activities on Java event driven application server, namely JSR-240 (JSLEE). This standard aim to provide a model to ease development of event driven and Telco application. Recently I've been playing with Erlang/OTP attracted by the concurrency model, proposed by the language and implemented inside the Open Telephony Platform. Both platforms have been used successfully in real world telephony application (with carrier grade requirements). Here is a short comparison between JSLEE and Erlang/OTP models on a few bullets.

NOTE: The comparison is not intended to be an evaluation but just a learning exercise to better understand the models proposed by the two platforms. Further more fact is not fair to compare a standard specifying a platform with a platform implementation. JSLEE implementers in the market today are usually providing extra features to those specified in the JSR. I'm not an erlang expert, I've just started using OTP after playing with Joe Armstrong book (http://armstrongonsoftware.blogspot.com/) and other resources on the net (http://www.erlang.org/).

JSLEE (Java Service Logic Execution Environment):

• Component Model: defines several components Service, Service Building Blocks, Events, Resource Adapters, etc...


• Platform Management: standard JMX interface used to deploy/undeploy, configure, star/stop components inside the platform.


• Platform Facilities: provides facilities for Profile, Trace, Alarm, Queue Naming, Timer.


• Concurrency Model: short lived event queues managed by the container internal event routing and transactional event delivery to service logic.


• Service Logic Activation: the event router takes care of creating new service instances when an initial event (trigger) comes in; the event router destroys the service logic instance according to rules provided inside the spec.


• Scalability: Cluster is allowed by replicating the application state in a well defined way. The platform uses Ids instead of pointers for services, service building blocks and the queues in order to allow replication of the entire service instance among nodes of the cluster. Usually implementations use a optimistic locking control to propagate changes to the service instance after delivering an event. Event delivery to service logic event handlers is transactional: one event, one transaction.


• Fault Recovery: Call Backs are invoked by the router algorithm to inform the service logic about fault condition in event delivery (e.g uncaught exceptions and commit failures).


• State Replication: The Service logic replicated state is stored inside Service Building Block CMP (Container Managed Persistent) Field, also event logic to queues subscription is replicated. The replication mechanism is transperent to the developers (power to the containers ;-) and depends on the container implementation.


• Implementation: the standard doesn't enforce scalability and fault tolerance requirements, those requirements are left to the platform implementation of different vendors (www.opencloud.com, www.jnetx.com, www.mobicents.org, www.alcatel.com, http://sce-se.alcatel.be/).


• Language: Java and OOP techniques are heavily used to develop JSLEE logic. OOP abstract methods are for instance used to fire events between components and the real code to interact with the container is created at deployment time by the container itself.


• Outside world: Resource Adapter can be used to access external resource, a standard Java Connector Architecture interface is provided to send event to the container from a Java Enterprise Edition environment.

OTP (Open Telephony Platform):

• Component Model: Defines processes, modules and functions, processes have builtin mailboxes queues where they can receive messages, also define a generic framework for event delivery and servers. Modules can be loaded/unloaded at run-time, allowing hot code replacement.


• Platform Management: provides tools for process monitor, the generic framework provides primitives for management operations these management operation can be performed using the Erlang/OTP console.


• Platform Facilities: builtin OTP APIs for trace, timers, naming and a replicated DB (in-memory or persistent) to store profile info or service sessions.


• Concurrency Model: Actor Model. Processes are green thread with no shared memory they exchange information using messages received using a mailbox queue. Mnesia provide a transactional memory shared across cluster nodes.


• Process Activation: spawning processes is under the developer control.


• Fault Recovery: a supervisor/worker model is used, a linking mechanism can be used after spawning a process to detect fault conditions.


• State Replication: state is replicated among different nodes by Mnesia Database, the developer can chose for each Mnesia table to have them in-memory replicated or stored on disk at runtime. The developer has to control the replication mechanism (power to the developers :-).


• Implementation: OTP platform was implemented inside Ericsson and released as open source some years ago.


• Language: Erlang, functional language with strong support for messages (send message, pattern matching); no pointer just process identifier and immutable variables.


• Outside world: Erlang port are used to allows application developed in other languages to interact with the platform using messages. Erlang port have mailboxes like process can receive/sends messages from/to other Erlang processes.

In the upcoming posts I will try to dig deeper onto some of the bullet points ...

Comments and contributions to the comparison bullets are very welcome !

JSIP working on Google Android

This morning I found out this example by Jean:

http://jeanderuelle.blogspot.com/2008/10/jain-sip-is-working-on-top-of-android.html

As soon as I saw the blog post I downloaded Andorid SDK and the example to check this with my own eyes ;-).

Jean manage to run the NIST-SIP stack (a public domain implementation of standard JSIP API) and a complete SIP dialog setup and tear-down example on the Google Phone platform (alias Andorid).

What's great about this achievement:

1) JSIP is a standard api that can now be used by developers to implement server-side and Andorid applications.

2) NIST-SIP is a stable implementation of the JSIP specification. So now google has a stable SIP stack by leveraging the OS path.

3) It's quite straight-forward to port/run JSDK application on Andorid JVM and NIST-SIP is a great example not just marketing fluff.

Kudos to Jean and Google for the great stuff !

Francesco

UMTS 3G Video Portal using JSLEE and WebFlow

Recently I've been working on a 3G video portal based on JSLEE (a java event driven application server) and Spring WebFlow 1.0.5 (a flow execution engine that allows to design a web app as a state machine).

The Video Portal uses SIP to established incoming calls and after the call is setup a Flow execution session is started to keep track of the state of the user inside the container. The user can interact with the video portal from a UMTS phone using DTMF tones sent to the application server as SIP INFO messages or inside the media path.

The JSLEE container provides a well define concurrency model using the concept of activity, all the event belonging to a given call are queued inside a so called activity context and are received by the application logic instantiated by the container to handle the call and registered to receive all the events inside the call.

Once the call is setup the application logic inside JSLEE (implementing using Service Building Blocks) ask the WebFlow Registry for a flow definition using a flow id and creates a flow execcution session and start the flow execution. After the flow is created all the events belonging to the call (like DTMF) are notified to the flow execution. The Flow Session is saved inside a persistent field that allows to continue the flow execution on a different node in case of failure of the first active node.

The call events are passed to the flow using a method of FlowExecutionImpl with the following signature:

Application signalEvent(String eventId, ExternalContext ctx)

the flow engine execute the transition described inside the flow definition for the given event, returns a view to be presented to the user and waits for the next event. The view usually is the url of the new video to be streamed to the user mobile phone using a Media Server.

A flow definition in spring webflow is represented using an XML files that defines the state machine implementing the video portal flow. The Flow Definition is very closed to the specification of the video portal application coming from the marketing, this reduces drammatically the implementation of the video application and provides a very fast and clean way to change the video portal behaviour according to the marketing needs.

JSIP and Spring

Last month I started using Spring and my first hands-on experience was a small project that starts a standard JSIP stack inside the Spring Framework. I was really amazed how Spring provide a nice component technology that's simplify the code and takes care in a well structured fashion of component initialization, reference and dependency.

SIP is a P2P protocol this means that every SIP entity acts as client and server, so in order to write a SIP application you need to start a TCP or UDP server listening on a local port. This usually require a good deal of initialization code in your program. Spring takes care to setup everything for you just using an xml file, let's take a look how.

First of all you need a file properties in order to configure the stack, here is an example for the properties file:

javax.sip.STACK_NAME=spring-sipstack
javax.sip.STACK_PREFIX=gov.nist
gov.nist.javax.sip.TRACE_LEVEL=32
gov.nist.javax.sip.DEBUG_LOG=sipdebug.txt
gov.nist.javax.sip.THREAD_POOL_SIZE=4
javax.sip.TRANSPORT=udp

Spring Framework defines all your application component (called Spring Bean) using a xml file with a beans root tag.

The first component we need is a bean that loads the properties from our sip.properties file. Here is the Spring Bean definition

<util:properties id="sipConfiguration" location="classpath:sip.properties"/>

Our component is referenced inside the spring bean registry using the id "sipConfiguration" and will create a java.util.Properties object.

The second component is the standard javax.sip.SipFactory that is needed in order to instantiate the stack.

We obtain an instance of the SipFactory using a static factory method getInstance and we declare that all the other beans referencing sipFactory will obtain the same instance using the scope singleton. We're also specifying a property that allows us to change the JSIP implementation just modifying the spring configuration file. In this case we are using the NIST SIP implementation providing the value "gov.nist" for the pathName property.

<bean id="sipFactory"
class="javax.sip.SipFactory"
method="getInstance"
scope="singleton">

<property name="pathName" value="gov.nist"/>

</bean>


Now let's create and start the stack:

<bean id="sipStack"
bean="sipFactory"
method="createSipStack"
scope="singleton">

<constructor-arg ref="sipConfiguration"/>

</bean>

The stack is created using the factory method createSipStack of the sipFactory bean, the factory method require a java.util.Properties argument and we just provide the reference to out sipConfiguration bean. After the bean creation the standard method start is invoked and the stack is started.

Now the stack is started but in order to perform any operation on the SIP Stack we need to obtain an instance of the SipProvider interface. In order to create a SipProvider we need to setup a Listening Point for the stack, the listening point identify the server socket inside the stack on which we are listening for SIP requests.
To create a listening point we use the factory method createListeningPoint of the SipStack and we configure the transport endpoint ip address, port and protocol.

<bean id="listeningPoint"
bean="sipStack"
method="createListeningPoint"
scope="singleton">

<constructor-arg type="java.lang.String" value="127.0.0.1"/>
<constructor-arg type="int" value="5560"/>
<constructor-arg type="java.lang.String" value="udp"/>

</bean>

Finally let's create our SipProvider using the createSipProvider factory method of the SipStack by passing as argument the listening point bean id.

<bean id="sipProvider" bean="sipStack" method="createSipProvider" scope="singleton">

<constructor-arg ref="listeningPoint"/>

</bean>

This is all you need to setup the stack. Now you just need to register your implementation of the SipListener interface with the SipProvider.
Finally in order to run the stack you have to start the Spring Framework Application Context using your bean definition xml file.

public class SipSpringStart {
private ApplicationContext springContext = null;
private String ctxFilePath = "spring-context.xml";

public SipSpringStart() {
this.springContext = new ClassPathXmlApplicationContext(
this.ctxFilePath);
}

public static void main(String[] args) {
new SipSpringStart();
}

}

Sip Servlets programming model

I'm currently developing a 3G Video Portal for a carrier's user community, the solution is based on JSLEE and I'm using Spring WebFlow to create the user navigation flows. I like the activity queueing concept of JSLEE and the implementation of the Video Portal has been straightforward. Sometimes I have the feeling that there are too much abstraction inside JSLEE and the standard could undertake a good deal of simplification. But when I look at the "competing" standard inside the JCP I have to admit that is no mature yet even in the upcoming release (JSR-289). The main issue I have with Sip Servlets is the programming model that is still too similar to the Http Servlets programming model, this has been a major selling point for the spec among Telcos but it's also one of the weaker point from the technical point of view.

The main difference between SipServlets and HttpServlet is in the underlying protocol. SIP is much more complex than http can be used in P2P mode by different actors User Agent Client, User Agent Server, Proxy, B2BUA. The greater difference is that http is an application protocol and you can built your own Web Application just using http while SIP is mostly a session protocol and you always need one more protocol (at least a protocol to talk to the media server) to build a compelling application.

This is why I wonder if the programming model of Sip Servlets, still too similar to the Http protocol, is appropriate and really ease development of applications like my 3G Video Portal. Sip Servlets should move towards a multi-protocol approach taking full advantage by queueing and lock-free concurrency introduced in Java5.