The

SCF: A Framework for Application Enablement

Service Composition
Kristin F. Kocan, Kevin W. McKiou, Ninoo R. Pandya,
Jorge Hernandez-Herrero, and F. Theodore Freuler
Communication service provider ambitions to protably leverage their
network capabilities, provide novel differentiating services, and potentially
even to tap into the talents of global development communities motivates
the idea of a exible service platform and service creation environment.
Optimally, the platform should include a multiplicity of enablers that provide
convenient programming interfaces to network elements and an
environment where those enablers may be woven into composite services.
The Service Composition Framework (SCF) for Alcatel-Lucents Open API
Platform is robust and sophisticated middleware for hosting composite
services. Such services can be created by third parties via an innovative service
creation environment. The SCF is built on a core of open source software,
with the valuable addition of a maintenance infrastructure, and a suite of
services, enablers, policies, and utilities to support new services. This
paper also describes the SCFs run-time hosting of composite services,
their conguration, and their creation using the companion SCE.
2013 Alcatel-Lucent.

Introduction
Communication service providers (CSPs) are
nding themselves in the midst of continuous evolution: evolution of usage patterns, evolution of endpoint technology, evolution of monetization models,
and evolution of services. A dynamic driver for all of
this evolution is the universe of applications that is
continuing to grow rapidly.
CSPs are challenged to increase revenue while
staying competitive in the current environment. While
the number and types of applications are driving up
network usage, at rates for data seem to be needed to
keep CSPs competitive. What is the consequence?

CSPs cannot directly monetize cool, new features as

introducing per-application or per-feature charges violates at rate. Instead, at rates force a situation where
the way to boost revenue is to increase the number of
customers. A key assumption is that value is a principle
means of increasing the number of customers, and,
further, that value can be broken down into various
actionable items, such as:
Handset appearance, features, ease-of-use,
Network speed and quality, and
Applications supported.
Although applications supported will have
dependencies on handsets and network speed/quality,

Bell Labs Technical Journal 18(1), 171193 (2013) 2013 Alcatel-Lucent. DOI: 10.1002/bltj.21598

Panel 1. Abbreviations, Acronyms, and Terms

APIApplication programming interface
BMSBusiness management system
BPMNBusiness Process Modeling Notation
CCITTInternational Telegraph and Telephone
Consultative Committee
CPUCentral processing unit
CSPCommunication service provider
CXFAn open source web services framework
offered by Apache (the CXF term comes from
combining Celtix and XFire, which together
formed the basis of CXF)
DAOData access object
DBDatabase
DNDistinguished name
DRLDrools Rule Language
DSLDomain specic language
FDFront Door
FPCForward progress counter
GPSGlobal Positioning System
GUIGraphical user interface
HTTPHypertext Transfer Protocol
IDEIntegrated development environment
IETFInternet Engineering Task Force
IPInternet Protocol
jBPMJBoss Business Process Management
JMXJava management extensions
JSONJavaScript Object Notation
JVMJava virtual machine
LDAPLightweight Directory Access Protocol
MBeanManaged bean

the prospect of differentiating on handsets and network speed/quality is a difcult one and tends to be
transient (although very effective, as attested by the
AT&T-iPhone* experience [2]). In addition, given
comparable handset offerings and comparable network speed/quality, there will be the same or, at least,
comparable over-the-top applications supported,
making a value differentiation difcult considering
only over-the-top applications.
The focus of this paper is a system for providing
network-resident capabilities enabling networkenriched applications that can be differentiators for a
CSP. This network-resident system is the Service

172

Bell Labs Technical Journal

DOI: 10.1002/bltj

MCRMeasurement counter record

MIBManagement information base
MMSMultimedia messaging service
MOManaged object
OAPOpen API Platform
OAuthOpen Authorization Protocol
OpenJPAOpen Java Persistence API
OSGiOpen Service Gateway initiative
QoSQuality of service
R&AReporting and analytics
RESTRepresentational state transfer
RMIRemote method invocation
SCEService creation environment
SCFService Composition Framework
SIPSession Initiation Protocol
SLAService level agreement
SMPSystem management portal
SMPPShort Message Peer-to-Peer Protocol
SMSShort message service
SMTPSimple Mail Transport Protocol
SNMPSimple Network Management Protocol
SOAService-oriented architecture
SOAPSimple Object Application Protocol
TCPTransmission Control Protocol
TDRTransaction data record
UCDUniversity of California, Davis
UIUser interface
WAPWireless Application Protocol
XMLExtensible Markup Language

Composition Framework (SCF) in Alcatel-Lucents

Open API Platform (OAP) offer.
OAP is not only about offering network-enriched
applications to retain and grow the customer base;
signicantly, it is also about supporting new revenue
streams. A major new revenue stream is generated
by partners from businesses that want to utilize and
even develop such applications for advertising
and other business-promotion activity (e.g., delivering coupons to mobile phones entering a certain geographic area). Another revenue stream is generated
by content providers from businesses that want to
use network control applications to deliver content

more competitively. A third new revenue stream

would be generated by developers who want to
develop differentiating network-enriched applications to be run on the SCF in order to sell them to
CSPs for use by the CSPs themselves or their partners
who use the OAP.

Value of Communication Service Capabilities

and Information
CSPs have a variety of assets that have their own
internal purposes. Coincidently, several of these
assets can be of great value to partners, content providers, and other application developers. These are
discussed below.
Network-Based Messaging
Short message service (SMS) has not only long
been popular, but its popularity has been continuing
to grow. For example, in the United States, the number of text messages, and more importantly, the preference to communicate via text messaging has been
increasing [18]. The ability to reach the multitude of
mobile phone users via SMS messaging has enormous utility to partners. In addition to SMS messaging, the network also can provide access to
multimedia messaging service (MMS) and Wireless
Application Protocol (WAP) service.
Network-Based Location
Questions may arise as to why mobile phone
location information available from the network
would be useful, given the superior Global Positioning
System (GPS) information obtainable by smartphones. Three factors can be considered: one is the
reality that not all mobile phones have or use GPS,
the second is that GPS is usually turned on by the
user of the mobile phone or by a phone-resident
application (web applications interested in location
would not be able to turn on a mobile phones GPS),
and the third is that for always-on location services,
such as geofencing, battery life becomes an issue.
Geofencing, where entering a geographic boundary
opens up location-relevant services is described in [7].
Secure Payment
The concept of utilizing mobile wallet applications equipped to interact with CSP networks via

