Chapter 17 - Wiley

walkingceilInternet και Εφαρμογές Web

22 Οκτ 2013 (πριν από 4 χρόνια και 8 μήνες)

106 εμφανίσεις

Chapter 17

Trying to Make Sense of Web Services in a Telco Environment

17.1 Introduction

In this chapter, we take a high level informal look at Web Services and the Service Oriented Architecture
paradigm, from the perspective of telecommunications deplo
yments. We will look at the simple core of Web
Service infrastructure standards (the publish/find/bind triangle and the WSDL/SOAP/UDDI core) and argue that
the model calls for a number of extension specifications and additional technologies required for re
alistic, large
scale, carrier grade Web Service deployments.

We often hear that telecommunication services design and standardization needs to change. ‘Telco services need
to be more like Internet services’ is the adage. But what does that mean? We need s
horter development life
cycles; we need to be able to tap into the sheer unlimited pool of Internet
savvy developers. We need the service
proliferation, the service customization, the service personalization, and above all, the service profitability and
effectiveness of Internet services. But how is this achieved? The answer, if one is to believe popular
publications on the web, is Web Services and Service Oriented Architecture. Or if you are really up to speed
with the latest buzzwords, the answer is
Semantic Web Services. However, these answers really raise the same
questions all over again. What does this mean? How is this achieved?

One approach at tackling these questions is to examine what exactly a Service Oriented Architecture means and
which pr
oblems it tries to solve, see which technologies from the web are adopted in order to realize it, and then
see if those technologies can be ported to telecommunications services realm. It is hoped that this approach will
get us beyond much of the inevitabl
e hype, and allow us to really understand Web Services. Such an
understanding will better facilitate us to assess future directions of service mediation and service delivery
architectures, rather than simply adopting and porting seemingly successful and en
abling technologies from one
paradigm and applying them to another.

This chapter has two objectives. The first is to gain a basic understanding of some of the more recent activities
in academia and industry to be able to see at least one possible future d
irection in which our current Service
Architectures may evolve. The second objective is to be able to assess and understand the current standards
contributions and strategies of some of the non
traditional players in telecommunications standards. This
ter is not intended as a survey on available research topics and technologies; there are many of those around
already. Instead, this chapter functions more as information and background for people interested in service
mediation and service delivery. It tr
ies to identify and understand those technologies that may play a role in one
of the possible future directions for industry standards in the area of service architectures.

Certain parts may seem trivial to the more astute reader, but are included here in

order to attempt to paint a
complete picture. Some of the topics addressed in this chapter are very popular in research and academia, and
hence numerous publications as well as pre
standards activities are available
. As such this chapter may not
many novel insights. However, for those with a history in telecommunications standardization for
services, service delivery and service mediation, using tightly coupled, object oriented, distributed paradigms,
some of these new concepts might appear quite

17.2 Web Services and Service Oriented Architecture

A Service Oriented Architecture (SOA) is an approach to describing a distributed computing environment for
Web Services. Web Services are discoverable software components available on the web. Ba
sically, the model
of the web as a collection of resources (e.g. documents, images, audio files, video files, etc.) is extended to
considering the web as a collection of services. The concept of web resources is being generalized to anything
that can be id
entified on the web, anything that has a URL

As described in OWSERv1.0 [OMA 2004], in its simplest form, a SOA can be depicted as the well
triangle (Figure 17.1). A Web Services
based architecture contains three functions:

a Web Service requester


a Web Service (offered by a Web Service Provider, or WSP); and


This chapter draws liberally from many resources in the field of research and academia, as well as more popular web p
Only some of the more significant resources are referenced explicitly in the chapter, whereas others are left as an exercise
to the reader
to find. The astute reader will have no difficulties dipping into the vast and overwhelming sources of i
nformation, available through
entering the appropriate combination of keywords in Google, AltaVista, and the like.

a Web Service Registry.

A Web Service Provider’s

responsibility is to create a Web Service description (in WSDL),

that Web
Service description to one or more means of Discov
ery (e.g. a UDDI Registry), and have the Web Service ready
to receive messages from Web Service Requesters (WSRs). A WSR
(discovers), possibly through one of
the many available service registries, the service description of interest and uses this ser
vice description to

to the Web Service provided by the Web Service Provider (WSP). Messages are exchanged conforming to a
particular protocol (specified in SOAP) and schema (specified in WSDL).

Figure 17.1

Web Service

A Web Service Registry's responsibility is to ‘advertise’ the Web Service descriptions (WSDL) published to it
by WSPs and to help WSRs search through its registry to find a service description of interest. In this context,
the service registr
y is similar to a matchmaker; once a match is found, it is no longer needed, and all subsequent
interactions are strictly between the WS and a WSR.


Strictly speaking, anything that has a URI.


In SOA, service provider should not be confused with what we usually refer to as Service Prov
ider in the sense of provider of
telecommunication end
user services. For example, AVIS is the service provider of the AVIS Car Rental Web Service, and
CinemaCity is the service provider for the online cinema ticket reservation Web Service.

17.2.1 What Problem is SOA Solving?

In its realization of Web Services, Service Oriented Architecture is a

distributed computing technology, one of
the many that are around. The main differentiating characteristic of SOA is that it is
loosely coupled
. Let us first
look at why a tightly coupled system has its problems.

