Generating OWL-S Families by Utilizing Business

Process Deﬁnitions and Feature Models

Umut Orhan and Ali H. Do˘gru

Middle East Technical University, Computer Eng. Dept., Ankara, 06531, Turkey

Abstract. This research introduces automated transition from domain models

and process speciﬁcations to semantic web service descriptions in the form of

service ontologies. Also, automated veriﬁcation and correction of domain mod-

els are enabled. The proposed approach is based on Feature-Oriented Domain

Analysis (FODA), Semantic Web technologies, and ebXML Business Process

Speciﬁcation Schema (ebBP). This approach is proposed to address the needs

for achieving productivity gains, maintainability and better alignment of business

requirements with technical capabilities in the engineering of service oriented

applications and systems.

1 Introduction

Business Process Management (BPM) and Service-Oriented Architecture (SOA) com-

bination is being promoted as a possible solution for achieving proper level of service

abstractions and reaching the desired agility and responsiveness to changing business

parameters. Unfortunately, in order to enable the anticipated BPM-SOA convergence,

knowledge of the domain should be ﬁrst transferred from domain experts to develop-

ers. This necessitates common means for shared vocabulary and understanding of the

business requirements which can conveniently be achieved by utilizing ontologies. In

this respect, we exploit the concept of service ontology as a bridge between business

process models and service interface implementations.

It is desirable to generate service ontologies automatically, especially when we con-

sider the complex and time-consuming nature of the ontology creation task. Thus, we

chose to automate service ontology creation to some extent. In addition, we enable the

Feature-Oriented Domain Analysis (FODA) [1] to manage differences and similarities

across multiple service deﬁnitions: we produce not only a single service ontology but a

set of related service ontologies.

An overall representation of this method is shown in Figure 1. We provide the do-

main experts with the necessary environment in order to deﬁne business process models

and feature models. These deﬁned domain engineering outcomes are then mapped to

corresponding OWL-S instances. A resulting OWL-S instance may then be related to

web service implementation in two ways; (1) provide requirements and eliciting con-

straints for the corresponding web service interface, (2) enable automatic discovery of

semantically matching web services already implemented.

Major contributions of this research can be listed as follows;

Orhan U. and H. Dogru A. (2009).

Generating OWL-S Families by Utilizing Business Process Deﬁnitions and Feature Models.

In Proceedings of the Joint Workshop on Advanced Technologies and Techniques for Enterprise Information Systems, pages 42-51

DOI: 10.5220/0002201300420051

 SciTePress

Fig.1. Product line approach for generating a family of service ontologies.

– An OWL

ontology is developed to represent feature models. We also developed a

set of SWRL

rules as axioms corresponding to relations among features. Veriﬁca-

tion and correction of feature model customizations are performed by enabling the

JESS [2] which is a rule-based automated reasoner.

– We developed an ontology-aware feature model editor in order to facilitate visual

development of feature models. The tool imports and exports feature models for-

mally deﬁned by our feature model ontology.

– We deﬁned model transformation rules from ebBP

instances and feature models

to accompanying service models. Generated service models are conceptualized as

OWL-S

instances.

The introduced method is realized through the scope of an ongoing open source

project called GENoDL

. The tool takes a feature model and an ebBP instance as input

and reﬁnes them in order to generate OWL-S instances.

OWL Web Ontology Language, http://www.w3.org/TR/owl-ref/

SWRL: A Semantic Web Rule Language Combining OWL and RuleML,

http://www.w3.org/Submission/2004/SUBM-SWRL-20040521/

ebXML Business Process Speciﬁcation Schema, http://docs.oasis-open.org/ebxml-

bp/2.0.4/OS/

Semantic Markup for Web Services, http://www.w3.org/Submission/2004/SUBM-OWL-S-

20041122/

Automated Service Ontology Generator Tool based on Description Logics,

http://sourceforge.net/projects/genodl/

In order to deﬁne ebBP instances, the ebBP Editor [3] tool is integrated. It was

previously developed within the scope of a research project funded by the European

Commission. The domain expert can model business processes in Business Process

Modeling Notation (BPMN) [4] and the tool then exports these models to accompany-

ing ebBP deﬁnitions.

The remainder of this paper is organized as follows. Section 2 summarizes the re-