exposure APIs to provide a secure payment mechanism potentially supports a variety of subscriber
applications, e.g., for unbanked consumers, as
described in [10].
Bandwidth Management
A highly useful capability that supports delivery
of video (e.g., real time television-quality video) and
other high-volume content is the exposure of mechanisms that improve the delivery and distribution of
high-speed trafc. An example would be mechanisms for reserving and using pipes with a guaranteed quality of service (QoS). The opening up of the
network to provide QoS and bandwidth control can
be of signicant benet to a host of content-related
applications. Various technical and business model
aspects of doing so are described in [5].
Subscriber Information
CSPs maintain a considerable amount of information that is subscriber-related. Some CSPs offer
network address and contact storage mechanisms,
which may include presence information.
Equipment information registers include data on
each subscribers device type. This is typically used to
prevent the use of stolen devices, but it can also be
used to enhance applications and services. CSPs also
have records of all subscriber calls and texts. If CSPs
were to develop applications that would benet subscribers by leveraging this information, subscribers
could sign up for such services.
Authorization and Privacy/Opt-In
Though there are various benets for opting-in
to applications, authorization services that provide
privacy protection are needed as well. Both partners
and subscriber applications would be supported by
including such capabilities (e.g., services based on
Open Authorization Protocol (OAuth) as described
in [6]) as a network offering that could be exposed.
Call Control
Messaging, discussed above, allows web applications to send messages to mobile end points. Call
control could also prove valuable to applications
and can be exposed using third-party call control
mechanisms.

DOI: 10.1002/bltj

Bell Labs Technical Journal

173

Web services

Web exposure engine

Web service
originated
request trafc

Service mediation,
normalization, and
composition

Provisioning
interface and
engine
Reporting/analytics
System management

Open API Platform (OAP)

Mobile
originated
trafc

Communication network and other services

APIApplications programming interface

Figure 1.
Open API Platform (OAP) bridging web services and communication/other services.

OAP as a Solution for Leveraging Communication

System Assets
The challenges that must be addressed by any
approach for exposing CSP assets include:
Network interfaces must be protected from general access,
Authorization must be easy, effective, and monetizable, and
Service level agreements must be enforceable.
The OAP system bridges the web application
environment and the communication system environment and provides various suites of functional
capabilities to address these challenges, as shown in
Figure 1.

174

Bell Labs Technical Journal

DOI: 10.1002/bltj

The OAP system exposes network resources

via application programming interfaces (APIs) based
on Hypertext Transfer Protocol (HTTP) requests such
as representational state transfer (REST) or Simple
Object Application Protocol (SOAP) requests. Each
API is created and on-boarded using the OAP Front
Door (FD) mechanism. The FD is used to associate
the API with an OAP application, and also to an associated commercial plan for monetization purposes.
The OAP system not only spans API creation and
on-boardingassociating the API with an application
and a commercial planbut also for conguring and
deploying any new software associated with the
application, and the reporting and analytics when

the API is live and in service. The element in the OAP

system that hosts new application software is the SCF.

Service Normalization, Mediation, and

Composition Concepts in OAP
A core function of the OAP system is to process
real time request trafc owing between external
applications and the CSPs exposed network elements. Considering real time request trafc, three
major sub-functions emerge as important OAP system capabilities: service normalization, service mediation, and service composition.
Service normalization in the OAP refers to taking
multiple interface types (such as seen in a communication network, e.g., for sending messages
and getting location information) and providing
normalized interfaces such as REST or SOAP
interfaces to the web world. Thus it is service
normalization that exposes communication network functions to web applications.
Service mediation in the OAP refers to taking an
incoming request and operating on it (such as
modifying and/or adding policy enforcement to
it). The purpose could be transformation such as
from Extensible Markup Language (XML) to
JavaScript* Object Notation (JSON), or it could be
enforcement of a service level agreement (SLA).
Service composition in the OAP refers to combining
multiple functional elements into a composite
function such as a composite that retrieves a
location and sends the result in a message, or a
composite that looks up group identities and
sends a message to all, or a composite that sends
messages to buddies that come within a certain
geographical area. The creation of a new service
via service composition should be open to thirdparty developers, and this requires a suitable service creation environment (SCE). Alcatel-Lucent
has also built larger, more complex functionality
such as authorization/privacy enforcement and
quality of service control and enforcement as
composite SCF services. Service composition
may also be used for customer-specic modications to basic functionality.

SCF Architecture
We determined that the element in the OAP system providing service normalization, mediation, and
composition should be alterable and congurable,
such that new normalization and mediation variants,
as well as new composite services can be added at
will, without requiring the element to be taken out
of service and/or restarted. This became a guiding
principle in the design of the SCF, which is the element in the OAP system providing these capabilities.
Another guiding principle was that the SCF should
be a true carrier-grade system, with the ability to
monitor, report, control, and bill for services that it
hosts. A third guiding principle is that the SCF should
be developed in such a way as to support highvolume trafc, geo-redundant congurations, and
deployment both in premise-based servers and in
cloud computing. The following sections describe
how the SCF has been architected and designed.
SCF Platform Technology
In order to accommodate on-the-y loading of
new software, as well as easy composition, we chose
to use a service-oriented architecture (SOA)
approach, since SOA concepts of modular and independent software components that can be linked
together t well with the SCF guiding principles.
The options of creating the SCF platform within
Alcatel-Lucent or using a vendor or other thirdparty solution had to be considered. A third-party
solution offered the possibility of reduced time-tomarket. Some attractive third-party solutions were
available externally, and early entry with SCF was
highly desired. However, the guiding principle of
providing a carrier-grade solution was not adequately met by the third-party solutions considered.
Performance, maintenance capabilities, and support
for geo-redundancy were typical inadequacies. We
chose to go with a hybrid of third-party and AlcatelLucent development, using Open Service Gateway
initiative (OSGi*) technology. OSGi technology is a
mature, component-oriented technology that augments a Java* execution environment by providing
the following [16]:

DOI: 10.1002/bltj

Bell Labs Technical Journal

175

Container resources
Apache ODE
OSGi container (single JVM)
Drools
JDBC
Composite
service 1

Composite
service 2

Composite
service n

Camel endpoints

CXF
component

Jetty
component

JMS
component

TDR
enabler

SMS
enabler

Location
enabler

LDAP
enabler

Email
enabler

Payment
enabler

Fuse ESB (Apache ServiceMix)

ServiceMix components
CXFCeltix and XFire
ESBEnterprise service bus
JDBCJava Database Connectivity
JMSJava message service
JVMJava virtual machine

Alcatel-Lucent added components

LDAPLightweight Directory Access Protocol
ODEOrchestration Director Engine
OSGiOpen Service Gateway initiative
SCFService Composition Framework
TDRTransaction data record

Camel, ODE, and ServiceMix are trademarks

of The Apache Software Foundation.
Drools is a registered trademark of Red Hat, Inc.
Java is a trademark of Sun Microsystems, Inc.
JDBC and JVM are trademarks of Oracle America, Inc.
Jetty is a registered trademark of Webtide, LLC.
MySQL is a registered trademark of MySQL AB.
OSGi is a trademark of the OSGi Alliance.

Figure 2.
Use of OSGiFuse/ServiceMix in the SCF.

Class-loading model and policies that support