Tightly coupled services are rigid. If yo
u try to wiggle one component out of the composition (e.g. to upgrade)
the entire thing caves in. As an example we take a look at the Parlay User Location service. Parlay interfaces are
defined using the object oriented computing paradigm, which supports t
he notion of a type system that is shared
among software components (objects that implement an interface). It is very difficult to take this interface and
for instance extend the address parameter to support the URI’s in addition to just MSISDN’s. Client a
nd server
need to be upgraded simultaneously. Updating the one but not the other breaks the system. In SOA terminology,
we call this brittle.

So what constitutes a loosely coupled system? The following description is taken from [Webber 2003].

A Web Servi
ce does not expose a set of operations, methods, or functions. Instead, it advertises the set of
structured messages that it will exchange. Perhaps the most important difference between service orientation and
object orientation resides in the way software

integration is achieved. As we’ve seen above, the concept of a
type system that is shared among software components is fundamental to object orientation. In the general case,
a hierarchy of interfaces has to be agreed upon in advance, before those softwar
e components can be integrated.

In contrast, services and their consumers achieve integration through the exchange of messages. The only thing
that is shared between them is the vocabulary used to define the structure of those messages. The absence of a
redefined type system enables loose coupling since no information needs to be shared among services and
consumers, before implementation and deployment (but only after discovery time).

Good service
oriented design mandates that all the information necessa
ry to invoke an action be contained in a
message, unlike object orientation where ‘chatty’ interactions between client and server object are the norm.

In object orientation, it is necessary to share an understanding about the underlying type system and t
behaviors that are realized through the sharing of interfaces/types. Type sharing results in systems that cannot
evolve easily, especially when they are distributed and not under a single entity’s control. The latter is, of
course, the case in the commu
nications environments we envision. The evolution of one interface/class may
break the entire system. The result is tight coupling, with brittle systems as its consequence.

Services on the other hand are deployed, implemented, and maintained independently
. They have well defined
boundaries and they communicate with others through messages. The only common understanding that is shared
between services is how to do message validation. Services define the message
exchange patterns and formats
of those message
s that they are willing to accept. Hence, loose coupling is achieved.

The Web Services paradigm is picking up where distributed object computing standards such as CORBA left
off, attempting to provide more flexible, and less structured, assembly of softwa
re components [Hull 2003]. A
primary goal of the Web Services paradigm, achieved through this loose coupling, is to support dynamic
discovery, selection, and composition of Web Services, be they atomic or themselves composite. Furthermore, a
key motivator
for this paradigm is the promise of supporting a high degree of customization and personalization
in the provision of services, e.g. through the use of intricate user profile and preferences data, and the use of
policy engines in the atomic Web Services [B
ultan 2003].

17.2.2 Sounds Great Doesn’t It?

We have introduced SOA as a loosely coupled distributed computing environment, aimed at overcoming some
of the drawbacks and limitations of other such environments. As with any new technology, SOA is being
sented as the panacea of service architectures, solving all our past problems, including the Ebola virus and
world hunger it seems. Superlatives like better, simpler, more flexible and more elegant are not uncommon.
However, is it really as simple as depic
ted in Figure 17.1 and described above? Or course not, nothing ever is.

Web Services, like any other technology area, has seen an explosion of the number of acronyms in use. The
Web Services core (WSDL, SOAP, UDDI) is continually being extended with propo
sals for new WS
. This is a natural phenomenon in any developing technology; one starts with the basics, then
gradually provides add
ons for those pieces of functionality expected of any mature technology (such as
security, reliability, et
c.), and finally numerous bells and whistles may be added once the technology has been
established in the mainstream. Some of the extensions however are intrinsically required as a result of the
chosen paradigm itself. The basic Service Oriented Architectu
re model, consisting of the core triangle, will not
yield any larger scale, realistic service. In order to be practical and scaleable, extensions are required which are
to be viewed separately from the add
ons, like security and reliability.

We are tryin
g to distinguish between those extensions that are intrinsic to the SOA paradigm, and those that
seem aimed at mimicking or re
creating all the CORBA Services. This chapter will try to show that the simple
paradigm of Web Services and Service Oriented Arch
itectures requires complicated and advanced extensions in
order to design and deploy realistic, high
performance, value added end
user services. This chapter will focus
on those intrinsic extensions.

17.3 Service Composition

We have seen that Service Ori
ented Architecture resolves the major drawback of object
oriented architectures,
namely the brittleness of tightly coupled services. However, like OO systems, the main objective of SOA
systems is still to design value added services out of distributed comp
onent services. Or, for instance in an OMA
context, to build value added mobile end
user applications out of OMA enablers. Service composition using
tightly coupled components is relatively straightforward, due to being tightly coupled. All the characteris
tics of
tightly coupled systems

chatty conversations, fine
grained programmatic client
server interfaces, shared type

allow larger, complex services to be composed out of individual service components. Because you
know how the components operate
, what they do and how they interoperate, you can ‘easily’ pre
design a
composite service, and its composite behavior is deterministic.

One could say that with tightly coupled systems, most of the workflow, or business process, is embedded in the
e definitions; that is, the client object invokes a method on the server object, and depending on the state


Policy, WS
Addressing, WS
Routing, WS
SecureConversation, WS
Reliability, Ws
Inspection, WS
Trust, WS
Privacy, WS
Federation, WS
Authorization, WS
Transaction, WS
Coordination, and many, many more, with new ones popping up
(footnote continued)

