Introducing Semantics to Cloud Services Catalogs

Yu Deng†, Michael R. Head‡, Andrzej Kochut†, Jonathan Munson†, Anca Sailer†, Hidayatullah Shaikh†

IBM T.J. Watson Research Center, P.O. Box 704, Yorktown Heights, NY 10598 USA†{dengy, akochut, jpmunson, ancas, hshaikh}@us.ibm.com

‡head@acm.org

Abstract—A formal catalog representation of Cloud servicesis required for automated fulfillment of user requests on catalogitems, sharing of building blocks across service offerings andsemantic interoperability between IT platforms. The technolo-gies and tools provided by the Semantic Web community arewell suited to achieve this formal representation.

In this paper, we give an analysis on the commonality anddifferences of typical Cloud service offerings and of theircatalog actions’ mappings to delivery operations. We introducea new ontological representation that leverages Semantic Webtechnology to formally model the structure and relationshipsof these service offerings and their operational processes. Ouralgorithm to select and order the execution of appropriatedelivery operations uses this representation together with a newnotion of safe sequences. This algorithm realizes the catalogaction requests while ensuring system robustness by followingsequencing rules we developed to prevent failures during thefulfillment processes for complex offerings. We evaluate ourmodel on concrete Cloud offerings.

Keywords-Ontology; Process composition; Catalog manage-ment; Cloud services; Service composibility

I. INTRODUCTION

Cloud computing is a new model to facilitate automated

delivering, elastic provisioning and scalability when fulfill-

ing high volume requests from small, medium and large

enterprises. IT Cloud aims to hide complexities of large

scale systems from its consumers. The complexities range

from the management of the underlying physical resources

(such as servers, networks and storage), capacity planning,

elasticity and scalability support in the Operational Support

System (OSS), to the modeling of service offerings, sub-

scription handling and revenue management in the Business

Support System (BSS). The BSS and OSS systems together

constitute a general IT delivery platform where services

across different domains, including health care, municipal

services (e.g., tax management), financial services and so

on, can be deployed.

Cloud services are typically presented to customers in a

service catalog. As more and more service providers lever-

age such catalogs to offer their services, it becomes critical

to formally systematize them. The knowledge contained in

catalogs typically include definitions of service offerings,

relationships between them, processes to implement oper-

ations on offerings as well as service related constraints

and rules. In Section IV, we assess the requirements for

a formal representation of the catalog knowledge by ana-

lyzing the characteristics of typical Cloud service offerings

and of their catalog actions. We identify the overlap of

functionality building blocks and processes among different

Cloud services. More concretely, for instance, both Water

Management and Tax Management services need to use

DB2, thus, they could share the DB2 provisioning workflow

when those services are provisioned in OSS. They also use

the same subscription management process, with different

parameters. A formal catalog representation facilitates the

expression of such sharing.

The catalog actions required by Cloud services trigger

complex and costly data center operations related to client

resource management. Hence, it is critical to ensure safeness

and reversibility when sequencing operations expected to

preserve data and state consistency - which is expensive to

correct.

To address the above needs, we propose an ontology

based approach to formally model the service offerings and

associated processes while keeping the system robustness in

mind. Ontology has received a lot of attention in the last

few years due to the Semantic Web movement. The Se-

mantic Web community has offered sophisticated technology

and tools to support ontological representation, including

modeling languages (e.g., OWL) and query languages (e.g.,

SPARQL1) which are well suited to be leveraged for our

model. Our contributions in this paper is three folded:

• We show how by using ontology we model Cloud

service offerings with common requirements on catalog

actions. With such a model, service providers can easily

manage their catalogs of service offerings.

• We introduce the notion of safe sequences to the

ontological model to provide transactional support for

Cloud services.

• We propose an algorithm to select and sequence a set

of delivery operation processes to automatically fulfill

catalog requests for complex offerings in two steps.

The first step harnesses the ontological representation,

especially the composite and dependency relationships

between offerings and processes. The second step

enforces system robustness through post-composition

reordering, limiting the situations that require costly

1http://www.w3.org/TR/sparql11-query/

2011 IEEE International Conference on Services Computing

978-0-7695-4462-5/11 $26.00 © 2011 IEEE

DOI 10.1109/SCC.2011.69

24

labor intensive repairs.

The rest of the paper is organized as follows. Section II

covers a motivating example: Property Tax Management in

a municipal service platform. In Section III, we compare our

methodology with related work. In Section IV, we describe