modularization with controlled linking between
modules,
Support for on-the-y addition and removal,
starting and stopping of software packages,
referred to as bundles. This includes an API for
run-time management of bundles and dependency mechanisms to ensure correct operation,
and
Service registry implementing a model for sharing objects across bundles.
One of the purposes for choosing a third-party
for the OSGi container implementation was to reuse
a rich set of assets useful for composing new services.
The third-party software chosen was Apache ServiceMix* [3]. This software package provides the following:
ActiveMQ*, supporting reliable messaging,
Camel*, supporting routes and including a substantial set of Camel endpoints,
CXF*, a web services framework, and

176

Bell Labs Technical Journal

DOI: 10.1002/bltj

Karaf*, the OSGi runtime container.

ServiceMix would now be extended by a rich set
of Alcatel-Lucent software to complete the SCF element as illustrated in Figure 2. The resulting SCF
structure is shown in Figure 3, where several of the
items illustrated will be discussed in later sections.
We also chose a Linux* operating system, which is
amenable to cloud computing.
The SCF Within the OAP System
As can be seen in Figure 4, there are two elements of OAP that handle real time/operational trafc. The API Management Engine provides access
control, security and transaction logging services for
analytics and billing, in addition to a variety of other
potential functions (e.g., threat protection and quota
management). Consequently, the external Internet
interfaces are provided by the API management
engine, which also accesses protected network interfaces. The objective for this engine is lightweight,

OSGi container/bundles

Utilities

Policies

Camel
FUSE/service mix
endpoints

Loaded at installation
Includes core enablers
(e.g., TDR, and measurements)

JVM

JMX
agent

RMI
registry

JVM

JVM

MySQL
DB

SNMP

Core

Enablers

Loaded from Maven repository

Can be provided by ALU or other
SCE can be used to create
Deployed and congured via
Front Door

Services

Components

Linux (OS), Linux services

ALUAlcatel-Lucent
DBDababase
JMXJava management extensions
JVMJava virtual machine
OSOperating system
OSGiOpen service gateway initiative

RMIRemote method invocation

SCEService Creation Environment
SCFService Composition Framework
SNMPSimple Network Management Protocol
TDRTransaction data record

Camel is a trademark of The

Apache Software Foundation.
JVM is a trademark of
Oracle America, Inc.
Linux is a trademark
of Linus Torvalds.
MySQL is a registered
trademark of MySQL AB.
OSGi is a trademark of
the OSGi Alliance.

Figure 3.
SCF structure.

pass-through functionality. The SCF, on the other

hand, is located in the secure CSP network. Unlike
the API Management Engine, the SCF is not designed
to provide functions such as authorization and
authentication as a core function. The SCF provides
an environment for high-volume processing of real
time trafc where it is desirable to support more
complex functions such as interworking/coordination of southbound network interfaces, service logic,
policy enforcement, transactions with long-term
states, monitoring and control of services, and
recording of transaction legs for monetization and
data collection.
In a typical OAP deployment, there would be
multiple instances of SCF, referred to as SCF nodes,
whether these instances are in individual servers or
in cloud instances. The FD, via its associated backend, provides interfaces to deploy and congure SCF
nodes and the components within each SCF node. It

has functions to associate SCF services with external

partners, applications, and campaigns, and to establish billing rules based on SCF transactions via the
business management system (BMS).
The SCF interacts with the system management
portal (SMP) by exposing a management information base (MIB), as well as by raising alarms when
appropriate, and sending measurement counter
records (MCRs). The SMP includes a correlation
function to correlate alarm data received from the
various elements in the OAP, including the SCF.
The SCF sends transaction data records (TDRs) to the
reporting and analytics (R&A) element. These interactions are described more fully in later sections.
Component Basis of the SCF
The SCF was designed to be component-oriented, where components can be deployed to the
SCF. Each component has a distinguished name

DOI: 10.1002/bltj

Bell Labs Technical Journal

177

Realtime/operational
interfaces

Conguration
interfaces

Reporting/business
interfaces

Monitoring
interfaces

OAP
Front Door (FD)
provisioning/
conguration

System
management
portal (SMP)

API management engine

Service Composition
Framework
(SCF)

Reporting and
analytics (R&A)

Business
management
system (BMS)

Protected network/interfaces
APIApplication programming interface
OAPOpen API Platform

Figure 4.
High-level OAP architecture.

(DN), and its own data, and is congured by the FD.

Components that can be deployed to the SCF are of
specic types, including service and enabler components, which have states and can raise alarms. The
roles of the various SCF component types are shown
in Figure 5, and will be further described in later
sections. From the ServiceMix perspective there is
no distinction of component types, nor is there an
over-arching notion of a service or application.
There are only components. Each component only
knows about its own data, interfaces, states and
relationships.
Each component can be a part of a larger service
which utilizes components of various types and may
have multiple layers of service and enabler components that comprise the service, as shown in Figure 6.
The overall service architecture is beyond the scope
of the SCF. That is why the SMP includes a correlation
engine. The correlation engine is used to keep traigher

178

Bell Labs Technical Journal

DOI: 10.1002/bltj

higher-level constructs such as services and the components involved in a particular service architecture.
The correlation engine can maintain a coherent view
of the service state based on the state of individual
components.
The SCF has enabler components which have
interfaces to southbound protected network interfaces, e.g., Short Message Peer-to-Peer Protocol
(SMPP), or internal resources such as the clustered
database (DB). These enabler components are interworked and connected by service component logic.
Logic for repeated decisions and tasks can also
be encapsulated in a component. Decision logic is
encapsulated in a policy component. Logic for
repeated/common tasks can be encapsulated in a
utility component.
Figure 7 shows the layering of the component
architecture. It is designed to simplify the job of the
component developer. As described above, the

API

Role of service
Expose a REST, Web services,
other HTTP-based or native
TCP-based API
Combine logic, policy, acquired
data
Provide desired result from
composite
Role of enabler
Provide access to external data,
service, or element

Service

TOD, throttling, subscriber

and application policies

Policy

Java libraries

Utility
Enabler 1

Enabler 2

External
data

Communication/other services

APIApplication programming interface SCFService Composition Framework

HTTPHypertext Transfer Protocol
TCPTransmission Control Protocol
RESTRepresentational state transfer
TODTime of day

Trademark

of Sun Microsystems, Inc.

Figure 5.
Role of SCF components.

Real time/operational
interfaces

FD

SCF
Service
component

Service
component

SMP
R&A

Policy
component
Enabler
component
Utility
component
Internal
resource
Utility
component

Policy
component

Enabler
component

Enabler
component

Protected network/interfaces
FDFront Door
R&AReporting and analytics

SCFService Composition Framework

SMPSystem management portal

Figure 6.
Component architecture within the SCF.

DOI: 10.1002/bltj

Bell Labs Technical Journal

179

Service/enabler/policy/utility component code

Conguration

Fault/state
management

Reporting

Deployment/
initialization

Alcatel-Lucent or external
developer software

Alcatel-Lucent proprietary
infrastructure additions

System infrastructure (e.g., ServiceMix)

Trademark

of The Apache Software Foundation.

