Tải bản đầy đủ (.pdf) (98 trang)

Xây dựng hệ thống so trùng dịch vụ web

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.2 MB, 98 trang )

Đạ
i họ
c quố
c gia Tp. HồChí Minh
TRƯỜNG ĐẠI HỌC BÁCH KHOA
-------------------

LUẬNVĂN THẠC SỸ

XÂYDỰNG
HỆTHỐNG SO TRÙNG DỊ
CHVỤWEB

Họcv
i
ê
n:LêDuyNgạn
Gi
á
ovi
ê
nhướn
gdẫ
n
:
Gi
á
os
ưAngela Goh (NTU, Singapore)
Ti
ế


nSỹCaoHo
àngTr
ụ(
ĐHBK TP.HCM,
Vi

tNa
m)

12/7/2005


NANYANG TECHNOLOGICAL UNIVERSITY

Building a Matchmaker for Web Services
A first year report
Submitted to the School of Computer Engineering of
Nanyang Technological University for Ph.D. conformation
By
Le Duy Ngan
Supervised by
Professor Angela Goh
and Co-supervised by
Dr. Cao Hoang Tru

July 12, 2005


Tóm tắ
t

Các dị
ch vụweb (Web services), đặ
c biệ
t là các dị
ch vụWeb ngữnghĩ
a, là những kỹ
thuậ
t quan trọng trong các hệthố
ng thương mạ
iđiệ
n tử. Những dị
ch vụWeb ngữnghĩ
a
này được xây dựng bởi những ontology, một đặ
c tảgồm những khái niệ
m và các mối
quan hệgiữa các khái niệ
m, từđócó thểsuy diễ
n ra những tri thức mới. Sựphát triể
n
nhanh chóng và sựtồn tạ
imột sốlượng lớn các dị
ch vụWeb hiệ
n tạ
i đãdẫ
n đế
nmột nhu
cầ
u vềtìm kiế
m những dị

ch vụWeb này. UDDI là một cơng cụđiề
n hình của loạ
idị
ch
vụtìm kiế
m này nhưng nó khơng hỗtrợngữnghĩ
a. Trong khi đó, hỗtrợngữnghĩ
alà rấ
t
quan trọngtrong các hệthống tim kiế
m.
Đểvượt qua những khuyế
t điể
m này, các nhà nghiên cứu đãphát triể
n những hệ
thống so trùng (Matchmaker). Những hệthống so trùng này có thểđá
p ứn
g tốt khi các
dị
ch vụWeb cung cấ
p và dị
ch vụWeb tìm kiế


u sửdụng chung các ontology, nhưng
chúng không hỗtrợkhi các dị
ch vụWeb sửdụng các ontology khác nhau. Vì thế
, mặ
c dù
nế

u dị
ch vụWeb cung cấ
p có thểđá
p ứng được yêu cầ
u của dị
ch vụWeb yêu cầ
u thì việ
c
so trùng này cũng trảvềkế
t quảlà sai. Trong khi đó, trong thếgiớithực thì nhà cung cấ
p
dị
ch vụvà nhà u cầ
udị
ch vụlà khác nhau và hoạ
t động độc lậ
p nhau nên họthường
dùng những ontology khác nhau đểmơ tảdị
ch vụWeb củamình.
Luậ
nvă
nnà
ygiới thiệ
u mộthệthống so trùng mà hỗtrợnhững dị
ch vụWeb sử
dụng những ontology khác nhau. Luậ
nvă
ntrình bày giả
i thuậ
t so trùng hỗt

rợnhữngdị
ch
vụWeb sửdụng những ontologies khác nhau và một kiế
n trúc hệthống cho giả
i thuậ
t
này. Những thành phầ
n chính của hệthống so trùng bao gồm: kỹthuậ
t phân loạ
i vă
n bả
n,
kỹthuậ
t xem xét hai khái niệ
m có xuấ
t phát từmột ontology hay khơng, kỹthuậ
t tính độ
giốngnha
ucủa các khái niệ
m. Một ứng dụng dây chuyề
n cung cấ
p (supply chain) được
giới thiệ
u và sửdụnghệthống so trùng mà chúng tôi đềnghị
. Việ
c mởrộng hệthống so
trùng bằ
ng cách sửdụng kỹthuậ
t kế
t nốicác dị

ch vụWeb đểđá
p ứng nhu cầ
u so trùng
được thực hiệ
n ởhai nă
m tiế
p theo củachương trình tiế
ns

.

i