the common requirements for Cloud services, including rules

for providing and sequencing offering operations. Our onto-

logical solution for these common requirements is described

in Section V. In Section VI, we discuss the application

of our model to the specific offering example described in

Section II. Section VII concludes the paper.

II. MOTIVATING EXAMPLE

We introduce a realistic example of a Cloud application.

The application of interest, Property Tax Management Sys-tem (PTM), is a complex service provided by a large service

provider to municipalities. The key functionality of this

service is to manage property tax collection for towns and

counties. Its responsibilities include maintaining a database

of properties, providing a tax accounting solution, as well as

handling payments, reporting, and other support functions.

It is composed of a multi-tiered J2EE (Java 2 Enterprise

Edition) application implementing the key logic of the

property tax management, and also a desktop application

used by clerks to access the back-end application.

Currently systems like our exemplary PTM are typically

implemented as software packages which are purchased,

installed, and operated by municipalities themselves or by

specialized vendors serving them. This delivery model is

not efficient for several reasons. Each municipality has to

purchase and maintain hardware resources required only to

run the application at peak usage times. Deployment and

steady-state management of PTM requires significant skills

and experience which are often not available to municipality

employees or small vendors serving them. Moreover, the

number of properties being managed poses specific sizing

and scalability requirements. Finally, the tax assessment and

collection processes differ due to the size and local laws. For

example, larger cities may require more complex approval

workflows while the small towns may need simplified assess-

ment rules. However, overlapping procedures and building

block components of these processes could be shared.

Delivering PTM as an on demand service by service

providers offers multiple advantages. Instead of investing

resources into building the system, local governments can

order the service and therefore delegate the responsibility

of maintenance to a specialized provider that can realize

savings through economies of scale. The sizing, scalability

and elasticity requirements can thus be handled by the

provider. From the service provider’s point of view, a major

key to success is automation of service delivery through

catalog management, which is the focus of this paper.

Such automation supports functions including: accepting

customers’ requests for catalog items; identifying the appro-

priate processes to fulfill the requests and sequencing them;

triggering the process execution. Note that such processes

may involve operations in both the BSS and the OSS.

III. RELATED WORK

Traditional operations and services catalogs or registries,

such as Universal Description Discovery and Integration

(UDDI), are intended to store metadata for SOA services.

The actions supported in our services catalog cover a broader

definition of operations, including SOAP, REST and DCOM,

to name a few. A graph service representation is used in

[7] for service composition, catalog creation and mapping

to an operational infrastructure in data centers in view of

optimized deployment. The work presented in this paper

relates to research carried out in the ontology and Semantic

Web services communities, as well as in the business process

and workflow management arena.

The Web Service Modeling Ontology (WSMO) [6] is

an effort that resulted from the Semantic Web services

community to enrich Web services with semantics. Given

the syntactic interchange approach (i.e., data format and

layout must be the same) first taken by the Web Services

community, WSMO addresses the needs to fill the semantic

gap between different services’ metadata, adding semantic

capabilities to Web services. Thus WSMO makes it easier

to discover and combine services. OWL-S2 is another effort

to provide ontological support to Web services.

The authors in [2] [9] [5] propose Semantic Web services

based frameworks to discover, compose and execute Web

services leveraging ontology solutions in various contexts.

The ontology-based global service discovery extension of

GloServ [2] performs service composition with services

described in OWL-S selecting descriptions that work best for

the composition. DataStorm [9] uses OWL and the Hadoop

platform to develop data models and associated software

tools for designing and deploying cloud-based systems. The

authors in [5] leverage the semantic support to automate

the process of change reaction in change management. The

authors of [1] put more focus on the semantic ambiguity

in Web service descriptions and proposed an algorithm to

compose Web services by combining semantic matching and

AI planning techniques.

Our work is complementary to the above efforts where

semantics were introduced to Web services in two aspects:

(1) our focus is on generating safe sequences to provide

transactional catalog support while existing work focuses

on service discovery and matching; (2) we target Cloud

services, which have different expectations than the services

existing work handles, e.g., booking airline tickets.

The Web Services Resource Framework3 was proposed

to make Web services stateful, that is Web service clients

2http://www.w3.org/Submission/OWL-S/3http://www.oasis-open.org/committees/tc home.php?wg abbrev=wsrf

25

communicate with resource services allowing state data to

be stored and retrieved.

Defining workflows explicitly and using execution engines

to run them have become key in business-process modeling

and workflow automation. There are several standards for