lated work on service ontology generation methods. In Section 3, we present our seman-

tically enriched feature modeling approach enabled in generating OWL-S instances.

The transformation method from ebBP to OWL-S is given in Section 4. An example

walkthrough with the implemented tool is described in Section 5. Finally, Section 6

concludes the paper and presents the future work.

2 Related Work

Various work has been conducted [5, 6, 7, 8, 9] that partially cover our ambitions. Usu-

ally, automation has been missing and also our mass customization of a set of related

ontologies was not addressed.

In this work, we separate the identiﬁcation, speciﬁcation and realization concerns

of a web service. Business processes for identiﬁcation, service ontologies for speciﬁ-

cation, and service implementations for realization. This separation of concerns, which

well ﬁts in Service-Oriented Modeling and Architecture (SOMA) [10], allows us to au-

tomate the mapping from identiﬁcation step to speciﬁcation step through semantic web

technologies. This also provides means for capturing commonalities and variabilities in

service models by exploiting feature models.

3 Semantically Enriched Feature Models

Basically, a feature model provides a hierarchical organization among features within a

concept. In addition to parent-child relation, a simple feature model can deﬁne manda-

tory, optional, alternative, excludes, requires and OR relations among features. In our

study, OWL is decided to be used for feature model formalism because it is a well

known standard in the area and is supported by various technologies, tools and de-

velopment environments like Protege-OWL

, SWRL and JESS. In this respect, OWL

reasoning engines such as JESS can be deployed to check for inconsistencies within a

feature model and correct them automatically.

Firstly, we deﬁne a Feature class having two object properties, hasParentFeature

and hasChildFeature respectively, which are transitive properties that are inverse of

each other. These properties are required to express IS-A relations in structured view

or OR relations in common feature model understanding. The concept of the feature

model can be considered as an ordinary feature which has no parent feature.

In order to fully represent the mandatory and alternative relations, we derive two

speciﬁc child classes from the Feature class. Each class is a subclass of the owl:Thing

Protege-OWL, http://protege.stanford.edu/overview/protege-owl.html

class. We assert that Alternative Feature and Mandatory Feature as mutually disjoint.

An overview of the classes deﬁned within the Feature Model Ontology is given below.

F eature ⊑ ⊤ (1)

AlternativeF eature ⊑ F eature (2)

MandatoryF eature ⊑ F eature (3)

AlternativeF eature ⊓ M andatoryF eature = ⊥ (4)

A number of axioms for checking the consistency of the feature model customiza-

tions are formally deﬁned within the scope of this work. In general, these axioms are

exploited not only for verifying the feature model but also correcting any inconsis-

tency found. These axioms are described as SWRL rules. They are normally stored

as OWL individuals which can refer to the resources within the associated knowledge

base. Class deﬁnitions of these OWL individuals are introduced in SWRL ontology.

Deﬁned axioms and their SWRL implementations are given below;

1. A feature cannot be selected unless its parent feature has been selected already. For

all x and y;

F eature(?x) ∧ isSelected(?x, f alse) ∧ hasChildF eature(?x, ?y)∧

isSelected(?y, true) → isSelected(?y, f alse)

2. A mandatory feature must be selected wheneverits parent feature has been selected.

For all x and y;

Mandatory F eature(?x) ∧ hasP arentF eature(?x, ?y) ∧ isSelected(?y, true)

∧isSelected(?x, f alse) → isSelected(?x, true)

3. Only one feature must be selected among its alternatives. For all x and y;

Alternative F eature(?x) ∧ isSelected(?x, true) ∧ alternativeOf (?x, ?y)

∧isSelected(?y, true) → isSelected(?y, f alse)

4. A feature is selected whenever the other feature which requires it has been selected.

For all x and y;

F eature(?x) ∧ requires(?x, ?y) ∧ isSelected(?x, true) → isSelected(?y, true)

5. A feature is deselected whenever the other feature which excludes it has been se-

lected. For all x and y;

F eature(?x) ∧ excludes(?x, ?y) ∧ isSelected(?x, true) → isSelected(?y, f alse)

The customized feature model has no variability points but a deﬁnite set of se-

lected features. In order to verify a customized feature model represented with OWL

instances, we employ our feature model axioms, Protege-SWRL plugin, and the JESS

