Professional Documents
Culture Documents
Figure 2: A Web 2.0 Service Composition Ecosys- 3.1 Several Categories of Developers
tem Following the Web 2.0 paradigm, there would be a plethora
of developers in the ecosystem, creating a variety of long-
tail applications 2 . Developers range from being skilled in
2.0 is more about connecting people, and making technol- programming languages like Java and C to having little or
ogy simpler and more efficient for people. Web 2.0 changes no programming experience. Further, these developers will
the way in which businesses interact with its customers, by have varying degree of Telecom expertise. Finally, these var-
advocating the following core principles, a) provide an ar- ious categories of developers will follow different program-
chitecture of participation that encourages customers to add ming styles. For instance, the same functionality can be
value to a service as they use it; b) offer rich, intuitive, and required by a Java programmer, an Ajax/HTML developer
interactive interfaces based on Ajax or similar frameworks; or a PHP user.
and c) harness collective intelligence by facilitating collab- A composition environment catering to this ecosystem
oration and sharing among users through communities and should support simple, intuitive means for collaboration and
social networks. reuse. More specifically, it should provide interfaces for look
Service developers in a Web 2.0 environment come with up and selection of available services, while offering a unified
varying expertise and usually have little experience in Telecom- view cutting across different programming styles. Moreover,
specific services and programming for mobile devices. To to harness community intelligence, the developers should be
support such developers, the composition environment should able to rate the services used by them and also publish util-
provide simple interfaces for the available functionality. For ity snippets that are re-used by other developers.
example, in Figure 1, the components for Location and Pres-
ence should be exposed while hiding the issues pertaining 3.2 Multiple, Heterogeneous Protocols
to privacy, security and complexity of Telecom protocols.
A composite Telecom service, in general, makes use of
Similarly, the device capabilities for retrieving the user loca-
multiple functionalities, which in turn are exposed using
tion and displaying a map should be made available through
different protcols. For example, Location and Call Con-
easy-to-use mechanisms.
trol can be accessed over the Parlay-X interface, Presence
In a Web 2.0 world, information and services are in a
related information through the SIP protocol, and Messag-
state of perpetual beta, continuously undergoing refinement.
ing capabilities via the SMPP protocol. Similarly, response
Therefore, information-centric tools like blogs and wikis can
from third party services can be in different formats, like
be used as a source to share comments, suggestions and new
XML (for REST based services), SOAP (for Web services),
developments regarding, for example, the Business Finder
HTML for services invoked over the Web, etc. The popular
service. These tools allow many developers to contribute
Google Maps service return its response in KML, an XML
to an online discussion, while updates can be distributed
based format.
to other developers using RSS (Really Simple Syndication).
To make the task of service composition easy, the develop-
Similarly, the developer community can be encouraged to
ment environment needs to hide protocol heterogeneity and
publish useful snippets/value-add fragments for existing ser-
complexity from the developers. Further, it should facilitate
vices. For instance, user of the Location service in Figure 1
interoperability among different protocols. As an example,
can publish a utility to parse the output of this service. This
it can provide utilities to parse the output of the Presence
utility can be re-used by other developers while incorporat-
service and send it over the SMS service.
ing the Location service in their applications.
3.3 Variety of End-user Devices
3. TELECOM SERVICE COMPOSITION ECO- There is a plethora of end-user devices over which the ser-
SYSTEM vices are accessed and executed in a Telecom environment.
Figure 2 describes an ecosystem for service composition Such devices range from being very basic ones (for exam-
in Telecom in an open-garden Web 2.0 world, comprising of ple, offering only the capabilities of messaging and voice) to
multiple providers, developers and consumers. On one side, 2
The concept of long-tail refers to the existence of a large
we have the Telecom operators that expose the core cellular number of applications, each being used by a small segment
capabilities of Messaging, Presence information, etc. On the of consumers.
being sophisticated, state-of-the-art devices like iPhone [2]. 4.2 Run-time Platforms and Standards
Services developed should be adapted and optimized for the It is clear that services in this ecosystem can be invoked
particular end-device. For example, Google Maps already by several standard-based protocols (e.g. SOAP, SIP over
provides a host of implementations for hundreds of mobile HTTP) and the business logic written in several languages
phones available in the market today. For easing the in- (e.g. Java, C, Workflow orchestration language like BPEL).
corporation of device functionality (octagonal boxes in Fig- Industry leaders like IBM, Sun, Oracle have undertaken ef-
ure 1), the same should be presented in a form that hides forts to come up with application servers that support con-
the underlying low-level details. current execution environments for heterogeneous protocols.
End-user devices communicate with the Telecom network Today, they offer application servers that include SIP servlet
and third party services by selecting among multiple modal- containers, thus allowing for Java business logic and SIP
ities of communication, made available by the underlying specific services to be executed on a single container. For
converged network. For example, services can be invoked example, the IBM Websphere Application Server product
over the Web interface, or through SMS and voice. The suite [8] implements a converged SIP and SOAP servlet con-
service composition process needs to abstract access modal- tainer, thus enabling the developers to compose applications
ities from application developers, so that it becomes easy for with business logic and SIP/SOAP based service invocation
them to integrate with the application. support within the same development environment. JSR-
289 3 [11] has been proposed by Sun and Ericsson to en-
hance existing SIPServlet specification and support devel-
4. EXAMINATION OF CURRENT EFFORTS opment of composed applications involving both HTTP and
In this section, we examine current efforts that are rele- SIP servlets. There are several other initiatives along this
vant towards enabling service composition in the Telecom front [15]. For instance, IBM supports extensions to a ser-
domain. For this purpose, we categorize current efforts into vice orchestrated in BPEL to have inline Java code.
(1) Efforts attempting to expose Telecom functions to the
community, (2) Creation of common run-time platforms for 4.3 Tools for Web 2.0 Application Composi-
execution of composed services, and (3) Tools and technolo- tion
gies being used by 3rd party application developers for Web One of the most commonly used terms for Web 2.0 appli-
2.0 centric application composition. Apart from these, we cations is a “mashup”. As per www.wikipedia.org, a mashup
also examine other relevant efforts in this direction. is ‘a website or application that combines content from more
than one source into an integrated experience’. Content is
4.1 Exposing Telecom Functions picked up from multiple servers (data sources) using tech-
The first wave of efforts along this direction primarily fo- nologies like Ajax and REST, and composed (or rendered) in
cused on creation of open standards and APIs to implement the ‘same’ user interface (UI), typically a browser. There are
core Telecom services and functions. Existence of open stan- several tools that aid in the creation of such mashup user in-
dards and APIs makes it easier for Telecom services to be terfaces. Examples are QEDWiki [6], Yahoo Pipes [18] and
interoperable with other applications, thereby making the Aqualogic [3], with PrestoStudio [10] from JackBe probably
development task easier. Examples of such APIs and stan- being the first enterprise Web 2.0 tool in this space. The
dards are JAIN Intelligent Network Application Protocol advantage of such tools is that it caters to a class of less
(INAP) and Service Logic Execution Environment (SLEE). sophisticated application developers who prefer “drag-and-
Session Initiation Protocol (SIP) is also an open standard be- drop” operations to create their own mashups. For example,
ing widely adopted across service providers to create Voice- QEDWiki provides a browser-based assembly portal where
over-IP services. Many Telecom operators are moving to- developers and users alike can choose services made avail-
wards implementing the IMS framework that would enable able by service providers and integrate the UI in a simple
them to expose their core functionalities (voice service, SMS mashup with other UIs. It also allows for specification of
service, Call control) using SIP. Composing applications us- simple data flows between two UIs, all driven by a visual
ing these standards, however, require the developer to have user interface. Moreover, these mashups can be shared with
a deep understanding of the protocols and standards. other users, who can then re-use them to create their own
In an effort to ease up the requirement of deep under- applications.
standing of protocols, the Parlay consortium came up with In a converged Telecom Web 2.0 ecosystem, services need
the Parlay [14] and the subsequent Parlay-X standards [13]. to be exposed in similar manner, while making them easy to
Parlay-X is SOA-compliant and exposes a Web Services im- invoke by Web 2.0 standards such as Ajax. However, we note
plementation for core Telecom services. Web services today that in this domain, apart from allowing easy mashup in a
are understood by a wide community of SOA programmers browser-based environment, orchestrating Telecom services
and developers. Parlay-X allows them to use familiar ap- together with 3rd party services might require specification
plication development tools to create services composed of of complex data flows and control flows. As an example, the
Telecom services as well as services belonging to 3rd party latitude and longitude information provided by a Location
providers (available over the IP network). For example, de- service may need to be parsed before passing it to a reverse
velopers can use an eclipse-based Java development environ- geocoder service (a service which returns a textual descrip-
ment to create a service using Telecom functions, 3rd party tion of the place given the latitude and longitude). Further,
service like Google Maps as well as internal application logic. as Figure 1 indicates, a composed service can also include
IBM Telecom Web Services Server (TWSS) [7] is one such 3
The focus of JSR 289 is to define application composition
implementation of Parlay-X. Alcatel is also exploring the op- and convergence more clearly and also to solve many issues
tion of SOA/REST APIs on top of its Telecom Application that were found in JSR 116, the current version of the SIP
Server [1]. servlets API.
application specific logic. Much of this requires explicit cod- about the service. In a Web 2.0 world, such resources can
ing from the application developer, thereby necessitating the be made available either by the component provider directly
need for a ‘programming’ environment as against a ‘mashup’ or contributed by other developers.
environment. Some enterprises have taken a step in this di- To enable effective reuse of various components, it is im-
rection. For example, Web21C [17] from British Telecom is portant for the service composition environment to place a
a Web 2.0 based service aggregation environment. It allows component and its various associated artifacts in a struc-
developers to integrate core Telecom services and other Web tured format. For example, a Telecom operator can struc-
2.0 services into a single application. Web21C hides the com- ture its core network services (Location, Presence, etc.) un-
plexity of Parlay-X or SIP by exposing these Telecom func- der a single format, including resources like sample client
tions as higher level APIs, suitable for invocation from a user code, parsing utilities, link to blogs, etc. Similarly, all device
interface or a simple Java application. Connected Services specific functionalities can be templatized and populated for
Framework Sandbox [12] from Microsoft provides high level various kinds of devices. From a developer’s perspective, this
Web services interface that hide low level Telecom protocol would help in better comprehension and easier incorporation
specific constraints and allows creation of Managed network of these components. It is a challenge to design a generic
mashups with services exposed via its service delivery plat- structure that cuts across not only different functionalities,
form. but also different programming styles (Java, AJAX, PHP,
etc.) Furthermore, we need a networked repository that
4.4 Other Efforts allows easy means of publishing for such structured compo-
Triana [23] introduces a service creation environment, which nents. Ideally, publishing should be as easy as filling up a
aims to facilitate Web service composition by providing a form on the Web. This repository should also provide easy
higher level of abstraction and guiding developers in creat- look up (search), and feedback mechanisms.
ing composed services. The paper presents a case study that With several providers and community developers con-
investigates how this environment can be used in a Telecom tributing towards development of services and its associated
setting. [19] discusses a service creation tool for intelligent artifacts, it is important to help a developer with effective
networks so as to allow rapid introduction of new telematic tools for inferencing and recommendation. For example, a
services. This tool enables methods of interactive visual pro- developer wishing to invoke a certain service as part of her
gramming for developing new services from basic building workflow should be made aware of the artifacts written by
blocks and monitoring their execution in an intelligent net- the community in parsing the output of the service. While
work. [20] demonstrates composition of a workforce man- there has been a lot of work in the domain of inferencing
agement application enabled over a Telecom network, where and collaborative filtering [22], this ecosystem opens up a
the core Telecom functionalities like Location are exposed as new environment for applying current work as well as iden-
semantically annotated Web services and orchestrated using tifying interesting problems to enable efficient selection and
AI planning techniques. However, while such efforts are in- recommendation techniques.
teresting, they do not address the issues involved in devel-
oping services in an “open garden” Web 2.0 ecosystem. 5.2 Encapsulating Telecom Services by provid-
ing Higher Level APIs
5. OPEN CHALLENGES Today, standards like Parlay-X allow for Telecom services
Section 2 proposed a generic model for Telecom services. to be accessed through standardized Web service interfaces,
Section 3 highlighted a number of characteristics for service with the intent of making it easy for developers to use these
composition in this domain, while Section 4 studied some services. However, these APIs still require the application
existing work. In this section, we present some of the open developers to understand the underlying protocol that the
challenges that need to be addressed for enabling rapid roll- Parlay-X APIs invoke. At the very least, it requires them
out of Telecom services. Some of these challenges apply to to understand Web services. To ease the burden on the
service composition in general, however, we believe these are developer, implementation of such APIs should be available
more relevant for Telecom networks in particular. at the level of the application development environment. For
example, generating a client code for the underlying Web
5.1 Tools for Effective Collaboration and Reuse service and making it available to a Java developer would
As discussed in Section 2, composed Telecom services of- tremendously improve her productivity. Similarly, in the
ten span across components that run on the client device, current set up, exceptions from a Web service invocation
and those that run on the Telecom (e.g. Presence service) are captured in the form of messages in the SOAP response
and 3rd party infrastructures (e.g. Google Maps). Rapid envelope. It would be helpful to a developer if the service
service development requires appropriate abstractions of each composition environment can provide constructs to parse
of these components in a form that can be utilized by a devel- these messages and throw higher-level exceptions that can
oper community with little Telecom expertise. For instance, be used by the developer directly in her application.
they can be exposed as widgets for a visual service compo-
sition environment, a Java module for a programmer, etc. 5.3 Testing and Debugging of Services
Further, each of these components can have several arti- In an application development environment where Tele-
facts, which are essentially additional resources associated com services are being composed with third party services
with the component. Examples of such artifacts include by a Web 2.0 developer community, providing effective test-
sample code fragments showing how a service is invoked, ing and debugging mechanisms becomes important. The de-
meta-information about the service, utilities like code snip- velopers need to test their services not only for correctness
pets to parse the response from the service, exception han- and robustness, but also estimate various QoS parameters
dlers, as well as unstructured free-text blogs and comments like scalability, response time and availability. A major chal-
lenge is in performing these tasks without going ‘live’ on the [5] Google Maps.
network. For correctness and functionality testing, develop- http://www.google.com/gmm/index.html.
ers can be provided with a Telecom simulator that mocks the [6] IBM QEDWiki.
basic Telecom operations of SMS, Call Control, etc. Simi- http://services.alphaworks.ibm.com/qedwiki/.
larly, we can have a client-device emulator. However, this [7] IBM Telecom Web Services Server. http://www-
alone is not sufficient for load testing on the real Telecom 306.ibm.com/software/pervasive/serviceserver/.
infrastructure. For the QoS attributes, the developers would [8] IBM Websphere Application Server.
need some guarantees from the components they utilize. For www.ibm.com/software/webservers/appserv/was/.
example, a Telecom operator can annotate its offerings with [9] IP Multimedia Subsystem (IMS) Architecture.
common QoS parameters like response time and availability. http://www.dataconnection.com/sbc/imsarch.htm.
Often, such guarantees can be tough to provide on part of
[10] JackBe PrestoStudio.
the operator. For instance, delay in the SMS service would
http://www.jackbe.com/Papers/JackBe-
depend on the network congestion at that time.
StudioOverview.pdf.
5.4 Billing and Provisioning [11] JSR 289. http://jcp.org/en/jsr/detail?id=289.
Telecom operators as well as 3rd party service providers [12] Microsoft Connected Services Framework Sandbox.
spend a significant amount of time making the necessary ar- http://www.microsoft.com/serviceproviders/solutions/
rangements for provisioning a new service and connecting it connectedservicesframework.mspx.
to their billing system. A Telecom operator needs to worry [13] Open Service Access (OSA); Parlay X Web Services;
about how much overhead a new service is going to put on Part 1: Common. 3GPP TS 29.199-01.
the network. For example, it needs to know the average [14] Parlay API Specification. http://www.parlay.org.
bandwidth that the new service will consume, the peak load [15] Telco Web 2.0 Mashups: A New Blueprint for Service
that it will place on core Telecom components such as the Creation.
Home Subscriber Service, the Location Server, etc. To roll http://www.networkmashups.com/docs/ssi 0507.pdf.
out services rapidly, these evaluations need to be done in [16] Web 2.0. http://en.wikipedia.org/wiki/Web 2.
a timely and efficient manner. Further, a challenge for the [17] Web 21c sdk. http://web21c.bt.com/.
mobile operator is to develop appropriate charging models [18] Yahoo Pipes. http://pipes.yahoo.com/pipes/.
for letting 3rd party developers access its services. These [19] S. Abramowski, M. Elixmann, H. Gappisch,
models can be of various types; for instance, charging could U. Heister, U. Heuter, and K. Klabunde. A Service
be based on a contract basis or a per usage basis. Finally, Creation Environment for Intelligent Networks. In
while provisioning for a service, Telecom operators and 3rd proceedings of International Zurich Seminar on
party service providers also need to manage security, access ‘Intelligent Networks and their Applications’, 1992.
control and privacy of data and information. For exam- [20] V. Agarwal, K. Dasgupta, N. Karnik, A. Kumar,
ple, access to Location information by unauthorized entities A. Kundu, S. Mittal, and B. Srivastava. A Service
should be restricted. Creation Environment based on End to End
Composition of Web Services. In Proceedings of the
6. CONCLUSION 14th International World Wide Conference, May 2005.
With voice revenues getting saturated, Telecom opera- [21] D. Chakraborty, K. Dasgupta, S. Mittal, A. Misra,
tors are looking towards offering rich value-added services A. Gupta, E. Newmark, and C. L. Oberle.
to attract end-users and create additional revenue channels. BusinessFinder: Harnessing Presence to enable Live
With the advent of Web 2.0, Telecom operators need to move Yellow Pages for Small, Medium and Micro Mobile
from their “walled garden” select partner ecosystem for cre- Businesses. In proceedings of IEEE Communications
ating new services, to a completely “open garden” model, Magazine, Issue on “New Directions in Networking
to keep up with the rapidity with which Internet content Technologies in Emerging Economies”, January 2007.
providers like Google and Yahoo are enabling roll out of new [22] S. S. Gediminas Adomavicius,
services. This paper closely examined service composition Ramesh Sankaranarayanan and A. Tuzhilin.
for Telecom in a Web 2.0 ecosystem. We proposed a generic Incorporating Contextual Information in
model for Telecom services and identified various attributes Recommender Systems using a Multidimensional
associated to a service composition ecosystem in this do- Approach. In proceedings of ACM Transactions on
main. We also categorized and evaluated recent work in this Information Systems, volume 23, pages 103–145, 2005.
direction and highlighted some open issues while proposing [23] S. Majithia, M. Shields, I. Taylor, and I. Wang.
insights to address them. Triana: a Graphical Web Service Composition and
Execution Toolkit. In proceedings of IEEE
7. REFERENCES International Conference on Web Services, 2004.
[1] Alcatel Open Service Delivery Solution.
http://www.eurescom.de/Parlay-OSA-
products/Alcatel/Alcatel open service delivery solution.pdf.
[2] Apple - iPhone. http://www.apple.com/iphone/.
[3] BEA AquaLogic Family of Tools.
http://www.bea.com/framework.jsp?CNT
=index.htm&FP=/content/products/aqualogic/.
[4] go2. http://www.go2.com.