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 deployments. 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 realistic, 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 shorter 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
cost-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 problems 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 inevitable 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 enabling 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 direction 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
chapter 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 tries 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 available1. As such this chapter may not
provide 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 alien.
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. Basically, 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 identified on the web, anything that has a URL2.
As described in OWSERv1.0 [OMA 2004], in its simplest form, a SOA can be depicted as the well-known
triangle (Figure 17.1). A Web Services-based architecture contains three functions:

a Web Service requester (WSR);

a Web Service (offered by a Web Service Provider, or WSP); and
1
This chapter draws liberally from many resources in the field of research and academia, as well as more popular web publications.
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 information, available through
entering the appropriate combination of keywords in Google, AltaVista, and the like.

a Web Service Registry.
A Web Service Provider’s3 responsibility is to create a Web Service description (in WSDL), publish that Web
Service description to one or more means of Discovery (e.g. a UDDI Registry), and have the Web Service ready
to receive messages from Web Service Requesters (WSRs). A WSR finds (discovers), possibly through one of
the many available service registries, the service description of interest and uses this service description to bind
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).
Web
WebService
ServiceRegistry
Registry
Find
Publish
Web
WebService
ServiceRequester
Requester
Web
WebService
Service
Bind
Web
WebService
ServiceProvider
Provider
Figure 17.1 Web Service Architecture
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 registry 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.
2
Strictly speaking, anything that has a URI.
In SOA, service provider should not be confused with what we usually refer to as Service Provider 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.
3
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 you 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 the 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 and 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 Service 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 software 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
predefined 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 necessary 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 the
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 communications 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 messages 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 software 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 [Bultan 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
presented 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 depicted 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 proposals for new WS-*
specifications4. 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, etc.), 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 Architecture 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 trying 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 Architectures 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 Oriented 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 component 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 characteristics of
tightly coupled systems – chatty conversations, fine-grained programmatic client-server interfaces, shared type
system – 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
interface definitions; that is, the client object invokes a method on the server object, and depending on the state
4
WS-Security, WS-Policy, WS-Addressing, WS-Routing, WS-SecureConversation, WS-Reliability, Ws-Inspection, WS-Trust, WSPrivacy, 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 5. 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 technique 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. Service 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 are, 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 interactions) 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 workflow is the automation of a business process during which information or tasks are passed
constantly, and old ones being combined or subsumed.
5
Strictly speaking this is not done in the interface definition, e.g., IDL does not have any possibilities to do this, but rather it is done in
informal (English) or (semi-) formal (UML state transition diagrams, message sequence diagrams) 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 Services 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 messages 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.
“VirtualExchange”
StockPurchaseFlow
Web Service
Exchange.com
buyStock
getStockPrice
“LiveQuotes”
checkCredit
Quote.com
getStockPrice
“e-Accounting”
buyStock
Credit.com
checkCredit
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
messages 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 (MEPs), 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
‘one-way’ (send and forget) and ‘request-response’. More sophisticated 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 2003] 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 Oriented 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 collaborative 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 piece 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 languages.
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 obvious 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 6. BPEL4WS defines how the WSDL
operations should be sequenced, describing an executable process from the perspective of one of the
participants.
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 the 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 (composed) 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 perform 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 orchestration.
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. There are a
6
BPEL4WS is a successor of XLANG and WSFL, representing a compromise between the two and as such enjoying powerful industry
backing.
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-and-forget,
or request-response. 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-ReliableMessaging7 and WS-Eventing8 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 conclusive 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-Coordination9 and WS-Transaction10
address 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
7
ftp://www6.software.ibm.com/software/developer/library/ws-reliablemessaging200403.pdf
http://ftpna2.bea.com/pub/downloads/WS-Eventing.pdf
9
ftp://www6.software.ibm.com/software/developer/library/ws-coordination.pdf
10
http://www-106.ibm.com/developerworks/webservices/library/ws-transpec/
8
So far we have seen that the basic core of Web Service standards will provide the Web Services infrastructure
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 composition 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 concept 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 pointer 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 11. The result
is that UDDI 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 problem, 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 be discovered based on the
capabilities they offer, and furthermore, logic inference can be performed to match the capabilities requested
with the capabilities offered 12.
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.
11
Imagine service names like User Location service, GeoLocation Service, Address Finder, Proximity service, Mobility Management
service, MapFinder, 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-based
searches. Be too specific and you get zero results, whereas being too general provides you with way too many
hits.
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 encoding, 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 like 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.
12
Semantic markup 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 updated 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.
http://purl.org/dc/elements/1.1/publisher
subject
http://www.parlay.org
predicate
object
“Parlay Home Page”
predicate
http://purl.org/dc/elements/1.1/title
object
“The Parlay Group”
Figure 17.3 Example of the use of RDF on the web
As Web Services 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 defined 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 what 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 request13. 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 web. 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 <unitprice> 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 14.
A Semantic Web Service is defined as a Web Service whose description is in a language that has well-defined
semantics. Therefore, it is unambiguously computer interpretable, and facilitates maximal automation and
dynamism in Web Services discovery15 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
markup 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.
13
Try looking 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 launched by Tim Berners-Lee (‘The Semantic Web’, Scientific American, May 2001) as the desire to add logic and
knowledge-representation to the web.
15
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, data 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 unified instance of
content via the web, a grid user essentially sees a single, large virtual computer.
14
17.4.3 Ontologies Explored Further
Work on ontologies dates back to the early philosophers. The American Heritage® Dictionary of the English
Language 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 Intelligence16, database theory17, and natural language processing18.
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
terms 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 be used in semantic markup that describes the content and
functionality of Web Services. Therefore, a Web Services ontology facilitates knowledge sharing among Web
Services.
For example, the service description (WSDL file) of a Web Service for a used car dealer 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 dealer’ is a ‘special kind’ of ‘car dealer’ (and that you cannot trust them of course).
16
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.
17
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.
18
Many contributions in the area 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, temporal 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 codes19 (e.g. name, number, state, operating
company, etc.), beer 20(e.g. porter, ale, pilsner, etc.), geo location21 (e.g. latitude, longitude, lastChangedDate,
etc.), GPS22 (e.g. lat, long, elevation, zone, etc.), people23 (e.g. name, age, gender, marital status, home address,
etc.), and time zone24 (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 Services 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
advance 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 capabilities 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 2003].
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-longitude 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 into 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
needs to be replaced.
19
http://www.daml.org/2002/02/telephone/1/areacodes-ont
http://www.cs.umd.edu/projects/plus/DAML/onts/beer1.0.daml
21
http://www.daml.org/2001/02/geofile/geofile-ont
22
http://orlando.drc.com/SemanticWeb/DAML/Ontology/GPS/Coordinate/ver/0.1.0/GPS-ont.daml
23
http://www.daml.org/ontologies/419
24
http://orlando.drc.com/SemanticWeb/OWL/Ontology/TimeZone/ver/1.0.0/TimeZone-ont.owl
20
Another example is where dynamic discovery of Semantic Web Services can be used to personalize an end-user
service. Consider the scenario where a sendSMS message is dynamically replaced by a sendEmail message in
the workflow, based on the 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 decision 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 possibly 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 (semantically 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-section.
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 collection of services,
DARPA extended RDF into DAML – the DARPA Agent Markup Language25. 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.
25
DAML can be considered as DAML = RDF + XML + Ontologies.
Ontology Language for Services
Ontology & Description Logic
Defining Taxonomies
Relating Statements
Syntax Layer
WWW Protocol
DAML-S/OWL-S
DAML+OIL/OWL
RDFS (RDF Schema)
RDF
XML
HTTP
Figure 17.4 Layered approach to Ontology Language definition
The OWL-S26 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 does; 2) how the service works; and 3) how to access the
service. This is depicted in Figure 17.5 and described below:
1.
The Service Profile describes what the Web Service does so that it can be discovered at matchmaking
time. It contains the contact information 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.
2.
The Service Process or Service Model presents 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.
26
OWL-S = OWL for Services.
3.
The Service Grounding 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 Service.
Resource
ServiceProfile
presents
(what it does)
provides
Service
supports
(how to access it)
ServiceGrounding
describedby
(how it works)
ServiceModel
Figure 17.5 Top-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 the
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 consuming. To improve
availability and performance, a service integrator could incorporate various asynchronous execution techniques
such as data caching, prefetching27, 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
messages?
There are without doubt a lot more issues with Semantic Web Services, however, this chapter does not 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 technologies 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 ‘Semantic 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 specified and
27
Prefetching is a technique in common use with browsers, where browser idle time is used to download or prefetch documents that
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 coupled? 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 of IOP
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 and 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 special. 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, overthe-Internet, cross administrative domain deployment, business-to-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 wrapper 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, decoupling
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 services? 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, where 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 dynamic 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? Well, 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 for 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 mean 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 silver 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 can 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
coupled) 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 Parlay 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 infrastructure 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 Parlay 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
offered through any user-to-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 generally 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 introduced 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 this service paradigm and its enabling technologies
apply to the telecommunication services domain.
References
[Aalst 2003] Aalst, W.v.d., ter Hostede, A., Kiepuszewski, B. and Barros, A., ‘Workflow Patterns’, Distributed
and Parallel Databases, 14(1), July 2003, 5–51
[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, Hungary, pp. 403-410
[DAML 2003] The DARPA Agent Markup Language Homepage [online]; OWL Services Coalition, ‘OWL-S:
Semantic Markup for Web Services’, December 2003, URL: http://www.daml.org/services/owl-s/1.0/owl-s.html
[accessed July 2005]
[DAML 2004a] The DARPA Agent Markup Language Homepage [online]; ‘DAML Ontology Library’, April
2004, URL: http://www.daml.org/ontologies/ [accessed July 2005]
[DAML 2004b] The DARPA Agent Markup Language Homepage [online]; Semantic Web Services Initiative
Architecture Committee, ‘Semantic Web Services Architecture Requirements’, July 2004, URL:
http://www.daml.org/services/swsa/swsa-requirements.html [accessed July 2005]
[Hull 2003] Hull, R., M. Benedikt, and V. Christophides, J. Su, ‘E-Services: A Look Behind the Curtain’,
Proceedings of the 22nd ACM SIGACT-SIGMOD-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’, Approved Version
1.0, July 2004, URL: http://www.openmobilealliance.org/
[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, pp. 225-236
[Paolucci 2003] Paolucci, M. and Sycara, K., ‘Autonomous Semantic Web Services’, IEEE Internet Computing,
7(5), Sept-Oct 2003, 34–41
[Peltz 2003] Peltz, C., ‘Web Services Orchestration and Choreography, a Look at WSCI and BPEL4WS’, IEEE
Computer, 36(10), October 2003, 46–52
[Qutub 2005] Qutub, S.S., and Weerasekera, I.N., ‘Advances in Policy Management Standardization in Mobility
Networks’, Bell Labs Technical Journal, May 2005, 77–82
[Richards 2003] Richards, D. and Sabou, M., ‘Semantic Markup for Semantic Web Tools: A DAML-S
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–289
[Sycara 2004] Sycara, K., Paolucci, M., Ankolekar, A. and Srinivasan, N., ‘Automatic Discovery, Interaction,
and Composition of Semantic Web Services’, Journal of Web Semantics, 1(1), 2004, 281–308
[Tatemura 2003] Tatemura, J., Hsiung, W. and Li, W., ‘Acceleration of Web Service Workflow 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 Architecture’, Web Services
Journal [online], 3(11), November 2003, URL: http://webservices.sys-con.com/read/39908.htm [Accessed July
2005]