Figure 7.
Component code and supporting infrastructure in the Service Composition Framework (SCF).

deployment, initialization, and conguration of the

component is handled by SCF infrastructure/core
classes for initialization and data handling. The job of
fault management has been reduced to incrementing a
forward progress counter (FPC) for service components
and calling a success/failure interface in enabler components. Administrative, deployment, and overload states
are handled by core component classes. TDRs and
MCRs are actually constructed and managed by the
core component classes. The component developer
passes the required data to the TDR interface and calls
the MCR interface to increment the appropriate transaction type.
The SCF core delivery includes an Alcatel-Lucent
developed component framework residing in the
ServiceMix Java virtual machine (JVM*) that makes
it easier to develop new services and enablers. It does
so by providing a framework within which new components can be developed. The framework functions
include:
Component management. Supports multiple instances
of a component with only one copy of the installed
component code. It allows creation and deletion
of component instances. Each instance has its
own copy of conguration context data.
Context/conguration data management. Provides
registration and invocation of component context data handlers for context data updates.

180

Bell Labs Technical Journal

DOI: 10.1002/bltj

Common context data schema. Application, campaign, partner, feature and API context data can
be stored in a common database table. This provides a way to congure context data accessible
by any SCF component.
Component control interface. This provides a common API accessible from the JMX agent to install/
uninstall a components OSGi bundles in
ServiceMix to create/delete a component instance.
Camel route conguration. Builds Camel routes
when context data is updated.
Base classes. SCF component infrastructure classes
can be inherited to create service, enabler, policy
and utility component instances.
Fault management framework. Contains infrastructure classes that components can use to raise/
clear alarms and send informational notications
(non-alarm related free text).
Data access classes. SCF infrastructure classes provide component access to data in the MySQL*
[15] cluster database.
Graphical composition support. Supports jBoss
Business Process Management (jBPM*) work
item handlers (described in a later section).
Service components. As indicated in Figure 5 and
Figure 6, service components present a northbound
interface for real time transactions. These northbound interfaces may be any Internet Protocol (IP)

based protocol, but are usually REST or SOAP

message interfaces. Service components range from
simple pass-through services (e.g., send an SMS message) to complicated services that access internal and
external DBs, and network services of various sorts.
An example of a complicated service component is
the QoS control bandwidth management service.
Service components generally provide logic which
interworks enabler, policy, and utility components.
They report transaction events to R&A in TDRs via
a TDR enabler. Measurements are collected on transactions and periodically pushed to the SMP using the
MCR enabler. Because service components do all
their work through other components which are
either very simple or are responsible for monitoring/
alarming any external or internal resource, the service component only needs to be responsible for
reporting its own health. This is accomplished with a
simple forward progress counter (FPC). As the service component makes forward progress (either by
processing real or test transactions), the FPC is incremented. If the FPC stops increasing in value for a sufcient amount of time, an external monitoring
system (JMX agent) will declare the associated service component operational state to be disabled, and
will raise a state-change alarm in the MIB and to the
SMP via a Simple Network Management Protocol
(SNMP) trap.
Each service component can be a part of a larger
service which utilizes service components of various
types and may have multiple layers of service and
enabler components that comprise the service. The
larger service architecture consisting of multiple components is beyond the visibility/scope of the SCF. This
again illustrates why the SMP includes a correlation
engine. The correlation engine is used to keep track
of components involved in a particular service architecture and maintains a coherent view of the service
state.
Enabler components. Enabler components provide
internal interfaces to external or internal resources.
The internal interface may be a Java object, message
queue, or Camel endpoint. The API choice is up to
the developer. Enablers convert between the internal

and external protocols. External resources include

things like service provider databases, SMPP servers,
and Simple Mail Transport Protocol (SMTP) servers.
Internal resources include the SCF cluster DB, R&A
(for TDRs) and SMP (for MCRs).
A critical function of the enabler component is to
monitor the resource it is connected to and report
failed transactions so a determination may be made if
the external resource has failed or become unreachable. If alarming of failed external resources was left
to individual development teams, there would be
nearly as many schemes as there are external
resources.
One objective for the design of the enabler component was to create a simple, easy-to-use monitoring scheme that provided broad coverage for faults.
To do so, we implemented a simple success/failure
SCF component infrastructure interface that the
enabler calls on every transaction. If a failure occurs
on a transaction with the monitored resource, the
failure interface is called with additional text that
can be included in an alarm. The SCF core keeps
track of transaction successes and failures, and
when the threshold is crossed, the enabler operational state is declared to be disabled and a state
change alarm is declared in the MIB and forwarded
to the SMP.
Policy components. Policies may be created any
time it is desirable to have a focused go/no-go decision based on the context of the transaction. They are
especially useful where congurable decision logic is
desirable.
Policy components provide go/no-go determination for individual transactions based on context data
passed to the policy, history, and sometimes externally acquired data. An example of a simple policy is
throttling. Various throttling and quota limits may be
established for partners, applications, other components, and combinations of components and partners
and applications. At the beginning of a transaction, a
component may call the throttling policy and pass it
the required context data. The policy will return an
allowed/not-allowed response with informational
text, which may be referenced in the event of a

DOI: 10.1002/bltj

Bell Labs Technical Journal

181

failure. Policies may be stateless or stateful. If they

are stateful, they can share state across SCF nodes
using DB table replication or messaging.
A policy such as throttling may be congured
with data, but the policy logic is xed. Other policies,
such as the subscriber policy, can have congurable
logic utilizing constructs such as equals, greater than,
less than and wildcard matching of subscriber record
data. Congurable logic is implemented using Drools*
Rule Language (DRL) and an on-the-y compiler.
The logic is recorded in the subscriber policy conguration data as an XML document using an XFormsbased [19] user interface (UI) to collect the desired
policy logic. The policy data handler then translates
the conguration data into DRL, compiles it, and
passes the compiled rule along with the appropriate
context data to the evaluation engine where each
rule is evaluated.
Utility components. Utility components are just
functions which may be used by a number of other
service, enabler, or policy components. An example
of one such utility is an internal routing service
which uses transaction context data and enabler
component registration data to route transactions to
the correct enabler component. A current implementation, called multi-carrier routing, uses the subscriber subscription information to route a transaction
to the preferred carrier. It has been implemented for
several network interfaces (e.g., SMS, MMS, WAP,
terminal location, and payment). The infrastructure
is generalized so that any transaction context data
may be used as a routing key to the preferred carrier
service interface.
Components Offered With the SCF
In addition to Alcatel-Lucent developed infrastructure software, a large number of Alcatel-Lucent
developed components are available. Notable among
these are:
Services and enablers for sending and receiving
SMS, MMS, and WAP messages,
Services and enablers for getting location information, including group location,
Services and enablers for a multitude of payment
functions, using standard payment interfaces [1],

182

Bell Labs Technical Journal

DOI: 10.1002/bltj

Services and enablers for privacy and consent

management, which can work with or without
an OAuth server,
Services and enablers for QoS control and management, and
Several policy components that can be used to
enhance the operation of other components.