describing process workflows, e.g., Business Process Exe-

cution Language (BPEL) and Business Process Modeling

Notation (BPMN). These languages are based on schema-

oriented representations, which do not provide inference

capabilities for process composition. Moreover, BPEL spec-

ifications are heavily dependent on the WSDL, addressing

SOA services only. The authors in [8] developed an work-

flow ontology, focusing on the tasks and activities that are

specific to ontology development. When integrated with a

workflow execution engine, they can map the top level of

their ontology to a process-modeling language as required

by a workflow execution engine.

The prior art has addressed a rich range of aspects when

dealing with services’ ontology and processes. Nevertheless,

generating complex sequences of operations that can be

executed safely and reversibly remain open questions. Our

notion of reverting sequences is similar to the concepts

of compensating transactions [4] and compensating ser-vices [3] for ensuring system integrity, but instead of relying

on programmers to explicitly create forward and compensat-

ing transactions, our approach uses semantic information to

algorithmically construct safe, complex sequences.

IV. ANALYSIS OF REQUIREMENTS

In this section, we analyze the requirements of catalogs for

Cloud services on three dimensions: general characteristics,

catalog-level actions, and offering-level operations. Then we

give the definition of a safe sequence.

A. Typical Cloud Services

Youseff et al. [10] gives a layered classification of the

Cloud Computing services, where the three typical offering

categories are IaaS (Infrastructure as a Service), PaaS (Plat-

form as a Service) and SaaS (Software as a Service). As

shown in Figure 1, Compute Cloud is an example of IaaS,

J2EEHosting is in the category of PaaS, DaaS (Desktop as

a Service) can be classified as either IaaS or PaaS, and the

Municipal service is a typical example of SaaS.

One of the common requirements for Cloud services is the

composibility [10]. The composibility is further reflected in

two aspects: composite offerings and composite operations.

The composite offerings are the services composed of one

or more other services. For example, the PTM service in

the above motivating example is composed of J2EEHostingand DaaS service. On the other hand, operations upon

composite offerings may be composite as well. For instance,

subscription of PTM service may invoke the subscription of

certain J2EEHosting and DaaS services. Note that we use

the term “composibility” as defined in [10], referring to the

ability to compose one Cloud service from one or more other

Cloud services. This is different from service composition

in SOA or Web services, which is focused on semantically

matching the input and output parameters.

B. Cloud Services Catalog Actions

We examine five catalog actions common across Cloud

service offerings and required by a service catalog. These

actions are Onboarding, Offboarding, Subscription, Unsub-

scription, and Upgrade/Migrate.

An onboarding process involves customer registration,

VPN setup, directory integration, and provisioning of re-

sources to support a service. When the process is complete,

the service is ready to support subscription requests from

the onboarded customer. A customer needs only onboard

once to a particular service offering. Offboarding is the log-

ical dual of onboarding. After offboarding, the deployment

environment will release all resources associated with that

customer.

Subscription is the action by which the resources are

allocated to provide the actual service to a customer. Once

completed, the customer may begin using and be billed

for the service. Customers cancel individual service sub-

scriptions using the unsubscription action. This frees the

resources associated with that subscription.

Customers may desire to change between different levels

of service. This requires an existing subscription to a partic-

ular service level to be migrated to a new level. This process

can be divided into three steps: (1) subscription to the new

level, (2) copy the data, possibly with transformation, from

the old level to the new level, and (3) unsubscription from

the old level.

Dependency is common among the actions. For example,

subscription to a PTM service depends on the subscription to

a DaaS service. Onboarding a customer to TaxMgmt needs

to onboard the customer to Municipal service first. Thus,

expressing dependency should be facilitated in the catalog

model.

Each catalog action is mapped to a sequence of offering-

level operations triggered by the system. Each offering-

level operation is bound to a specific offering. For example,

subscription to PTMTrial in the catalog is resolved into

such a sequence of offering-level operations: subscription

to BronzeDaaS, subscription to ExpSgServer, subscription to

WSSgServer, subscription to J2EEHstTrial, then subscription

to PTMTrial, as illustrated in Figure 1.

C. Offering-level Operations

An offering-level operation is the smallest unit of automa-

tion that a Cloud services catalog is concerned with when

supporting a particular action requested by a customer. Such

operations include the concrete subscription process for a

non-composite service, or a data copy step taken during an

upgrade from one offering service level to another. Dozens

26

of these operations may be implicated in a catalog action

