Development of Front End Tools for Semantic Grid Services

goldbashedAI and Robotics

Nov 15, 2013 (3 years and 1 month ago)

103 views



Development of Front End
tools for Semantic Grid Services




TechReport


1

IT@MIT


Development of Front End Tools for Semantic Grid Services



TECHNICAL PROGRESS REPORT

(April, 2005


October, 2005)



Submitted to


Centre for Development of Advanced Computing

Bangalore



By


Dr S.THAMARAI SELVI

CHIEF INVESTIGATOR










Department of

Information Technology

M.I.T. Campus of Anna University

Chromepet, Chennai


600 044.












Development of Front End
tools for Semantic Grid Services




TechReport


2

IT@MIT


Project Summary



Grid computing has emerged as an important field, distinguished from conventional
distributed computing by its focus on large
-
scale resource
sharing, innovative applications. The grid
problem is defined as flexible, secure, coordinated resource sharing among dynamic collections of
individuals, institutions and resources


what is referred as virtual organizations. Grid technologies
support the
sharing and coordinated use of diverse resources in dynamic virtual organizations. In
such settings, a problem of unique authentication, authorization, resource sharing, resource
discovery and other challenges were encountered. These problems were effectiv
ely addressed by
Open Grid Service Architecture. It proposes Monitoring and Discovery Service for enabling
resource sharing and discovery that support conventional keyword matching for discovering the
resources.

The project attempts to develop a methodolo
gy that describes the various grid resources
semantically and presents an algorithm that enables semantic search of those resources. With this
project, we propose an architecture for semantic grid services that exploits the concept of semantic
web services

to an extent. We use WSDL2OWLS tool to describe Grid Service semantically. The
Algernon inference engine is used to query the service ontology and thereby facilitate semantic
search of resources. This module can further be extended to semantic Matchmaking

with proper
literature survey. This project would be the initial step to develop Front End Tools for Semantic Grid
Services.














Development of Front End
tools for Semantic Grid Services




TechReport


3

IT@MIT

Index


Sl.No


Contents


Page No





1.

Introduction










2

2.

Background










4


2.1

WebServices









8


2.2

WSRF









10


2.3

The WSRF Specification






12


2.4

Globus Toolkit







13



2.4.1

GT4 Architecture






14



2.4.2.

GT4 Components






16

3.

Semantic Web Service
s







16



3.1

Introduction








16


3.2

Motivation








17



3.2.1

Increasing Number of Web Services



18



3.2.2

Limitations of UDDI






19


3.3

Advantage of using Semantics in Service Discovery


20

4.

Semantic Grid Services







20



4.1

Concep
tual layers of Semantic Grid




21


4.2

Knowledge Layer







22


4.3

Ontology and its Importance





24


4.4

Research Issue in Semantic Grid





25

5.

Matchmaking of Semantic Web Services





26


5.1

Role of OWLS in Matchmaking





27


5.2

Limitations of
OWLS for Grid Services




28

6.

Issues of Matchmaking for Semantic Grid Services



29


6.1

Architecture of Semantic Grid Services




31


6.2

Ontology








32



6.2.1

Algernon







33





Development of Front End
tools for Semantic Grid Services




TechReport


4

IT@MIT



6.3

Matchmaking Algorithm






34

7.

Implementation








37


7.1
.

Developing Grid Service






37


7.2.

Creation of Ontology






39


7.3.

Matchmaking Module






41


7.4.

Grid Portal








42

8.

Experience with WSMX







43


8.1.

WSMO








43


8.2

WSMT








44


8.3.

WSMX








44


8.4.

FLORA
-
2








45

9.

Futu
re Work










10.

Conclusion








References




















Development of Front End
tools for Semantic Grid Services




TechReport


5

IT@MIT


List of Figures



Fig No

Title

Page No

1.1

A typical Virtual Organization

5

2.1

The layered Grid Architecture

7

2.2

Relationship between OGSA, WSRF and Web Services

10

2.2.1

A stateles
s Invocation

12

2.2.2

A stateful invocation

13

2.2.3

WS
-
Resource

14

2.4.1.1

GT4 Architecture

17

4.1.1

A Layered Architecture of Semantic Grid

24

5.1.1

Top Level Ontology of OWL
-
S

29

6.1.1

Architecture of semantic grid services

33

6.3.1

Various stage
s of Matchmaking algorithm

37

7.2.1

Grid Service Ontology

42

7.4.1

Program Model of Proposed Architecture

44

8.3.1

WSMX Architecture

47










Development of Front End
tools for Semantic Grid Services




TechReport


6

IT@MIT

Development of Front End Tools for Semantic Grid Services

Abstract



Grid computing has emerged as an importa
nt field, distinguished from conventional
distributed computing by its focus on large
-
scale resource sharing, innovative applications. The grid
problem is defined as flexible, secure, coordinated resource sharing among dynamic collections of
individuals, i
nstitutions and resources


what is referred as virtual organizations. Grid technologies
support the sharing and coordinated use of diverse resources in dynamic virtual organizations. In
such settings, a problem of unique authentication, authorization, res
ource sharing, resource
discovery and other challenges were encountered. These problems were effectively addressed by
Open Grid Service Architecture. It proposes Monitoring and Discovery Service for enabling
resource sharing and discovery that support conv
entional keyword matching for discovering the
resources. The project attempts to develop a methodology that describes the various grid resources
semantically and presents an algorithm that enables semantic search of those resources. With this
project, we p
ropose an architecture for semantic grid services that exploits the concept of semantic
web services to an extent. We also propose an algorithm that ranks the matching degree of service
descriptions on the basis of certain parameters similar to the matchma
king of web services based on
OWL
-
S. Different degree of matches is

achieved based on comparison of Inputs, Outputs and
Functionality types for requested and advertised services. Protege editor is used here to develop the
ontology and the algernon inferenc
e engine is effectively used to query the ontology knowledge base
and hence for matchmaking of services. Contrary to mechanisms that return only success or fail,
ranked results provide criteria for the selection of a service among a large set of results. W
ith such a
discovery mechanism additional grid services can be found that might have normally been
eliminated. Automatic conversion of WSDL file written for grid services into OWL file is also under
construction which will overcome the manual overhead of c
reating ontology. The front end
developed for the proposed architecture will thereby enable the service requester to submit his query
and performs the matchmaking of requested service against the advertised ones. It also provides
necessary interface to inv
oke the services too.





1.
Introduction



Development of Front End
tools for Semantic Grid Services




TechReport


7

IT@MIT

Until recently, application

developers could often assume a target

environment that was
homogeneous, reliable and centrally managed. Increasingly, however, computing is concerned with
collaboration, data sharing an
d other new modes of interaction that involve distributed resources.
The result is an increased
f
ocus on the interconnection of systems both within and across enterprises,
whether in the form of intelligent networks, switching devices, caching services, ap
pliance servers,
storage systems, or storage are network management systems. Moreover, the continuing
decentralization and distribution of software, hardware and human resources make it essential that
we need to achieve desired qualities of services on res
ources assembled dynamically from enterprise
systems, service provider systems and customer systems. We require new abstractions and concepts
that allow applications to access and share resources and services across distributed, wide area
networks. Develop
ment of grid technologies addresses precisely these problems and which are
seeing wides
pread and successful adoption fo
r scientific and technical computing.