of the server object, a pre
defined number of response behaviors can be expected
. For example, if you look at
the Parlay interface specifications,
there are extensive sequence diagrams and state machines included. In
Service Oriented Architectures, this is not the case. Services are defined to operate as stand
alone or potentially
as peers, but without
a priori

knowledge of each other’s message sets,

of each other’s purpose, or even of each
other’s existence. That’s what loosely coupled means; that’s what message based means; that’s what service
oriented means.

Web Services are self
contained, web
enabled software components, capable of performing a
business activity.
The platform independent nature of Web Services, through the service oriented, message
based way they are
defined, opens the possibility to combine individual Web Services into more complex ones. Service composition
refers to the techniq
ue of composing arbitrarily complex services from relatively simpler services available over
the web.

With loosely coupled, message based services, composing a well behaved, aggregated service with deterministic
behavior is significantly more difficult. S
ervice composition becomes an issue, which is implicit to the paradigm
of Service Oriented Architectures; it was never such a large issue with other service paradigms. A solution will
have to be found.

17.3.1 Workflow

Different loosely coupled services a
re, or should be, designed and deployed independently from one another.
However, in a composed service they still need to collaborate during run
time. To do this, the loosely coupled
services have to expose their behavior (including the ordering between in
teractions) in a machine
readable (i.e.
formal) manner, beyond the messages they provide (i.e. beyond merely their WSDL definitions).

Web Service workflows are a set of Web Services that are executed in a structured way. A more traditional
definition of w
orkflow is the automation of a business process during which information or tasks are passed

constantly, and old ones being

combined or subsumed.


Strictly speaking this is not done in the interface definition, e.g., IDL does not have any possibilities to do this, but rat
her it is done in
informal (English) or (semi
) formal (UML state transition diagrams, message sequence di
agrams) design or specification documents that
describe the semantics/behavior of the interfaces/methods.

from one participant to another for action, according to a set of procedural rules. This latter definition reveals
that the problem of workflow predates the Web Se
rvices technology. Workflow has a history that dates way
back, but formal thinking on workflow and workflow tools became important with assembly line planning and
warehouse systems planning, ordering, and shipping. This formal thinking has led to research
in the area of
workflow languages or process description languages. Much of the more recent research activity in the area of
service composition builds on this older work.

WSDL describes a Web Service via its set of visible operations, i.e. the set of mes
sages it can send and receive.
The interaction of composite Web Services can be modeled as conversations, i.e. the global sequence of
messages exchanged by the component Web Services. Since Web Services are stateless in nature,
complementary specifications

are being proposed to provide business process related state control. Workflow
then is the technique to specify that a message sent by one component Web Service is received by another
component Web Service, etc.

Figure 17.2

Workflow and Web Service composition

Figure 17.2 shows an example where a single StockPurchaseFlow Web Service is composed out of three Web
Service components (‘LiveQuotes’, ‘VirtualExchange’ and ‘e
Accounting’), using a workflow applied to the

of the three components. Each of the Web Service components performs a function (getStockprice,
checkCredit, and buyStock respectively). The ‘composed service’ needs to have a logical structure on the
sequence of message exchanges. First, one obtains the
stock quote, then the user’s credit is checked for
sufficient funds, and if successful, the stock purchase is made.

Web Service Composition enables Web Services to be strung together in predefined patterns. These patterns, or
message exchange patterns (ME
Ps), are a type of design pattern that describe distributed communications. The
patterns describe the interactions between the different participants in the network. The most common MEPs are
way’ (send and forget) and ‘request
response’. More sophisti
cated and complicated patterns are available
and can be classified as, for example, basic flow control patterns, advanced branching and synchronization
patterns, structural patterns, and state
based patterns. The interested reader is referred to [Aalst 200
3] for more
information on workflow patterns.

17.3.2 Orchestration and Choreography

The initial work on Web Service Composition draws heavily on earlier workflow technologies, as outlined
above. With the growing importance of this topic in Service Orie
nted Architectures, two new terms have been
brought into vogue: Orchestration and Choreography.

Orchestration refers to an executable business process. Orchestration describes how Web Services can interact at
the message level. Choreography is more collab
orative in nature, where each party involved in the process
describes the part they play in the interaction. Choreography tracks the sequence of messages that may involve
multiple parties, where no party truly ‘owns’ the conversation. Orchestration differs

from Choreography in that
it describes a process flow between services, controlled by a single party [Peltz 2003].

One can apply here the analogy of an orchestra conductor, who is in control of all the musicians and conducts
them in order to deliver a pi
ece of music collectively, whereas the dancers in a ballet perform jointly to a
choreography, each acting out a part that together composes the dance performance. We will now continue by
briefly describing the two most popular Web Service composition langu

The Web Service Choreography Interface (WSCI, pronounced ‘Whiskey’) is a choreography language, defined
as an extension to WSDL, which describes the messages exchanged between Web Services that participate in a
collaborative exchange. It should be o
bvious that because of the Choreography approach (i.e. the collaborative
nature), WSCI requires each Web Service component of the composition to define its own WSCI interface.

The Business Process Execution Language for Web Services (BPEL4WS, or BPEL for
short, pronounced ‘bee
pel’) provides an XML
based grammar for describing the control logic required to coordinate component Web
Services participating in a workflow, and is layered on top of WSDL
. BPEL4WS defines how the WSDL
operations should be sequenc
ed, describing an executable process from the perspective of one of the

17.3.3 The OMA PEEM Connection