for a composite Cloud service. Unless all steps for each

catalog entry’s actions are explicitly prepared by the catalog

administrator, the catalog management system (CMS) itself

will need to select and sequence these operations.

In order to support the expected failure of operations

implementing a particular catalog action, the CMS must be

able to return the system to the state before the catalog

action was initiated. For example, if a complex upgrade

process fails during the operation that copies content from

the old service level subscription to the new one, then the

new subscription should be canceled. As more operations

are involved in an catalog action, this can become complex.

Without the use of costly checkpoints, it is necessary to

define rules for sequencing the offering operations in support

of a catalog action.

D. Safe Sequences

Types of operations An examination of offering level

operations reveals that they fall into two broad classes:

fallible and infallible.

Fallible operations are those that are expected to en-

counter situations that will cause them to fail. Subscription

operations are fallible, because, for example, during normal

circumstances there may not be enough resources to support

the new subscription. A copy operation during any upgrade

process may fail because it depends on working with poten-

tially unpredictable customer data. Fallible operations mustbe implemented by robust routines that either a) succeed or

b) revert the system to its state before the operation started

and report failure.

Infallible operations are those that cannot or should not

be allowed to fail. The unsubscription process is such an

example because it needs to release data center resources

and direct the billing management system to stop charging

the customer. Infallible operations, which are generally de-

structive and irreversible, like any software component, may

encounter errors. These errors should be handled in one of

two ways: 1) safely ignore the error or 2) do not complete

the operation until the error has been remedied.

Types of operation sequences In order to define the rules

to which the CMS must adhere when combining operations,

we define two kinds of sequences: revertible and safe.

Revertible sequences are defined recursively in the length

of the sequence:

• A sequence s of length 0 is always revertible;

• A sequence t of length N is revertible if and only if:

1) the sequence containing the first N − 1 elements of

the sequence is revertible and

2) there is a sequence of infallible operations (known

as t′: the reverting sequence for t) that can return the

entire system to the state that existed before t was

initiated.

Safe sequences of operations are those that can be parti-

tioned into exactly two sub-sequences: the left and the right,either of which may be empty. The left portion must be a

revertible sequence and the right must be composed only of

infallible operations. An intuitive interpretation of sequence

safety is captured in this rule when upgrading systems: neverdestroy the old system before ensuring that the new systemis functioning.

Rules for sequencing and implementing operations The

following rules for offering operations are necessary to

ensure that the CMS will never put the system in an

inconsistent state if an operation in the middle of a sequence

fails:

1) All pre-defined sequences must be safe2) No fallible operation depends on the result of an

infallible operation

Rule 1 ensures that the sequencing algorithm will never

have to consider unsafe sequences. Rule 2 ensures that a new

safe sequence can be formed from existing safe sequences

by commuting the right sub-sequence of a safe sequence

with the left sub-sequence of another. In other words, for

any two safe sequences L1R1, L2R2, a new safe sequence

can be generated: L1L2R1R2.

This forms an inductive proof that any selection of pro-

cesses from the catalog can be put into a safe sequence for

execution, with rule 1 as the base case, and rule 2 as the

inductive step.

V. A SERVICES CATALOG ONTOLOGY

In this section, we present our ontology based method-

ology to model service offerings and their corresponding

processes.

A. Ontology Based Representation

Ontologies are used to represent knowledge in many

domains, such as bioinformatics, health care, patents and

business. They model classes as well as their attributes and

relationships in a domain. By using axioms, they can express

constraints. Data instances or individuals are also modeled

through ontologies.

We choose to use OWL to represent our catalog ontology

due to its strong formalization abilities and tooling support.

Specifically, we choose OWL DL which provides a rich set

of vocabulary for describing classes, properties, relationships

and axioms with good reasoning support.

To fulfill the catalog requirements highlighted in Sec-

tion II and IV, we propose an approach to model service of-

ferings with their supporting processes, such that the seman-

tics of offerings and processes are captured by the ontology.

The ontology is used to select and sequence the appropriate

processes to fulfill a catalog action request. The processes

27

������������

� �

� �����

������������

� ���� �

������� ������� �

���� �

������ �

������ �

�� ���

��� �!��"���

��������������

�������" ���!������������������#��� � ���#� ��

" �������������

���#��� �

�������$���%����

$���������� ���������$�&�������� ��������

'�$$

&�����

'�$$

&����� �

'�$$

&�����

" �������

������������

���#��!�������%�

���#� ��

������

" ��!� �����������

���#� �����#��� �

" ��!� �����������

" ����%�������

���#� ��

���#� ��

���#��� �

���#��� �

" �(��!���������������

���#��� �

���#� ��

(a) Class Hierarchy

���������� ������������

���������

��

�����������

�������������������������� ���������

����� ���������

�����������������

��������� ���������������� ���

�� ���

���������

������������

����������

���������

������

����� ��������������

������� �

�� �����

����������������

��������

!$$"���������

������

#�������

�� ������$�%$������ ���

���������

���������

������������#������ ���

���)�����������

���������

������������������

���������

������ �����*��� �

�� �����*��� �

���$������ ���)�������

���������

���������

���������

������������������

(b) Operations

Figure 1. An Ontology for Services Offerings (ServiceOffering and Process are repeated in subfigure (a) and (b))

can be represented in forms of state machines, BPEL or

other appropriate languages. Figure 1 illustrates a model

of the offerings involved in the motivating example. The

links without any label correspond to the rdfs:subClassOfproperty. The oval represents classes (concepts) and the

rectangle represents defined properties.

In Figure 1(a), a class hierarchy of the offerings is

shown. We assume that there is an upper ontology for

enterprise services offerings which includes common classes

and properties, based on which, new offerings and operations

can be defined. This upper ontology must have three general

concepts: (1) ServiceOffering, such that specific offerings

can inherit this concept to form a class hierarchy, as shown

in Figure 1(a); (2) Op, such that operations can be defined

on top of this concept; (3) Process, such that processes

can be defined to be leveraged in the sequencing algorithm.

Furthermore, it must have a set of properties to describe

service offerings, including RAMSizeGB (size of memory in

gigabytes), HDDGB (size of hard drive in gigabytes) and

so on. Moreover, new concepts and properties can be easily

added into this upper ontology to support the definition of

new types of service offerings and their operations. Here

we show how we handle the common requirements in

Section IV via examples.

Simple offerings A simple offering is defined through

properties. For example, we define BronzeDaaS as follows,

which is a subclass of BasicDaaS and has 1 GB RAM and

10 GB hard drive:

BronzeDaaS ≡ BasicDaaS � ∃RAMSizeGB.1 �∃HDDGB.10

Here we abuse the Description Logic notation to use

∃RAMSizeGB.1 for denoting that the value of RAMSizeGBis 1. Similarly for ∃HDDGB.10. Notice that both RAM-SizeGB and HDDGB are functional properties, i.e., it is true

that Func(RAMSizeGB) and Func(HDDGB). This is to

ensure that a resource like BronzeDaaS has exactly one size

of RAM and one size of hard drive. Note also that DaaSservices may have other properties besides RAM size and

hard drive size. Here, without loss of generality, we only

choose the two of them.

Similarly, SilverDaaS is defined as a subclass of Basic-

28

DaaS that has 2 GB RAM and 30 GB hard drive.

By definition, each offering inherits the processes as-

sociated with their ancestor offerings. For example, the

subscription process directly associated with DaaS is also

a subscription process of BronzeDaaS.

We also define a few constructs related to Process for

specifying the characteristics of offering-level operations.

For example, we define FallibleProcess as a subclass of

Process. In addition, a process can be dependent on other

process via hasDependProcess. Each process for catalog-

level actions must declare lower level processes (offering-

level operations) via hasLowLevelProcess. To ensure that

the lower level processes of a given process are executed

in a right order, we define ProcessSequence to hold the

lower level processes. The property hasFirstProcess points

to the first process in a sequence and hasRemainingPartpoints to the remaining part of the sequence. We then

define SafeProcessSequence as subclass of ProcessSequenceto model the safe sequences we discussed in Section IV-D.

The property hasLeftPart points to the left (revertible) part of

the sequence and hasRightPart points to the right (infallible)

part. We assume that each sequence for a catalog-level action

is safe.

Composite offerings Before we can define PTM services

in the example, we need to model the composite offer-

ings. A composite offering leverages operations provided

by simple or other composite offerings. As we explained

in the example, PTM services build upon DaaS services

and J2EEHosting services, while J2EEHosting services need

support from DB2 and WebSphere services. Therefore, we

define CompositeOffering as a subclass of ServiceOfferingand use the property hasIncludedOffering to point to the

supporting offerings of a CompositeOffering.

Semantically, hasIncludedOffering should be transitive,

because if offering A has a supporting offering B, B has