Acknowledgements
After one year‟
sha
r
dwor
k
, I have obtained preliminary results to contribute to the
scientific community. During this time, I have received a lot of help, guidance, and
encouragement from many individuals. The research can not be completely successful
without their support. This report is a good opportunity for me to express my thanks to
them.
First and foremost, I would like to express my special gratitude towards my
supervisor, Professor Angela Goh, for her invaluable advice and enthusiastic help.
Although very busy, she spends much time advising me and revising my errors in this
report and papers. During the time working with her, I not only learn how to do academic
research but also many good characteristics from her.

Second, I wish to express my thanks to people who shared their ideas, gave their
comments, and spent their time in discussion with me. They are Quan Thanh Tho, Do
Tien Dung, and Zhou Chen in NTU; all members of IMSS pilot project in SIMTech
especial Chong Minsk, Siew Poh, Ramasamy; and Michael C.Jaeger in Berlin University.
Next, I wish to thank Dr. Cao Hoang Tru, my co-supervisor in Vietnam, for his
help and advice. I would like to thank Vietnamese teachers who recommend me to
receive the scholarship which has changed my life. I would like to express my gratitude
to Dr. Duong Tuan Anh and Dr. Nguyen Van Hiep who wrote recommended letter to
NTU. I wish to thank NTU for the financial support through the scholarship.
Finally, I am grateful to my parents, my younger sister Le Thuy Ngoc, and my
closest friend Nguyen Hong Khoat in Vietnam for their love and encouragement, which
has helped me overcome many difficulties faced during the research.

Singapore, July 12th 2005
Le Duy Ngan

ii


Table of Contents

Chapter 1: Introduction ................................................................................................... 1
1.1 Web Service and Semantic Web Service .................................................................. 2
1.1.1 Web Services ..................................................................................................... 2
1.1.2 Semantic Web Service ....................................................................................... 3
1.2 Motivations and Objectives ...................................................................................... 4
1.2.1 Problem definition ............................................................................................. 4
1.2.2 Scope and objectives .......................................................................................... 5
1.3 Outline of the report .................................................................................................. 6
Chapter 2: Related technologies ...................................................................................... 7

2.1 Semantic web architecture ........................................................................................ 7
2.2 Introduction to Ontology .......................................................................................... 8
2.3 Web Services .......................................................................................................... 10
2.3.1 Web Services Standards................................................................................... 10
2.3.2 Web Services Model ........................................................................................ 13
2.4 Semantic Web Services .......................................................................................... 14
Chapter 3: Literature Review ........................................................................................ 18
3.1 A survey of web services discovery ....................................................................... 18
3.1.1 Web services discovery systems ...................................................................... 18
3.1.2 Discovery of web services using the same ontology ....................................... 19
3.1.3 Discovery for web services using different ontologies .................................... 24
3.2 Web services discovery problems and approaches ................................................. 25
3.2.1 Matching web services using different ontologies........................................... 25
3.2.2 Matching semantic web services against non-semantic web services ............. 26
3.2.3 Matching semantic web services that use different description languages...... 28
iii


Chapter 4: MOM Framework ....................................................................................... 29
4.1 MOM algorithm ...................................................................................................... 29
4.1.1 Storing advertised web service information in MOM ..................................... 29
4.1.2 Basic terminology ............................................................................................ 31
4.2 The four stages matching algorithm ....................................................................... 33
4.2.1 User-defined Matching .................................................................................... 34
4.2.2 Input matching ................................................................................................. 35
4.2.3 Output matching............................................................................................... 38
4.2.4 Operation matching.......................................................................................... 39
4.2.5 The final matching result ................................................................................. 40
4.3 The algorithm for web services using different ontologies .................................... 42
4.4 MOM Architecture ................................................................................................. 45

4.4.1 MOM components ........................................................................................... 45
Chapter 5: Main modules in the MOM ........................................................................ 48
5.1 Relationship of two concepts from different ontologies ......................................... 48
5.1.1 Ontology replications in the internet................................................................ 48
5.1.2 Checking if two concepts from different ontologies are related ...................... 49
5.2 Computing the semantic similarity of two concepts ............................................... 50
5.2.1 Previous work on computing semantic similarity............................................ 51
5.2.2 Our approach to compute the semantic similarity ........................................... 54
5.3 Text clustering ........................................................................................................ 56
5.3.1 Text Processing ................................................................................................ 56
5.3.2 Clustering methods .......................................................................................... 58
5.3.3 Choosing Text Clustering Approach ............................................................... 60
Chapter 6: A Scenario using MOM .............................................................................. 63
6.1 A Supply Chain Application ................................................................................... 63
6.2 An Example ............................................................................................................ 65
6.2.1 Same ontologies used....................................................................................... 65
6.2.2 The requester and providers use the same ontology ........................................ 69
6.2.3 The requester and providers use different ontologies ...................................... 70
iv