This section attempts to understand certain concepts in OMA [Brenner 2005] using the technologies explained
above. A central concept in t
he OMA Service Environment (OSE) is the Policy Enforcer (PE), and its
realization in the Policy Evaluation, Enforcement and Management enabler (PEEM) [Qutub 2005]. The PE
logically intercepts the request from an application (Web Service Requester) to a (co
mposed) service, and
subsequently delegates certain specified tasks or functions to other OMA enablers (the component Web
Services). The PEEM enabler, as a realization of the PE, enforces the sequence of message exchanges, which
OMA enablers need to perfor
m before other OMA enablers can continue with processing the service request.

One way of looking at the role of PEEM in the OSE is to view PEEM as the one entity in control of the
workflow among OMA Enabler components. Delegation in this sense equals orch

17.3.4 Issues with Service Composition

Web Service Composition, through Orchestration and Choreography, is a necessary aspect to Service Oriented
Architecture, and allows one to build complex, value added services out of service components. Th
ere are a


BPEL4WS is a successor of XLANG and WSFL, representing a compromise between the two and as such enjoying powerful industry

number of complicating factors and issues with service composition, some of which will be briefly outlined in
this section.

Message based services mostly use synchronous communication, with exchange patterns like send
or request
onse. Chaining such multiple services together in a workflow, the response time and availability
of the composed service can easily be degraded by one of the service components [Tatemura 2003].
Specification candidates like WS

and WS

address these issues.

Service Level Agreements (SLA) is as important for Web Services as it is for any other service paradigm,
especially when component Web Services, each with their own individual SLA (as each is offered potentially by
a different

WSP), are integrated with workflows. What statements can you make about the overall, composed
SLA? Is the SLA as strong as the weakest link in the workflow? Or is this perhaps dependent on the Message
Exchange Pattern? Interesting questions for which no c
onclusive answer currently exists.

Transaction control over the components in a workflow is an important aspect as well. Transactions may need to
be atomic, performed at most once, etc. Specification candidates like WS

and WS

dress these issues.

Another issue with composing larger services out of service components in a workflow is security. In order to
ensure security for the entire composition, each component needs to be trusted.

Web Service components must be trusted, not
only with respect to security, but also with respect to
performance. Therefore, for large scale, carrier grade telecommunication services it may not be realistic to
compose services out of just any component with suitable functionality out there on the web
. A WSR may opt to
only select Web Service components within a federation, or a set of pre
arranged partner providers.

17.4 Semantic Web Services







So far we have seen that the basic core of Web Service standards will provide the Web Services infrastructur
that let Web Services interact. More recently proposed standards, such as WSCI and BPEL4WS, provide
mechanisms for describing how multiple Web Services can be assembled to participate in a shared business
process. However, their focus remains on composit
ion at the syntactic level. Composition is ‘easy’, provided
you know which components you have, what they do, and where to find them. But how do you know all this?

Finding Web Service components is part of the process called discovery, and is key to the c
oncept of Service
Oriented Architectures. We have seen that UDDI, out of the core of WSDL/SOAP/UDDI, can be used for this.
UDDI allows businesses to register their contact points, and a host of useful information about Web Services,
such as the name, a poi
nter to the provider of the service, a port where to access the service, and binding
information to allow Web Services to interact.

The limitation of UDDI is its lack of an explicit representation of the capabilities of Web Services
. The result
is that U
DDI supports the discovery of essential information about the Web Service,
once it is known

that the
Web Service exists. But it is impossible to locate a Web Service only on the basis of what it does [Sycara 2004].
Discovery is inherently a semantic proble
m, because it has to abstract from the superficial differences between
representation of the Web Services provided, and the Web Services requested to recognize semantic similarities
between the two [Paolucci 2002]. Semantically described Web Services can b
e discovered based on the
capabilities they offer, and furthermore, logic inference can be performed to match the capabilities requested
with the capabilities offered

Semantic Web Services have a use beyond just discovery. Once you have discovered a Web

Service component
that provides the service you need, you might still have semantic differences in the message formats (interfaces),
e.g. how you identify a user (MSISDN, yahoo id, SIP id, etc.). Semantic Web Service technologies should assist
with this,
thereby allowing even looser coupling.


Imagine service names like User Location service, GeoLocation Service, Address Finder, Proximity service, Mobility Management

service, Map
Finder, WhereAmI, FindMe, etc. Presumably, all have to do with ‘location’ but exactly what their capabilities are is not
clear, even if, for instance, it is known that the service takes ‘person’ as input, and provides ‘location’ as output.

17.4.1 Semantic Matching versus Syntactic Matching

Trying to find a document on the web is exactly the same problem, based on the limitations of keyword
searches. Be too specific and you get zero results, wher
eas being too general provides you with way too many

In the late 1990s, within the World Wide Web Consortium (W3C

), activities started on the definition of the
Resource Description Framework (RDF). The RDF is an infrastructure that enables the enco
ding, exchange, and
reuse of structured metadata. Metadata, or data about data, improves the discovery of and access to globally
distributed and essentially disparate information. Originally, RDF was intended to represent metadata about web
resources, such

as the title and author of a web document, the last modification date of a web page, copyright
and licensing information about a web document, etc. Modeling the web as a big library, and mimicking how
you find a book in a library by providing metadata lik
e title and author, allows you to find the resources you are
looking for. RDF does the same for the web. Figure 17.3 provides an example of RDF use on the web.