SCF Provisioning and Maintenance

A key aspect of carrier-grade systems is the care
with which their provisioning and maintenance is
designed. The following sections describe the provisioning and maintenance design of the SCF.
Shared Component Functions
When components are deployed and initialized,
they read their conguration data from the conguration DB which is keyed by the DN of the component. The SCF supports a variety of context/
conguration types of data that are supported for each
component (e.g., Global, PerComponent, PerPartner,
PerApplication, PerComponentPerPartner, and so
on). See Conguration of SCF Components for further details.
The check-state interface is a simple management interface that was developed to control each
service, enabler, and policy component. Prior to any
transaction, each component is required to call a
check-state interface to determine if the administrative state has been locked, if the deployment state is
not active, or if an overload condition exists. If any of
these conditions exist, the response will be to deny
the transaction. Thus, the component does not need
to understand any of these conditions. It must simply
call the core SCF interface to determine if it is permitted to proceed with a transaction. Patents are currently being pursued for fault detection implementation
in the SCF.

Deployment of SCF Components

Deployment is the process of installing an SCF
component on one or more SCF nodes. SCF components can be deployed and undeployed on SCFs as
they simultaneously process transactions in normal
operation. The deployment user interface (UI) is

presented by the FD within the OAP system. The FD

supports deployment groups of SCF nodes so that components can be deployed on the multiple SCF nodes
within such a group simultaneously. By entering
information and commands using the FD, the associated provisioning engine communicates with the
JMX agent of the SCFs in the deployment group to
initiate the deployment.
Components to be deployed to the SCFs are
packaged as OSGi bundles. An SCF component
OSGi bundle is placed into a Maven repository to
which each SCF node has access. The SCFs JMX
agent entity is then used to perform the actual
deployment. When instructed by the FD via the
JMX agent, ServiceMix rst retrieves the SCF components OSGi bundle from the Maven repository,
and then, using OSGi facilities embedded in it,
installs the bundle, and activates it. The component
is then ready for use.
The FD also is responsible for SCF component
version control. To deploy a new version of an SCF
component, FD rst undeploys the old version, and
then deploys the new version.
An important aspect of deployment is componentdependency resolution. SCF components can depend
on other components in order to operate properly.
The typical example of this is an SCF service component being dependent on the SCF enabler components and policy components that the service
component invokes. The service cannot operate
properly without these dependent components also
being deployed.
To facilitate the resolution of component dependencies at deployment time, each component is bundled with a le which lists all of the other components
on which it depends. (The Maven archetypes discussed in the SCE section will contain a template for
this le.) Upon deployment of a component, the JMX
agent will look through that list of declared dependencies and attempt to deploy all of the dependent
components before deploying the component itself.
Of course, the dependent components may in turn
have their own dependencies. Those dependencies
will be resolved in a similar manner. If there is a failure at any point in the deployment, the entire

deployment is backed out leaving the SCF in its original state. Thus, any failure in the deployment of a
deployment group results in the entire deployment
group being backed out.
The same OSGi bundle for an SCF component
can be used to create and deploy identical instances
of the component on different SCF nodes or even on
the same SCF node. Reasons for deploying identical
instances of the same component on the same SCF
node include load sharing and basic redundancy.
Components can have multiple instances that
are congured differently as well. Different instances
of the same SCF component execute identical software, but they can be made to behave differently
based on the different kinds of context data congured
for them.
Conguration of SCF Components
The conguration of SCF components, now
deployed, is also through the FD. The process of supplying data for an SCF component in order for the
component to be congured properly and operate
in the desired manner is also referred to as provisioning the component. This data is known within the
SCF as context data.
The FD communicates, via the associated provisioning engine, with the JMX agent to provision context data for an SCF component. Note that context
data are provisioned for a component while that
component is up and running on the SCF, meaning
that the component does not have to be stopped or
undeployed to provision context data for it.
All context data for an SCF component is provisioned via FD using an XForms-based interface.
When the XForm is submitted at the FD, an XML
document is created and the FD sends the XML document to the JMX agent on the appropriate SCF. The
JMX agent then sends the context data to the target
component for validation and processing.
All components must implement customized
context data change listeners to allow for validation
and processing of dynamic changes to their associated context data. A components context data handler makes appropriate changes within the component
based on how the handler is programmed to do so.

DOI: 10.1002/bltj

Bell Labs Technical Journal

183

Table I.

Context data types supported for SCF components.

Context data type

Description

Global

Data that applies to every deployed instance of a particular SCF component.

PerDeployment

Data that applies to a particular deployed instance of a

particular SCF component.

PerPartner

Data that applies to a particular partner for a particular

SCF component.

PerCampaign

Data that applies to a particular campaign for a particular

SCF component.

PerApplication

Data that applies to a particular application for a particular SCF component.

PerComponent

Data that applies to a particular component that uses

another particular SCF component.

PerAPI

Data that applies to a particular API for a particular SCF

component.

PerComponentPerPartner

Data that applies to a particular component that uses

another component for a particular partner.

PerComponentPerCampaign

Data that applies to a particular component that uses

another component for a particular campaign.

PerComponentPerApplication

Data that applies to a particular component that uses

another component for a particular application.

APIApplication programming interface

SCFService Composition Framework

All the while, the component continues to process

transactions for which it is invoked. The handler can
reject the context data if data is incorrect, invalid,
and/or missing. If context data is rejected by the components context data handler, the component is
restored to its original state and the JMX agent does
not commit the new context to the DB. Otherwise,
the JMX agent commits the context data to the DB.
A powerful feature of SCF is the ability to ascribe
several different types of context data to a component. This enables great exibility in specifying and
tuning the behavior of a component simply by providing certain kinds of data for it.
The different types of context data supported in
the SCF are described in Table I. An individual component denes which types of context data it needs.
Some context data types require keys to be associated
with them. For example, the PerPartner context data
type has a key whose value identies the partner for

184

Bell Labs Technical Journal

DOI: 10.1002/bltj

which the data is applicable. Whenever PerPartner

context data is provisioned for any SCF component,
the appropriate key value must also be provided.
To illustrate, suppose an SCF service component accepts SOAP requests from a number of APIs
and forwards those requests southbound to different endpoints based on the invoking API. The context data types for this service might be the
following:
Global, which denes the types of SOAP requests
supported by the service. This will be the same
data for every deployed instance of the service.
PerDeployment, which denes the port number(s)
on which the service listens for incoming SOAP
requests. This will likely be different data for
each deployed instance of the service.
PerApi, which for a given API, denes the endpoint to which to forward a received SOAP
request. Multiple instances of this dataone

System
monitor

Provisioning
engine

SMP
SNMP
daemon
Other MIB
support

Monitors ServiceMix,
jmxAgent and other
processes. Raises
alarms if needed.

SNMP
Traps
JMX agent
JVM

ServiceMix JVM
SNMP
adapter

JMX RMI
connector

