Tech blog to share ideas about ongoing project and discuss interesting stuff related to Communication tech and programming.

Saturday, December 13, 2008

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 !