Semantic marku
p may allow inference logic to determine for instance that an offered service performs part of the tasks of the
requested service (sub
service) or provides the requested tasks and more (super
service), or even that the offered service conforms to
an update
d capability set compared to the requested service. For example, when requesting a ‘restaurant service’ it is useful to know
that a ‘pizza place’ is a ‘kind_of’ restaurant. Based on syntactic matching only, such an inference could not be made.

Figure 17.3

Example of the use of RDF on the web

As Web Servic
es are considered web resources as well, the model of the web as a collection of documents is
extended to the model of the web as a collection of services. Web Services are defined in terms of the messages
they exchange, and the messages in turn are define
d using WSDL, which is XML based. Although WSDL offers
sufficient expression power to define Web Services in terms of their messages, it lacks any real form of
information for reasoning about what the inputs and outputs of a Web Service are, and indeed wha
t those inputs
and outputs actually mean. The major problem with matching is that it is unrealistic to expect service
advertisements (registered services) and service requests to be equivalent, or that there even exists a service that
fulfills exactly the
needs of the request
. This problem of syntactic interoperability versus semantic
interoperability is inherited from the interface definition language, in this case XML.

As an example, consider two XML descriptions of a service for ordering goods on the w
eb. The data parameters
<price> and <unitprice> may be semantically the same, but certainly not syntactically. This also shows why
XML, and therefore also WSDL, themselves are not suited to serve as semantic language, since replacing
<price> with <unitpric
e> would break the DTD or XSD. Other examples are (name, identity), (person,
individual), or (location, position) etc.

Truly seamless interoperability between Web Services that have not been pre
designed to work together (recall,
they are loosely coupled)

require mechanisms to describe their own capabilities and understand other Web
Services’ capabilities.

Extending Web Services with semantic markup and reasoning yields the new field of Semantic Web Services
A Semantic Web Service is defined as a Web Se
rvice whose description is in a language that has well
semantics. Therefore, it is unambiguously computer interpretable, and facilitates maximal automation and
dynamism in Web Services discovery

and composition [Sycara 2004]. An important concept
to realize
Semantic Web Services is that of Ontologies.

17.4.2 Ontologies Introduced

Before we dig further into the, admittedly rather heavy, topic of the nature of ontologies and what technologies
are available, let’s recall what ontologies are for and
why we need them in Service Oriented Architectures.
Ontologies enable knowledge sharing. In SOA, we use knowledge sharing to facilitate information sharing, or
rather service composition.

We have seen that currently the definition of Web Services (in WSDL
) only allows for syntactic matching
between an advertised Web Service and a requested Web Service. In order to perform a more useful capability
based matching, one needs some semantic description of the Web Service as well. The idea is to add semantic
kup to the Web Service descriptions, i.e. adding WSDL constructs that tell you something about the
capabilities of the Web Service to the existing WSDL service description. The terms of the semantic markup
(the vocabulary) are defined in an ontology. Such
an ontology is basically a taxonomic hierarchy of terms that
allows you to perform logic inferences on those terms as well.


Try lookin
g for a stock quote service when the only services advertised in the registry are financial news providers.


Semantic Web Services originated by combining the Web Services paradigm with another new paradigm, the Semantic Web. The
Semantic Web was launche
d by Tim Berners
Lee (‘The Semantic Web’,
Scientific American
, May 2001) as the desire to add logic and
representation to the web.


Dynamic Service Discovery has its roots in grid computing. Computational Grids enable the sharing, selection, and

aggregation of a wide
variety of geographically distributed computational resources (such as supercomputers, compute clusters, storage systems, dat
a sources,
instruments, people) and presents them as a single, unified resource for solving large
scale and
data intensive computing applications (e.g.
molecular modeling for drug design, brain activity analysis, and high energy physics). Just as an Internet user views a unifi
ed instance of
content via the web, a grid user essentially sees a single, large virtua
l computer.

17.4.3 Ontologies Explored Further

Work on ontologies dates back to the early philosophers. The
American Heritage

Dictionary of
the English

will tell you that ‘ontology’ is ‘the branch of metaphysics that deals with the nature of being’. That is
a bit too deep for our purposes. As a research field for languages and computing, the more recent work on
ontologies is based on
Artificial Intelligence
, database theory
, and natural language processing

Ontologies are defined as a ‘representation of a shared conceptualization of a particular domain’. This means
that they provide a shared and common understanding of a particular

domain that can be communicated across
distributed systems; that is, knowledge sharing in distributed systems. Ontologies provide a vocabulary for
representing and communicating knowledge about some topic and a set of relationships that hold among the
ms in that vocabulary. Typically, an ontology contains a hierarchical description of important concepts in a
domain, and describes crucial properties of each concept through an attribute
value mechanism.

Terms whose meaning is defined in ontologies can b
e used in semantic markup that describes the content and
functionality of Web Services. Therefore, a Web Services ontology facilitates knowledge sharing among Web

For example, the service description (WSDL file) of a Web Service for a used car d
ealer can be semantically
marked up (WSDL constructs added to the WSDL service description) by identifying this particular service as a
used car dealer service. The ontology will then tell you what a ‘used car dealer’ is, and furthermore that a ‘used
car d
ealer’ is a ‘special kind’ of ‘car dealer’ (and that you cannot trust them of course).


The philosophy definition of ontologies deals with existence. So how come this term was adopted in AI? For AI systems, what
‘exists’ is that which can be represented, and ontologies are the representation of knowledge.