Chapter 7: Conclusions and future work ..................................................................... 73
7.1 Conclusions ............................................................................................................. 73
7.2 Future work ............................................................................................................. 74
7.2.1 An extension of MOM ..................................................................................... 74
7.2.1.1 Using web services composition for discovery ........................................ 74
7.2.1.2 Clustering ontologies to improve MOM ................................................... 78
7.2.2 Implementation and state of components ........................................................ 78
7.2.3 Future work schedule ....................................................................................... 80
Schedule of 2005 - 2006 ............................................................................................... 82

Schedule of 2006 - 2007 ............................................................................................... 83
Reference: ........................................................................................................................ 84
Publication ....................................................................................................................... 90

v


List of Figures
Figure 2.1: The Semantic Web Architecture [72] ............................................................... 7
Figure 2.2: A WSDL Example.......................................................................................... 11
Figure 2.3: Web service roles, operations, and artifacts ................................................... 13
Figure 2.4: Top level of the service ontology ................................................................... 16
Figure 3.1: Taxonomy of web service discovery systems ................................................ 18
Figure 4.1: The relation of concepts ................................................................................. 32
Figure 4.2: Four stages matching algorithm ..................................................................... 41
Figure 4.3: Matching Algorithm ....................................................................................... 43
Figure 4.4: MOM Engine.................................................................................................. 47
Figure 5.1: The relationship of two ontologies ................................................................. 49
Figure 5.2: The different context of the Laptop concept .................................................. 55
Figure 5.3: Comparison process by similarity score......................................................... 58
Figure 5.4: A hierarchical clusters .................................................................................... 59
Figure 6.1: A supply chain model using MOM ................................................................ 65
Figure 6.2: Ontology in eBusiness domain ....................................................................... 66
Figure 6.3: Ontology for computer device domain ........................................................... 67
Figure 6.4: Ontology for price domain ............................................................................. 68
Figure 6.5: Requested and advertised services. ................................................................ 69
Figure 6.6: Ontology for computer hardware device domain ........................................... 71
Figure 6.7: Toshiba request service .................................................................................. 71
Figure 7.1: Proposed Extension to MOM ......................................................................... 77
Figure 7.2: The status of MOM components ................................................................... 80

Figure 7.3: Research schedule for the second year ........................................................... 82
Figure 7.4: Research schedule for the third year .............................................................. 83

List of Tables
Table 3.1: Advantages and disadvantages of three approaches to semantic web discovery
based on the same ontology ...................................................................................... 23
Table 4.1: The information of web service providers is advertised in MOM................... 30
Table 4.2: Degree similarity for input matching ............................................................... 38
Table 4.3: Degree of similarity for output matching ........................................................ 39

vi


Chapter 1: Introduction

The World Wide Web is considered one of the greatest inventions of the twenty-first
c
e
nt
ur
y
.I
ti
sc
a
l
l
e
d“
ar

e
vol
ut
i
onofi
nf
or
ma
t
i
on”s
i
nc
ei
tpr
ovi
de
sne
w wa
y
st
os
ha
r
e
,
search, and publicize information easier and more conveniently than ever before.
HyperText Mark-up Language (HTML) [71] is one of the most important reasons behind
its success. Most web documents formatted using HTML, link documents to other
documents. Currently, the World Wide Web has billions of web pages and continues to

increase rapidly. As a consequence, there has been an enormous demand to have
mechanisms to retrieve information. Search engines such as Google [25], Yahoo [77],
Excite [20], etc have been developed to satisfy this demand. However, the documents are
formatted in HTML and support searching only by keywords. There are three main
disadvantages. Firstly, searches produce a large number of results, many of which are
inaccurate. Additionally, users must select from a large number of links in the results
manually. Furthermore, without linguist matching, synonyms of keywords are ignored
and hence, the results are inaccurate and incomplete.
To overcome these problems, Tim Berners-Lee, the inventor of the World Wide
Web, has coined the term “
Semantic Web”[5].
The Semantic Web is an extension of the current web in which information is
given well-defined meaning, better enabling computers and people to work in
cooperation." -- Tim Berners-Lee, James Hendler, Ora Lassila, The Semantic
Web, Scientific American, May 2001
The Semantic Web is the next generation of the web and is an extension of the
current World Wide Web. It attempts to overcome the drawbacks of the current Web by
using metadata to describe the semantics of the data. When metadata is used to mark-up
data, the data can be not only human readable but also be understood by machines. An
ontology is a specification of classes or concepts and their relationships, with constraints
1


CHAPTER 1: INTRODUCTION