rule engine. Prot´eg´e-SWRL plugin has no reasoning capability, however, it supports

API level integration with existing rule engines such as JESS. The plugin can translate

SWRL rules to the JESS rule language. The necessary transformation methods from

OWL and SWRL concepts to JESS constructs and vice versa are given in [11]. Once

the OWL and SWRL concepts are transformed to JESS context, the execution engine

can perform reasoning. The overall view of the integration between SWRL, Prot´eg´e-

OWL and JESS rule engine is given in Figure 2. The implementation of the GENoDL

and Prot´eg´e-SWRL integration is also given in [12].

Fig.2. Reasoning engine integration through the Prot´eg´e-SWRL adapter.

3.1 Mapping Customized Features to OWL-S

OWL-S is an emerging de-facto semantic web standard that supports automation of

various web service related activities such as service discovery, composition, execution

and monitoring. OWL-S provides process models of atomic as well as composite web

services.

During the service ontology generation, the selected (or in other words customized)

nodes of the feature model are automatically transformed into accompanying OWL-S

constructs which is in this case the serviceParameter element of OWL-S Proﬁle. OWL-

S provides an unbounded list of service parameters that can contain any type of infor-

mation. Thus, the serviceParameter construct is very suitable for representing feature

customizations. A serviceParameter consists of two attributes serviceParameterName,

the name of the actual parameter, which could be just a literal, or perhaps the URI

of the process parameter, and sParameter which points to the value of the parameter

within some OWL ontology. A customized feature placed as a leaf node in the feature

model can be mapped to a serviceParameter instance with the Condition type for the

sParameter.

Moreover, new features can be included under the related variability category by the

domain experts in order to extend the scope of the default web service variability model.

After a new feature is added to the model, it can be transformed into the service ontol-

ogy deﬁnition as it is explained for the default features. Variabilities captured within a

feature model can be reﬂected to a business collaboration’s OWL-S counterpart which

is Service.

3.2 A Sample Feature Model for Web Services

We analyze the variability in web service deﬁnitions from three broad perspectives

namely Service Grounding, Service Proﬁle, and Service Model which have been once

introduced by the OWL-S service ontology. We adopt the Jiang et al’s notion [13] of

families of web services and bring the feature-oriented domain analysis (FODA) to it

instead of the pattern-based variability management approach.

In general, Service Grounding describes how to access the service through concrete

speciﬁcations such as binding protocol, address, message formats etc. Main variability

points of service grounding are identiﬁed in [14] as Binding Protocol and Binding Time.

Service Model describes the semantics of how a service interacts with its clients,

and the data and control ﬂows of corresponding process speciﬁcation. OWL-S process

models; Simple, Atomic, and Composite are subclasses of the Service Model. The ways

a client may interact with a service through exchanging messages provides a basis for

Service Model variability.

Service Proﬁle describes what is done by the service and presents necessary in-

formation such as service name, its text description, and contact information. Service

proﬁles are generally enabled in automated operations like dynamic service discovery.

It can be considered as a yellow page entry for the service functionality. Information

about inputs, outputs, preconditions and effects of the service are given the proﬁle part.

One important aspect of the service proﬁle is its service parameter option which give

the characteristic features of the service such as QoS and classiﬁcation of service func-

tionality in taxonomies provided by service registries. OWL-S’s service proﬁle can be

directly mapped to UDDI registry data model [15].

In order to produce appropriate exceptions, the ebBP speciﬁcations mandate a busi-

ness service interface to conform to a number of service parameters such as Authoriza-

tionRequired, NonRepudiationRequired, and NonRepudiationOfReceiptRequired dur-

ing the execution of the corresponding business activity. Indeed, each of these parame-

ters create a source of variability in service proﬁles.

We expose the previously identiﬁed variability points to our semantically enriched

feature model as shown in Figure 3.

4 Mapping ebBP to OWL-S

In this study, ebXML Business Speciﬁcation Schema (ebBP) is exploited in capturing

process deﬁnitions and business choreographies from a high abstraction level where

contributions of domain experts can be effectively incorporated in devising the domain

model. The main advantage of using ebBP is its powerful built-in mechanisms for sepa-

rating the deﬁnition of the process model from its realization and making it independent

from its enablers namely business actors.

ebBP is capable of specifying process model parameters for conﬁguring service in-