a supporting offering C, then it is true that A needs support

from C. Thus it is true that Trans(hasIncludedOffering).In addition, we define hasDirectIncludedOffering as a sub-

property of hasIncludedOffering so that hasDirectIncluded-Offering is used to model the direct composite relationship

between two offerings while hasIncludedOffering can be

used to query all of the supporting (via transitive closure)

services for a given offering. Then we define J2EEHstTrialas a composite offering based on ExpSgServer and WSS-gServer:

J2EEHstTrial ≡ J2EEHosting �∃hasDirectIncludedOffering.ExpSgServer �∃hasDirectIncludedOffering.WSSgServer

Similarly, we can define J2EEHstPro as a composite

offering based on where EntHACluster and WSCluster. Here

ExpSgServer (Express Single Server) and EntHACluster (En-

terprise HA Cluster) are the two DB2 offerings while WSS-

gServer (WebSphere Single Server) and WSCluster (Web-

Sphere Managed Cluster) are the two WebSphere offerings.

Based on J2EEHosting offerings, we can define PTMservices. Specifically, we define PTMTrial and PTMProas subclasses of TaxMgmt. Furthermore, PTMTrial is a

composite offering on top of BronzeDaaS and J2EEHstTrial,while PTMPro is a composite offering on top of SilverDaaSand J2EEHstPro.

Multi-ary and composite operations Some operations

involve two or more services offerings, such as the upgradeoperation, which is a binary operation. As we described

in the motivating example, we may upgrade BronzeDaaSto SilverDaaS or upgrade PTMTrial to PTMPro. Different

from a subscription process which is associated with a single

service offering, an upgrade process has to be associated

with an upgrade relationship. Therefore, we model multi-ary

operations as first-level concepts as shown in Figure 1(b).

The concept Op in the upper ontology has a subclass Bina-ryOp. BinaryOp has two properties hasOriginOffering and

hasTargetOffering. Then we can define upgrade operations

as a subclass of BinaryOp. The hasOpProcess property is

defined to associate processes with the operations, such as

upgrade processes. This modeling method can be easily

extended to other multi-ary operations.

For composite offerings, some of their operations are

composite as well. For instance, when PTMTrial is up-

graded to PTMPro, the supporting offerings of PTMTrialshould also be upgraded, i.e., BronzeDaaS to SilverDaaS and

J2EEHstTrial to J2EEHstPro. We define CompositeOp as a

subclass of Op which has a property hasIncludedOp pointing

to the operations on the supporting offerings. Similar to the

hasIncludedOffering property, hasIncludedOp is transitive.

We also define a subproperty hasDirectIncludedOp to model

the direct composite relationship between two operations.

Then the upgrade operation PTMTrialProUpgrade can be

defined as

PTMTrialProUpgrade ≡ CompositeOp � BinaryOp �∃hasOriginOffering.PTMTrial �∃hasTargetOffering.PTMPro �∃hasDirectIncludedOp.BronzeSilverDaaSUpgrade �∃hasDirectIncludedOp.J2EEHstTrialProUpgradeSimilarly, we can define BronzeSilverDaaSUpgrade and

J2EEHstTrialProUpgrade.

B. Process Selection and Sequencing

Given a submitted catalog action, the system resolves

it into a sequence of offering-level operations (represented

in processes) to be executed. In this section, we focus on

the algorithm to select and sequence the processes given a

catalog action.

A catalog action can be represented as a binary vec-

tor <A, �>, where A is the action, � is the list of

involved resources (R1, . . . , Rn). Each resource Ri (i =

29

1, . . . , n) can be a type or an instance in ontology. For

example, <Subscription, (BronzeDaaS)> is a request of

subscription to Bronze desktop service, while <Upgrade,(BronzeDaaS1,SilverDaaS)> is to upgrade the instance

BronzeDaaS1 to Silver desktop service.

In our algorithm on dynamically allocating a sequence of

processes given a catalog action, Step 1 is to first retrieve

all of the related processes (catalog-level actions) from the

ontology. For example, if the action is subscription, then it

retrieves all of the relevant subscription processes, including

the ones from ancestors and supporting offerings. Step 2 is

to construct a directed acyclic graph (DAG) based on the

dependency relationships between the processes and order

them based on the constructed dependency graph. Note that

the dependency relationships between processes should form

a DAG to make the sorting feasible. Step 3 is to adjust

the order based on the sequencing rules in Section IV-D.

Specifically, for each process p in the ordered list L from

