In simple terms, a portable application is one that can run on multiple platforms. Practically speaking, we can define an application as portable (or "exhibiting portability") across a class of environments to the degree that the cost to adapt the application to a new environment is less than the cost of redevelopment.
An application is portable across a class of environments to the degree that the effort required to transport and adapt it to a new environment in the class is less than the effort of redevelopment
A program is portable if and to the degree that the cost of porting is less than the cost of redevelopment. A software unit would be perfectly portable if it could be ported at zero cost; this is never possible in practice. Instead, we characterize software by its degree of portability, which is a function of the porting and development costs, with respect to a specific target environment
Portability is generally considered a positive feature for applications that may require different implementations in future
. Developers often claim that the software they write is portable. What they usually mean is that little effort is needed to port it to a new environment. In reality, the amount of effort will depend on:
how the original environment (the source platform) differs from the new environment (the target platform)
whether the original authors' knew and accounted for platform constructs that may not be portable
whether the authors knew and invested in using only portable constructs
Why is portability important?
Generally speaking, if future implementations are at all likely, portable applications:
cost less — development and maintenance (and redevelopment) is streamlined through the use of shared, core components
are more reliable — using robust, well-tested features
migrate quicker and easier — if truly portable, adapt to other platforms seamlessly
are less risky — roll out network-wide using proven business models
are potentially more profitable — facilitate developing revenue streams from rich applications spanning networks.
Portability and telecommunications In the context of telecommunications, portable applications maximise operator flexibility and responsiveness.
Why isn't portability more common?
click to enlarge
Unfortunately the status quo in today's telecommunications industry is to deliver applications through "stovepipes".
As shown in the illustration, for most installations there is little convergence between separate, vertically integrated, application-specific networks (other than in the transport of the networks through the sharing of main trunks). At the application layer, there are almost no shared applications, specifically because each network has its own vendor-proprietary applications platform.
While some vendor-proprietary platforms support standard signalling protocols, they do so using vendor-proprietary extensions. Many operators have become reliant on such vertically oriented architectures and vendor-proprietary platforms and protocols. (And the vendors promote that reliance, because it "locks in" future revenue.)
Reluctance to change For the operator who has acquired disparate networks, the cost of rolling out new network-wide applications may seem daunting
. And platform-specific constructs may seem a cheaper solution (at least in the short run). Many operators are used to working with these stovepipes, may be reluctant to change, and suspicious of the very idea of portable applications — some are sceptical that it's even possible!
...in an increasingly horizontal world
(For example innovations such as the IP Multimedia System (IMS), with horizontal architectures and application platforms from many vendors, are becoming the norm.)
Standards and best practices needed
Much resistance to developing portable applications in the telecommunications industry might vanish with the adoption of an international standard, to:
specify details of the computing environment in a way that minimises differences between platforms
allow porting software between platforms by simply running the program on the new platform!
Exploring support for developing portable applications Following a discussion of the general issues around developing portable applications, this paper will discuss the JAIN SLEE standard for developing portable telecommunications applications, and move on to a process for developing applications that are transparently portable, using JAIN SLEE.
Portable development principles
Below are some general principles for developing portable applications (plus a few references to how they relate to the JAIN SLEE standard, detailed later in this paper).
Focus on the interfaces
Portability is an issue where environments differ — at the interfaces (between and within systems).
Methods to address portability issues at an interface
click to enlarge
Strategies: standardise, port across, translate
You can use three principal techniques to overcome portability problems at an interface:
adopt standards — make sure the source and target environments support common standards
port the "other side" — port the entity on the other side of the interface, adapting features in the application to work on multiple interfaces (this may increase the scope of what needs porting, until you find interfaces where substitutability is viable)
translate interfaces — add a software layer to translate interface elements of the target environment into a form that the software being ported expects.
Consider portability throughout the software-development lifecycle
Secondly, it is important to be conscious at all times of portability as a goal. Most portability barriers can be avoided by proper awareness of portability during the software development process
. Portability can be described as a "supplementary requirement" — it is a non-functional requirement that cannot be associated with any particular use-case
. Below is a summary of the impact of portability on each stage of the software-development process.
At the outset, consider portability as an important goal, to balance against other project goals, to avoid unnecessary portability barriers. Consider the intended lifecycle of the product, including where portability may be an explicit goal. Acknowledge that portable design, if an explicit goal, may incur up-front costs, and identify what costs are acceptable.
A principle objective of JAIN SLEE is to support the development of portable applications, thereby minimising the need for additional investment to achieve portability.
Identify a development methodology that facilitates portability. Partition the problem and solution. Identify standards to be followed.
(These choices can strongly enhance or obstruct portability!) A good methodology should encourage partitioning of the design in a way that can isolate significant external interfaces to a small number of modules. The best development approaches are object-oriented or component-based, as these represent current software engineering best practice.
JAIN SLEE is ideally suited to an object-oriented and component-based methodology. It also facilitates building new SLEE applications by re-using components from previous SLEE applications, and developing application frameworks and company-wide re-use programs.
Apply systematic attention and discipline to portability during implementation. Carefully study and strictly follow the standards identified during design.
Conduct application testing as a vital activity throughout the development lifecycle. A good test plan is always a justifiable cost, including any moderate increases to test for portability. In the long run, it can save money — faults found early in common code are not likely to recur in ported versions, reducing need for debugging. Design the test plan to be reused whenever necessary, to support regression testing after modifications — especially for portable software, where ports to new environments must be retested.
Maintain core components to simultaneously fix or upgrade multiple versions of portable applications. If a single organization is responsible for maintenance, and multiple ported implementations are based on common-source code modules, most bug fixes and feature upgrades can be performed only once (instead of requiring separate projects to modify each version). Moreover, common changes can be propagated rapidly to the appropriate implementations, and tested using a common test plan. Also common documentation may be developed to describe multiple versions of the application.
Portability can provide major cost savings during maintenance (which is typically 60-70% of software-development costs). Fixing errors in portable applications is easier, quicker, and cheaper.
Creating a standard for portable development: JAIN SLEE
In 1998 SUN Microsystems launched the JAIN programme, with the aim of leveraging the operating system independence of the Java platform, to achieve application portability and network independence:
SUN is continuing its push to render Java the platform of choice for next-generation telecom applications via its JAIN initiative. The Java Advanced Intelligent Networks (JAIN) initiative was announced by Sun last year with an eye towards replacing the massive legacy systems commonly used by telco providers with more flexible platforms running Java-based applications
The meaning of JAIN Soon after its inception, the project agreed to change the meaning of JAIN to "Java APIs for Integrated Networks", to reflect its widening scope.
Portable JAIN in action
JAIN at Supercom 2000
click to enlarge
JAIN at Supercom 1998
click to enlarge
At Supercomm 1998, SUN and three SS7 protocol stack vendors demonstrated a set of applications running transparently over three different SS7 protocol stacks without alteration
. This event generated significant interest in the telecommunications industry.
At Supercomm 2000, Telcordia showcased an application working transparently over three different vendor platforms. This was excellent progress and proved the efficacy of the Java approach. It only addressed a subset of requirements, and was a gateway model (similar to Parlay), with a defined API. However, it did not consider a standard application architecture or deal with common application features such as alarms, tracing, and timers. The JAIN SLEE standard however does (see below) !
The JAIN SLEE standard
The culmination of the JAIN programme is the JAIN SLEE standard, which defines the features and requirements — APIs and semantics — for a telecommunications application server (AS)
. One of the key objectives of this standard is application portability. That is, .
An international standard JAIN SLEE provides the core features common to most telecommunications applications. It's an international standard, developed through Java Community Process.
How JAIN SLEE promotes portability
Portability is one of the major factors that influenced the design of JAIN SLEE
. This is clear from its common core features (see below).
Objectives of JAIN SLEE
click to enlarge
Common core features for telecommunications
A JAIN SLEE server provides a high-level, operating system-independent environment, with core facilities that telecommunications applications need. For example, the SLEE will generate traces and alarms, manage connections to external systems, and compile application-usage statistics. Instead, developers can concentrate on features unique to their application, and quickly develop robust applications, using and extending the comprehensively tested and deployed common core from JAIN SLEE. (JAIN SLEE applications may be thought of as "extensions" of the SLEE.)
JAIN SLEE architecture
click to enlarge
Subsystems for management, framework, and components
The JAIN SLEE architecture includes subsystems for:
Management — defines a standard operations-and-maintenance interface using Java for Management Extensions (JMX), for tasks such as application deployment, tracing, statistics, and provisioning.
SLEE Framework — defines the interface between JAIN SLEE applications and the JAIN SLEE container. The JAIN SLEE specification carefully defines the Java APIs (and semantics of those APIs) so all JAIN SLEE vendors can provide functionally and semantically equivalent JAIN SLEE implementations.
Components — defines a model that developers use to build applications. D'Souza succinctly defines components as, "reusable parts that can be adapted, but not modified," noting that they "range from compiled code without program source to parts of models and designs"
. Component types that the JAIN SLEE programming model defines include:
Service Building Block (SBB) — provides the basic component of a JAIN SLEE application (which are composed of one or more SBBs)
Profile — defines an interface to provisioned data (such as per-subscriber or configuration data), with an application run-time view and an operations and management view (through JMX)
Resource Adaptor Type — defines the interface to a class of external systems
Resource Adaptor (RA) — implements a resource adaptor type, and realises the integration with a particular external system (for example, you might implement a resource adaptor type for the CAP protocol with an RA that uses the Ulticom Signalware SS7 protocol stack).
The JAIN SLEE standard specifies how to implement, package, configure and manage these components.
External Resources and Resource APIs — defines the extensibility architecture for JAIN SLEE. This presents a standard way of integrating external systems and resources into the SLEE, for use by applications.
Supporting strategies to develop portability
Key strategies for cost-effectively developing portable applications include: Modularity — structuring an application to permit isolating environment-specific pieces into separate modules, for example using software-engineering best practices such as object-oriented and component-based development Focus on interfaces — identifying and managing the points where differences typically occur between environments, and adopting international standards to effectively reduce the number of interfaces Managing multiple implementations — employing techniques for managing multiple ported versions of the same application running in different environments.
The JAIN SLEE standard explicity supports these strategies with the following key features:
Java — JAIN SLEE is a Java standard, so it includes all the benefits of the Java programming language (including those related to portable-application development).
common facilities and common runtime — JAIN SLEE defines the entire application runtime environment, including state management, transactions, event routing and facilities such as tracing and usage. Applications can be developed quickly and robustly by extending the already extensively tested and deployed JAIN SLEE .common core.
component-based programming model — JAIN SLEE adopts software-engineering best practice with a component-based and object-oriented programming model. JAIN SLEE applications are built as collections of Service Building Blocks (SBBs). This approach lends itself re-using and developing programs for re-using SBBs.
versioning — Every JAIN SLEE component is uniquely identified by an associated name, vendor and version. JAIN SLEE allows multiple versions of the same component to be deployed and active at the same time, and also provides standard management operations that support hot patching. (Versioning support is especially important in the maintenance phase of the software lifecycle, as it simplifies the task of managing multiple versions of a ported application.
resource adaptor architecture — JAIN SLEE is defined to be extensible (as well as modular). It recognises the plethora of external systems/nodes in telecommunications networks, and of signaling and messaging protocols, now and in the future.
JAIN SLEE versus proprietary solutions
The following tables highlight the benefits of JAIN SLEE over other, proprietary application server platforms, for building portable applications. They illustrate that achieving application portability becomes simple, as long as:
SLEE vendors comply with the SLEE standard, and do not provide needless proprietary extensions to JAIN SLEE.
SLEE application developers follow the JAIN SLEE standard closely, and only use SLEE features (and not proprietary extensions provided by SLEE vendors).
What do you need to build a service?
Facilities (alarms, usage, ...)
JAIN SLEE services are all built the same way!
What do you need to integrate with external resources?
Integration: service view
Integration: platform view
By the Industry
By the Industry
Integration with external resources is done the same way!
Scope of the JAIN SLEE specification
click to enlarge
Portable applications with JAIN SLEE
Below are summaries of how JAIN SLEE 1.0 and 1.1 were designed for portable applications.
Portable applications with JAIN SLEE 1.0
click to enlarge
Portable applications with JAIN SLEE 1.0
A key objective of JAIN SLEE 1.0 was to support the development of portable applications. This includes a focus on applications, as well as definitions of the interface between an application and the JAIN SLEE (the JAIN SLEE API), and between an application and external systems (resource adaptor types).
About resource adaptor types
A resource adaptor type, as introduced with JAIN SLEE 1.0, is a component that defines the interface (as a Java API) that JAIN SLEE applications use to access an external resource. This interface consists of a set of event types, activity types and other components that define the boundary between applications and an external system that conforms to such an interface. For example, a resource adaptor type may be defined for the CAP signalling protocol or the SIP signalling protocol. This component is only a definition of the interface itself, and not an implementation. JAIN SLEE applications only depend on the JAIN SLEE API and the resource adaptor types that it references (note the arrows in the illustration). SLEE applications never depend on a resource adaptor implementation.
This is a powerful application of object-oriented technique of polymorphism, as the resource adaptor type may be implemented in many different ways, by different vendors. The as the application only depends on the resource adaptor type. JAIN SLEE 1.0 also defines all the runtime interfaces that a JAIN SLEE application requires. Overall, everything needed to build portable applications is provided with JAIN SLEE 1.0.
Portable applications with JAIN SLEE 1.1
click to enlarge
Portable resource adaptors with JAIN SLEE 1.1
JAIN SLEE 1.1 enhances JAIN SLEE 1.0 in many ways. The most significant extension, from the perspective of portability, is to define the interface between a JAIN SLEE and resource adaptor implementations. By doing so, JAIN SLEE 1.1 supports portable resource adaptor implementations as well as portable applications.
This means that not only are JAIN SLEE based applications portable, but so are all the dependent resource adaptor implementations. An application developed on JAIN SLEE A that made use of resource adaptor types and resource adaptor mplementations only provided with JAIN SLEE A, could be simply ported to JAIN SLEE B by also running the dependent resource adaptor types and resource adaptor implementation in JAIN SLEE B (so ).
Testing JAIN SLEE portability claims: a real-world example
The following excerpt from a press release describes a real-world example of JAIN SLEE portability in action: an SS7-based application that Vodafone Spain ran live on two platforms with no modifications nor application access to source code, using the same service binary.
Vodafone Spain Proves Software Portability for Programmable Network Services
Wireless Carrier Proves a Major Benefit of JAINSLEE Technology by Demonstrating Binary Software Portability Across Vendor Platforms
Madrid, Spain, 5 July, 2005 - While the telecommunications industry readies for the deployment of truly programmable network services that provides service portability in both IN and 3G/IMS, Vodafone Spain has already successfully used JAIN SLEE (Java) technology to deploy and run a real life commercial IN service on two different vendors platforms.
The service, which is live in the Vodafone Spain network, is an enhancement to a typical IN voice service. This service requires support for MAP, CAP and INAP SS7 protocols and is integrated into the Vodafone Spain 2G and 3G networks. Vodafone Spain successfully deployed and ran this service on the jNetX and OpenCloud platforms, both of which have passed and registered JAIN SLEE 1.0 compliance.
Jorge Gató, Head of Design and Engineering of Vodafone Spain, said: "Wherever possible, Vodafone Spain is committed to adopting standards-based technology and moving away from proprietary systems. Proprietary systems drive up the cost of deploying services and significantly prolong time to market. This portability project is a major step for the telecommunications industry, demonstrating that the binary code of a telecommunications application could run unchanged on two different vendors platforms."
Best practices for developing portable applications
Why do you need a process? The JAIN SLEE standard provides an application developer with a lot of tools to facilitate the development of high-quality, portable applications. But . Essentially, JAIN SLEE provides the right tools, but cannot, by itself, ensure those tools are used appropriately.
Clearly, the software-development process must be expanded to include portability standards. By making portability a key requirement during the development process, standard software-development practices should enforce portability. The missing piece of the puzzle is that as a part of the acceptance and quality-assurance process:
An application must be verified on each platform, regardless of whether it is portable software or platform-specific software. If the same application is being run on many different platforms, it may be possible to reduce the verification effort for the follow-on platforms, because the confidence in both the software itself and its portability increases as it is verified on additional platforms. Thus the choice to make as much software portable as possible is a decision to invest more effort in the first implementation phase in order to secure savings as the software is ported to different platforms.
Testing portability as a part of acceptance and QA processes
We propose a three-step process to test the degree of portability of a JAIN SLEE application:
Test the application with the JAIN SLEE 1.1 RI — The JAIN SLEE standard consists of three parts: the specification document, the reference implementation (RI), and the technology compatibility test kit. The RI is a proof-of-concept JAIN SLEE implementation (that is, a real SLEE!). Whilst the JAIN SLEE RI is not suitable for testing performance, it is suitable for functional testing. This approach will quickly uncover any unintentional use of proprietary features of a specific platform.
Conduct a test-suite audit — The test suites that accompany an application should be treated as an asset that is just as valuable as the application itself. A comprehensive test suite and test plan is very important for an application that has portability as a key goal. The test suite should be reviewed to ensure it is of sufficient scope to test the application running in a JAIN SLEE other than that used to develop the application.
Conduct an application audit — A JAIN SLEE application binary consists of a set of JAIN SLEE deployable units (Java jars of a format defined by the JAIN SLEE specification). The audit process should be executed on the application deployable units, considering the following:
— Applications should only use the SLEE facilities, and most importantly, not build their own versions of SLEE-provided facilities. JAIN SLEE defines O&M interfaces for managing SLEE facilities, so not using them means more effort and expense in managing the application. (Also, substituting for JAIN SLEE features spawns applications that are effectively more complex than need be!)
— An application that grants itself permission to create threads, access classloaders, or write to the file system (for example) cannot be guaranteed to work in all JAIN SLEE implementations. These are clear danger signals and very likely mean an application is non-portable, or that the cost of porting the application is higher than necessary.
— Portable JAIN SLEE applications should use Container Managed Persistence (CMP) fields to store application state. CMP fields are transacted; the SLEE owns and controls state stored in CMP fields. CMP is an important part of the JAIN SLEE programming model, for reliability and resilience. The JAIN SLEE standard clearly and carefully defines the semantics of CMP fields and explicitly warns that not using them can lead to non-portable applications. You can verify CMP fields used by reviewing the application deployment descriptors. An absence or, or unexpectedly few, CMP fields may be a sign that a state-representation strategy other than CMP is being used. This can be a significant barrier to portability.
— JAIN SLEE defines a mechanism that applications may use to define their application-specific statistics (the usage interface). An application should define and use a usage interface, rather than doing something in a bespoke or proprietary way (or rely on any platform-specific statistics feature).
— JAIN SLEE specifies how to define, adjust and configure the run-time environment of an application at deployment time. The application should use environment entries defined in its deployment descriptor (as per the SLEE specification) and JAIN SLEE profile components. Applications that use other methods (such as reading properties files) are not only insecure, but are making assumptions about the file system that are not appropriate. These are danger signals that might mean an application is non-portable or that the cost of porting the application is higher than necessary.
Conclusions: follow the standard and best practices
Portable applications are less expensive, faster to implement, and more robust. JAIN SLEE was designed for portable development — (and don't, for example, provide or use needless proprietary extensions to JAIN SLEE). This is not because something is lacking or missing in JAIN SLEE, but rather because JAIN SLEE is a technical standard that is only meant to define the runtime environment to be supplied by JAIN SLEE servers for JAIN SLEE based applications. (To make an analogy, it is similar to the Unified Modeling Language in that the UML only defines a language or vocabulary used to describe object-oriented systems, but does not define a process that can be followed to design and build such systems.)
A recommended three-step testing process — using the JAIN SLEE 1.1 RI, auditing the application test suite, and auditing the application — verifies the true portability of JAIN SLEE applications.
Portability made easy By following the JAIN SLEE standard, and augmenting the software-development process to leverage the benefits of portable application development with JAIN SLEE, you can create applications that run seamlessly in multiple environments.
Systemnews.com, SUN Microsystems Launches Drive To Bring Benefits Of Java Software To Telecom Intelligent Network Blending Intelligent Networks And Internet Technologies: SS7 Stack Providers ADC NewNet, DGM&S and Ericsson InfoTech Endorse Sun's Java Advanced Intelligent Network Technology Program, 1998, http://sun.systemnews.com/fullsource?article=1137, October 2007
Vodafone Spain, Vodafone Spain Proves Software Portability for Programmable Network Services — Wireless Carrier Proves a Major Benefit of JAIN(TM) SLEE Technology By Demonstrating Binary Software Portability Across Vendor Platforms, July 2005, http://www.prnewswire.co.uk/cgi/news/release?id=149657, September, 2008