MBean
server
MIB table
MBean
MBean
MBean

Component
manager
MO MBean
MO MBean
Registered
MBean
MBean

JMXJava* management extensions

JVMJava* virtual machine
MBeanManaged bean
MIBManagement information base
MOManaged object

Features
service
MBean

Alarm
manager
Deploy features and
create component
instances via JMX
RMI

Component
control port
MBean

State
manager

RMIRemote method invocation

SCFService Composition Framework
SMPSystem management portal
SNMPSimple Network Management Protocol

Trademark of The Apache Software Foundation.

Trademark of Oracle America, Inc.
*Trademark of Sun Microsystems, Inc.

Figure 8.
SCF management architecture.

instance for every API supported by the service

would be provisioned to every deployed instance
of the service.
The FD provides interfaces to deploy and congure
SCF nodes and the components within each SCF node.
It has functions to associate SCF services with external
partners and applications, and to establish billing rules
based on SCF transactions via BMS. The FD handles
software updates for the SCF core functionality as well
as the components deployed to the SCF.
Management Infrastructure of the SCF
The Service Composition Framework uses standard Java management technology [14] to manage

and congure the various SCF components. The Java

management interface uses a managed bean
(MBean). Each SCF component has a managed
object associated with it. The management interface
allows users to set and to obtain the value of specic
attributes of a managed object. It also contains operations to be performed on the managed object.
The SCF provides a management agent (called
the JMX agent) or JVM for management purposes, as
shown in Figure 8. OAP elements (like the provisioning engine) use remote method invocation (RMI)
to remotely access the management interfaces on the
JMX agent. This allows installing and uninstalling of
components, and the management of conguration

DOI: 10.1002/bltj

Bell Labs Technical Journal

185

Top
AES

ManagedElement

SCF

PolicyComponent

Alarmable

Monitor

ActiveMonitor

ScfSysMonitor

FPMonitor

Policy

PolicyComponentThrottle

LogicalGroup

Agent

Resource

Service
QosControlService

ScfAgent
EnablerLocation
ThrottlePolicy
EnablerMMS
AuditMgr
EnablerNetworkQOS
EnablerScfDB
SvcMonitor
EnablerSMS
EnablerTDR
EnablerWAP
EnablerMCR
ServiceComponentQosControl
MonitorScfLB
ServiceComponentPing
EnablerSDCS[1]

LocationResource

PingService

MmsResource
NetworkQosResource
ScfDbResource
SmsResource
WapResource
ScfLBResource
SDCSResource[1]

SCFService Composition Framework

Figure 9.
SCF managed object inheritance hierarchy.

data. A managed object (MO) is created at the time a

component is installed on the SCF. The component
can be managed via the MBean interface.
Managed objects in the SCF adhere to an objectoriented inheritance hierarchy, shown in Figure 9,
which allows managed data and functionality to be
partitioned into smaller classes with well dened
roles and responsibilities.
Each SCF host has an SNMP daemon (provided
by net-snmp [12]), which receives external SNMP
requests (e.g., from the SMP) and proxies SCF MIB
related requests to the JMX agent. The SNMP daemon includes support for standard MIBs like Internet
Engineering Task Force (IETF) RFC 1213-MIB [11]
to access the system, interfaces, Transmission Control
Protocol (TCP), IP information, and UCD-SNMPMIB [13] to access disk, central processing unit

186

Bell Labs Technical Journal

DOI: 10.1002/bltj

(CPU), and memory utilization data. The SNMP daemon is congured to also support certain third-party
MIBs to access ServiceMix JVM data and for hardware monitoring.
An SNMP adaptor server allows the JMX agent
to handle SNMP requests. An SCF MIB denes the
objects that can be accessed via SNMP. The SCF MIB
consists of a state table and alarm table. A subset of
each components managed object data is exposed
via the state table and is accessible via SNMP. This is
used by the SMP to monitor and display the components states. The alarm table contains a list of active
alarms, and each entry contains alarm attributes
such as alarm type, probable cause, specic problem,
severity, and additional free text. The state and alarm
table entries include a distinguished name (DN)
which uniquely identies an SCF component.

The alarm table and a managed objects data are

maintained in a MySQL database which is accessed
via a data access object (DAO) using an Open Java
Persistence API (OpenJPA*) [4].
SCF alarms are associated with SCF components.
The SCF only reports state change alarms for a given
component. Services are monitored by a forward
progress monitor. An alarm is raised if a problem is
detected by the monitor. Enabler components can
raise alarms directly if the enabler has a problem
accessing its underlying network resource. Similarly,
a system monitor process can raise an alarm against
the SCF agent if it encounters trouble communicating with the ServiceMix JVM. Alarm entries are
added to the alarm table as alarms are raised and
are removed from the table when an alarm clears.
In addition, an SNMP trap is sent to one or more congured destinations when an alarm is raised or
cleared. There can be multiple outstanding alarms
against a component.
The SCF host does not attempt to do any alarm correlation. It is the responsibility of the SMP to perform
the correlation and to determine the system-wide operational state of a component based on alarms received
from each SCF host.
Transaction Records in the SCF
The SCF records transaction events as TDRs. A
TDR is produced by every service and enabler component involved in a transaction. All TDRs for a
transaction include the same unique correlation ID.
This is so that events within a transaction can be
associated for data collection and billing and so that
they can be correlated with TDRs generated by other
entities within the OAP. TDRs are pushed from the
SCF to the R&A where they are correlated and stored
for retrieval and analysis. The R&A provides an interface to the BMS so that billable events may be
retrieved and billing records created. It also has analytic functions for the creation of periodic service/
trafc reports as well as datamining capabilities for
analysis of service and trafc patterns. Measurements
are recorded by service and enabler components
using MCRs which are periodically pushed to the
SMP. Standard measurements include counts for
each transaction type attempt, completion, and

failure. Gauge counters are also available which can

measure maximum and minimum values.
Each service and enabler component within the
SCF has an operational and administrative state as
recommended in the International Telegraph and
Telephone Consultative Committee (CCITT) X.731
standard [8] and is capable of raising alarms as specied in CCITT X.733 [9]. Each component has an
associated managed object with a unique distinguished name for identication. All logged events
and TDRs include the component DN so that the
source may be precisely identied. States and alarms
are tied to the managed object in the SCF MIB and
are forwarded to the SMP where they are displayed
and correlated. The SMP correlates states of service
components to determine an overall state of each
service. It also correlates states of enabler components to determine an overall state of the resource
accessed by the enabler. The SMP has a congurable
correlation engine which allows analysis of complex
events and creation of service level alarms as determined from the state of individual components.

Service Creation Environment for the SCF