Step 2, it is replaced by its lower level operation sequence S(S is a safe sequence). The right part (infallible operations)

of S is then moved to the end of the list L (due to the

characteristics of safe sequences).

Suppose S1 and S2 are two safe sequences, whose left

parts are L1 and L2 respectively, and right parts are R1 and

R2 respectively. S1 and S2 can be combined into a new

safe sequence S3 by concatenating the subsequences in the

following order: L1,L2,R1,R2. Note that the concatenation

of L1 and L2 can be totally decomposed into revertible

subsequences because L1 and L2 have total decompositions

into revertible subsequences. The concatenation of R1 and

R2 is composed entirely of infallible operations because

R1 and R2 contain only infallible operations. Thus S3 is

a safe sequence. We assume that all sequences of operations

implementing each offering’s processes are safe, so by

induction, any collection of processes from the ontology

can be combined into a single safe sequence. For example,

suppose A, B and C are catalog-level processes. After Step2, the ordered list is B, A and C. Suppose B is replaced by

its three lower level processes B1, B2 and B3, A is replaced

by A1, A2 and A3, and C is replaced by C1, C2 and C3.

Further suppose B3, A3 and C3 are the right parts of B,

A and C respectively. Then after Step 3, the order should

be B1, B2, A1, A2, C1, C2, B3, A3, C3. In Section VI,

we show how to use this algorithm to handle our motivating

example.

Assume that a reasoning engine has loaded the offering

ontology and done the computation to get inferred class

hierarchy. Certain information is cached such that a task like

testing if t is subclass of CompositeOffering can be done in

constant time. Then we can analyze the time complexity

as follows. Suppose there are N classes in the ontology.

Suppose the number of processes the algorithm picks from

one specific offering/operation class given a request is bound

by a constant factor, then the number of processes resulted

from Step 1 is bound by O(N). Thus the running time for

Step 1 and the step of constructing the DAG in the above

algorithm is O(N2). For the step of sorting the processes

based on the DAG, we use topological sort whose time

complexity is O(|V | + |E|) where respectively V and E

are the set of nodes and the set of edges of the dependency

graph. Both |V | and |E| are bound by N2. Since the number

of processes in each process sequence is bound by O(N),the rest of the algorithm should be run in O(N2). Therefore,

the total running time of the algorithm is O(N2).

VI. USE CASE DISCUSSION

We illustrate our approach by examining its application

to a particular service offering, Property Tax Management(PTM), which we described in Section II. We discuss the

automated functions of our system that are needed to provide

transactional provisioning of services, and compare this to

the labor required to ensure the same correctness in the

absence of our system. PTM services are composed of

DaaS services and J2EEHosting services (the latter is further

composed of DB2 and WebSphere services).

Realizing each of the required functions, such as customer

onboarding, subscription, or upgrade, requires careful

orchestration of BSS and OSS operations. Dependency

relationships represented in the ontology are used to

automatically determine sequences of operations to

perform; the fallibility of operations, as represented in

the ontology, is used to determine safe sequences of

operations. Without the ontology, and the mechanisms

that use it, individual developers must take into account

these considerations for each upgrade that is allowed, and

must ensure that the code they write either performs the

upgrade operations without error, or safely reverses the

operations. Furthermore their code must, in each case,

follow the BSS/OSS protocol that no chargeable operations

are performed without a charge being recorded, and likewise

that no charges are applied for operations that did not

complete (see last three steps of upgrade example). While

it is true that such requirements are not new in the field

of computing, applying these requirements for each new

offering or offering combination that a business may desire

to offer entails significant costs. Once the business team

has decided on the offering to introduce, a developer or

team of developers must be assigned and perhaps trained.

Once development is complete the code must enter a unit

test phase before it can be put into production. Following

unit testing, the code is tested with the BSS.

To illustrate the above issues, consider a Service Upgrade

Process of the PTM. It is a common request, since in many

cases customer simply wants to try out the service before

signing a longer term contract. To meet this requirement

service providers allow creation of trial configurations

30

which can later be converted into the production ones. The

conversion is accomplished in several steps:

• An order for upgrading PTMTrial to PTMPro is submit-

ted to BSS. BSS first runs a query to find the upgrade

concept PTMTrialProUpgrade whose original offering

is PTMTrial and target offering is PTMPro. Then all of

the related upgrade processes are identified, including

the ones inherited from ancestors (if there is any) and

the ones from the supporting upgrade operations (since

PTMTrialProUpgrade is a composite operation). The