that can be used to represent and infer knowledge, and shared by the communities or
programs. These ontologies are used as metadata in the Semantic Web and provide many
advantages such as knowledge representation and reasoning, and re-use and sharing of
such knowledge between programs. By using ontologies to describe knowledge, the web
can be brought to its full potential.

This introduction presents technologies that are key to the project, namely web
service and semantic web service. This leads to the motivations and objectives of the
project, followed by an outline of the report.

1.1 Web Service and Semantic Web Service
1.1.1 Web Services
Web services are an emerging technology that enables e-business and e-commerce to
become a reality. This is achieved through its support of discovery, composition,
invocation, monitoring and so on. Web services have become a competitive tool of
companies in business. Firstly, they allow companies to reduce cost by fast, effective, and
reliable services to customers, suppliers, and partners over the internet. Secondly, they
enable business operations to function more efficiently via the web and enhance business
opportunities to companies. A web service is a software component representing a
specific business function that can be described, published and invoked over the network
(typically Internet) using open-standards. It uses a remote invocation method based on
XML [73] for its binding, and supports both asynchronous and synchronous interaction.
A web service has the following features: platform independence, internet scoped,
loosely coupled, easy interaction. The web service requesters and providers do not need
to run on the same platform. Web services can run on different networks (Internet,
I
nt
r
a
ne
t…)a
nd di
f
f
e
r

e
ntope
r
a
t
i
ng s
y
s
t
e
ms (
Wi
ndows
,Li
nux …)
,a
nd c
a
n be
i
mpl
e
me
nt
e
dus
i
ngdi
f

f
e
r
e
ntpr
og
r
a
mmi
ngl
a
ng
ua
ge
s(
J
a
va
,C,C++…)
.A we
bs
e
r
vi
c
e
has a global scope and can be invoked over the internet, including computers that are
firewalled.

2



CHAPTER 1: INTRODUCTION

Prior to the availability of web services, mechanisms such as CORBA [50, 51]
DCOM [48, 57], Electronic Data Interchange (EDI) [36, 55] had to be used in order to
invoke some functionalities of another or
ga
ni
z
a
t
i
on‟
s computer. However, these
techniques have limitations. Firstly, these distributed technologies require specific
languages. For example, CORBA uses Interface Definition Language (IDL) [14, 44]. In
contrast, web services are very flexible in implementation; C, Java, or other commonly
used languages can be used to develop web services. Secondly, these distributed
techniques require exact function names to be called, whereas, web services are loosely
coupled. For example, a computer sales service has price as the input, and the output is
the configuration of the computer. To invoke this service in the distributed techniques,
the output must be a specific computer configuration which was described by the offered
service. In the web service, the output does not need to describe the specific computer
configuration. It could be general or specific. Finally, those mechanisms do not operate
well over the Internet in the presence of firewalls. Web services have overcome the
shortcomings of previous distributed mechanisms.
Web services which are supported by W3C [75] include three standard
technologies, namely, service description, service discovery, and communication
protocols. Web Service Description Language (WSDL) [69, 76] is used to describe the

service. A web service registers its information in the Universal Description, Discovery
and Integration (UDDI) [52, 76]. Web services communicate via Simple Object Access
Protocol (SOAP) [70, 76] which is a W3C standard. However, based on these standard
technologies, the web service cannot fully satisfy the requirements of business
applications because of limitations in automatic discovery and composition. For example,
awe
bs
e
r
vi
c
ei
suna
bl
et
o“
know”t
ha
t“
not
e
book”a
nd“
l
a
pt
op”r
e
f
e

rt
ot
hes
a
met
hi
ng
.
The reason for this shortcoming is the lack of semantic understanding. To overcome this
problem, web services require a method to incorporate semantics.

1.1.2 Semantic Web Service
Web services are indispensable to e-business and for exchanging information over the
web. Unfortunately, using WSDL to describe the services allows them to be accessed by
3


CHAPTER 1: INTRODUCTION

keyword only. This limitation prevents fully automatic discovery, invocation,
composition, and so on. Just as the Semantic Web is an extension of the current World
Wide Web, a semantic web service is an extension of web services. It overcomes web
service limitations by using knowledge representation technology from the Semantic
Web. Specifically, it uses ontologies to describe its service instead of using WSDL. Such
ontologies can be understood by machines and can be reasoned upon. This allows a fully
automatic discovery, composition, and invocation in web services.

1.2 Motivations and Objectives
1.2.1 Problem definition
Web service discovery is the most important task in the entire web service oriented