Grid Technologies support the sharing and coordinated use of diverse resources in dynamic
virtual o
rganization that is the creation, from geographically and organizationally distributed
components, of virtual computing systems that are sufficiently integrated to deliver desired
QoS[2].In [1],
the essential properties of Grids
are defined
and
also
introd
uce
d

the

key requirements
for protocols and services, distinguishing among connectivity protocols concerned with
communication and authentication, resource protocols concerned with negotiating access to
individual resources and collective protocols and ser
vices concerned with the coordinated use of
multiple resources.














Development of Front End
tools for Semantic Grid Services




TechReport


8

IT@MIT


Fig 1.1: A typical Virtual Organization


Grid Concepts and technologies were first developed to enable resource sharing within far
-
flung scientific collaborations. Applications in
clude collaborative visualization of large scientific
data
analyzes (
pooling of computer power and storage), and coupling of scientific instruments with
remote computers and archives (increasing functionality as well as availability) [1]. We expect
similar

applications to become important in commercial settings, initially for scientific and technical
computing applications and then for commercial distributed computing applications, including
enterprise application integration and business to business partne
r collaboration over the Internet.
Grid concepts are critically important for commercial computing not primarily as a means of
enhancing capability, but rather as a solution to new challenges relating to the construction of
reliable, scalable and secure di
stributed systems.

A Grid instantiation is a grid system prototype using one or more of the grid middleware
technologies such as Globus, Condor or UNICORE. Most current grid instantiations are focused on
computational services for end users. They lack the

ability to provide domain problems solving
services and knowledge related services. Fundamental research on semantic web has allowed the
grid community to move from the current data centric view supporting the Grid, towards a semantic
Grid with a set of d
omain specific problem solving services and knowledge services.

The semantic Grid is a service oriented architecture in which entities provide services to one
another under various forms of contract. The semantic Grid is characterized by an open system, w
ith





Development of Front End
tools for Semantic Grid Services




TechReport


9

IT@MIT

a high degree of automation, which supports flexible collaboration and computation on a global
scale. In such an environment it is essential that information relating to the needs of the user and
their applications, and the resource providers and th
eir networking, storage and computational
resources all have easily discoverable interfaces and are defined, which means that can be used by
higher level services to effectively exploit the grid. Like the semantic web which is defined as “an
extension of t
he current web in which information is given well defined meaning, better enabling
computers and people to work in cooperation”, the semantic grid can be described as an “extension
of the current Grid in which information and services are given well define
d meaning, better
enabling computers and people to work in cooperation”.

The architecture proposed in this project
addresses

the problem of discovery of grid resources semantically by providing an algorithm for
match making of resources requested against t
he available ones.

T
he

rest of the document
organize
d as follows
:
-

Section 2 provides the necessary
background for semantic grid services and its evolution. The semantic web services and its
architecture
are

described briefly in section 3. It also descri
bes the motivation for semantic grid
services. Section 4 gives an introduction to the related software technology used for semantic web
services. The process of matchmaking of web services is described in section 5. The issues and
difficulties involved in
semantic match making of grid services and the proposed methodology is

discussed
elaborately

in section 6. In section 7, implementation of proposed architecture and the
matchmaking algorithm is described. A sample case study in emerging Web Service Executi
on
Framework is presented in section 8. The document aggregates the results and presents the inference
in the section 9.


2.
Background


The establishment, management, and exploitation of dynamic, cross
-
organizational VO
sharing relationships require new
technology and Architecture. Hence, the Grid Architecture
identifies fundamental system components, specifies the purpose and function of these components
and indicates how these components interact with one another. The figure 2.1 shows the grid
architect
ure defined in [2].







Development of Front End
tools for Semantic Grid Services




TechReport


10

IT@MIT










Fig 2.1: The layered Grid Architecture

Fabric Layer


The Grid Fabric layer provides the resources to which shared access is mediated by Grid
protocols: for example, computational
resources, storage systems, catalogs, netwo
rk resources and
sensors. A “resource” may be a logical entity, such as a distributed file system, computer cluster, or
dis
tributed computer pool. Fabric components implement the local, resource
-
specific operations that
occur on

specific resources as a res
ult of sharing operations at higher levels. There is thus a tight
interdependence between the functions implemented at the fabric level, on the one hand, and the
sharing operations supported, on the other.


Connectivity Layer


The connectivity layer define
s core communication and authentication protocols required for
Grid
-
specific network transactions. Communication protocols enable the exchange of data between
Fabric layer resources. Authentication protocols build on communication services to provide
crypt
ographically secure mechanisms for verifying the identity of users and resources.


Resource Layer



The Resource Layer builds on connectivity layer protocols to define protocols including APIs
and SDKs for the secure negotiation, initiation, monitoring, co
ntrol, accounting and payment of
sharing operations on individual resources. Resource layer implementations of these
protocols

calls




Application

Resource

Connectivity

Collective

Grid Protocol Architecture

Fabric



Development of Front End
tools for Semantic Grid Services




TechReport


11

IT@MIT

f
abric layer functions to access and control local resources. Resource layer protocols are concerned
entirely with indi
vidual resources and hence ignore issues of global state and atomic actions across
distributed collections; such issues.


Collective Layer


The Collective layer
contains protocols

including APIs and SDKs

and services

that are not
associated with any one sp
ecific resource but rather are global in nature and capture interactions
across collections of resources. Because Collective components build on the narrow Reso
u
rce and
Connectivity layer “neck” in the protocol hourglass, they can implement a wide variety
of sharing
behaviors without placing new requirements on the resources being shared.


App
l
ications


The final layer in the architecture comprises the user applications that operate within a VO
environment. Applications are
constructed

in terms of, and by c
alling upon, services defined at any
layer.



Hence a Typical Grid
application

will usually consist of several different components. For
example, a typical grid application could have:



VO Management Service: To manage what nodes and users are part of each

Virtual
Organization



Resource Discovery and Management Service: So applications on the grid can discover
resources that suit their needs and then manage them



Job Management Service: So users can submit tasks in the form of jobs to the grid.



And a whole ot
her bunch of services like security, data management etc.,

Furthermore, all these services are interacting constantly. For example, the job
management
service might consult the resource discovery service to find computational resources that match the
job’s

requirements. With so many services and so may interactions between them, there exists the
potential for chaos. What if every vendor out

there decided to implement a Job Management Service

in a completely different way, exposing not only different functi
onality but also different interfaces?





Development of Front End
tools for Semantic Grid Services




TechReport


12

IT@MIT

It would be very difficult to get all the different pieces of software to work together. The
solution is Standardization: define a common interface for each type of service.

The Open Grid
Services Architecture (OGS
A), developed by The Global Grid Forum, aims to define a common,
standard, and open architecture for grid
-
based applications. The goal of OGSA is to standardize
practically all the services one commonly finds in a grid application (job management services,

resource management services, security services etc.,) by specifying a set of standard interfaces for
these
services
. While creating this new architecture, the developer realized that they needed to
choose some sort of distributed middleware on which to b
ase the architecture. In other words, if
OGSA, for example, defines that the JobSubmissionInterface has a submitJob method, there has to
be a common and standard way to invoke that method if we want the architecture to be adopted as an
industry
-
wide standa
rd. This base for the architecture could, in theory, be
any distributed
middleware, Web services were chosen as the underlying technology as it
has its own reasons.
However, although the Web Services Architecture was certainly the best option, it still did
n’t meet
one of OGSA’s most important requirements; the underlying middleware had to be stateful.
Unfortunately, although Web Services can in
theory
is