identified processes are sequenced based on depen-

dency relationships. BSS starts running the sequenced

processes.

• OSS provisions new resources for the target offering,

such as resizing the property database, deploying larger

number of J2EE application nodes, as well as config-

uring HA and load balancing features (which are not

required for trial setup).

• OSS notifies BSS that the new resource provisioning is

complete.

• BSS cancels subscription to old class and notifies OSS.

• OSS reclaims the resources used in the old subscription

and notifies BSS that the order is complete.

In our Cloud development experience, introducing a new

offering based on a combination of existing offerings may

require up to several months of development effort —

specifically, the programming required to provide the BSS

and OSS functions needed to correctly manage the lifecycle

of the new composed offering. In addition, this work has

to be repeated for any new composed offering, therefore

significantly increasing the cost of catalog modification. It

also introduces significant delay between identification of

requirements for the new feature and its delivery to the

market.

With our system, this effort is replaced by one of creating

new entries in the ontology-based catalog, bypassing the

developer-acquisition, development, and unit-testing phases,

and going straight to testing with the BSS. The approach

we proposed allows the offering manager to define new

offerings using composition approach without waiting for

the development cycle to complete. It also reduces the

testing required since the system is reconfigured rather than

reprogrammed.

VII. CONCLUSIONS AND FUTURE WORK

We have presented a novel ontology based approach

for enterprise services catalog management. This approach

includes an ontological representation to model a range of

enterprise services and their processes. The representation

is motivated by our analysis of common requirements and

characteristics of service offerings as well as their opera-

tions. One of the important requirements we have modeled

is composite relationships across offerings.

With the ontological representation, we proposed an al-

gorithm to select and sequence a set of processes given a

catalog action. This algorithm is based on the sequencing

rules we developed to prevent failures during fulfillment pro-

cesses for complex offerings from leading to system states

requiring costly repairs. Our use case analysis has shown

that our methodology enables the automatic answering of

catalog requests and the sharing of building blocks across

enterprise services.For our future work, we expect to enhance the model with

rule support to refine process selection and result feedback

to the model. In addition, we plan to study the semantic

interoperability issues between different catalog ontologies.

VIII. ACKNOWLEDGEMENTS

The authors would like to thank Achille Fokoue for

valuable comments on the catalog ontology.

REFERENCES

[1] R. Akkiraju, B. Srivastava, A.-A. Ivan, R. Goodwin, andT. Syeda-Mahmood. Semaplan: Combining planning withsemantic matching to achieve web service composition. InICWS ’06: Proceedings of the IEEE International Conferenceon Web Services, pages 37–44, Washington, DC, USA, 2006.

[2] K. Arabshian and A. Mehta. Distributed service compositionand execution framework in gloserv. In Proceedings ofthe IEEE International Conference on Services Computing(SCC), 2010.

[3] T. Erl. SOA Design Patterns. Prentice Hall, 2008.

[4] H. Garcia-Molina and K. Salem. Sagas. SIGMOD Rec.,16(3):249–259, 1987.

[5] X. Liu, C. Liu, M. Rege, and A. Bouguettaya. Semanticsupport for adaptive long term composed services. In Pro-ceedings of the IEEE International Conference on ServicesComputing (SCC), 2010.

[6] D. Roman, U. Keller, H. Lausen, J. de Bruijn, R. Lara,M. Stollberg, A. Polleres, C. Feier, C. Bussler, and D. Fensel.Web service modeling ontology. Applied Ontology, 1(1):77–106, 2005.

[7] A. Sailer, M. Head, A. Kochut, and H. Shaikh. Graph basedcloud service placement. In Proceedings of the IEEE Inter-national Conference on Services Computing (SCC), 2010.

[8] A. Sebastian, N. F. Noy, T. Tudorache, and M. A. Musen.A generic ontology for collaborative ontology-developmentworkflows. In Proceedings of EKAW, pages 318–328, 2008.

[9] T. W. Wlodarczyk, C. Rong, B. Jia, L. Cocanu, C. I. Nyulas,and M. A. Musen. Datastorm - an ontology-driven frameworkfor cloud-based data analytic systems. In Proceedings ofthe IEEE International Conference on Services Computing(SCC), 2010.

[10] L. Youseff, M. Butrico, and D. D. Silva. Towards a unifiedontology of cloud computing. In Proceedings of the GridComputing Environments Workshop (GCE08), held in con-junction with SC08, 2008.

31