The SCF is a programmable platform open to
third-party developers, so Alcatel-Lucent designed
and developed a service creation environment tuned
to developing components to be deployed on the SCF.
Generally speaking, an SCE is a set of software assets
that facilitates creation of new service assets. These
software assets include Eclipse* as the base integrated
development environment (IDE), custom Eclipse plugin extensions, and a variety of third-party and
Alcatel-Lucent tools. The SCE facilitates the development, testing, integration, and deployment of runtime
components. The key values offered by the SCE are:
Easy composition of new SCF software components using Java on a desktop system,
Easy composition of new SCF software components
using graphical technologies on a desktop system,
Easy evaluation, testing, and debugging of SCF
components on a desktop system,
Deployment, debugging, and testing of SCF components on the production SCF labs from a desktop system,

DOI: 10.1002/bltj

Bell Labs Technical Journal

187

SCFService Composition Framework

Figure 10.
Service composition in Eclipse using the SCF component libraries.

Integrated touch-and-feel, and

Rapid service creation.
Due to the multitude of technologies upon which
the SCF is built (although mostly Java based), creating
such a developer-friendly environment meeting these
goals is challenging. The SCE relies on a combination
of custom and third-party tools to achieve these goals.
The SCE targets two different types of developers: a) the seasoned Java developer, uent in enterprise technologies, and b) a technical person, not
necessarily well-versed in Java technologies. We
envisioned that the seasoned enterprise Java developer will make use of the third-party technologies
and SCF additions made available to him. The seasoned developer will develop primarily in Java using
technologies such as Camel or Drools. The nonseasoned developer will use a higher programmatic
level of abstraction, for example jBPM, to graphically
compose new components.
Service Composition with SCE
Alcatel-Lucent has developed a set of software
assets to ease the task of composing new SCF components. These include:

188

Bell Labs Technical Journal

DOI: 10.1002/bltj

SCF component and associated documentation

libraries,
Maven archetypes and examples of composite
services and enablers, and
Graphical tooling for composition of services.
SCF component libraries. The SCF makes a large
collection of assets, such as enablers, services, policies, utilities, and infrastructure libraries and Javadoc
bundles, available to third-party developers as a collection of Maven artifacts. Each SCF component
offers a programmatic API that can be used to develop
composite services. The APIs offered span a large
variety of network services that include SMS, MMS,
Diameter, email, payment, privacy and consent,
Session Initiation Protocol (SIP), QoS, and ParlayX.
Figure 10 shows a composite service being created in
Eclipse using the SMS enabler API. The Javadoc view
shows the associated API documentation.
Maven archetypes and examples. Sample projects
are provided to developers in the form of Maven
archetypes and examples; these are included in the
SCE package. Archetypes and examples provide
the quickest way for a developer to bootstrap an

DSLDomain specic language

SCFService Composition Framework

Figure 11.
Graphical service composition using the SCF DSL.

application. Maven archetypes provide parameterized

template code that can be used to generate base
source code for new services or enablers.
Graphical tooling. The SCF supports graphical
composition of services using the Business Process
Modeling Notation (BPMN) specication. Several
Java-based BPMN technologies were considered for
our purpose, using different evaluation metrics, with
special attention to performance. The results led us to
choose jBPM [17].
The SCE supports graphical composition of SCF
services using jBPM tooling. This includes the ofcial
jBPM Eclipse plugins, and Alcatel-Lucent service
tasks. SCF service tasks provide an SCF with domain
specic languages (DSLs) that can be used for composition of SCF ows with jBPM. Service tasks bring
the level of abstraction to a higher level for SCF. The
functionality of enablers, services, and infrastructure
components are abstracted into service tasks.
Composition of new components is done by dragging
and dropping service tasks into a jBPM ow and populating the properties associated with each

component. Figure 11 shows the composition of a

service component using the Lightweight Directory
Access Protocol (LDAP) and email service tasks to
serve REST queries.

Evaluation and Testing of Components

The myriad of Java enterprise technologies can
make software development overwhelming at rst
for the new developer. As part of the SCE, testing
and runtime environments have been precisely created to aid the new developer with testing and
debugging.
The SCF provides a set of Eclipse and standalone
tools to aid developers, including:
A desktop version of the SCF that enables developers to test and debug their creations on their
own laptop or desktop,
A standalone Java graphical user interface (GUI)
supporting multiple administrative and testing
functions to interface with the desktop version of
the SCF,

DOI: 10.1002/bltj

Bell Labs Technical Journal

189

JMXJava management extensions

RMIRemote method invocation
SCFService Composition Framework

Figure 12.
Non-Eclipse based SCF tools.

Eclipse plugins to test, debug, and administer

both desktop SCFs and remote SCF environments (including clusters) in either premise of
cloud environments, and
Protocol endpoints and device simulators to provide support for testing of end-to-end scenarios.
Standalone tools. A set of endpoint simulators
and standalone tools has been developed to aid the
developer with administration of the SCF. Figure 12
shows the SCF shell capabilities as well as the status
of a locally installed SCF (in the desktop).
Eclipse extensions. Alcatel-Lucent also provides a
set of extensions to Eclipse, which is arguably the
most popular integrated development environment
(IDE), to aid the developer with testing and debugging
interactions with components deployed on the SCF.
These extensions consist of a set of plugins that enable
the development of end-to-end ows (component
creation, deployment, and testing) in any local or
remote SCF.

190

Bell Labs Technical Journal

DOI: 10.1002/bltj

Figure 13 illustrates testing against a remote lab:

a SOAP request is sent using the soapUI Eclipse plugin. The remote SCF labs view shows the status of the
labs being used. The SCF console view displays additional information in the console window.

Summary and Conclusions

Exposing the valuable assets of communication
system providers (CSPs) so they can be accessed by
web applications and other external applications
has the potential to increase operator revenue in
multiple ways. Chiey, the approach creates differentiating value that can increase the customer base,
and furthermore, it can open a new revenue stream
by attracting partners who own applications that
make use of these valuable assets. Alcatel-Lucents
OAP system has been developed to accomplish
asset exposure for CSPs. This system includes the
Service Composition Framework as the element to
provide:

DSLDomain specic language

SCFService Composition Framework

Figure 13.
Graphical service composition using the SCF DSL.

Service normalization, which exposes network

assets.
Service mediation, which transforms or enhances
service requests that come in from external
applications.
Service composition, which enables creation and
deployment of new capabilities.
As described in this paper, the development of
the SCF involved a few key technical choices. A
major challenge was to provide a exible platform
that supported on-the-y addition of new functional
components. The technical choice made was to
incorporate an open-source OSGi-based software
platform. Some disadvantages we had to compensate for were inherent complexity and the lack of
carrier-grade characteristics. The technical choice for
ameliorating complexity was to provide an Eclipsebased
service
creation
environment
to

assist component developers in dealing with the

complexity of the framework. The technical choice
for providing the desired carrier-grade functionality
was to tap into Alcatel-Lucent expertise in this area,
adding a component model, a management agent,
and a managed object paradigm. The resulting SCF
framework provides:
An associated SCE, including graphical capabilities and integrated testing capabilities,
Embedded monitoring, reporting, controlling,
and billing capabilities, for use with both existing
and new components, and
Carrier grade deployment and maintenance, performance, and support for geo-redundancy.
Since the SCF is Java based, it is hardware platform agnostic. The SCF, and the whole OAP system,
has been designed and tested for deployment utilizing commercial servers and cloud computing.