As an example of the
applicability of semantic information to database theory, let us have a look at long
lived database applications,
where stored data are considered worth surviving changes in the database schema. Schema evolution becomes an issue. Database
schema evolution
is the mechanism of performing modifications to the schema (i.e. representation) without modifications to the data
(i.e. content). Semantic mark
up, in addition to representation mark
up, is a helpful tool in schema evolution.


Many contributions in the a
rea of ontologies come from the area of Artificial Intelligence and Language Processing. Terms like
Description Logic
Based Reasoning, Case
Based Reasoning, and for example situation calculus, automata, Mealy machines, Petri
Nets, Transaction Logic, tempor
al logic, etc., keep popping up. The chapter, with all due respect of course, desperately tries to steer
way clear of this and happily leaves this field to the researchers.

Ontologies have been defined for a vast range of domains, many of which are listed at the DAML Ontology
Library [DAML 2004a]. Some examples include ontologies on area c

(e.g. name, number, state, operating
company, etc.), beer
(e.g. porter, ale, pilsner, etc.), geo location

(e.g. latitude, longitude, lastChangedDate,
etc.), GPS

(e.g. lat, long, elevation, zone, etc.), people

(e.g. name, age, gender, marital stat
us, home address,
etc.), and time zone

(e.g. region, offset, day light saving, etc.).

Back to our problem domain, semantic markup can be used to manage capability
based discovery as well as
managing interactions between Web Services. Semantic Web Service
s can be viewed as a way to extend the
capabilities of Web Services in the direction of dynamic interoperability. The underlying theme is the
overcoming of interoperability limitations arising from the need for server and client developers to agree in
nce on the syntax and semantics of interactions, thereby making it possible for clients to utilize Web
Services successfully without prior arrangements [DAML 2004b]. One objective behind Semantic Web Services
is to provide languages for expressing the capa
bilities of Web Services and making that information available
and accessible to computer programs. Such languages have well
defined semantics and inferential procedures
that let computer programs draw inferences from the languages’ statements [Paolucci 20

The following is an example of a composed service where one preferred Web Service component is unavailable
but by using semantic markup, two new components can be used to achieve the same instead. An existing Web
Service obtains the latitude
e coordinates for a user identified by his phone
number. In case this
component is unavailable, the same functionality can be provided by the combination of obtaining an address
for the user in the phone
directory and subsequently translating the address i
nto a lat
long pair. This example
can be useful in scenarios where during service design time it turns out that a desired component is unavailable
or too expensive, or where during service deployment and operation the component becomes unavailable and
s to be replaced.







Another example is where dynamic discovery of Semantic Web Services can be used to personalize an end
service. Consider the scenario where a sendSMS message is dynamically replaced by a sendEmail message in
the workflow, based on th
e preference or presence and availability of the end
user. In the ‘old days’, either such
behavior would have to be hard
coded, or, for instance using Parlay/OSA, one envisioned a sendMessage
component where the service mediation gateway then makes the dec
ision to send an SMS or email.

Summarized, Web Services may be able to parse information that they exchange, but fail to understand the
content of that information. By extending the Web Service description with semantic information we can
alleviate and po
ssibly remove this problem, by linking the data exchanged to a set of ontologies, which specify
the conceptual framework that helps with the interpretation of the data.

17.4.4 Ontology Languages: DAML
S and OWL

We have seen that Semantic Web Services (se
mantically marked up Web Services, using terms defined in an
ontology) can be viewed as a way to extend the capabilities of Web Services in the direction of dynamic
interoperability. In order to achieve this we need to introduce semantic mark
up to service

description languages
and service discovery mechanisms; we need a semantic markup language or an ontology language. Such a
language can then be used to extend the service descriptions in WSDL and the service registrations in UDDI.
For this purpose, we’ll
describe the Web Ontology Language (OWL) in this sub

The first activity that led to OWL was the Resource Description Framework (RDF), described at the start of this
section. When the model for the web changed from a collection of documents to a c
ollection of services,
DARPA extended RDF into DAML

the DARPA Agent Markup Language
. As the technology grew in
popularity, DAML evolved into OWL, and hence for the remainder of this chapter we’ll only look at OWL.
Figure 17.4 shows the layered approach
to the definition of an ontology language.


DAML can be considere
d as DAML = RDF + XML + Ontologies.

Figure 17.4
Layered approach to Ontology Language definition


ontology [DAML 2003, Richards 2003] is a Web Service ontology, which supplies Web Service
providers with a
core set of markup language constructs for describing the properties and capabilities of their
Web Services in unambiguous, computer
interpretable way. The OWL
S ontology is conceptually divided into
three sub
ontologies for specifying: 1) what a service d
oes; 2) how the service works; and 3) how to access the
service. This is depicted in Figure 17.5 and described below:


Service Profile

describes what the Web Service does so that it can be discovered at matchmaking
time. It contains the contact informa
tion of providers, an extensible set of features that specify
characteristics of the Web Service, and a functionality description by specifying the inputs, outputs,
preconditions, and effects of the Web Service.


Service Process

Service Model

s the internal working of the Web Service in terms of the
internal processes, their process model, and the internal data flow. Although this information can be
used at discovery time, it is aimed to assist Web Service execution monitoring.


S = OWL for Services.


Service Grou

specifies the operational level details of the Web Service by linking the
conceptual level descriptions to the WSDL description of the Web Service. The Grounding basically
provides a mapping from OWL
S to WSDL and details how to access the Web Servic

Figure 17.5

level ontology for services