terfaces to execute and monitor business collaborations. However, ebBP does not spec-

ify how to associate a deﬁned service interface to its real world implementation.

In this research, conceptual mapping schemes between the generic ebBP instances

and OWL-S ontologies are developed. As an outcome of this mapping, previously de-

ﬁned business processes are reﬁned and brought one step closer to the realization phase

Fig.3. A reference variability model for semantic modeling of web service families.

automatically. Moreover,mapping ebBP deﬁnitions to OWL-S may foster service reuse.

Once the OWL-S model of a business service interface is described then the service

implementation may be discovered from the existing assets instead of developing the

service every time from scratch.

The basis for our mapping method is formed through comparing common compo-

nents sharing similar semantics in both standards. Also, we adopt ebBP’s bottom up

design approach for describing business collaboration and propose our transformation

strategy as follows;

1. Transform Business Transactions

2. Transform Business Document Flow for Business Transactions

3. Transform Binary (Business) Collaboration re-using the mapped Business Trans-

actions

4. Transform the choreography for the Binary (Business) Collaborations

5. Transform higher level Business Collaborations re-using the lower level Business

Collaborations translated previously

An overview of the mapping speciﬁcation is depicted in Figure 4. The conceptual

mappings from ebBP elements to their OWL-S counterparts are listed in [12]. However,

due to the size limitation we can only provide an essence of the transformation method

which is for the mapping from ebBP’s BusinessCollaboration to OWL-S’s Compos-

iteProcess. According to the ebBP speciﬁcations, a choreography is an ordering of

business activities within a business collaboration in order to specify which business

state is expected to follow another state.

Basically, OWL-S’s composite process consists of other atomic or composite pro-

cesses. Control ﬂow of a composite process is speciﬁed using control constructs which

can be nested to an arbitrary depth. Like business collaborations in the ebBP, composite

processes can be considered as state-oriented workﬂows. In the transformation method,

CompositeProcess class is preferred for representing underlying semantics of business

choreography. Main control mechanisms of the whole choreography is the Sequence

Fig.4. Overview of the mapping speciﬁcation.

element. Linking constructs (FromLink and ToLink) are mapped according to their type

and the class of the state they refer. For example, FromLink is transformed into a Con-

trolConstruct that can be further speciﬁed as a Perform, Split, Split-Join or Choice based

on the type of the referred state; Business Transaction Activity, Fork, Join and Decision

respectively. In ebBP, a choreography starts by linking to a business state so, we can

associate Start with a Sequence instance whose list:rest element refers to the state that

ToLink of the Start linking as well. Overall mapping from choreography construct of

ebBP to their OWL-S counterparts are given in Table 1. Transition, Fork, Join and De-

cision have at least one FromLink and one ToLink but maximum occurrence of these

linking constructs can vary depending on the choreography type. Fork and Decision

include at least two ToLink on the other hand, Join has at least two FromLinks.

Table 1. Choreography to Service Process Model.

ebBP Choreography OWL-S Counterpart (ControlConstruct)

/FromLink /ControlConstructList/list:ﬁrst/ControlConstruct

/ToLink /ControlConstructList/list:rest/ControlConstructList

/Start CompositeProcess/@composedOf/Sequence

/Start/@nameID /Sequence/@rdf:ID

/Transition/@nameID ControlConstruct/@rdf:ID

/Fork/@nameID /Split/@rdf:ID

/Join/@nameID /Split-Join/@rdf:ID

/Decision/@nameID /Choice/@rdf:ID

/B.T.A /C.C.L./list:ﬁrst/Perform/AtomicProcess

/Success No suitable match

/Failure No suitable match

5 An Example Walkthrough with the GENoDL

The ﬁrst step in generating web service ontologies is to provide our reasoning tool with

an ebBP instance as input. The tool then reﬁnes business process constructs such as

BusinessCollaboration in order to compile them in possible service ontology represen-

tations. To start the transformation process, ﬁrst a BusinessCollaboration is selected

from the Business Process Manager section of the user interface. The tool then loads

the default service feature model to the feature model editor. If the domain expert has

any extension or further customization requests, she can modify the feature model by

inserting/deleting or (de)selecting features through using the feature model editor bun-

dled within the tool. Newly inserted features should be associated with their formal and