DOI: 10.1002/bltj

Bell Labs Technical Journal

191

Acknowledgements
The authors would like to acknowledge the associated work of Ransom Murphy, a chief OAP architect, and Troy Echols, for work on the SCF roadmap.

[10]

*Trademarks
ActiveMQ, Camel, CXF, Karaf, OpenJPA, and ServiceMix
are trademarks of The Apache Software Foundation.
Drools is a registered trademark of Red Hat, Inc.
Eclipse is a trademark of the Eclipse Foundation.
iPhone is a registered trademark of Apple Inc.
Java, JavaScript, and JMX are trademarks of Sun
Microsystems, Inc.
jBPM is a registered trademark of Red Hat, Inc.
JVM is a trademark of Oracle America, Inc.
Linux is a trademark of Linus Torvalds.
MySQL is a registered trademark of MySQL AB.
OSGi is a trademark of the OSGi Alliance.

References
[1] 3rd Generation Partnership Project, Parlay X
Web Services Part 6: Payment, 3GPP TS
29.199-06, <http://www.3gpp.org/ftp/Specs/
html-info/29199-06.htm>.
[2] C. Albanesius, Verizon Customer Growth
Slows, iPhone Helps Boost AT&T, PCMag.
com, Oct. 22, 2010, <http://www.pcmag.com/
article2/0,2817,2371287,00.asp>.
[3] Apache, ServiceMix, <http://servicemix
.apache.org/home.html>.
[4] Apache Software Foundation, OpenJPA:
Welcome to the Apache OpenJPA Project,
<http://openjpa.apache.org/>.
[5] J. A. Brunetti, K. Chakrabarti, A. M. IonescuGraff, R. Nagarajan, and D. Sun, Open
Network Quality of Service and Bandwidth
Control: Use Cases, Technical Architecture,
and Business Models, Bell Labs Tech. J.,
16:2 (2011), 133152.
[6] I. Faynberg, H.-L. Lu, and H. Ristock, On
Dynamic Access Control in Web 2.0 and
Beyond: Trends and Technologies, Bell Labs
Tech. J., 16:2 (2011), 199218.
[7] A. Greenwald, G. Hampel, C. Phadke, and V.
Poosala, An Economically Viable Solution to
Geofencing for Mass-Market Applications,
Bell Labs Tech. J., 16:2 (2011), 2138.
[8] International Telegraph and Telephone
Consultative Committee, State Management
Function, CCITT Rec. X.731, Jan. 1992,
<http://www.itu.int>.
[9] International Telegraph and Telephone
Consultative Committee, Alarm Reporting

192

Bell Labs Technical Journal

DOI: 10.1002/bltj

[11]

[12]
[13]
[14]

[15]
[16]
[17]
[18]

[19]

Function, CCITT Rec. X.733, Feb. 1992,

<http://www.itu.int>.
M. J. Mampaey, Secure Remittance
Transaction to Bankless Consumers in a
Fragmented Applications Market, Bell Labs
Tech. J., 16:2 (2011), 219233.
K. McCloghrie and M. Rose (eds.),
Management Information Base for Network
Management of TCP/IP-Based Internets:
MIB-II, IETF RFC 1213, Mar. 1991,
<http://www.ietf.org/rfc/rfc1213.txt>.
Net-SNMP, <www.net-snmp.org/>.
Net-SNMP, UCD-SNMP-MIB, <http://www
.net-snmp.org/docs/mibs/ucdavis.html>.
Oracle, The Java Tutorials: Java Management
Extensions (JMX), <http://docs.oracle.com/
javase/tutorial/jmx/index.html>.
Oracle, MySQL, <http://www.mysql.com>.
OSGi Alliance, Technology, <http://www
.osgi.org/About/Technology>.
Red Hat, JBoss Community: jBPM, <http://
www.jboss.org/jbpm>.
A. Smith, Americans and Text Messaging,
Pew Internet, Sept. 19, 2010, <http://
pewinternet.org/Reports/2011/Cell-PhoneTexting-2011.aspx>.
World Wide Web Consortium (W3C),
XForms, <http://www.w3.org/TR/
xforms/>.

(Manuscript approved January 2013)

KRISTIN F. KOCAN is a technical manager currently
leading the SCF development team in the
Application Enablement Domain within
Alcatel-Lucent and is based in Naperville,
Illinois, USA. She holds a B.S. degree in
engineering and a M.S. degree in
information engineering from the University
of Illinois in Chicago, and a Ph.D. specializing in systems
engineering from Southern Illinois University in
Carbondale. Dr. Kocan began her career at Bell Labs in
1980. Her current interests are next-generation service
architectures, service composition and blending, service
creation environments, and novel services and
applications.
KEVIN W. McKIOU is a distinguished member of
technical staff in the Application
Enablement Domain within Alcatel-Lucent
in Naperville, Illinois, where he is currently
working on application enablement
software development. His professional

interests include systems design and development of

highly available systems for application enablement.
Mr. McKiou holds a B.S. in aerospace engineering from
St. Louis University in Missouri, an M.S. in industrial and
systems engineering from The Ohio State University in
Columbus, and an M.B.A. from Southern Illinois
University in Carbondale.
NINOO R. PANDYA is a product development engineer
in the Applications Enablement Domain
within Alcatel-Lucent in Naperville, Illinois,
where he is currently developing
application enablement software. Prior to
joining Alcatel-Lucent, Mr. Pandya was a
lead software engineer at TMS Digital Laser Technology
where he developed real time embedded software for
pre-mastering systems used by laser beam recorders.
Mr. Pandya holds a B.E. in electrical engineering from
BMS College of Engineering in Bangalore, India, and a
M.S. in computer science from Oklahoma State
University in Stillwater, Oklahoma.
JORGE HERNANDEZ-HERRERO is a product
development engineer in the Applications
Enablement Domain within Alcatel-Lucent
in Naperville, Illinois, where he is currently
developing application enablement
software. His current professional interests
include Internet networking and security. Mr.
Hernandez-Herrero holds a B.S. in computer
engineering from the Universidad Complutense de
Madrid, Spain, and a M.S. in computer science from
DePaul University in Chicago, Illinois.
F. THEODORE FREULER is a distinguished member of
technical staff in the Applications
Enablement Domain within Alcatel-Lucent
in Dublin, Ohio. At Alcatel-Lucent,
Mr. Freulers primary responsibilities have
been in architecting, designing, and
developing real time applications,
software platforms, and web services for
telecommunications networks. Prior to joining the
company, Mr. Freuler was a principal research scientist
at the Battelle Memorial Institute in Columbus, Ohio
where he designed and developed computer
simulation models and programming language
compilers. He holds B.S. and M.S. degrees in computer
and information science from The Ohio State
University.

DOI: 10.1002/bltj

Bell Labs Technical Journal

193