Thursday, August 04, 2005

JAIN SLEE, SIP Servlets, and Parlay/OSA (2nd Ed)

You are reading the second edition of this article. It was revised after a good amount of useful feedback was given to the initial version.

In a recent IM chat over Skype, Marco Moneiro and I were discussing various VoIP service delivery platforms. One of his comments struck me. He pointed out that Parlay has an easier to program API than JAIN SLEE, while SIP Servlets is about as hard as JAIN SLEE.

This was certainly intriguing to me, since we are implementing a JAIN SLEE container (the first and only open source certified implementation). I should know how it stacks up against the other competing or complimenting open standards.

Marco works at the Portugal Telecom research lab and has direct experience with multiple VoIP technology platforms. As an active contributor to Mobicents, he often shares valuable perspectives with the team.

So I took the time to look at some example applications and build out my own point of view. After hours of playing with Parlay and SIP Servlet code, I reached my non-expert conclusion, which more or less agrees with Marco, but with certain qualifiers.

Provided that each of the three technology standards have specification documents in the hundreds of pages, my thoughts below are merely scratching the surface of the problem and should be taken with a grain of salt. A lot of them are subjective as they are based on limited information and raw intuition. My opinion may change in the future as I gain more experience.

Telephony protocols and abstraction layers

Before we begin comparing the platforms, I would like to emphasize on a criteria that they will be measured against. Namely communication protocol abstraction.

Everyone seems to talk and write about SIP these days. It is no doubt an elegant, HTTP-simple protocol proposed by IETF that is quickly picking up momentum. However unlike the Web, where HTTP has been the predominant transport for UI content almost since the beginning of the Internet, SIP is just another kid on the telephony block.

Telecom services exist for over 100 years. You can imagine how much legacy has built up in the industry. It is a $600 (six hundred) billion global market, with enormous investments in technology and infrastructure. Add to the mix goverment regulations for service quality, downtime, and auditing. To expect that a new, even if brilliant, session initiation protocol will come in and swiftly wipe everything else out is...utopia.

VoIP represents a mere 5% of the telephony today...and VoIP has been available since the mid-90s when H323 was the packet based protocol slated to commoditize telephony. Well... the Web came to the stage around the same time, revolutionized the way we work and communicate, then crashed, then came back up. VoIP has still to make its point. How much have you heard of H323, how about http://? A recent survey by TNS confirms that consumer awareness of VoIP is still low.

Furthermore there are new emerging telephony protocols such as IAX (Asterisk) and Skype that aggressively capture developers mind-share. Examples of the influence are the new generation devices that directly support these protocols.

Here is a Skype phone on the market today:

And here is an Asterisk based PBX appliance:

I firmly believe that VoIP will be a significant part of our lifestyle in the near future. However it won't happen just by replacing existing infrastructure. Rather introducing new converged services, of higher value and lower cost that interoperate nicely with legacy systems will drive consumer interest and ultimately win VoIP a bigger market share.

To allow rapid development of new generation intelligent features, server side developers should not need to know whether the end points connect to the server via SIP, H323, SS7, IAX, Skype, or any other protocol. They should be able to focus on the logic that adds value for the end user.

Now that we covered the perspective on protocol abstraction, let's go back to the original topic and compare examples for Parlay, SIP Servlets and SLEE.


Parlay has a natural programming model, which resembles the style of sequential code seen in desktop applications.

I used the Ericsson Network Resource Gateway SDK, which is freely distributed for research.

Here is a sequence diagram from working Java code implementing a Multi Call Control feature. Disregard the fancy name of the feature, it is actually pretty simple logic. If you are not familiar with telecom terminology, Feature is what a programmer would typically call a service. Take a look:

Feature.handleCall() is the key method in the application. It answers a phone call, asks the user to enter a digit, says something in return and routes the call to the next feature.

If the author had to write the same application for a text user interface, the structure of the code would be essentially the same. Start the app, open the console input, ask for a number, print a text line in response and forward the control to another routine. Plain and simple!

Here is the full source code of the feature:

* Invoked by MPCCProcessor when a subscriber has dialled the service number.
* This method will reroute the call towards a destination that will be specified
* by the calling subscriber, or terminate the call if no valid destination is
* specified.
* @param aCall the new call
* @param aFirstLeg the one and only leg of the call
* @param anOriginatingAddress the address of the calling
* subscriber

public void handleCall(
TpMultiPartyCallIdentifier aCall,
TpCallLegIdentifier aFirstLeg,
TpAddress anOriginatingAddress)
// prepare playing announcements to the calling subscriber.
TpUICallIdentifier uiSession = itsUIProcessor.start(aCall);

// ask the calling subscriber to choose a destination
Object uiResult = itsUIProcessor.askDigit(uiSession,
Configuration.INSTANCE.getQuestion(), false);

// determine the destination based on the response
Configuration.Area destination = getDestination(uiResult);

// abort the call if no destination could be determined
// (e.g. because the user response timed out)
if (destination == null)
// no more user interaction needed