architecture. They have been used in e-business, workflow, e-learning etc. In the
workflow field, web services discovery is used to automatically locate web services, in
order to complete some services that is lacking in the workflow. A web service is
dysfunctional if it cannot be discovered. UDDI provides standard registration and
discovery of web services. We can search by service name and other information through
UDDI. However, the search provided by UDDI is only limited to keyword search. These
keyword searches cannot recognize the web services with different keywords but have
the same or similar meaning.
To overcome this problem, researchers have developed Matchmakers to match
web service requesters with web service providers. The web service providers advertise
their information to the matchmaker and the advertised information will be stored in the
Matchmaker. When a requester with a certain requirement wants to find a service, the
Matchmaker will attempt to match the profiles of the requester with the advertised
information of providers in its database. As a result of the matching, the Matchmaker will
produce a list of relevant providers.
Current Matchmakers are adequate when the web service requester and provider
use the same ontology and reasoner to determine the relationship between two services.
Unfortunately, they do not support the situation where a web service requester and
4


CHAPTER 1: INTRODUCTION

provider use different ontologies. In the real world, a web service provider can provide an
exact service to the requester even though both services use different ontologies. Since
the web service requester and provider operate independently, they usually define their
own ontologies to describe their services. Therefore, a Matchmaker that supports web
services using different ontologies is extremely important and provides the motivation
behind this work
Consider the following scenario: Some companies in Singapore provide computer

solution services. They define their own ontology in the computer domain to describe
their services. A company in Vietnam wishes to buy a computer and it defines its own
ontology in the same computer domain to describe its services. There are no global
ontologies in the domain and the provider and the requester do not know each other. So,
the two ontologies they define in the same computer domain are different. Current
Matchmakers are unable to match the web service requester and provider in such a
s
i
t
ua
t
i
on,butobvi
ous
l
y
,t
hepr
ovi
de
r
sc
a
npr
ovi
dea
ne
xa
c
tf

i
tt
ot
her
e
que
s
t
e
r

s demands.

1.2.2 Scope and objectives
There are many issues related to semantic web services such as discovery, invocation,
composition, and monitoring. Each issue is an interesting research area and provides a
challenge to the research community. The focus of this work is on web services
discovery. The other issues are outside of our scope. For example, we will introduce how
web services are invoked and composed but will not undertake to explore these areas in
this report.
Additionally, as mentioned above, the web service provider and web service
requester do not know each other and they use different ontologies. We assume that a
group of providers offer services in a specific domain, and they develop an ontology to
describe their services. A requester requires a service and it develops its ontology to
describe the web service. In the discussion to follow, we assume that the building and
maintaining of the ontologies are outside the scope of our work.

5



CHAPTER 1: INTRODUCTION

The primary aim of the project is to design a Multi-Ontologies Matchmaker for semantic
web services (termed MOM). In order to achieve this aim, the following objectives are to
be met:
1. Develop algorithms to determine if web services perform the same function by
checking if two concepts can be subsumed, and by computing similarity of two
concepts.
2. Design MOM engine.

1.3 Outline of the report
This chapter gives background information, motivation, and objectives of the report.
Some major issues are also discussed. The rest of the report is organized as follows:
Chapter 2 presents a background of related technologies utilized in Matchmakers.
The major technologies are web services, Semantic Web, semantic web service,
ontology, and tools. Chapter 3 is a literature review of current Matchmakers. Their
advantages and disadvantages are highlighted. Three shortcomings of current web service
discovery systems are pointed out.
This is followed by Chapter 4, which describes the algorithm and architecture of
MOM. Chapter 5 introduces three main components which are crucial to the building of
MOM, namely, text clustering, checking if two concepts can be subsumed, and
computing the similarity of two concepts.
An application and example in the supply chain domain is presented in Chapter 6.
This illustrates the practical application of MOM. Finally, chapter 7 contains the
conclusion and future work, including a schedule and detailed discussion of the proposed
work for the next two years of the Ph.D.

6



Chapter 2: Related technologies

This chapter introduces further details about the Semantic Web, web services, and
semantic web service technologies which were briefly introduced in chapter 1. Firstly, the
architecture of the semantic web is introduced, followed by an elaboration of the concept
of ontology. Web service standards such as WSDL, UDDI, and SOAP are briefly
explained and web services model which has been recommended by W3C is introduced.
Finally, semantic web service features such as automatic discovery, composition, and
monitoring are presented.

2.1 Semantic web architecture
Berners-Lee, t
he„
inventor‟oft
heWorld Wide Web, recommended the semantic web
architecture (figure 2.1) which has been considered as a standard. It includes seven layers
[71], namely, Foundation, XML Schema, Ontology, Logic, Proof, and Trust layer.

Figure 2.1: The Semantic Web Architecture [71]
The Foundation layer consists of Uniform Resource Identifier (URI) and Unicode.
URI is used to identify the Web resource and Unicode standard is used to encode the
7


