|
 |
 |
A Look Under the Hood at JAVA and XML
Why Application Engines Matter to Prepaid Services
By Ken Osowski |
Over the last six months, we’ve looked at some of the prepaid telecom market’s major opportunities, threats, innovative potential business models and network options. We’ve reviewed VoIP’s emergence as a platform of choice. This column looks ‘inside the wheelhouse’ of IP telephony, comparing the two dominant IP service platform approaches – XML and JAVA – and how their relative strengths & weaknesses can affect Prepaid Service Providers.
A brief look at some basics:
Each of these two core IP technologies has a Service Logic Execution Engine (SLEE) that defines how a SIP-based (Session Initiation Protocol) application - in this case prepaid calling - executes a call flow on an application server. The two major platform choices differ greatly in their implementations.
The first approach was developed specifically to execute real-time telecom services, such as voice, with a SLEE based on XML (eXtensible Markup Language) scripts. XML is usually extended with a schema of defined functions to build in telephony specific functions used in call control. The two superset XML dialects that have emerged for this purpose are XTML (eXtensible Telephony Markup Language) and CCXML (Call Control eXtensible Markup Language). For the sake of this article we will use the term XML to refer to the telephony specific functions XTML and CCXML. Both dialects are, in fact, a way to represent the call flow diagram of which we have grown accustomed. They define the order and groupings of the various call functions that occur as calls are processed. These scripts can be unique to the individual service provider, based on how they configure IVR functions and various features of their services. The SLEE executes these processes and accesses various resources as a call is processed: IVR response, authentication, prepaid-balance checking, execution of the outbound call, etc. XML scripts are like player piano scrolls: once the process starts, it continues down set pathways depending on IVR responses and data driven call paths determined by authentication, account balances etc. XML scripts don’t continually force the network infrastructure to stop or slow down in order to process various call functions. XML call processing proactively avoids ongoing processor interruptions that could otherwise kill or corrupt real time voice services, disenfranchise users and threaten the PSP’s network stability and customer retention.
XML scripts are constructed from a reusable set of pre-defined, preassembled call and resource functions, and these service applications can be created relatively easily within a telecom graphical development environment, commonly called a Service Creation Environment (SCE). The SCE is essentially a rich palette of ‘drag & drop’ building blocks of various call functions. Leading SCEs also automatically embed into applications created. Within them are some critical capabilities and management features to ensure call reliability and enable massive scale, such as n+1 server clustering, failover logic, protocol details and SIP policies. In addition to protecting call states and scalability, these embedded capabilities appreciably speed and simplify the process of creating new service applications, and allow PSPs to build differentiating services whether or not they possess advanced programming skills and protocol expertise.
The other main approach to creating telecom services uses JAVA and SIP Servlets. JAVA is the ubiquitous data application environment that is the virtual foundation of the Web as we now know it. In this approach, unique vendor-built applications are written with a JAVA editor, and a JAVA SLEE continuously processes calls, accessing various resources and executing functions on a JAVA application server supporting a SIP Servlet virtual machine for access to SIP protocol functions. JAVA has some clear advantages, the most compelling of which are its ease of integration with Web services, and the relative abundance of IT programmers and developers who’ve worked with JAVA to create data applications.
On the down side, this approach does not embrace reusable functions, features or objects, nor are calls processed as a deterministic single-dip processor event to preserve network processor capacity and stability. Instead, requests are handled, responses are sent and call processing functions are executed by a series of unique application function calls referred to as SIP Servlets. Additionally, each developer also creates their own JAVA code to manage call states and provide data persistence for call recovery schemes, etc.
Another drawback is that this is a processing-heavy approach: as previously noted, JAVA applications draw on the CPU and local memory resources continually rather than once per processed subscriber call. Moreover, JAVA was first created for data delivery, not real time service delivery. JAVA telephony service applications involve a few more steps than XML ones, and so are inherently vulnerable to slightly slower execution than XML ones.
However, the real problem with JAVA/SIP Servlet-based telecom services is another, more disruptive type of built-in delay, a complex set of problems collectively known as Garbage Collection. Garbage is created when multiple application threads – i.e., calls in process – leave behind a series of memory artifacts as various call processing functions are performed. These vestigial artifacts, for example local memory that remains for the SIP Servlet virtual machine, and assigned and local variables that remain allocated after a portion of a call process is performed, can tie up and collectively congest the CPU.
Every so often (which can be several times a minute), all processing must stop so that the CPU can sweep its reserved main memory areas clean, processing and restoring affected bits of memory. Think of it this way: when the garbage truck blocks the road, no one gets by. In other words, all application threads stop until garbage collection’s completed. And if the process of garbage collection is interrupted, it has to start all over again. This degrades the stability and scale of both real time applications such as voice call processing as well as near-real time processes, such as processing large numbers of transactions. The adverse affects of garbage collection are directly proportional to the amount of calls and transactions – i.e., the scale – of a PSP’s business. The process of collecting garbage has been continually updated and streamlined, but for the foreseeable future will remain inherently disruptive.
Unfortunately, call and transaction processing are the PSP’s bread & butter. Despite the comparative simplicity involved in integrating new Web 2.0 features (at least in the near term) and the greater availability of JAVA data programmers, JAVA vs. XML is not an automatic or easy decision.
So which approach should you choose?
Many believe that the answer to making SIP simpler for the programmer and inherently more reliable for the service provider and subscriber requires the use of an object layer and SCE, rather than SIP Servlets which place the full burdens of reliability and recovery on programmers. Moreover, the Garbage Collection issue continues to be an open question dealt with by platform vendors as best they can, but more likely are dealt with as a PSP’s business model and forecast start to scale significantly. As always, arriving at the right answer requires that you start by defining some of your primary goals, and understanding the advantages and drawbacks of these two approaches.
Ken Osowski is the VP of Marketing & Product Management at Pactolus Communications Software. He can be reached at Keno@pactolus.com.
 |
|
.gif)