either stateless or stateful, they are usually
stateless and there is no standard
way of making them sta
teful. To overcome this limitation, OASIS

developed a specification called Web Services Resource Framework (WSRF) that specifies how we
can

make our Web Services stateful, along with adding a lot of other features. It is important to note
that WSRF is a jo
int effort by the Grid and Web Services communities, so it fits pretty nicely inside
the whole Web Services Architecture. Hence, it is possible to derive the
relationship

between OGSA
and WSRF. WSRF provides the stateful services that OGSA needs. In otherw
ords
,

while OGSA is
the architecture, WSRF is the infrastructure on which that architecture is built on.

Before taking a
closer look at WSRF, we need to have some background knowledge in Globus Toolkit 4.0 and Web
Services.











Development of Front End
tools for Semantic Grid Services




TechReport


13

IT@MIT







Fig 2.2
: Relationship between OGSA, WSRF and Web Services


2.
1

Web Services


The term
Web services
describes an important emerging distributed computing paradigm that
differs from other approaches such as DCE, CORBA, and Java RMI in its focus

on simple, Internet
-
based standards (e.g., eXtensible M
arkup Language: XML [
4,
5
]) to address heterogeneous
distributed computing. Web services define a technique for describing software components to be
accessed, methods for accessing these components, a
nd discovery methods that enable the
identification of relevant service providers

[3]
. Web services are programming language
-
,
programming model
-
, and system software
-
neutral.

Web services standards are being defined within the W3C and other standards bod
ies and
form the basis for major new industry initiatives such as Microsoft (.NET), IBM (Dynamic e
-
Business), and Sun (Sun ONE).
However the three main concerns are the
standards:

SOAP, WSDL,
and WS
-
Inspection.



The
Simple Object Access Protocol
(SOAP) [6
]
provides a means of messaging between a
service provider and a service requestor. SOAP is a simple enveloping mechanism for XML
payloads that defines a remote procedure call (RPC) convention and a messaging convention.
SOAP is independent of th
e underlying

transport protocol too.




Extends

OGSA

WSRF

Stateful

Web Services

Web Services

Requires

Specifies



Development of Front End
tools for Semantic Grid Services




TechReport


14

IT@MIT




HTTP, FTP, Java Messaging Service (JMS), and the like. We emphasize that Web services can
describe multiple access mechanisms to the underlying software component. SOAP is just one
means of formatting a Web service invocation.



The
Web Services Description Language
(WSDL) [7
] is an XML document for describing Web
services as a set of
endpoints
operating on messages containing either document
-
oriented
(messaging) or RPC payloads. Service interfaces are defined abstractly in terms

of message
structures and sequences of simple message exchanges (or operations, in WSDL terminology) and
then bound to a concrete network protocol and data
-
encoding format to define an endpoint. Related
concrete endpoints are bundled to define abstract en
dpoints (services). WSDL is extensible to allow
description of endpoints and the concrete representation of their messages for a variety of different
message formats and network protocols. Several standardized binding conventions are defined
describing how

to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.



WS
-
Inspection
[8
] comprises a simple XML language and related conventions for locating
service descriptions published by a service provider. A WS
-
Inspection language (WSIL) document
can c
ontain a collection of service descriptions and links to other sources of service descriptions. A
service description is usually a URL to a WSDL document; occasionally, a service description can
be a reference to an entry within a Universal Description, Di
scovery, and Integration (UDDI) [
9
]
registry. A link is usually a URL to another WS
-
Inspection document; occasionally, a link is a
reference to a UDDI entry. With WS
-
Inspection, a service provider creates a WSIL document and
makes the document network acce
ssible. Service requestors use standard Web
-
based access
mechanisms (e.g., HTTP GET) to retrieve this document and discover what services the service
provider advertises. WSIL documents can also be organized in different forms of index.

The Web services f
ramework has two advantages for
Grid architecture
. First,
the

need to
support the dynamic discovery and composition of services in heterogeneous environments
necessitates mechanisms for registering and discovering interface definitions and endpoint
impleme
ntation descriptions and for dynamically generating proxies based on (potentially multiple)
bindings for specific interfaces. WSDL supports this requirement by providing a standard
mechanism for defining interface definitions separately from their embodime
nt within a particular
b
inding (transport protocol and data encoding format). Second, the widespread adoption of
w
eb


services mechanisms means that a framework based on Web services can exploit numerous tools and


Development of Front End
tools for Semantic Grid Services




TechReport


15

IT@MIT

extant services, such as WSDL processors
that can generate language bindings for a variety of
languages (e.g., Web Services Invocation Framework:
WSIF)
, workflow systems that sit on top of
WSDL, and hosting environments for Web services (e.g., Microsoft .NET and Apache Axis).
In [4],

it is
emphas
ize
d

that the use of Web services does not imply the use of SOAP for all
communications. If needed, alternative transports can be used, for example to achieve higher
performance or to run over specialized network protocols.


2.
2

WSRF