machine readable deﬁnitions. After modiﬁcations, reasoner checks the resulting feature

model’s consistency and automatically corrects any invalid customization with domain

expert’s empowerment. Finally, the veriﬁed feature model along with the selected busi-

ness collaboration speciﬁcation is transformed into OWL-S notation according to the

given transformation rules.

It can be easily understood that a family of related service ontologies can be quickly

generated by applying the proposed generative method. For example, by selecting dif-

ferent children of the BindingProtocol feature can result in various service conceptu-

alizations that each of their implementations will be subject to be used in a distinct

application scenario.

6 Conclusions and Future Work

The developed mechanism was experimented through an example as in [12]. This ex-

ample included the mapping from an existing business process model, that represents

the domain-level knowledge. The outcome has been promising: in general it has been

observed that automated generation of web service ontologies is possible and usable.

However, our observation also states that very high-abstraction level elements of the

domain are not easy to map directly.

Our novel generative method for service ontology creation has not reached its ma-

turity yet. We would also like to address coarser-grained service ontologies and more

detailed process models. Also, the generative method will be extended with the map-

ping rules of other ebBP concepts such as guards, exceptions and signals.

Current versions of the feature model editor and feature model ontology do not

support cardinality-based relations among features as proposed in [16]. This is another

possible improvement area. An evaluation of memory allocated for varying input sizes

will be performed in order to assess the feasibility of the feature model veriﬁcation

operation from a different perspective.

Although our product line approach for service ontology generation is based on two

well known standards (ebBP and OWL-S), a more generic approach which is indepen-

dent from implementation technologies is considered as future work. Finally, evalua-

tion of the quality and domain coverage of the resulting service ontologies should be

explicitly justiﬁed through anticipated metrics and methods, so that domain experts and

developers can assess them easily.

References

1. Kang K. C., et al.: Feature-oriented domain analysis (foda) feasibility study. Carnegie-

Mellon University Software Engineering Institute (1990)

2. Jess: the rule engine for the java platform http://www.jessrules.com/

3. Ride deliverable 5.3.1 - contribution to standards: ebbp editor v1.0.4 user manual http://-

www.srdc.metu.edu.tr/webpage/publications/2007/ebBP Editor UserManualv1.0.4.pdf

4. Business process modeling notation (bpmn), Object Management Group/Business Process

Management Initiative http://www.omg.org/docs/dtc/060201.pdf

5. Czarnecki K., Kim C. H. P., Kalleberg K. T.: Feature models are views on ontologies. IEEE

SPLC (2006)

6. Lee S., et al.: An approach to analyzing commonality and variability of features using ontol-

ogy in a software product line engineering. IEEE SERA (2007)

7. Wang H., et al.: A semantic web approach to feature modeling and veriﬁcation. SWESE

(2005)

8. Guo L., et al.: Mapping a business process model to a semantic web service model. ICWS

’04: Proceedings of the IEEE International Conference on Web Services (2004)

9. Shen J., et al.: From bpel4ws to owl-s: integrating e-business process descriptions. SCC ’05:

Proceedings of the 2005 IEEE International Conference on Services Computing (2005)

10. Arsanjani A.: Service-oriented modeling and architecture (SOMA). IBM developerWorks

(2004)

11. O’Connor M., et al.: Supporting rule system interoperability on the semantic web with swrl.

Fourth International Semantic Web Conference (2005)

12. Orhan U.: Automated service ontology generation from domain engineering outcomes

http://genodl.wiki.sourceforge.net/space/showimage/genodl.pdf

13. Jiang J., Ruokonen A. and Systa T.: Pattern-based variability management in web service

development. ECOWS ’05: Proceedings of the Third European Conference on Web Services

(2005)

14. Segura S., et al.: A taxonomy of variability in web service ﬂows. Service Oriented Architec-

tures and Product Lines (SOAPL - 07)

15. Luo Jim, et al.: Adding owl-s support to the existing uddi infrastructure. International Con-

ference on Web Services ICWS’06, pp. 153–162 (2006)

16. Czarnecki K., Helsen S., Eisenecker U.: Staged conﬁguration through specialization and

multi-level conﬁguration of feature models. Software Process Improvement and Practice,

special issue on ”Software Variability: Process and Management, vol. 10(2), pp. 143 – 169

(2005)