CHAPTER 2: RELATED TECHNOLOGIES

documents. The second layer is XML Schema which is an XML based alternative to
DTD (Document Type Definition) and is used to describe the structure of an XML
document. The third layer is RDF Schema which includes RDF + rdfschema. RDF which
stands for Resource Description Framework is a language for representing information

about resources in the Web. RDF schema is a language for declaring basic class and types
for describing the terms used in RDF. The two layers define objects and classes, their
relations and constraints. The next layer is the Ontology vocabulary which provides a
way to express more semantics which cannot be represented in the two schema layers.
The logic layer enables inferences from the existing knowledge. The Proof Layer
confirms the truth of a statement. The Trust layer resolves conflicts between knowledge
carried by the Semantic Web. Currently, the Proof Layer and the Trust layer have not
been extensively developed. Digital signature is used to secure documents.

2.2 Introduction to Ontology
As mentioned in chapter 1, the semantic web uses metadata to describe the semantics of
the data. Metadata is structured data about data. On the web, metadata is usually a
descriptive language which describes Web resources. Ontology has been proposed as the
primary metadata since it can describe the knowledge accurately and expressively. The
most important difference between ontology and other methods of knowledge
representation is ontology should be machine readable. Ontologies are usually used to
represent knowledge in a specific domain (a domain is a specific area such as medicine,
manufacturing, supply chain, finance, etc.).
The above is a general definition of ontology. A formal definition is as follows:
“An ont
ol
ogyc
ons
i
s
t
sof6 e
l
e
me

nt
s{
C,AC, R, AR, H, X}, where C
represents a set of concepts; AC represents a collection of attributes sets,
one for each concept; R represents a set of relationships; AR represents a
collection of attribute sets, one for each relationship; H represents a
concept hierarchy; and X represents a set of axioms. Each concept ci in C
represents a set of objects of the same kind, and can be described by the
same set of attributes denoted by AC(ci). Each relationship ri(cp,cq) in R
8


CHAPTER 2: RELATED TECHNOLOGIES

represents a binary association between concepts cp and cq, and the
instances of such a relationship are pairs of (cp,cq) concept objects. The
attributes of ri can be denoted by AR(ri). H is a concept hierarchy derived
from C and it is a set of parent-child (or superclass–subclass) relationships
betweens concepts in C. (cp,cq) H if cq is a subclass, or sub-concept, of cp.
Eac
hax
i
omi
nXi
sac
on
s
t
r
ai

ntont
hec
onc
e
pt

sandr
e
l
at
i
ons
hi
p’
sat
t
r
i
but
e
values or a constraint on the relationships between concept objects. Each
constraint can be expressed like a Prolog-l
i
k
er
ul
e
.
”[7]
To describe ontologies in Semantic Web, some languages have been defined.

They can be classified into three groups: HTML-based, XML-based, and RDF-based. In
the HTML-based group, knowledge is represented by using HTML tags. Simple HTML
Extension (SHOE) [29] and Ontobroker [21] are two typical examples of this group.
However, ontologies in this group do not support schema definition. Thus, classes are
difficult to define. To overcome this shortcoming, XML-based ontology description
languages support schema based on XMLS or DTD. Semantic information can be
embedded directly into XMLS or DTD. However, ontologies in this group have
limitations in expressing semantics.
RDF [72] is used to overcome this drawback. RDF can be used to represent
ontology more effectively by representing relationships between concepts. Moreover,
RDF Schema (RDFS) [72] can be used to create classes in domains in the form of class
hierarchies. The DARPA Agent Markup Language (DAML) [10] extends RDFS by using
the object-oriented approach to represent ontology. By using the object-oriented
approach, the class representation of DAML is superior to that of RDF. The Web
Ontology Language (OWL) [74] is an extension of DAML. OWL allows various types of
relationships between classes to be defined. It also supports properties of a class. OWL is
an emerging ontology representation, and hence, is used in the implementation of the
proposed Matchmaker.

9


CHAPTER 2: RELATED TECHNOLOGIES

2.3 Web Services
2.3.1 Web Services Standards
W3C has defined three standards, namely, Web Service Description Language (WSDL),
Universal Description, Discovery and Integration (UDDI), and Simple Object Access
Protocol (SOAP).
Web Service Description Language (WSDL): WSDL [69, 76] is used to

describe how to access a web service and what operations (methods) it performs. WSDL
is also used to locate web services. A WSDL document defines a web service using four
major elements, namely, port types, message, types and binding. An elaboration of these
elements is as follows:
 WSDL Ports: The is the most important element in WSDL. It defines