Plain Web services ar
e usually
stateless
(even though, in theory, there is nothing in the Web
Services

Architecture that says they can't be stateful). This means that the Web service can't
"remember" information,

or
keep state
, from one invocation to another. For example, imag
ine we
want to program a very

simple Web service which simply acts as an integer accumulator. This
accumulator is initialized to zero,

and we want to be able to add (accumulate) values in it. Suppose
we have an
add
operation which receives the value to add

and returns the current value of the
accumul
ator.


Fig: 2.
2
.1: A stateless Invocation


As shown in the
figure

2.2.1
,

the

first invocation of this operation might seem to work (we
request that 5 be added, and we receive

5 in re
turn). However, since a Web service is stateless, the
following invocations have no idea of

what was done in the previous invocations. So, in the second








Client




Web
Service

Reques
t Add 6

Request Add 8

Request Add 12

Re
sponse

6

Re
sponse

8

Re
sponse

12



Development of Front End
tools for Semantic Grid Services




TechReport


16

IT@MIT

call to
add
we get back 6, instead of 11

(which would be the expected value if the Web service was
able to keep state).


The fact that Web services don

t keep state information is not necessarily a bad thing. There
are plenty

of applications which have no need whatsoever for statefulness. For example, the Weather
Web service

is a real, working Web servi
ce which has no need to know what

happened in the
previous invocations. However, Grid applications
do
generally require statefuln
ess. So, we would
ideally like the

Web service to

somehow keep state information.




Fig 2.
2
.2:

A stateful invocation


Giving Web services the ability to keep state information while still keeping them stateless
seems like a

complex problem. Fortunately, it's a problem with a very simple solution: simply keep
the Web service

and the state information completely separate.


Instead of putting the state
in
the Web service (thus making it stateful, which is generally
regarded as a

bad thing)
it is kept in a
separate entity called a
resource
, which will store all the state
informat
ion.

Each resource will have a unique
key
, so whenever we want a
stateful interaction
with a
Web service

we simply have to instruct the Web service to use a particular resource.

This pairing of
a Web service with a resource is called a WS
-
Resource

(Figure
2.
2
.3)
. The address of a particular
WS
-
Resource is called an endpoint reference.

The difficulty encountered in this approach is that how
to specify what resource must be used. A URI might be enough to address the Web service, but
something more tha
n

that i
s needed to address the resource. A new specification called WS
-
addressing is used to overcome this difficulty which provides a more versatile way of addressing
Web Services
.







Client




Web
Service

Request Add 6

Request Add 8

Request Add 12

Re
sponse

6

Re
sponse

14

Re
sponse

26

6

14

State

26



Development of Front End
tools for Semantic Grid Services




TechReport


17

IT@MIT














Fig 2.
2
.3: WS
-
Resource

2.3

The WSRF specification


The WSRF is a
collection of five different specifications and they all relate to the
management of WS
-
Resources.

WS
-
ResourceProperties


A resource is composed of zero or more
resource properties
. For example,
as shown
in the
figure
2.
2
.3
each resource has three resource

properties: Filename, Size, and Descriptors. WS
-
ResourceProperties

specifies how resource properties are defined and accessed.
T
he resource
properties are defined in the Web service's WSDL interface description.

WS
-
ResourceLifetime


Resources have non
-
tri
vial lifecycles. In other words, they're not a static entity that is created
when our

server starts and destroyed when our server stops. Resources can be created and destroyed
at any time.

The WS
-
ResourceLifetime supplies some basic mechanisms to manage th
e lifecycle of
our resources.

WS
-
ServiceGroup


We will often be interested in managing
groups of Web Services
or
groups of WS
-
Resources
,
and performing

operations such as 'add new service to group', 'remove this service from group', and
(more importantly)

'find a service in the group that meets condition FOOBAR'. The WS
-



Web

Service

Filename:

“mynotes.doc”

Size:
250

Descriptors
: {“notes”,”Globus”)

Resource 0x09EB23FA

Filename:

“tutorial.zip”

Size:
750

Descriptors
: {”Globus”,”Tutorail”)

Resource 0xF56433FA

Filename:

“pacma
n.exe”

Size:
150

Descriptors
: {“game”)

Resource 0x106E43FA

RESOURCES

Web Service

+

Resource

=

Ws
-
Resource



Development of Front End
tools for Semantic Grid Services




TechReport


18

IT@MIT

ServiceGroup specifies

how exactly we should go about grouping services or WS
-
Resources
together. Although the functionality

provided by this specification is very basic, it is nonetheless

the
base of more powerful discovery services

(such as GT4's IndexService) which allow us to group
different services together and access them

through a single point of entry (the service group).

WS
-
BaseFaults


Finally, this specification aims to provide a

standard way of reporting faults when something
goes

wrong during a WS
-
Service invocation

Related specifications

WS
-
Notification


WS
-
Notification is another collection of specifications that, although not a part of WSRF, is
closely related

to it. This spe
cification allows a Web service to be configured as a
notification
producer
, and certain

clients to be
notification consumers
(or subscribers). This means that if a
change occurs in the Web

service (or, more specifically, in one of the WS
-
Resources), that
change is
notified
to all the subscribers

(not
all
changes are notified, only the ones the Web services
programmer wants to).

WS
-
Addressing


As mentioned before, the WS
-
Addressing specification provides us a mechanism to address
Web services

which is much
more versatile than plain URIs. In particular, we can use WS
-
Addressing to address

a Web service + resource pair (a WS
-
Resource).


2.4
Globus Toolkit



The Globus Toolkit
a (
GT
)

[
1, 2]

is a community
-
based, open
-
architecture, open
-
source set
of services an
d software libraries that support Grids and Grid applications. The toolkit addresses
issues of security, information discovery, resource management, data management, communication,
fault detection, and portability. Globus Toolkit mechanisms are in use at h
undreds of sites and by
dozens of major Grid projects worldwide
.

The toolkit, first and foremost, includes quite a

few high
-
level services that we can use to build Grid applications. These services, in fact, meet most of

the
abstract requirements set forth

in OGSA. In other words, the Globus Toolkit includes a resource

monitoring and discovery service, a job submission infrastructure, a security infrastructure, and data

management services (to name a few!). Since the working groups at GGF are still working
on
defining

standard interfaces for these types of services,
it is not possible to
say (at this point) that




Development of Front End
tools for Semantic Grid Services




TechReport


19

IT@MIT

GT4

(GT Version 4.0)

is an implementation

of OGSA (although GT4 does implement some security
specifications defined by GGF). However, it is

a real
ization of the OGSA requirements and a sort of
de facto standard for the Grid community while

GGF works on standardizing all the different
services.


Most of these services are implemented on top of WSRF (the toolkit also includes some
services that are

no
t implemented on top of WSRF and are called the
non
-
WS components
). The
Globus Toolkit 4, in

fact, includes a complete implementation of the WSRF specification. This part
of the toolkit (the WSRF

implementation) is a very important part of the toolkit sinc
e nearly
everything else is built on top of it.



2.4.1
GT4
Architecture


The Globus Toolkit 4 is composed of several software components. As shown in the figure

2.4.1.1
,

these components are divided into five categories: Security, Data Management, Executi
on
Management,

Information Services, and the Common Runtime. Notice how, despite the fact that
GT4 focuses on Web

services, the toolkit also includes components which are
not
implemented on
top of Web services. For

example, the GridFTP component uses a non
-
WS protocol which started as
an ad hoc Globus protocol,

but later became a GGF specification.


















Development of Front End
tools for Semantic Grid Services




TechReport


20

IT@MIT



Fig 2.4.1.1: GT4 Architecture


2.4.2 GT4 Components

Common Runtime


The Common Runtime components provide a set of fundamental libraries and to
ols which
are needed to

build both WS and non
-
WS services.

Security


Using the Security components, based on the Grid Security Infrastructure (GSI), we can
make sure that

our communications are secure.

Data management


These components will allow us to man
age large sets of data in our virtual organization.






Development of Front End
tools for Semantic Grid Services




TechReport


21

IT@MIT

Information services


The Information Services, more commonly referred to as the Monitoring and Discovery
Services

(MDS), includes a set of components to discover and monitor resources in a virtual
org
anization. Note

that GT4 also includes a non
-
WS version of MDS (MDS2) for legacy purposes.
This component is deprecated

and will surely disappear in future releases of the toolkit.


Execution management


Execution Management components deal with the initia
tion, monitoring, management,
scheduling and

coordination of executable programs, usually called
jobs
, in a Grid.


3.
Semantic Web Service

3.1 Introduction


Formulated by the creator of the World Wide Web Tim Berners
-
Lee, the Semantic Web is
about “bringin
g the web to its full potential” [
10
]. The web currently contains around 3 billion static
documents, which are accessed by over 500 millions users. While these numbers are increasing at a
staggering rate, the task of dealing with the information is getting

harder [
11
]. The Semantic Web is

an effort to develop technologies so that the value of information can scale with the increase of
information, thus brining the web to its full potential.


The Semantic Web’s approach of bringing this about is to make in
formation
“understandable” by computers. Information must therefore be described in such a way that
computers can interpret it and derive its meaning. This will enable computers to work more
intelligently with the information; for example assisting humans
in classifying, filtering and
searching information.


Computer understandable information is information annotated with semantics. Annotations
can therefore be though of as metadata that describes the meaning


the semantics


of the
information. The anno
tations themselves have to be defined so that
c
omputers

can interpret and
reason with them. A collection of annotations where their meaning is described is called an ontology

which will be discussed in detail in the next section.


For ontologies to represe
nt knowledge of a domain, they need to be expressed with language
that can convey the necessary complexity of the domain. Description Logic (DL) is
knowledge






Development of Front End
tools for Semantic Grid Services




TechReport


22

IT@MIT

formalism that describes the abstract world with concepts and relations. These basic constructs

can
be used to build up advanced hierarchies and graphs with restrictions on various levels.


Knowledge has to be represented so that logic can be applied. In special it is important to be
able to compare and derive similarities between annotations. DL h
as advanced capabilities for this.
One powerful feature in DL is subsumption, which checks whether or not a concept contains another
concept. The advantages of annotations are closely related to what can be derived from the
representation. Using a language

with advanced capabilities for reasoning is therefore of great
importance.


Applications interpreting the semantics of a document need to have access to the ontologies
that define the semantics. When a document is annotated with semantics it includes inf
ormation
about where the annotations are described. The ontologies describing the annotations must therefore
be available and readable so that applications can derive their meaning. For example in context of
the Semantic Web


which is a distributed system



the ontologies have to be network accessible.
They are therefore defined with URIs which
is

unique network identifications.


For ontologies to be used in distributed systems and across systems there has to be
agreements on how knowledge is represented
and reasoned with. These standards should be general

and


at the same time


advanced enough to capture the wide needs of different interest groups.
They should also specify syntax and formats for representation. Recently developed open standards
for kno
wledge representation are RDF and OWL [
12
] [
1
3].


3.2 Motivation


The idea of Semantic Web Services is here introduced gradually by first looking into how
current Web Services are described, and then how these services can be extended with semantics. A
tr
anslation service is used through the text to make the explanation clear. The capabilities of Web
Services are described with Web Service Definition Language (WSDL) [7] by defining operations
and parameters that the service supports. This is done by naming

operations and parameters, and
then associating the parameters with abstract types which can be though of as data types.


The problem with this service description is that agents can not derive what the service does.
An agent interpreting the parameters
of the service can not derive their meaning by simply looking at
them. For agents they are only parameters names


named variables that are used to contain





Development of Front End
tools for Semantic Grid Services




TechReport


23

IT@MIT

information. Agents can not derive the content of these parameters, because they can not read the

parameter names like humans can. What agents can infer from a service description is that
the

input
and o
utput parameters
and
their data types.


Agents can only interpret information that confirms to a syntactical structure. They are
programmed to derive
the meaning from formats like WSDL, which is an agreement on how service
descriptions are interpreted. The service description can thus be seen on as a structured syntactical
description. A human developer who wants to use a service in a client program nee
ds to read the
syntax of service description, interpret it, and then write the client program confirming to the syntax
of service. Agents can not read text like humans


they can understand the structure of the service
descriptions but not the content [
14
]
. Semantic Web Services are described so that agents can
interpret their capabilities. Autonomous agents should be able to look into the service description to
determine if the service provides the desired capabilities and if the agent is able to use the s
ervice.

The service description must thus be extended with computer interpretable information called
semantics. The parameters or the service names must be described in such a way that agents can find
out what they mean. This is achieved by defining vocab
ularies


organized in ontologies


that are
used to annotate service capabilities. For agents to interpret service descriptions they will have to use

these ontologies


which are shared conceptualizations of domains
[11
].
Research is currently being
done

on how the state of services can be represented

as preconditions and effects [1
5]. Preconditions
would represent what is necessary for using the service, and effects would represent the
consequences of using the service. Preconditions and effects are ther
efore
specifying the state
t
ransformation of the service [16
].

3.2.1
Increasing Number of Web Services


There are important trends in distributed systems that affect the importance of service
discovery. The most noticeable trend is that the number of ser
vices increases rapidly. This is due to
the popularity of Web Services and the fact that the service
-
oriented paradigm encourages lousily
coupled independent services.


A result of the latter is that services are looked up on demand when they are needed a
nd the
effect of this might be that services are looked up more often. Service discovery is thus becoming






Development of Front End
tools for Semantic Grid Services




TechReport


24

IT@MIT

more and more important in distributed systems.
Service Discovery in Semantic Web Services is
described in the next section.

3.2.2
Limitations of
UDDI


The most prominent technology for web service discovery is the Universal Description
Discovery and Integration (UDDI). This technology is expected to be the internet standard for
service discovery due t
o its strong industry backing [
1
7
].

UDDI is de
signed to be used by humans. This becomes clear from reading how services are
typically found and invocated in the technical white paper [9]. It involves manual searching or
browsing based on business descriptions, manual selection of service descriptions,

and then finally
construction of the client program based on the service description. Due to the fact that the intended
users of UDDI are humans, it is natural that automated usage is not straight forward. It is however
interesting to investigate what lim
itations it has to enable automated usage.


UDDI provides functionalities


an API


to search for services using keywords. These
keywords are matched with text used in the descriptions of the services. It is very hard for agents to
work with keywords bec
ause it involves some degree of language understanding. Keyword based
search is thus not enabling autonomous discovery.


UDDI provides also functionalities to search for services based on the web service
description given in the WSDL format. The compariso
n between the requested service and the
searched service is then done on a syntactical level. This has some limitation; first, the syntactical
match does not make sure that the service provides the requested service; second, since the agent can
not look in
to the textual description provided for humans, it can not distinguish between two services
providing the same syntactical description. This way of searching for services is therefore also not
desirable for automated usage.


UDDI does not define a relatio
nship between service descriptions in their so
-
called TModels.
Different services with the same capabilities can thus be categorized in different business categories.
Finding the service that best fit the agent’s needs is thus difficult.


The TModel


whi
ch provides the main structure for the service description


is however
general enough to contain semantic information. UDDI is simply not intended for
automated usage,
and lacks therefore what is necessary for agent interaction. What is needed is a guidel
ine for how to





Development of Front End
tools for Semantic Grid Services




TechReport


25

IT@MIT

semantically annotate services and an API that supports search based on semantics. A lot of research
activities are currently going on in how to extend UDDI w
ith semantic functionalities [18] [16] [19
].

3.3
Advantages of using Semantics
in Service Discovery


There are several advantages of using semantics in service discovery. The accuracy of the
service discovery will improve with semantics. Semantics provide the expressiveness needed to
make detailed descriptions of advertised service
capabilities and capability requests. Matchmaking
using semantics is more accurate than a keyword
-
based search, because the direct similarities are
found using inference logic, while the keyword
-
based searches can be vague and inaccurate.


Service discove
ry based on semantics will enable a more dynamic coupling between clients
and services. The exact services do not need be known in advance and the client can more easily
change services that are used. This is an improvement towards the service oriented par
adigm, where
services are loosely coupled.


Dynamic coupling of services based on semantics will furthermore enable new technologies
and applications to emerge. More resilient and flexible systems can for example be made by smart
service mediators that us
e semantics to provide functionality transparency. This is useful in dynamic
service environments or for systems that need high operability. Functionality transparency means
that a client using a set of services through a service mediator does not know whi
ch or where these
services are. The required functionality is just provides to the client. Failing or disappearing services
can therefore be replaced unknowingly by the client.


Semantics can also improve the administration of service registers provided f
or manual
browsing. Services can be automatically categorized and classified based on their semantics, making
administration easier and registries more up to date.


4. Semantic Grid Service
s



The computing infrastructure for e
-
Science is commonly referre
d to as the Grid,
whose terminology is chosen to connote the idea of a “Power Grid”: namely that e
-
Scientists can
plug into the e
-
Science computing infrastructure like plugging into a power grid. Though the aspect
of the Grid is certainly an important enab
ling technology for future e
-
Science, it is only a part of
much larger picture that also includes information handling and support for knowledge processing





Development of Front End
tools for Semantic Grid Services




TechReport


26

IT@MIT

within the e
-
sc
ientific process. This broader
view of the e
-
Science infrastructure is adopted for

Semantic Grid
; the view is that as the Grid is to the Web, so the Semantic Grid is to Semantic Web

[22]
. Thus the Semantic Grid characterized as an open system in which users, software components
and computational resources come and go on a continual basi
s. Hence there should be a high degree
of automation that supports flexible collaborations and computation on a global scale, Moreover, this
environment should be personalized to the individual participants and should offer seamless
interactions with both
software components and other relevant users.


4.1 Conceptual layer
of
Semantic Grid


Given the above view of the scope of e
-
Science, it has become popular to characterize the
computing infrastructure as consi
sting of three conceptual layers.




Data/computa
tion

This layer deals with the way that computational resources are allocated, scheduled
and executed and the way in which data is shipped between the various processing resources.
It is characteri
z
ed as being able to deal with large volumes of data, prov
iding fast networks
and presenting diverse resources as a single metacomputer. The data/computation layer
builds on the physical ‘grid fabric’, i.e. the underlying network and computer infrastructure,
which may also interconnect scientific equipment. Here
data is understood as uninterpreted
bits and bytes.



Information

This layer deals with the way that information is represented, stored, accessed, shared
and maintained. Here information is understood as data equipped with mean
ing. For
example, the characte
riz
ation of an integer as representing the temperature of a reaction
process, the recognition that a string is the name of an individual.



K
nowledge

This layer is concerned with the way that knowledge is acquired, used, retrieved,
published and maintained

to assist e
-
Scientists to achieve their particular goals and
objectives. Here knowledge is understood as information applied to achieve a goal, solve a
problem or enact a decision. In the Business Intelligence literature knowledge is often





Development of Front End
tools for Semantic Grid Services




TechReport


27

IT@MIT

defined as a
ctionable information. For example, the recognition by a plant operator that in the
current context a reaction temperature demands shutdown of the process.



Fig 4.1.1: A Layered Architecture of Semantic Grid



Although this view is widely accepted, to d
ate most research and development work in this
area has concentrated on the data/computation layer and on the information layer. While there are
still many open problems concerned with managing massively distributed computations in an
efficient manner and
in accessing and sharing information from heterogeneous sources, the full
potential of grid computing can only be reali
z
ed by fully exploiting the functionality and capabilities
provided by knowledge layer services. This is because it is at this layer that

the reasoning necessary
for seamlessly automating a significant range of the actions and interactions takes place. Thus this is
the area we focus on most in
this research project
.

4.2 Knowledge Layer


The aim of the knowledge layer is to act as an infras
tructure to support the management and
application of scientific knowledge to achieve particular types of goal and objective. In order to
achieve this, it builds upon the services offered by the data/com
putation and information layers.

The
first thing to r
eiterate with respect to this layer is the problem of the sheer scale of content we are
dealing with. We recogni
z
e that the amount of data that the data grid is managing is likely to be
huge.





Development of Front End
tools for Semantic Grid Services




TechReport


28

IT@MIT


Once information is delivered that is destined for a particul
ar purpose, we are in the realm of
the knowledge grid. Thus at this level we are fundamentally concerned with abstracted and
annotated content and with the management of scientific knowledge.

The effort of acquiring
knowl
edge was one bottleneck recogniz
ed
early
b
ut so too ar
e; modelling, retrieval,
publication and
maintenance.


Knowledge acquisition

sets the challenge of getting hold of the information that is around,
and turning it into knowledge by making it
usable
. This might involve, for

instance, maki
ng tacit
knowledge explicit, identifying gaps in the knowledge already held, acquiring and integrating
knowledge from multiple sources (e.g. different experts, or distributed sources on the Web), or
acquiring knowledge from unstructured media (e.g. natural

language or diagrams).


However, the process of explicit knowledge acquisition from human experts remains a costly
and resource intensive exercise. Hence, the increasing interest in methods that can (semi
-
)
automatically elicit and acquire knowledge that
is often implicit or else distributed on the web. A
variety of information extraction tools and methods are being applied to the huge body of textual
documents that are now available
.


Knowledge modelling
bridges the gap between the acquisition of knowledg
e and its use.
Knowledge models must be able
both
to act as straightforward placeholders for the acquired
knowledge,
and
to represent the knowledge so that it can be used for problem
-
solving. Knowledge
representation technologies have a long history in Art
ificial Intelligence. There a numerous
languages and approaches that cater for

different knowledge types; structural forms of knowledge,
procedurally oriented representations, rule based characteri
z
ations and methods to model
uncertainty, and probabilistic

representations
.


Once knowledge has been acquired and modelled, it needs to be stored or hosted somewhere
so that it can be retrieved efficiently. In this context, there are two related problems to do with
knowledge retrieval
. First, there is the issue o
f finding knowledge again once it has been stored. And
second, there is the problem of retrieving the subset of content that is relevant to a particular
problem. This will set particular problems for a knowledge retrieval system where content alters
rapidl
y and regularly.







Development of Front End
tools for Semantic Grid Services




TechReport


29

IT@MIT


Technologies for information retrieval exist
in many forms.
They include methods that
attempt to encode structural representations about the content to be retrieved such as explicit
attributes and values. Varieties of matching algori
thm can be applied to retrieve cases that are similar
to an example or else a partial set of attributes presented to the system.


Having acquired knowledge, modelled and stored it, the issue then arises as to how to get that
knowledge to the people who su
bsequently need it. The challenge of
knowledge publishing

or
disseminating can be described as getting the right knowledge, in the right form, to the right person
or system, at the right time. Different users and systems will require knowle
dge to be presen
ted and
visualiz
ed in different ways. The quality of such presentation is not merely a matter of preference. It
may radically affect the utility of the knowledge. Getting presentation right involves understanding
the different perspectives of people with d
ifferent agendas and systems with different requirements.
An understanding of knowledge content will help to
ensure that important related pieces of
knowledge get published at the appropriate time.

Finally, having acquired and modelled the knowledge, and
having managed to retrieve and
disseminate it appropriately, the last challenge is to keep the knowledge content current


knowledge
maintenance
. This may involve the regular updating of content as knowledge changes. Some
content has considerable longevity
, while other knowledge dates quickly. If knowledge is to remain
useful over a period of time, it is essential to know which parts of the knowledge base must be
updated or else discarded and when. Other problems involved in maintenance include verifying an
d
validating the content, and certifying its safety.


4.3 Ontology and its Importance


The concept of an
ontology
is necessary to capture the expressive power that is needed for
modelling and reasoning with knowledge. Generally speaking, an ontology deter
mines the extension
of terms and the relationships between them. However, in the context of knowledge and web
engineering, an ontology is simply a published, more or less agreed, conceptualization of an area of
content. The ontology may describe objects,
p
rocesses, resources, capabilities or whatever.
O
ntology
can be viewed as the explicit statement of a logical theory. “Ontologies describe domain theories
with the intent of the explicit representation of the semantics of the domain data”
.

Recently a number

of languages have appeared that attempt to take concepts from the knowledge representation





Development of Front End
tools for Semantic Grid Services




TechReport


30

IT@MIT

languages of AI and extend the expressive capability of those of the Web (e.g., RDF and RDF
Schema). Examples include DAML [20], and OIL [21]. Most recently ther
e has been an attempt to
integrate the best features of these languages in a hybrid called DAML+OIL. As well as
incorporating constructs to help model ontologies DAML+OIL is being equipped with a logical
language to express rule
-
based generalizations.


The

benefits of
ontology

include improving communication between systems whether
machines, users or organizations. They aim to establish an agreed and perhaps normative model.
They
endeavor

to be consistent and unambiguous, and to integrate a range of perspec
tives. Another
benefit that arises from adopting an ontology is inter
-
operability and this is why they figure large in
the vision for the Semantic Web [22]. An ontology can act as an
Interlingua
, it can promote reuse of
content, ensure a clear specificatio
n of what content or a service is about, and increase the chance
that content and services can be successfully integrated.


4.4 Research Issues in Semantic Grid


The following is some of the key research issues that remain for exploiting knowledge
services

in the Semantic Grid. In many cases there are already small
-
scale exemplars for most of
these services; consequently many of the issues relate to the problems of scale and distribution



We need tools and infrastructure to automate the creation of ontology

of knowledge present
in the Grid environment.



We need to develop front end tool that enables the Matchmaking of Grid services.

Matchmaking of semantic web services can be done in OWL
-
S but it pose problems when comes
to Grid.



Methods are required to build

large
-
scale ontologies and tools deployed to provide a range of
ontology services.



Knowledge capture tools are needed that can be added as plugins to a wide variety of
applications and which draw down on ontology services. This will

include a clearer
und
erstanding of profiling individual and group e
-
Science perspectives and interests.



Dynamic linking, visualization, navigation and browsing of content from many perspectives
over large content sets





Development of Front End
tools for Semantic Grid Services




TechReport


31

IT@MIT



Construction of repositories of solution cases with suf
ficient annotation to promote reuse as
opposed to discovering the solution again because the cost of finding the reusable solution is too
high.



Provision of knowledge discovery services with standard input/output APIs to ontologically
mapped data



Underst
anding how to embed knowledge services in ubiquitous and pervasive devices


The res
t of the document focuses on
the research issue
o
f developing a front end tools for
matchmaking of semantic Grid Services.



5.
Matchmaking of
Semantic
Web Services


The Se
mantic Web working group of the W3C develops technologies and standards

for the
semantic description of the Web. The goal of these efforts is to make the Web

understandable by
machines and to increase the level of autonomous interoperation between

c
omputer

systems
. The
most relevant are the Resource Description

Framework

(RDF), and the Web Ontology Language
(OWL) .Based on RDF and RDF Schema, OWL


the successor of the DARPA Agent Markup

Language in conjunction with the Ontology Inference Layer, in short D
AML+OIL


increases the
level of expressiveness with a richer vocabulary but retaining the decidability.

These languages are
primarily used to describe content. The next logical step is

to describe the semantics of services in
order to improve their platfo
rm
-

and
organization
-

independent interoperability over the Internet.
Referring to the Semantic Web,

the research field addressing this objective is named
Semantic Web
services
. Its

vision is the application of semantic description for Web services in orde
r to provide

relevant criteria for their automated selection. Based on the predecessor of OWL


DAML+OIL


an
upper ontology for the description of Web services named DAMLServices

(DAML
-
S) had been
introduced
. Using DAML
-
S, the functionality, execution

str
ucture and the binding to existing
interface information can be described.

Recently DAML
-
S has been updated and renamed to OWL
-
S, adapting the evolution of

DAML+OIL to OWL.

Using OWL
-
S for the description of Web
services can increase the ability of compute
r

systems to find eligible services autonomously. This is
important in open environments

where provided services can appear and disappear dynamically.
Basically a

service provider describes his advertised services in an OWL
-
S compliant ontology

and a





Development of Front End
tools for Semantic Grid Services




TechReport


32

IT@MIT

se
rvice requester queries for services with an OWL
-
S ontology expressing his

requirements. In this
scenario, matching service descriptions of advertisements with requirements

has the purpose to
select a suitable service among a set of available ones.

Conside
ring known matching approaches that
return
mismatch

or match, this selection

process has
some
potential benefits.


5.1 Role of OWL
-
S in Matchmaking


In line with the Semantic Web, the OWL
-
S language itself is defi
ned by a semantic language.

OWL
-
S is thus a
n ontology that provides the necessary concepts and relations to describe the general
capabilities of web services. This includes representation of the information transformation with
I
nputs
and O
utputs, and state transformation like
P
reconditions and
E
ffe
cts

normally referred as
IOPE together
.



Fig: 5.1.1: Top Level Ontology of OWL
-
S




OWL
-
S provides moreover a high level description of web services as shown in Figure
5.1.1
. This top level ontology describes how a Resource is related to a Service, and s
ubsequently
how the Service is related to the Profile, the Service Model and the service Grounding. In short, the
Profile contains information about what the service does, the service Model describes how the
service works, and the grounding describes how t
he service is accessed. Together, these three
concepts are designed to give a total picture of the capabilities of a service.







Development of Front End
tools for Semantic Grid Services




TechReport


33

IT@MIT

Matchmaking, in this context refers to capability matching which
means to compare the
requested service description with the
advertised service descriptions. The goal of this comparison is
to obtain information on how similar they are. This degree of similarity is used to determine if the
advertised service satisfies the requested capabilities.


Comparing the requested service
description with the advertised service descriptions takes all
the inputs and the outputs into account. The inputs of the requested service description are compared
to the inputs of the advertised service descriptions. And the outputs of the requested serv
ice
description are compared to the outputs of the advertised service descriptions.
In most of the
matchmaking algorithm, only
I

and
O

are considered for matching, because
P

and
E

are not
sufficiently standardized to be considered for Matchmaking algorithm
.

The
profile defines
a set of
additional properties that are used to describe the

features of the service. From these properties
, in
addition to IOPE
we
can
also
use the service category

[23]
, which is

used to classify the service with

respect to some on
tology or taxonomy of services. On

an optional basis, other properties can also be
taken into account, such as the element

QualityRating, or custom defined properties, such as the
duration of the execution.


5.2 Limitations of OWLS for Grid Services


The c
onventional match making for web services uses OWL
-
S descriptions for finding out
the degree of match. In this case, ProfileRDF properties point to the IOPE elements Input, Output,
Precondition and Effect. These properties can point to elements of an arbit
rary conceptualization.
The OWL
-
S definition leaves open, whether the definition uses OWL or other conceptualization
languages. A matching algorithm can only support conceptualizations that are covered by a
reasoning functionality. Hence, we need to assume

that the conceptualization is provided in OWL,
so that an OWL reasoner can determine a subsumption relation or the equivalence of concepts. Apart
from the IOPEs, a web service can be described by additional elements like the service category or
functional
ity.
As found in the definition of the IOPE types, it is also left open, whether the definition
for service categories uses OWL or other conceptualization that are covered by a reasoning
functionality as well. Therefore the conceptualization of additional
elements should also be provided
in OWL.






Development of Front End
tools for Semantic Grid Services




TechReport


34

IT@MIT


6.
Issues of Matchmaking

for
Semantic Grid Services


Grid
Service

is infact a web service, with defined rules and policies, the same definition of
Semantic Web services is also applicable to grid. Hence, the sem
antic Grid is an extension of the
current Grid services in which information and services are given well
-
defined and explicitly
represented meaning, better enabling computers and people to work in cooperation. It is possible to
describe the web services se
mantically with the help of OWL for Services called a
s OWL
-
S which
will not work for

semantic description of Grid services. The OWL
-
S editor
provides tool to convert
Web Service Description Language file of a Web Service into OWLS description that comprise
s
Service Profile, Service Grounding and Service Model.

Currently we are not able to use the same
tool to convert WSDL written for Grid service into OWLS. This is because WSDL file has peculiar
features which are specific to WSR
F.



Resource Properties:
We u
se the
wsrp:ResourceProperties

attribute of the
portType

element to specify what our service’s resource properties are. The resource properties must
be declared in the
<types>

section of the WSDL file. Resource properties are where we will
keep our state i
nformation.

The OWLS doesn’t contain any features to specify resource
properties with which the grid services are implemented as a stateful service.



Because of the
wsdlpp:extends

attribute of the
portType

element, we can include
existing WSRF portTypes in
our own portType
without

having to copy and paste from the
official WSRF WSDL files. A WSDL preprocessor will use the value of that attribute to
generate correct WSDL which includes our own portType definitions plus any WSRF
portType we might need in our s
ervice. This is a Globus specific feature that is intended to
make life easier for programmers. In our case, we use
GetResourceProperty portType

from the WS
-
ResourceProperties WSDL file.



Bindings are an essential part of a normal WSDL file. However, we don
’t have to add them
manually, since they are generated automatically by a
GT
4 tool that is called when we build
the service.



Since WSRF uses document/literal bindings, it requires that the parameters be implemented
in a very particular way. Whenever we wri
te an operation which is a part of our WSDL
interface, the parameters and the return values will in some cases be boxed inside stub classes




Development of Front End
tools for Semantic Grid Services




TechReport


35

IT@MIT


which are generated automatically from the WSDL file. This is more evident when we



have several
par
ameters.

For

example, if we declared the following operation in

our



WSDL file:

void multiply(int a1, int a2);

The actual Java code would look like this:

public MultiplyResponse multiply(Multiply params) throws RemoteException

{

int a1 = params.getA1(
)

int a2 = params.getA2()

// Do something

return new MultiplyResponse();

}

Multiply and MultiplyResponse are stub classes. Notice how the two parameters (a1

and a2)
are 'boxed' inside a single
M
ultiply

parameter, and how we return a MultiplyResponse

object
, even though we don't really want to return anything.

The tricky thing about this is
that, as mentioned earlier, this 'boxing' process only happens in

some cases:



When the number of parameters is more than one. For example, our add method



ou
r add method has a

single parameter, so it is
not
'boxed'.



When the return type is void or a complex type. For example, our getValueRP method

returns an int value, so it is not 'boxed'. On the other hand, both add and subtract return

void,
so what we reall
y have to return is AddResponse and SubtractResponse.


The WSDL2OWLS tools cannot interpret the above said features of WSRF which is not
present n normal Web Services.

Also, the WSDL2OWLS tools doesn’t provide any meant to take
ResourceProperties into acco
unt and it is solely for Web Services. Hence, developing
a
tool that
automatically converts Grid Service Description Language into OWLS is still considered as a

research issue.

In this project, we propose an overall architecture for semantic search of grid

services
and also a matchmaking algorithm to perform matching of grid services that

ranks the matching
degree of service descriptions similar to matchmaking of web services based on OWL
-
S. Different
degree of matches is achieved based on comparison of Inp
uts, Outputs and Functionality types for
requested and advertised services. Contrary to mechanisms that return only success or fail, ranked





Development of Front End
tools for Semantic Grid Services




TechReport


36

IT@MIT

results provide criteria for the selection of a service among a large set of results. With such a
discovery mecha
nism additional grid services can be found that might have normally been
eliminated.



6.1 Architecture of Semantic Grid Services


The architecture proposed for semantic grid service
s is shown in the figure 6.1.1. It identifies
the required components for

the purpose.
In this project, we create a grid service using GT4 toolkit
and deploy onto the Globus container.
This Globus Middleware is the reference implementation of
WSRF specification for Grid Architecture. This toolkits all packages for building a
ty
pical

WSRF
compliant Grid infrastructure.





Fig: 6.1.1
:

Architecture of semantic grid services.





Reg
Portlet

Sem
Portlet

Semantic Grid
Services Ontology
Repository















Grid Environmen
t


Grid Middleware

Globus

GS
1

1

GS
2


GS
n


Matchmaking

module

Service
Ontology

Reasoner

Grid
Portal



.

.

.

Registry portal



Development of Front End
tools for Semantic Grid Services




TechReport


37

IT@MIT


G
T
4 contains Resource Monitoring and Discovery service that enables the registration of all
Grid services and to monitor. I
t also provides a browser namely the webMDS to view all grid
services deployed onto the Globus container. It also implements Grid Security Infrastructure
component that provides secure communication across grid environment. To submit the job on the
grid re
source, it has Grid Resource Allocation and Manager that can monitor the job submission,
scheduling

and execution of a particular job on a specific resource. To utilize all these features, the
Grid Service developed must be deployed onto the Globus contain
er and registered in the MDS
registry. The MDS collects the information about the resource and maintained in a registry so that
it
can answer for queries ag
a
inst a particular resource.

Since, MDS registry structure supports
conventional keyword
searching

o
f
resource properties and service
s
, it is

not
possible

to expect
semantic searching
and retrieval
from MDS.

Hence to semantically describe
the services
, we need to
create ontology of grid service. Ontology is used to represent the knowledge and to

describe

it

semantically
. OWL is widely used to create ontology of a service and possibly
maintained in a
semantic grid services ontology repository. The knowledge
base
can be queried with the help

of a
suitable inference engine such as Algernon, pellet etc. The
m
atching algorithm implemented in the
matchmaking
module
match
es

the requested
service

against

the advertised one based on certain
parameters

and
obtain
s the degree of match

which will be discussed in detail in the next section
.


6.2
Ontology


As we discuss
ed earlier, there is no tool available to convert Grid Service Description
Language file into OWL file, we need to
describe

the concepts of the Gri
d service semantically.

Ontologies are used to capture knowledge about some domain of interest. Ontology desc
ribes the
concepts in the domain and also the relationships that hold between those concepts. Different
ontology languages provide different facilities. The most recent development in standard ontology
languages is OWL from the World Wide Web Consortium. I
t makes it possible to describe concepts
but it also provides new facilities. It has a richer set of operators


e.g. and, or and negation. It is
based on a different logical model which makes it possible for concepts to be defined as well as
described. Co
mplex concepts can therefore be built up in definitions out of simpler concepts.
Furthermore, the logical model allows the use of reasoner which can check whether or not all of the
statements and definitions in the ontology are mutually consistent can also