This layered description is used as follows. First the Profile is inspected to see if the Web Service has the
desired functionality and capability. Further, the Service Model
can give more detailed information about how
the Web Service works internally. The Service Profile provides the information needed to discover a Web
Service, whereas the Service Model provides enough information to make use of a Web Service. Finally, if th
Web Service conforms to the requirements, the Grounding specifies the implementation details needed for
executing the service.

17.4.5 Issues with Semantic Web Services

Dynamic discovery of web service components during service operation may be time con
suming. To improve
availability and performance, a service integrator could incorporate various asynchronous execution techniques
such as data caching, prefetching
, and replication [Tatemura 2003].

With syntactic matching, either there is a fit or there
isn’t. With semantic matching two services may fit exactly,
almost exactly, pretty good, only a bit, or really not very well at all. In the case of multiple discovery results, the
service integrator is now faced with the problem of determining which is the

best fit. Is a fit in a certain
capability category or a certain subset of messages ‘better’ than a fit in other capability categories or set of

There are without doubt a lot more issues with Semantic Web Services, however, this chapter does no
t explore
these any further.

17.5 And Now Back to Telco

We are reaching the end of this chapter. So far we have introduced Service Oriented Architecture and Web
Services, and argued that the paradigm requires extension specifications and additional techn
ologies beyond the
simple publish/find/bind triangle and the WSDL/SOAP/UDDI core specification set, in order to build large
scale, carrier grade Web Service deployments. The necessary extensions we have identified are ‘Web Service
Composition’ and ‘Semanti
c Web Services’. Our discussions covered paradigms and enabling technologies,
mainly as they apply to the web. Now let us look at a different application area for these new concepts that is of
specific interest to us; the telecommunications services domain

17.5.1 Do these New Paradigms apply to Telco?

A good question to start with is to ask whether current telecommunication services are loosely coupled. We all
know that traditionally they aren’t. For instance for IN services, all service components are s
pecified and


Prefetching is a technique in common use with browsers, where browser idle time is used to download or prefetch documents tha
the user might visit in the near future.
The prefetched content

gets stored into the browser's cache, and will therefore appear quickly
once the user goes to the page containing the prefetched content.

designed with a very specific operation and interaction in mind. The design time takes up a significant chunk of
the development life cycle, which itself may span across months.

So do we expect Telco services to become completely loosely coup
led? Is all that level of sophistication really
necessary for instance for Parlay Web Services, or Web Services in OMA? For these, are we really envisaging
automated services to be composed on the fly, without human intervention? Without the usual levels o
testing, etc.? When a telecommunications Service Provider designs a service, do they really rely on automated
discovery and composition/choreography? Probably not to the extent as can be expected for Internet services.
Typically, regression testing a
nd interoperability testing of Telco services before rollout in a live network is very
extensive. Telco services are somewhat special in this respect, compared to enterprise services. But then again,
perhaps sometimes the Telco world thinks they are too sp
ecial. For instance, financial institutions such as banks
have very large scale, highly secure, and reliable high performance systems as well. However, the authors
believe we can safely say that in order for Telco services to be applicable to the 3rd party

development, over
Internet, cross administrative domain deployment, business
business models, they have to be more
loosely coupled than they are now.

One way not to proceed is to merely provide existing Telco service assets with a Web Services wra
pper and
deploy them in a Web Services infrastructure. In this context, SOA is sometimes jokingly expanded as ‘Save
Our Assets’. The assets will ‘speak’ Web Services, but are as tightly coupled as they were before. That is not
what is meant by ‘Telco needs

to be more like Internet’. The SOA paradigm was originally very popular (and
still is) within the Enterprise Application Integration (EAI) domain, where enterprise applications are integrated
through a Web Services infrastructure. Providing existing Telco

service assets with a Web Services wrapper
may offer a first step for a Service Provider or Network Operator to evolve towards a Service Oriented
Architecture while leveraging existing investments, but in order to fully benefit from the paradigm, decoupli
needs to take place. The next step must be taken. Let us look at whether Service Composition and Semantic
Web Services apply to the Telco domain as well.

How realistic is dynamic composition of Web Service components in the case of composed Telco servi
ces? Will
value added services still be pre
defined? You bet, but probably not to the extent as say IN services. Individual
services may not be pre
defined anymore, but perhaps there will be common, reusable communication patterns
and workflow templates, w
here certain component Web Services are replaceable. Services need to be agile,
there will be more dynamics, but in order to keep this manageable we might see more automated processes
making use of pre
defined patterns and templates.

How realistic is dyna
mic search and discovery of Web Service components, based on semantic markup, in the
case of composed Telco services? Aren’t the services interfaces, including their semantics, standardized, by the
likes of the Parlay Group, 3GPP, or OMA working groups? We
ll, perhaps we could envisage the use case of
finding a new version of a known Web Service component with a new endpoint, or an extended set of
endpoints? Or finding an upgraded implementation, which implements the use of more parameters (or more
values fo
r a given parameter)? Or replacing a Parlay Location enabler with a Liberty Alliance GeoLocation
enabler? Perhaps we are moving away from this strict level of interface standardization. If that is the case, then
ontologies might help. Of course that does m
ean that we are pushing the problem from which service to
standardize to which ontology to standardize, and towards interoperability of ontologies. Ontologies will have
their advantages beyond the current service paradigm, but they are certainly not a silv
er bullet. Using some
existing or Telco specific ontologies will help interoperability and ‘evolve
ability’ of Telco Web Service
components a lot. Using ontologies for semantic discovery to include information on, e.g., which MSISDN the
location service ca
n provide addresses for, or what would be charged, will provide a very helpful extension to
current discovery mechanisms.