a web service with operations that can be performed and messages that are
involved. The element is similar to a function library (or a module, or
a class) in a traditional programming language.
 WSDL Messages: The <message> element defines an abstract, typed definition of
the data being communicated. Each message can consist of one or more logical
parts like parameters of a function call in a traditional programming language.
 WSDL Types: The <types> element defines a container for data type definitions
that are relevant for the exchanged messages. For maximum interoperability and
platform neutrality, WSDL uses XML Schema syntax to define data types.
 WSDL Bindings: The <binding> element defines a concrete protocol and data
format specification for a particular port type.
In the example given in figure 2.2, the portType element defines glossaryName as
the name of a port, and getName as the name of an operation. The getName operation has
an

input

message

called

getNameRequest

and


an

output

message

called

getNameResponse. The message elements define the parts of each message and the
associated data types. As a means of comparison with traditional programming,

10


CHAPTER 2: RELATED TECHNOLOGIES

glossaryTerms is a function library, getName is a function with getNameRequest as the
input parameter and getNameResponse as the return parameter.
WSDL Example:
<message name="getNameRequest">

</message>
<message name="getNameResponse">

</message>

<operation name="getName">
<input message="getNameRequest"/>
<output message="getNameResponse"/>
</operation>

</portType>

Figure 2.2: A WSDL Example
Universal Description, Discovery and Integration (UDDI): UDDI [52, 76] is an
industry specification for describing, publishing, and finding Web services. It allows
developers to describe and classify their services, and the technical details about the
interfaces of the web services which are exposed. UDDI also enables developers to
consistently discover services, or interfaces of a particular type, classification, or
function. It also defines a set of Application Programming Interfaces (APIs) that
developers can use in order to interact with UDDI data directly.
The UDDI scheme uses White, Yellow, and Green pages as data categories. The
following are details of each category:
 White Pages: store basic contact information about an advertised company,
such as the business names, addresses and contact information.
11


CHAPTER 2: RELATED TECHNOLOGIES

 Yellow Pages: store industry classification. It describes a business service
using different categorizations ("taxonomies" in UDDI terminology). This
information allows others to discover business services based upon its
categorization.
 Green Pages: are expected to offer more specific information on what types of
electronic documents a business can receive, the entry points for transactions and
underlying technology. Green pages provide technical information on the
behavior and supported functions of a business service hosted by a business.
Simple Object Access Protocol (SOAP): SOAP [70, 76] is a communication
protocol based on XML that allows applications to communicate over the Internet. SOAP
does not define any programming model or implementation specific semantics. It

describes a simple mechanism for expressing application semantics by providing a
modular packaging model and encoding mechanisms for encoding data within modules.
SOAP is independent of platform and language.
A SOAP message is an XML document containing four elements, namely,
envelope, header, body, and fault. These elements are described as follows:
 Envelope: a mandatory root element that identifies the XML document
representing the message.
 Header: is an optional element and is the first child element of the Envelope
element. It defines a few attributes that can be used to indicate who should deal
with a feature.
 Body: is a mandatory element that contains the actual SOAP message intended
for the ultimate endpoint of the message.
 Fault: is an optional element that provides information about errors which
may occur while processing the message. It is a child element of the Body
element.

12


CHAPTER 2: RELATED TECHNOLOGIES

2.3.2 Web Services Model
The web service model in figure 2.3 shows the interaction between service requester,
service provider, and service registry.
 A service provider offers web services which provide functions or business
operations. They are created by companies, organizations, or countries. In order to be
called, the web services must be described. This will facilitate discovery and
composition. WSDL is used to carry out this function.

Service

Registry:
UDDI

Find

- White pages
- Yellow pages
- Green pages

Publish
WSDL

WSDL

Service
Requester

Bind

WSDL

Service
Provider
WSDL

Figure 2.3: Web service roles, operations, and artifacts
 The web service requests describe requirements in order to locate service providers.
Service requesters usually contain a description of the web service, though it is not a
web service which can run on the internet. The requirements are usually described by
WSDL.

 The service registry is a broker that provides registry and search functions. The
service providers advertise their service information in the service registry. This
information will be stored in the registry and will be searched when there is a request
from service requester. UDDI is used as a registry standard. UDDI stores service
information in white pages, yellow pages, and green pages.
13


CHAPTER 2: RELATED TECHNOLOGIES

All three roles interact with each other via publishing, discovery, and binding
operations. These operations are elaborated upon as follows:


Publish: the web service providers publish their service information through

the registry for requesters to discover. Through the publishing operation, the web
service provider stores WSDL in the UDDI.
 Discovery: the web service requesters retrieve service providers from the
