Abstract: testing JAIN SLEE's aim of simplifying Telco development
JAIN SLEE is a Java application-server standard for building telecommunications applications on any network including NGIN, IMS and Messaging. One of the aims of the JAIN SLEE standard is to simplify the development of telecommunications applications and, because it is a Java standard, be accessible to the very large pool of Java developers in the market. This study tests that assertion.
Specifically, this paper poses the question:
"Can a JEE developer quickly learn to build applications with JAIN SLEE?"
This paper looks for an answer by monitoring the progress and eventual success of a JEE developer — with no prior knowledge of JAIN SLEE — tasked with developing a complex SIP application (a SIP presence and IM server) for a JAIN SLEE server. In only two months, the developer learned JAIN SLEE (and the SIP protocol), and built the application successfully.
Conclusion The JEE developer successfully learned JAIN SLEE and SIP, and implemented a SIP presence and IM server, in just two months. We can conclude that developing applications with JAIN SLEE is indeed simple! We were so happy with the resulting application, we bundled it with the [Rhino SDK] as an example.
Keywords — JAIN SLEE; SIP; SIMPLE; Presence; IMS
Tasking a JEE developer to build a presence server with JAIN SLEE
To see how easy it might be for someone with no prior experience to develop complex telecommunications applications on a JAIN SLEE application server, we asked a developer to develop an implementation of a SIP presence server on a carrier-grade JAIN SLEE application server ([OpenCloud Rhino v1.4.5-01]). The goal we tasked him with was to develop a presence server that could, when deployed into a JAIN SLEE application server, successfully communicate with several readily available SIP clients and enable both presence and instant messaging.
3 years of experience with Java
1 year of experience with JEE (mostly using Servlet with minimal use of EJB)
No knowledge of JAIN SLEE
No knowledge of SIP
No knowledge of any other signaling protocols
Develop a SIP presence server on a carrier-grade JAIN SLEE application server:
Use [OpenCloud Rhino v1.4.5-01]
The presence server should work with the following reference clients:
Linphone (version 1.7.1)
, an open-source SIP client for Linux operating systems
Windows Messenger (version 5.1.0701)
, the communications client bundled with Windows XP
Pidgin (version 2.02)
, a multi-protocol, instant-messaging client that functions in both Linux and Windows environments.
The developer keeps a diary and records the time spent during the project. In particular time spent: learning about SLEE, learning about SIP, service design and implementation, bug fixing and problem solving.
Criteria for success
We resolved to monitor the developer's progress (and any problems) throughout the development process, and to measure the success of our "experiment" by:
the ease with which the developer adapted to the JAIN SLEE programming model
the complexity of the software components developed
whether the completed presence server could pass a series of unit tests.
About IM and presence
Instant messaging (IM), in conjunction with a presence service, provides a form of informal communication where users can compose and exchange short messages in near real time. One of the drivers of the early uptake of this technology was the capability of client applications to clearly display presence information for registered "buddies", that is to give the user a real-time indication of whether or not their "buddy" is willing and able to communicate at any time. Although initial use was most significant among private individuals using simple messaging clients (such as those provided by Microsoft and AOL), the business world has increasingly recognised the potential of instant messaging to improve communication through interactivity and real-time transfer of information
Presence service, presentities, and watchers
In RFC 2778
, the IETF have set out a generic model for presence and instant messaging, which gives an excellent framework for discussions on the topic. The model describes a number of conceptual entities that are central to the technology, including:
presentities — entities that provide presence information to the presence service
presence service — the service that collates and stores information from presentities, and distributes that information to watchers
watchers — applications that can subscribe (in which case, they are known as subscribers) to receive updates from the presence server on any changes in the presence information of particular presentities.
Most IM client applications implement functionality for both the subscriber and presentity part of the mode. Allowing the user to compose a list of buddies fulfills the role of the subscriber, and allowing the user to update their online status fulfills the role of presentity.
Implementations of presence and IM services widely use the Session Initiation Protocol (SIP). SIP is an IETF-standardised signaling protocol for establishing communication sessions
. Although SIP is a versatile protocol that has been well established for use in a wide variety of applications, it is particularly well suited to IP communications, and as IP communications services (such as VoIP, collaborative multimedia conferences, and instant messaging) become more prominent in business applications, the profile of SIP as a signaling protocol has also risen. This trend has gained momentum with the uptake of the protocol by several major vendors, including Microsoft, who have used SIP in their implementations of communication and collaboration services, notably Live Communications Server and Windows Messenger. SIP is also recognised as a key protocol in the emerging field of IP Multimedia Subsystems (IMS), defined by the 3rd Generation Partnership Project (3GPP)
SIP extensions for IM and presence
Example message flow for a SIP implementation of a presence service
SIP owes its versatility to the fact that at a high level it is quite simple, implementing a basic request-and-response model similar to HTTP, and to the fact that it is readily extensible
. One of several extensions that have been made to the protocol is an adaptation to enable the transmission of IM and presence information. This extension is known as Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions, or SIP/SIMPLE. Although there are several RFCs pertaining to this area in the SIP specification
, on its most basic level, implementing SIP/SIMPLE requires only three extra SIP messages: SUBSCRIBE, NOTIFY, and MESSAGE requests.
For example, if user A (identified by the SIP address sip:firstname.lastname@example.org) wants to access the presence information of user B (identified by the SIP address sip:email@example.com), user A's SIP client sends a SUBSCRIBE message addressed to sip:firstname.lastname@example.org, containing a from header with the value sip:email@example.com. If user A is allowed access to user b's presence information, the server sends it back in various NOTIFY requests. SIP/SIMPLE implements instant messages using MESSAGE requests, with similarly constructed to and from headers.
To function correctly, SIP services require the following SIP servers:
registrar server — Every user of a SIP service must register a SIP address with a SIP registrar server, so it can map the user's SIP address to a physical network location.
proxy server — Using the registrar server mappings, the SIP proxy server routes SIP messages between client applications.
presence server — For SIP/SIMPLE extensions, a SIP presence server collects and collates presence information from SIP users, and makes it available to other authorised SIP users.
SIP with JAIN SLEE
Many options are available for implementing SIP services, including the use of a Service Logic Execution Environment (SLEE). JAIN SLEE, the Java SLEE standard, provides a specification for an event-driven container targeted at communication applications. The JAIN SLEE specification was written for applications to be developed once, and then deployed into any JAIN SLEE compliant container.
The JAIN SLEE architecture considers entities external to the SLEE (such as network elements, protocol stacks, and databases) as resources. The SLEE accepts available resources through the use of resource adaptors (RAs). RAs adapt the various interfaces and requirements of a resource to the interfaces and requirements of SLEE and the services running in the SLEE. The interaction between a resource and the SLEE produces a stream of events. For example, SIP messages in the illustration above (such as SUBSCRIBE, NOTIFY and 200 OK) represent events. Software components process events. For example, service building blocks (SBBs) are stateful software components that process events, encapsulate business logic, and can be composed together to form complex services.
Learning about JAIN SLEE and SIP
To develop a SIP presence server, our test developer first had to build a working knowledge of both JAIN SLEE and SIP. To do this, he studied training materials and other information about JAIN SLEE from a number of websites
, and reviewed, as a primary resource, the JAIN SLEE specification itself
He also reviewed online information about SIP and its various implementations
, including a number of relevant IETF RFCs
, and the SIP examples provided with the Rhino SDK
Taking advantage of the Rhino SDK The Rhino SDK includes a suite of sample SIP applications, including a SIP resource adaptor (which provides the interface between the SIP stack and the application server), and a registrar, proxy, and location service. This significantly eased our test development process, as all those components could potentially be reused in developing a presence service.
While the learning process continued throughout the development process, the initial learning phase required only about a month for the developer to achieve the requisite knowledge to make the required design decisions. This phase was split about evenly between learning SIP and JAIN SLEE.
Designing the SIP presence service
The event-driven programming model specified by JAIN SLEE lends itself particularly well to the development of a SIP presence service. At the most basic level, a presence service must be able to:
accept and process subscriptions to the presence information of a presentity
provide that presence information to subscribers
process changes in the presence state of subscribed presentities
convey those changes in presence state to subscribers.
Both the receiving of subscriptions and presence-state change notifications, and the sending of update notifications to interested parties, model well as events.
PresenceSbb with the registrar and location services
Since service building blocks (SBBs) are the basic JAIN SLEE software component for accepting, processing, and firing events, our developer first decided to implement the presence service with a single SBB, the PresenceSbb. He then realized that not all of the functions described above had to be performed single-handedly by that one SBB. In particular, as suggested by RFC 3856, information collected by the SIP registrar could be used to deduce presence information for registered presentities:
The registrar knows which SIP entities are registered and therefore online — any presentities not registered can safely be considered offline.
The registrar stores this information using the location service.
The location service SBB can be included in a composition relationship (using the JAIN SLEE component model), to give the PresenceSbb access to information about which presentities are registered as being online.
The PresenceSbb then:
handles a SIP SUBSCRIBE request as an initial event
creates a subscription for the requesting SIP entity ("client"), for the requested presentity's presence information
immediately checks with the location service as to whether or not the requested presentity is already online
notifies the client with the appropriate SIP NOTIFY request.
The SLEE instantiates a new SBB object for each new SUBSCRIBE request that it receives, so that a single SBB handles each subscription.
Our developer decided to modify the registrar so that it could fire a custom event to the PresenceSbb upon receiving a registration change request from a SIP entity. The registrar would then notify the PresenceSbb of any changes, so it could send notifications to any clients subscribed to a particular SIP presentity's presence information.
Presentities can also use a further SIP request, the PUBLISH message, to notify the presence service of a change in their presence information. This can be useful with detailed presence information, such as states beyond a simple "online" or "offline" (such as "on the phone"). This study only required a presentity's online or offline status, retrieved from the location service — but implementing further functionality to handle NOTIFY requests would not be difficult.
More complex features: ACIs and the naming service
The architecture of our developer's basic design leveraged several specific aspects of the JAIN SLEE model, to let the presence service elegantly handle more complicated situations such as receiving multiple subscriptions for a particular presentity. The model defines a SUBSCRIBE request as the initial event for the PresenceSbb, and instantiates a new PresenceSbb object for each SUBSCRIBE request that the SLEE receives. To handle the likely potential of more than one PresenceSbb being interested in the presence information of a particular presentity, our developer used Activity Context Interfaces (ACIs).
The JAIN SLEE specification states that all events must be fired on an ACI. If an SBB is interested in receiving an event, it must attach to an ACI; the SLEE then successfully delivers that event to the SBB. More than one SBB can attach to an ACI. JAIN SLEE also lets you name specific ACIs, with references stored by a naming service. When the PresenceSbb then receives a subscription request for a presentity (identified by its SIP address, such as "sip:firstname.lastname@example.org"), it:
checks the naming service for an appropriately named ACI
if it finds one, it binds to it
creates a new ACI
binds to it
gives it an appropriate name
binds it to the naming service (making it available to future PresenceSbb objects that may wish to bind to it).
When the registrar receives a registration change request, it also checks the naming service for an ACI that corresponds to the SIP entity that requested the change. If it finds one, the registrar then fires a custom event on that ACI, detailing the presence state change. Since only PresenceSbbs attached to that ACI can be interested in the presence information for that SIP entity, the service delivers presence state-change information to exactly the interested PresenceSbb entities. Once each individual PresenceSbb has received the event, the service processes it and (where applicable) sends a NOTIFY request to the client application.
Adapting Rhino SDK components for IMs After finalising development of the PresenceSbb, our developer turned his attention to developing instant messaging capabilities. With the exception of Windows Messenger, it was merely a matter of correctly proxying MESSAGE requests to the appropriate destinations.
Evaluating the results
We answered the questions that prompted this study ("Does JAIN SLEE fulfill its aim of simplifying telecommunications development?", and specifically, "How quickly can a JEE developer learn to build SIP applications with JAIN SLEE?"), by evaluating:
Table 1. Breakdown of time spent on development tasks
Initially learn JSLEE and SIP
Development of Presence Service
Debugging Presence Service
Developing Test Suite
2.5 weeks (21%)
3.5 weeks (29%)
2 weeks (16%)
1 week (8%)
3 weeks (25%)
In all, it took two months after the initial one-month learning phase to complete development of the presence service. Part of this time, however, included continued learning about both JAIN SLEE and SIP development (mostly SIP development).
It is interesting to note from the breakdown of time spent on the various tasks involved in the development process (summarised in Table 1) that one of the key challenges the developer faced was debugging the client applications we chose for the study. The publishers of all three reference applications claimed to implement SIP, but their level of compliance varied significantly. This process of . It is also interesting to note that while JAIN SLEE and SIP initially required a similar amount of learning to use, the of the development process.
Did it work? ( As well as it could )
Table 2. Functional results of interaction between presence service and reference applications
Linux, Windows XP
Our developer encountered further challenges in dealing with the SIP clients used as reference applications. Both Linphone and Pidgin proved to implement only certain areas of the SIP/SIMPLE specification:
Linphone, while accepting the NOTIFY requests sent to it, did not recognise the presence information included in those requests, and would not update its buddies list accordingly.
Pidgin does not recognise subscription expiry times sent to it by the server in response to initial SUBSCRIBE requests; it does however accept the presence information sent to it in NOTIFY requests, and updates its buddy list accordingly.
Both clients implemented MESSAGE requests in accordance with the SIP/SIMPLE specification. This part of the development process required negligible time, as the proxy already handled this functionality.
Windows Messenger worked well and was stable with respect to presence information and the processing of notifications, but proved to be more challenging with respect to instant messaging. Windows Messenger appears to only accept instant message communications from clients that have been authenticated with the server (by either Kerberos or NTLM authentication), and rejects all other instant messages. As the presence service does not authenticate clients, Windows Messenger could not possibly use the service to communicate successfully by instant messaging (within the time frame of this study). Determining this cause for this problem with Windows Messenger was also a difficult process, requiring a further week's development time.
Tracking down client-implementation issues
This mixture of compliance added a degree of difficulty to the development process. The developer had to find out where failures were due to either the implementation of PresenceSbb or the client application. This process of tracking down the location of bugs took approximately two weeks of the development process.
How complex was the solution? ( Relatively simple )
The developer created this application with a relatively simple solution: four new Java classes (the PresenceSbb, a custom ACI, a custom event, and a static data class for safe presence information comparisons). The most complex of these by far was the PresenceSbb, which contained approximately 30 methods over some 400 lines of code — not very complex, considering the resulting functionality. Part of the relative simplicity of the solution can be attributed to the successful use of the JAIN SLEE composition and event models, which let the developer leverage several other available components.
How did it fare with unit testing? ( Passed all tests )
The viability of a software component may also be measured through the use of unit testing. The developer created a test suite for the presence service using JUnit. (This required a week's worth of development, as several SIP test suites were already available, with reusable components.) The test suite verified whether the service could correctly handle subscriptions and presence state-change events, checking that it sent the appropriate NOTIFY requests, and that SIP clients could send MESSAGE requests to one another.
Conclusion: JAIN SLEE simple
This paper has presented a study of how easy JAIN SLEE is to build telecommunications applications by posing the question, We tasked a developer — with no previous exposure to either JAIN SLEE or SIP — with developing a presence service using OpenCloud's Rhino application server. What we found is that:
The developer successfully finished the learning and development tasks required to produce a working presence service application in two months:
an initial learning phase of approximately one month, divided equally between learning JAIN SLEE and SIP programming environments
an initial development phase of approximately one month (a significant component of which was learning more about both SIP and JAIN SLEE, especially the finer details of the SIP specification required for a functional SIP application).
The developer spent an additional month debugging and testing the application due to:
the varying levels of SIP compliance implemented by the reference clients
difficulties encountered determining which bugs were due to the clients and which were due to the implementation of the presence service.
The resulting application performed successfully on both functional tests with a number of reference client SIP applications, and a suite of JUnit tests.
Considering the relatively short time of development, and the success of the resulting application, we can conclude that developing applications with JAIN SLEE is indeed simple!
We were so happy with the resulting application, we decided to bundle it with the [Rhino SDK] as an example application!