// terminate the call
else // a (valid) destination was determined
// give the user feedback on the choice that was made
itsUIProcessor.say(uiSession,, true);

// reroute the call
itsMPCCProcessor.route(aCall, anOriginatingAddress,

// cancel suspension of first leg

// the application is no longer interested,
// so disconnect the association between Ericsson Network Resource Gateway and the network

Pros and Cons of Parlay

  1. Intuitive API
  2. Protocol abstraction: hides the details of the communications protocol
  3. Lends itself to unit testing. Features are well encapsulated in logically complete methods.
  1. Scalability
    • Footprint: When the application code invokes Parlay methods like askDigit(), the execution environment has to remember the call stack, carry out a complex intereaction with the end point and then return control to the application. Depending on the protocol the interaction with the user can be synchronous (e.g. TCP) or asyncrhonous (e.g. UDP). The voice packets might be routed directly or via proxy servers. In any case the askDigit() method invocation has to appear as a simple synchronous call to the application developer. Such a deep level of abstraction triggers some concerns regarding the resource consumption that each such call incurs on the execution environment. How many OS threads, heap memory, TCP sockets and other system resources are tied up until the call returns?

    • Fail over :If the server where the application is currently executing crashes for some reason, how does the execution continue on a fall back server transparently to the end user...hard. Possible, but very complicated.

  2. Troubleshooting: In such highly sophisticated and complex runtime system, how does one trace bugs such as interrupted calls. How do you tell whether the reason is in the protocol layer, runtime engine or the clustering code? Since the application developer is so remote from the inner workings of the deployment platform how can s/he determine inteligently where the root cause is and communicate it efficiently to the platform vendor when needed?
I am sure the engineers who designed Parlay are aware of all the drawbacks enumerated above and have good answers. However having years of hands-on experience with scalability problems in enterprise systems I am having trouble seing comprehensible practical solutions. If you know otherwise, please let me know; Constructive criticism is welcome.

An interesting idea that is circulating in the community regarding Parlay is to implement its APIs as higher level services for SLEE. Working examples have not been shown yet, but it is a good mind teaser.

SIP Servlets

J2EE developers should feel right at home with the SIP Servlets API. This was a design goal for the authors of the spec and they did a good job at it. The most popular API within the J2EE stack is the Servlet API. There are many developers that are not familiar with EJB, JMS, JTA or JMX, but are quite comfortable with servlets. By induction, a vast majority of HTTP Servlet developers should be able to quickly jump onboard and start cranking out useful VoIP services. Right?...maybe. Take a look at the SIP Servlet API:

All Implemented Interfaces:, javax.servlet.Servlet, javax.servlet.ServletConfig

public abstract class SipServlet
extends javax.servlet.GenericServlet

Provides an abstract class to be subclassed to create a SIP servlet.

This class receives incoming messages through the service method. This method calls doRequest or doResponse for incoming requests and responses, respectively. These two methods in turn dispatch on request method or status code to one of the following methods:

The default implementation of doAck, doCancel and all the response handling methods are empty. All other request handling methods reject the request with a 500 error response.

Subclasses of SipServlet will usually override one or more of these methods.

The resemblence with HttpServlet is obvious. Both extend javax.servlet.GenericServlet and have similar doOptions() methods. What else is similar? Not much.

SIP Servlets have a fundamentally different purpose in life compared to HTTP Servlets. While the latter are primarily intended to serve HTML pages back to Web browsers, the former are primarily used for registering callers and consequently forwarding call setup requests to the current IP adress of the callee. SIP Servlets can be also implemented on User Agents or Endpoints.

In a casual day-to-day scenario, a Web surfer, friendly Alice for example, uses a search engine to find a web site with the content she is looking for, then hit the URL of the site and get the HTML content from the web server powering the site.

Alice also has a SIP phone that is registered with the SIP server of her VoIP service provider. To call Bob, she uses the phone book or a people search engine on the web to find his phone number (because she always forgets it). Then she punches in the digits and her phone will ask the SIP server about the current IP address of Bob's phone, so that the two can establish a direct voice channel. The SIP server finds the information and returns it to Alice's phone, which then establishes a voice channel over RTP/RSTP (not SIP!) with Bob's phone. At the end of the call Alice hangs up the handset and her phone notifies the SIP server that the line is available to take incoming calls.

This is an oversimplified scenario, that assumes a SIP only world, but fits the scope of this text. Notice that the actual content (voice) is not delivered over SIP as it is in the HTTP case with HTML. It is instead delivered over RTP. SIP and RTP are independant standards. SIP is used for signaling, RTP is used for media. SIP Servlets do not deal with content delivery(media). It is not possible to play a voice message back to a caller directly from the SIP Servlet doResponse() method. Notice the difference with Parlay?

What about VoiceXML? Many developers have heard of it as the cool XML language similar to XHTML Forms that allows users to input data by speaking instead of typing. Maybe SIP Servlets can serve VoiceXML content to SIP phones? It's possible...but it is not how VoiceXML is used typically. In most scenarious VoiceXML is served by Web servers directly to end points or to an intermediary text-to-voice transformation engine. The following research paper from the Columbia University, illustrates well the roles of SIP, RTP, HTTP, and VoiceXML in a conference call system:

Here is a snippet of code from a SIP Servlet, which connects a caller to a callee either directly or via alternative SIP Proxy:

protected void doInvite(SipServletRequest req)
throws ServletException, IOException {

if (!req.isInitial()) { super.doInvite(req); return;}

List contacts = resolve(req.getRequestURI());
if (contacts.isEmpty()) contacts = resolve(req.getTo().getURI());

if (!contacts.isEmpty()) {
trace("Found contact info - " + contacts );
Proxy p = req.getProxy();
String next = getContextParam("next_app");
if(next == null) {
// Reject as not found
trace("User not found and no forwarding servlet info available");
SipServletResponse resp = req.createResponse( 404 );

// pass it to next proxy
SipURI nextUri = getPlainURI((SipURI) req.getRequestURI());
nextUri.setParameter("servlet", next);
trace("User not found, route request to <" + nextUri + ">");
Proxy p = req.getProxy();

Pros and Cons of SIP Servlets

  1. Familiar API. Most J2EE developers will be comfortable to try it without going through specialized training.
  2. Scalability: SIP Servlets are designed to be mostly stateless. SipSession is the recommended structure where servlets should store non-persisted state. To ensure transparent failover the session has to be replicated to other cluster nodes. This is a well understood problem and there are practical solutions that can be borrowed from Http Servlet containers.
  1. Protocol Dependency: As the name implies, SIP Servlets are strictly tied to SIP and do not address other practical protocols like H323, SS7, and IAX. It is up to the application developer to come up with abstraction layers so that code written for SIP Servlets can be reused for non-SIP clients.
  2. Danger of mixing front end with business logic: Sip Servlets seem vulnerable to some of the problems that HttpServlets exhibit.
    • Servlet developers tend to mix flow control with business logic, which makes the code harder to maintain and reuse.
    • Unit testing of servlet code is not simple, because it requires simulation of the communication protocol. Frameworks similar to Jakarta Cactus and HttpUnit will have to be developed to alleviete this inconvenience.
  3. Lack of rigid component model: As VoIP applications mature and grow in size, there will be likely demand for component frameworks that separate the call control from the business logic classes and the persistence layer. Existing J2EE APIs like EJB and JMS will be prime candidates to fill the void. JAIN SLEE is also a contender. Time will tell, which one will be the preferred direction for developers in the long run.


SLEE (Service Level Execution Environment) is viewed by some as the crown jewel of JAIN (Java APIs for Inteligent Networks).

If you glance through the specification you will notice that many concepts sound, look and feel like J2EE. For example ActivityContext reminds us of HttpSession, CMP semantics of SBBs and Profiles are similar to EJB CMP, transaction isolation, JMX and JNDI are also present in SLEE with almost identical characteristics as in J2EE.

That is not accidental. The expert committee took their time to learn from the J2EE lessons and cherry pick concepts, techniques, and best practices from it that best fit the needs of a Next Generation Service Delivery Platform. It took 5 long years from the initial formation of JSR 22 until its public release in late 2004.

Compared to the 100+ years of telecom legacy, 5 years is an impressive achievement for a standard that accomodates input from such a wide variety of industry players with disparate interests. The discussion took a long route starting from the possible adoption of a Java API for SS7, which is a a highly specialized telephony stack covering a wide range of networking layers including a physical layer.

Eventually the experts recognized the need to attract the mainstream application developers and made a significant effort to accomodate relevant J2EE ideas and constructs.

But the story is not all rosy. My personal initial experience with JAIN SLEE was not a positive one. The spec is overwhelming and hard to grasp at first! This is a red flag for its future adoption rate. I have 5 years of hands on experienced with J2EE and am member of the JBoss core team. JBoss is the J2EE server with #1 market share. If I cannot get up and running with SLEE in a few days, what chance does it stand to win mainstream developers mind-share?

Those who have been on the front rows of the Web technology evolution from CGI to PHP3 to JServ and eventually EJB, would probably appreciate a chance to skip a few iterations in the VoIP middleware evolution and go straight to SLEE. 7 years ago, EJB was insanely overwhelming for newcomers. Now, we all love EJB3.

Now let's look at some application code. Assume a new call comes into the SLEE. The call has one call leg that an SBB is interested in. SBBs are Service Building Blocks used to compose higher level intelligent features. They are similar in conept to EJBs.

If the SBB in question decides to immediately disconnect the connection it will do so in the call back from SLEE:

public void onAlertingEvent(JccConnectionEvent event, ActivityContextInterface ac){
JccConnection connection = (JccConnection)ac.getActivity();
For the SBB to create a new call, it will use the following sequence:

JccProvider provider = (JccProvider) new InitialContext.lookup("location");
JccCall call = provider.createCall(args);

To receive events on this call, the SBB must subscribe in the following manner:

ActivityContextInteface ac =

You probably notice the resemblence with Parlay. The call protocol is abstracted via the JCC API, which nicely fits in the context of SLEE.

One unique characteristic of SLEE is its asynchronous signaling model. SLEE encourages components to communicate among each other via asynchronous events. SBBs are expected to implement self-contained units of logic, which react to events, promptly perform their assignment and produce another event as ouput. The resulting event can be a message to another SBB or a Resource Adaptor.

SBBs are mostly stateless, but they can have CMP fields which allow them to keep non-persisted state, similar to Stateful Session EJBs. Persisted state is stored in Profile Tables, which can be viewed as simplified relational database tables.

SBBs do not directly interact with objects outside of SLEE. Instead they receive and send events to specialized Resource Adaptors, which in turn are responsible to interface with the world. Examples for RAs include SIP RA, EJB RA, Web Services RA.

Multiple SBBs are assembled into Services (aka Features) such as Find Me and Call Forward.

Here is a SLEE component diagram:

Another important characteristics of SLEE is that it defines event delivery semantics based on SBB priority level. Since most of the signaling is asynchronous and goes through the SLEE event router, the prioritization semantics allows emergency (e.g. 911) calls to quickly go through despite the presence of other ongoing calls no matter how many of them there are.

To learn more about SLEE, you can start with the following white papers and articles:

Pros and Cons of JAIN SLEE

  1. Protocol Abstraction: SLEE promotes multiple planes of abstraction. However it does not go as far as hiding the asynchronous nature of call signaling.
  2. Scalability: Mostly stateless, well defined structures for replication and persistence. Asynchronous messaging allows the runtime engine to quickly route important calls. A simple event routing algorithm, which lends itself to multi-threading.
  3. Component model: Strong component model reflecting best practices derived from vast experience with telecom systems. Rigid mathematical model for event routing and well defined state machines for the life cycle of each component should make it safe to switch between compliant vendor implementations.
  4. J2EE friendly: SLEE APIs heavily borrow from J2EE. There is also a set of best practices for interoperability between SLEE and J2EE.
  1. Steep learning curve: Developers will likely need initial training before they can write proper SLEE applications. Availability of visual tools, self-guided tutorials and best practices will be essential to flatten the learning curve.
  2. Integration testing:Well designed, self-contained SBBs should be easy to unit test. However testing end to end scenarious that involve multiple SBBs are harder to write, because the flow sequence can be time sensitive. The SLEE TCK provides a good base for writing end-to-end tests and it offers good examples, which alleviates the problem to some extend. There seems to be a need for a testing framework which further simplifies matters.


In this text we looked at three viable VoIP middleware platforms - JAIN SLEE, SIP Servlets and Parlay/OSA. We saw some of their key diferences and similarities. Since each of the three open standards has been implemented by multiple vendors and deployed in real-life production systems, they have all proven their qualities.

Adoption however remains limited to relatively small communities as compared to mainstream middleware systems such as J2EE or .NET. Google search returns 8,370 results for Parlay/OSA, 40,300 for JAIN SLEE, and 45,800 for SIP Servlet. Compare that to 8,870,000 for J2EE and40,900,000 for Microsoft .NET. The question still remains, which VoIP platform, if any, will come close to these numbers.

For completeness, it should be noted that there are reports of alternative solutions, which bypass the forementioned VoIP platforms altogether. For example a click-to-dial application can be constructed with a plain HTTP Servlet container and a JAIN SIP library.

So there it is. Now that the cards are on the table. which direction are You most likely to take?

Related reading

The following resources offer alternative views on the comparison between the three platforms discussed here:


I would like to thank Ranga, who is a respected expert in the JAIN community, for taking out of his own time on the weekend to review this text and provide important corrections. I would also like to thank Phelim O'Doherty, Swee Lim and the rest of the people who posted comments to this text since it was initially published.


Anonymous said...

Thank you very much on providing this summary. Please allow me a couple of comments.

I don't have much experience on SIP or SIP Servlets, so I'll skip the SIP part.

As for the comparison of JAIN SLEE and OSA/Parlay, my opinion is that there is no comparison possible, as one of the white papers you cite says, they're complementary technologies, JAIN SLEE focuses on the execution model, while OSA/Parlay restricts itself to the API.

It is then possible to create a resource adaptor that provides the call control OSA/Parlay API inside the JAIN SLEE environment, the same way any other Java APIs could be provided.

Here we come to perhaps one of the main weaknesses in JAIN SLEE: the lack of standarization of the APIs. JAIN effort (of which JAIN SLEE is just a part) has defined several API and potentially it is possible to use any JAVA API within the JAVA SLEE (even the Java realization of the OSA/Parlay IDLs). However to keep the objective of portability of applications across different vendors, the APIs used must be standardized.

Standardized means really two aspects: 1.- The reality model offered by the API being standard (e.g. OSA/Parlay or JCC call control state models). 2.- The API being standard (not only the methods that the SBBs can invoke in the API... but also the possible events received and the definition of the activity context).

Except for some notes on how it could be possible to use JCC, SIP and JAIN TCAP within the JAIN SLEE there's little on that area, opening the field to interoperability problems. Bridging the gap between a given Java API and defining a unique way of using it within JAIN SLEE is the real problem right now.

Your comparison really pits JCC against MPCC, two APIs and call control models. In my opinion you can see from where the APIs come from: JCC comes from JTAPI, an API to control phones, while MPCC is influenced by INAP protocols designed to write applications that control the processing of calls.

In the first case your application receives a call and handles it. In the second case a switch (or network element) receives a call and given a criteria it asks the application how to proceed.

I must say that there're cross-influences. JTAPI evolved into JCC by trying to apply IN paradigms, while original Parlay Call Control API was influenced by JCC to evolve into MPCC.

MPCC and OSA/Parlay APIs in general are encumbered by the complex negotiation process required for any application to gain access to network resources (e.g. the SCS providing the MPCC API). The requirement to support applications outside the network operator domain brings strong requirements in authentication an enforcing of access policies.

Unfortunately operators do not seem prone to allow outside applications to use their network, using Parlay or not, making Parlay complexity a major drawback

As for scalability and reliability. There seem to be quite a lot of discussion around that, with different proposals going on, but without a definitive answer approved yet.

To finish, I personally like JAIN SLEE execution model, however the JAIN API efforts seems not to be very focused in some cases with APIs withdrawn or not modified in a lot of time. OSA/Parlay APIs on the other hand, maintained by 3GPP has probably a stronger standard backing [not that that means anything]...

.... so what about JAIN SLEE adopting Parlay APIs as The APIs?

Anonymous said...

[I'm the anonymous in the previous comment]
One additional side note: AFAIK askDigit() is not part of any Parlay API.... and AFAIK most of the Parlay API methods are asynchronous, reporting success or error in a separate method to a corresponding callback interface (specially the call control APIs).
This is good because it responds to the asynchronous nature of the communication with the network elements.... but it is bad because any application needs a complex infrastructure to build in order to receive the answers and correlate them with the requests.

Anonymous said...

I do agree to the previous poster on the OSA/Parlay vs. SLEE comparison:

- OSA/Parlay has a considerably amount of defined APIs
- The set of JAIN APIs is less complete with regard to protocols/functionality addressed (and lots of withdrawns)
- SIP Servlets are restricted to SIP

Execution Environment:
- This is where the SLEE environment has its obvious scalability and performance advantages while still being open to other fields of integration between Resource and Component (almost every large scale event based system; not telco restricted)
- OSA/Parlay focuses its execution capabilities on supporting its APIs. Execution model and APIs are more thightly aligned to each other than with JSLEE
- SIP Servlets are for SIP, and servlet-like is the only execution model.

So when comparing the technologies to their fields of appliance one might come to this conclusion (discussion welcome):
- use SIP servlets if you want to quickly write a SIP restricted application where it is overseeable into which direction it will develop regarding performance and scalability.
- if you are a telco and have to handle a large volume of calls, etc. then you might choose JSLEE for fault tolerance and scalability issues.
- one might choose to integrate and use OSA/Parlay APIs within the JSLEE environment instead or together with JAIN standardized APIs

It might also be interesting to have an eye on BEA's strategy. They started to announce and promote SIP servlets but currently its coming clear that their telco grade environments will not only support SIP servlets but also have other telco functionality support in their AS. Wheather this is JSLEE or some other proprietary approach doesn't seem to be absolute clear at the moment.

And last a side note to Ivelin:
It seems that you related CMP and Profiles incorrectly by saying that profiles are used for storing the CMP values. I guess you're wrong here:
- CMP is (obviously) managed by the container. But it doesn't use profiles for this.
- Profiles are in the 1.0 spec read-only tables that can be queried by SBBs (directories, user preferences, etc.)
- In the 1.1 spec profiles loose their read-only manner and can be modified by SBBs.

Ivelin said...

Thank you for the objective feedback.
I do agree with the comment:

"2.- The API being standard (not only the methods that the SBBs can invoke in the API... but also the possible events received and the definition of the activity context)."

History repeats itself. When J2EE came out it was regarded as a promising foundation, but there was no clarity how to best apply it.

Now that there is an open source, usable SLEE implementation, I am expecting that the community will naturally promote blueprints, best practices and SBB service libraries.


Ivelin said...

Thank you for the clarification on
"Ivelin,...It seems that you related CMP and Profiles incorrectly by saying that profiles are used for storing the CMP values. "

My intention was to say that container managed persistence for SBBs and Profiles is similar to EJB CMP.


Anonymous said...

I dont have programming experience with OSA/Parlay but from the architectural descriptions of it clear that it is that it is a higher level API than JAIN-SLEE and can indeed use JAIN-SLEE as an execution environment. ( Would a resource adaptor be the right bridge between the two or should OSA Parlay be a SLEE service? )

Thus a direct comparison between the two, in my opinion, is not really comparing apples to apples.

Anonymous said...

Thanks for the comparative study. Agree in general with the gist of the summary.

Couple of points:

I've worked some with a Parlay Gateway and do feel that the API is quite expansive breadthwise. Also agree with the point about its implementation being relatively complex. However, one thing to note is that the API is defined in terms of Corba IDLs and also WSDLs. Its a minor technicality but the former means there already CORBA middleware (ORBs) available to provide a lot of the underlying complex implementation ( sync/async remote calls, callbacks etc). BTW, framework for correlating requests is already designed into the API itself by means of IDs which are passed into both call and callbacks. WSDL-based means the API can be implemented as Web Services (which may be attractive to proponents of that model though I don't really know how successful thats been).

I agree about idea of the SLEE being an execution environment within which Parlay components can be deployed through resource adaptors.
Seems like a logical way of combining the versatility of Parlay and the execution efficiencies of a well-designed and implemented SLEE container.

Anonymous said...

I haven't done much development with JAIN SLEE. I read the spec a while back when it was still at 1.0. And I tell you it's an order of magnitude more complex than J2EE/EJB programming model, which itself is very complex. I don't have much hope in the short term for the JAIN SLEE community to accomplish something similar to what EJB3.0 is doing to EJB on the ease of use, and simplification front. I think what needs to happen to JSLEE is something similar to what Spring did to the EJB space with its Dependency Injection/IOC approach which has shaken up that space with its elegance, and simplicity. I think we need a Spring analog for the JAIN SLEE space to energize it, and I'm hoping that the mobicents group will the one who will offer it first.

Anonymous said...

Agree with the last poster about SLEE being overly complex, and that like EJB, a lightweight Spring-like approach would be the way to manage the complexities.

When I first encountered SLEE, having a more conventional IT background, the entire specification looked like a kitchen sink approach structured in a manner that didn't make sense.

Only later did a realize as to why it was structured the way it was. That was because old telecom switching systems provided their services in an analagous manner to SLEE. This mirrors EJB where EJB was defined based on existing Transaction Monitor based systems. Old habits truly die hard.

The problem is, the old telecom model is more of a hindrance than a strength in the world of convergent systems. One may argue that its structure leads to scalable and reliable systems. However one only needs to look a Google to realize how myopic this thinking truly is.

Anonymous said...

I have a chance to work on both Parlay and SLEE, not extensively but enough to know some differences.

. The separation of the application layer and platform is quite cleared. The application is in the application space with a rich set of API. The Parlay components are in the telco space with its own set of API. The common transportation layer is the CORBA.
. The programming language is free of choice due to the CORBA features.
. Similar to the JSLEE core, Parlay provides the Framework components which is the controller for Parlay components.
. The API is quite easy to follow
. Testing is simply to exercise the set of the API.
. portability-easy for the application but hard on the platform

.security-authentication is very much the only authentication mechanism. People can snoop in across the LAN or WAN during the session
.High Availabililty - Parlay doesn't specify anything about this area. It is up the implementors to figure out. This is a complex area but require by every telecom. One major facing problem is that application uses the CORBA IOR for communication . And the CORBA IOR is the physical address and port number of a particular Service Instance. When that goes down then service interruption is almost impossible to avoid.
. At the time I remember only draft version of TCK is available. I don't know what is the status now.
. Upgradability - Parlay doesn't have a clear understanding of backward compability, method deprecation and so for.
. Setup - it is quite difficult to setup and consume more time to set up.
. Debugging is a lot more difficult then the JAIN SLEE

. easy to setup and install
. can run on anywhere
. easier for debugging
-very complicate to understand for the beginner like me. The terminologies are also hard to grab.

-portability- application run on the same box
-there is not much detail on the security
-high availability - ???
-Parlay is more maturity in term of adoption.

Anonymous said...

I have a chance to work on both Parlay and JSLEE, not extensively but enough to know some differences.

. The separation of the application layer and platform is quite cleared. The application is run in the application space with the rich set of API. Parlay SCSs (Service Capabilities Server) are in the telco space with its own set of API. The standard transportation layer is the CORBA.
. The programming language is free of choice due to the CORBA features.
. Similar to the JSLEE core, Parlay provides the Framework SCS which is the controller for Parlay other SCSs.
. The API are quite easy to follow
. Testing is simply to exercise the set of the API.
. Very easy to move the application from one platform to another platform. Moving Parlay gateway is much harder.
. A lot more adoption then JAIN SLEE

. Security-authentication is very much the only authentication mechanism. People can snoop in across the LAN or WAN during the session
. High Availabililty - Parlay doesn't specify anything about this area. It is up the implementors to figure out. This is the complex area but requires by every telecom. The issue is that applications reply on the CORBA IOR for communication . The CORBA IOR is the physical address and port number of a particular SCS. When the SCS went down then the service interruption is almost impossible to avoid because the application only knew about that physical address and port number.
. At the time I remembered only draft version of TCK is available. I don't know what is the status now.
. Upgradability - Parlay doesn't have a clear understanding of the backward compatibility. Between the application, framework, and SCSs, you can come up with number of combinations of compatibility issues.
. Setup - it is quite difficult to setup and take more time than JAIN SLEE
. Debugging is a lot more difficult than the JAIN SLEE
. Management - there is not a common software management interface.

I have to admitted that my understanding of JSLEE is very little. But here are my few comments on it
. easy to setup and install
. can run on anywhere (e.g., windows, solaris)
. easy for debugging
. all Java
. events based
. managements with JMX is great.
. very complicate to understand for the beginner like me. The terminologies are also hard to grab.
. portability- applications will have to run on the same box as the platform and can end up to use the proprietary features.
. security - there is not much detail on the security
. high availability - ???
. real telecom adoption- I don't hear a lot.
. upgradability - it can be a lot easier than Parlay since the RAs and SBBs are deployable units.

Anonymous said...

I think this is a good article that tries to get to the crux of an important issue in the industry. It also covers an area were there is alot of confusion in the industry, mostly generated by competing vendors trashing one technology over another to make sales.. real life business I suppose.

I think the article as pointed out by others compares two Java containers (SIP servlet and JAIN SLEE) and a set of API's(Parlay). That is Parlay does not define an execution environment, it only defines a set of abstracted API's. JAIN on the other hand defines a set of abstracted and protocol API's and two containers (JAIN SLEE and SIP servlet). Yes SIP servlet was also developed within the JAIN community.

So leaving the containers until later as I think you do a reasonable job evaluating them in the article. The last comparision to be made is the JAIN API's and the Parlay API's, i.e. there is no comparision to be made about containers as the JAIN community developed two and the Parlay community developed none.

Specific to API's:

JAIN: is really the collection of people trying to solve communication problems using Java through the JCP. The technologies ranges from SS7, to IP to containers. The SS7 API's in JAIN was were the idea of driving Java into communications came from. This wasn't the sweet spot but got everyone started - the only real successful SS7 one was JAIN TCAP - but it is only an integration interface at best as the development interfaces has abstracted away from SS7 thank goodness. The world of IP communications took off so the JAIN community developed some protocol interfaces for the IP network, JAIN SIP has being really successful as obvious on Finally the JAIN community then developed a set of abstracted API's JCC and SAMS being the most famous and getting a little traction (this is the only area were Parlay and JAIN competed), Sun stopped support for JAIN SPA (Parlay API's through the JCP) as the larger community wasn't really behind it.

Parlay: is really the collection of people trying to solve communication problems using no explicit programming language through 3GPP. They have developed a suite of abstracted API's i.e. GCCS, MPCCS, ULS etc...

As the abstracted API space is the only space in which Parlay and JAIN compete. It is my hunch that a few of the Parlay interfaces will become the defacto abstracted interfaces for call control and user interaction, policy, and others may appear from some other bodies such as OMA, LIF and probably SAMS from JAIN etc.. It is fair to say however that JAIN SIP, SIP servlet and JAIN SLEE will all be successful standards developed by the JAIN community. They are all mature technologies and will continue to live a life of there own in the industry and they don't compete with Parlay standards.

There are some comments in the thread that say that JSLEE should adopt the Parlay interfaces as the API's for services. I believe it is not up to the JSLEE standard to adopt the Parlay API's as the programming interfaces. JSLEE is a general purpose app server that should not be bound to any specific technology, it is up to the Parlay vendors to use JSLEE as the standard execution model for Parlay services instead of there home grown execution environment. The Parlay API's are supposed to be standard afterall so if JSLEE provides a standard system contract to plug them in all should be good. The obvious reason for not doing this is that ISV's/NEP's want to lock the vendor into there proprietary solution for revenue purposes. JAIN and Parlay technologies don't really compete, but the products from the respctive camps do - but it really a proprieatry execution environment/standard execution environment fight. I think it time for vendors to stop confusing the industry and use the correct abstracted interfaces with the correct containers. This is what the operators want.

Now back to the container discussion (SIP servlet and JAIN SLEE). I believe it is not an either or approach. JSLEE is a general purpose server that has its place in the industry for a certain set of applications (NGIN + IMS), and SIP servlet has its place in the industry for a certain set of application (IMS + enterprise). SIP servlet will be a strong choice for simple applications and http integration, but as the applications grow more complex and need to interact with more systems don't be surprised to see JSLEE play a role. I hope this clarifies a little of the confusion and does not add to it.

Ivelin said...

Phlelim, thank you for the comments.

It is good to see a well known entity in the JAIN community such as yourself to share thoughts on this hot topic.

I wish more folks would use their real names when posting comments so that we can establish proper discussion.


Anonymous said...
This comment has been removed by a blog administrator.
Anonymous said...

In follow up to my comments, I have received email from some SIP Servlet developers that my response implied that complex SIP applications could not be built on SIP Servlet. It was not my intention to imply this. What I was implying was when developing more 'complex applications'; complex in that they require more than just the SIP protocol; do not be surprised to see JSLEE play a role. It was too good to expect no further confusion, so hopefully this clarifies that statement. For background I have served on both the SIP Servlet and JAIN SLEE expert groups.

Anonymous said...

Great Work Ivelin.
Congratulations on passing the JAIN SLEE 1.0 certification.


Anonymous said...

Isn't this a catch 22? Before SLEE can be applicable to more "complex" scenarios not covered by SIPServlet it needs to have the Resource Adapters.

That brings us now to the question of the availability of STANDARD resource adapters. After all, if you're coding to it and want the portability, then the API sure as well need to be standard.

So when one says SLEE is useful in complex application that are non-SIP, then you have a red herring. SIPServlet makes sense, so does Parlay, SLEE on the otherhand, in the absensce of standard APIs to talk to the network layer, is essentiall a non-standard pretending to be a standard.

Anonymous said...

Interesting subject that is worth a complete forum for itself :D
- First AskDigit is not in the parlay API, it's in the demo application.
- Parlay API offers many other usefull functionalities not related to call control (position, charging, user interaction, mobile capabilities) and it the only adopted standard AFAIK that provides all these capabilities, and it's thus the choice in non-callcontrol.only apps.
-Parlay API is an API, and JAIN SLEE is like an application server like Appuim Telecom AS, or IBM WTAS.
- Parlay APIs (most likely Parlay X, web services) will be provided to 3.rd party developers, while applications developed for SIP servlet/jain SLEE AS would most likely be developed internally by operators.

Anonymous said...


Thanks for the analysis. I also appreciated the comments, and more especially those positioning OSA/Parlay and JAIN SLEE with regards to each other.

My background is one of a network architect, so let me try to bring another perspective to the discussion.

You may compare OSA/Parlay and SIP servlets for the implementation of VoIP applications, i.e. applications which naturally fit OSA/Parlay.

The problem with OSA/Parlay is that all the existing APIs were specified in a pre-SIP and pre-IMS world based on circuit-switched and a few packet-switched based capabilities(e.g. MMS, location).

Most of the future SIP-based services will be very different, and for them OSA/Parlay is of no help at all.

No push to talk server, no presence server was implemented on OSA/Parlay. Why? Because it is impossible.

Even if you consider call control, OSA/Parlay is ill-suited for a SIP-based network.

Of course, it is possible to map OSA/Parlay call control APIs on SIP. But by doing so, you map a circuit-switched vision of calls over SIP, a vision where a natural call is voice only, where a multimedia call is voice or video plus "data", where multiparty calls are handled in a very specific way, where forking, callee capabilities, caller preferences, media negotiation, do not exist.

Take the only existing 3GPP report describing the mapping of OSA/Parlay over (supposedly)IMS.

First the mapping hardly take into account the IMS architecture. It is mainly a mapping on (IETF) SIP.

Second, the mapping is full of mistakes and "holes".

Third, the way it supports multiparty call control is not aligned with how multiparty call control (called "conferencing") is specified for IMS.

The advantage of a SIP servlet approach is that by providing access to the protocol, the API does not have any preconception about what the protocol is going to be used for, e.g. session control, messaging, presence, reporting random events...

The fact that the API is protocol-specific is not such an issue, when the protocol can be used for so many things and when it is the control protocol for next generation fixed, mobile and converged networks.

Of course higher abstraction APIs would be welcome, but only if they are specified to optimally make use of the SIP and IMS capabilities.

Even in a SIP-centric world like IMS, SIP should very seldomly be used alone. Most of the time SIP-based applications need to use other protocols such as XCAP, HTTP, SOAP, Diameter, MSRP (not mentioning legacy telco protocols such as SMPP for SMS, MM3/MM4 for MMS, MLP for location).

Therefore, SIP servlets can only be part of a greater sheme, which definitely includes J2EE, but may also include JSLEE.

JAIN SLEE advantages and drawbacks have been well listed. For me the possibly worst drawback is that it is perceived as a telco standard, while SIP servlets are rapidly gaining acceptance in the community through VoIP and IMS hypes.

In any case, for me no existing JAIN SLEE or SIP servlet environment is optimal to support IMS services.

JAIN SLEE -based platforms have been tailored so far to support next generation IN services. IMS is a brand new target and it might not be so straightforward to tune the enviromment for it. SIP cannot be handled as just another protocol to be integrated on par with INAP or SMS.

SIP servlets are optimal to implement SIP applications. But there is a certain gap between "SIP applications" and "IMS services" ("services" in the sense of services offered to end-users).

There currently exist two contradictory statements about IMS and SIP. The first one is explicit, largely unproven but true. The second is implicit, widely accepted but wrong.
1) IMS and SIP will permit to implement new innovative services which will change the telco world.
2) Implementing services on IMS and SIP will not require any major change in the telco mindset.

Unknown said...


According to Parlay approach, NRG SDK is not only solution for application designers. I recommend to try the Appium XWay Telecom Application Server. It and its state machine is an answer for most cons you mentioned (failover, footprint,...). I used to work for Appium some time ago and I know this solution, it's worth of recommendation.

Cegonsoft said...

Really, your sequence diagram shows the effective of your blogs....From your blogs , I came to know about SIP servlets..Thanks for your valuable post and blogs...