service registry. Based on WSDL, which describes the requirements the web
service requesters, the UDDI will output a list of web service providers which
satisfy the requirements.
 Bind: After discovery, the service registry provides a number of web service
providers. The web service requester invokes these web service providers. The
binding occurs at runtime. The web service requesters and web service providers
will communicate via SOAP protocol.

2.4 Semantic Web Services
As mentioned in the chapter 1, semantic web services are an extension of web services by
using knowledge representation technologies of the Semantic Web. For semantic web

services to become a reality, the markup languages must be sufficiently descriptive that a
computer can automatically determine its meaning. The requirements of such a language
include:
Automatic Discovery: Automatic web service discovery is an automated process
for locating web services whose properties and capabilities satisfy t
he r
e
que
s
t
or

s
requirements. For example, a user wishes to find a service that sells computers and
accepts a particular credit card. Currently, this task must be performed by a human who
might use a search engine to find a service. The user must read the results through a web
page, and execute the service manually, to determine if it satisfies the constraints. With
semantic web services, the information necessary for web service discovery could be
specified as computer-interpretable semantic markup, and a service registry or agent
could be used to locate the services automatically.
14


CHAPTER 2: RELATED TECHNOLOGIES

Automatic Invocation A software agent or a computer program must be able to
automatically determine how to invoke or execute the service. A semantic web service
provides a descriptive list of what an agent needs to do to be able to execute the service.
A software agent should be able to interpret the description to determine what input is
necessary to invoke the service, and what information will be returned.

Automatic Composition:

This

task involves

the automatic selection,

composition, and interoperation of web services to perform some complex task or a highlevel description provided by requesters. Currently, the user must select the web services
and specify the composition manually. In semantic web services, software agents are
expected to select and combine a number of web services to complete a complex
objective.
Automatic Monitoring: while the system is operating, software agents need to be
able to verify and monitor the service properties automatically.
There are different semantic web service description languages and each uses
different ontology description languages. For example, DAML-S [9], a semantic markup
for web service language, uses DAML [10] ontology to describe the services. OWL-S
[11], which supersedes DAML-S [11], uses Web Ontology Language (OWL) [74]. OWLS was created to replace DAML-S and has a more expressive description capability.
Another such language is Web Service Modeling Ontology (WSMO) [60]. WSMO is an
ontology language which is used for describing semantic web services. WSMO together
with Web Service Modeling Framework (WSML) [41] and Web Service Execution
Environment (WSMX) [62] presents a framework for semantic web services, combining
semantic web and web service technologies. Currently, WSMO and OWL-S are the most
expressive description languages.
A semantic web service includes four basic classes, namely Service,
ServiceProfile, ServiceModel, and ServiceGrounding (figure 2.4).

15



CHAPTER 2: RELATED TECHNOLOGIES

Resource

ServiceGrounding
pr ovides

supports
How to access the service

Service

presents

describeby

ServiceProfile

ServiceModel

What the service does

How the service work

Figure 2.4: Top level of the service ontology
Matching uses only ServiceProfile because it contains the description of the service to be
discovered. The ServiceProfile represents the service through class Profile. A class
Profile has three basic types of information, namely, contact information, functional
description of the service, and additional properties.
The contact information is meant for human users. It includes serviceName which

is the name of the service, and contactInformation which shows the address, telephone
number, etc. of the owner of the service. The textDescription provides a brief description
of the service. It summarizes what the service offers, or describes what service is
requested. In the proposed framework, we use textDescription of the web service
provider and requester to check if two services have a common description. If such a
commonality exists, we assume these two services perform the same function. This
implies that the provider is able to me
e
tt
her
e
que
s
t
e
r

sne
e
d.
The functional description of the service is the most important declaration in the
Profile that is used for matching. It specifies the parameters of the inputs, outputs,
preconditions, and effects of the service. The inputs are parameters required by the
service and the outputs are the parameters which are generated by the service. The
precondition indicates the condition necessary before execution of the service and the
effect is the condition after execution of the service. For example, to invoke a web
16


CHAPTER 2: RELATED TECHNOLOGIES


service to buy a computer and pay via credit card, the input is price, the output is the
computer configuration, the precondition is that the credit card must be valid, and the
effect is that the credit card must be charged.
Additional properties which describe features of the service are serviceParameter,
qualityRating, serviceCategory, etc. The Profile also declares an operation of the web
service. Matching two operations of two web services is one of four stages of the
matching algorithm. This stage is called operation matching which will be elaborated on
in section 4.2.4.
This chapter has described the technologies that form the foundation to the
project. An understanding of such technologies was needed not only to appreciate the
evolution of web services but to determine the choice of languages to utilise in the
implementation of MOM.

17


×