17.5.2 Wrapping Up

We have seen that Telco services need to be decoupled (looser coupled, though perhaps not completely loosely
pled) in order to reap all the benefits provided by Service Oriented Architectures, and to be more like
Internet services. Certain enabling technologies from the Web Services realm can be applied and used to achieve
this objective.

Starting with the Parla
y initiative, we have effectively extended network resources and capabilities to the third
party domain and enterprise world. Web Services are typically discrete (e.g. buy a book, charge my credit card,
give a stock quote). Web Services technologies and in
frastructure were originally designed for these discrete
services. Telco services however are more conversational and session
oriented in nature. Therefore, not all Web
Services considerations apply. But then again, we see Web Services being developed for
such Telco domains,
and we see Web Services technologies and infrastructure evolving to address these more involved services as
well. At the same time, we see more interest in small, almost atomic Parlay X like Web Services, rather than
highly capable Parl
ay Service Capability Features. Telco Web Services are becoming more discrete as well. The
evolution towards Web Services has already started.

From a Service Provider perspective, such loosely coupled Web Service building blocks allow services to be
ed through any user
Internet interaction that can take place over any access technology, be it cellular,
WiFi, DSL, etc. From a Network Operator perspective, they can now offer some non
Telco related services like
buying online tickets (which is general
ly no different from any other service provider offering something similar
over the Internet) in addition to providing Web Service enablers for the resources in their networks (which may
serve as value added differentiator).

17.6 Summary

This chapter in
troduced Web Services and Service Oriented Architecture, and argued that in order to build
realistic, large scale, carrier grade Web Service deployments, a number of extension specifications and
additional technologies are required. We then explored how th
is service paradigm and its enabling technologies
apply to the telecommunication services domain.


[Aalst 2003] Aalst, W.v.d., ter Hostede, A., Kiepuszewski, B. and Barros, A., ‘Workflow Patterns’,
and Parallel Databases
(1), Jul
y 2003, 5


[Bultan 2003] Bultan, T., Fu, X., Hull, R. and Su, J., ‘Conversation Specification: A New Approach to Design
and Analysis of E
Service Composition’, Proceedings of 12th International World Wide Web Conference
(WWW2003), May 2003, Budapest, H
ungary, pp. 403

[DAML 2003] The DARPA Agent Markup Language Homepage [online]; OWL Services Coalition, ‘OWL
Semantic Markup for Web Services’, December 2003, URL:
[accessed July 2005]

[DAML 2004a]
The DARPA Agent Markup Language Homepage [online]; ‘DAML Ontology Library’, April
2004, URL: [accessed July 2005]

[DAML 2004b] The DARPA Agent Markup Language Homepage [online]; Semantic Web Services Initiative

Committee, ‘Semantic Web Services Architecture Requirements’, July 2004, URL:
requirements.html [accessed July 2005]

[Hull 2003] Hull, R., M. Benedikt, and V. Christophides, J. Su, ‘E
Services: A Look Behind the Cur
Proceedings of the 22nd ACM SIGACT
SIGART, Symposium on Principles of Database Systems
(PODS), June 2003, San Diego CA, USA, pp. 1
14, ACM Press, New York

[OMA 2004] Open Mobile Alliance, ‘OMA Web Services Enabler (OWSER): Overview’, Approve
d Version
1.0, July 2004, URL:

[Paolucci 2002] Paolucci, M., Kawamura, T., Payne, T. and Sycara, K., ‘Importing the Semantic Web in
UDDI’, Proceedings of E
Services and the Semantic Web Workshop, 2002, Toronto, Canada, p
p. 225

[Paolucci 2003] Paolucci, M. and Sycara, K., ‘Autonomous Semantic Web Services’,
IEEE Internet Computing
(5), Sept
Oct 2003, 34


[Peltz 2003] Peltz, C., ‘Web Services Orchestration and Choreography, a Look at WSCI and BPEL4WS’,
(10), October 2003, 46


[Qutub 2005] Qutub, S.S., and Weerasekera, I.N., ‘Advances in Policy Management Standardization in Mobility
Bell Labs Technical Journal
, May 2005, 77


[Richards 2003] Richards, D. and Sabou, M., ‘Semantic Mar
kup for Semantic Web Tools: A DAML
description of an RDF
Store’, Second International Semantic Web Conference (ISWC2003), Florida, USA, 20

23 October 2003, proceedings published by Springer as LNCS 2870 (2003), pp. 274


[Sycara 2004] Sycara, K., Paol
ucci, M., Ankolekar, A. and Srinivasan, N., ‘Automatic Discovery, Interaction,
and Composition of Semantic Web Services’,
Journal of Web Semantics
(1), 2004, 281


[Tatemura 2003] Tatemura, J., Hsiung, W. and Li, W., ‘Acceleration of Web Service Workf
low Execution
through Edge Computing’, the Twelfth International World Wide Web Conference (WWW2003), May 2003,
Budapest, Hungary, WWW2003 Alternate Paper Tracks Proceedings

[Webber 2003] Webber, J. and Parastatidis, S., ‘Demystifying Service
Oriented Arc
hitecture’, Web Services
Journal [online],
(11), November 2003, URL: http://webservices.sys
- [Accessed July