publishing web services which enable systematic search

International Journal on New Computer Architectures and Their Applications (IJNCAA) 2(1): 103-112 The Society of Digital Information and Wireless Communications, 2012 (ISSN: 2220-9085)

103

Publishing Web Services which enable systematic search

Vitezslav Nezval

Computer Information Systems Dpt., University of Malta

[email protected]

ABSTRACT

Web Services (WS) are used for

development of distributed applications

containing native code assembled with

references to remote Web Services. There

are thousands of Web Services available on

Web but the problem is how to find an

appropriate WS by discovering its details,

i.e. description of functionality of object

methods exposed for public use. Several

models have been suggested, some of them

implemented, but so far none of them

allowing systematic, publicly available,

search.

This paper suggests a model for publishing

WS in a flexible way which allows an

automated way of finding the desired Web

Service by category and/or functionality

without having to access any dedicated

servers. The search results in a narrow set

of Web Services suitable for problem

solution according to the user specification.

KEYWORDS

Web Service, WSDL, XML, HTTP, WSDF,

Search by Category, Search by Operation

1. BACKGROUND

1.1 Web Services (WS)

Web Service is software implemented by

any object oriented language (e.g. Java,

.NET languages, etc) following

prescribed standards. It is hosted by a

Web server as a module containing one

or more classes defining various

operations. The objects of the classes

can be instantiated by a remote

application (WS Consumer) by invoking

its constructor and then by invoking the

object’s methods. The object and

operations executed by the object

methods are running on a server host.

The communication between a WS

consumer/requester entity and server is

done by exchanging messages through

two standard protocols: SOAP and

REST; both operating on top of the

HTTP protocol.

SOAP uses XML for encoding the

messages according to the W3C

specification [1].

REST is indifferent to the component

architecture and inner workings. A

requirement of REST is that any

resource which is used must have a

URL. In order to execute an operation on

the resource, the HTTP defined

operations must be used. The most

frequently used ones include GET and

POST.

1.2 Web Service Definition

Language (WSDL)

To be able to use the Web Service the

Client application (a program running at

the WS consumer host machine) is to

use a proxy (a middleware which maps

local calls to the remote ones and then

marshals the requests to the Web

Service).

By standard a Web page presenting the

Web Service is to have a URL reference

to the WSDL file which is necessary for

the creation of a proxy used by the WS

consumer application to invoke the

mailto:[email protected]


104

remote services. WSDL is defined by the

W3C specification [2].

The popularity of Web Services lies in

an easy way of creating a proxy by

downloading the WSDL file which contains

all the XML encoded information necessary to

create the proxy. When the WSDL file is

downloaded a utility parser (also named wsdl

and available for various computer platforms)

generates the proxy in a chosen source code of

the Client application.

1.3 Web Service Example

An example of a simple Web Service,

referenced by a web portal of Membrane

[6], and used throughout this paper for

illustration, is a CurrencyServer created

by daenet [14]. Its function is to provide

the user with up to date currency

exchange rates that are available around

the clock. Presentation file of the web

service, can be found on:

http://www.currencyserver.de/webservic

e/currencyserverwebservice.asmx

The presentation web page of this Web

Service (Fig. 1) follows the standards

required for web services publishing.

Note that the presentation page of this

Web Service:

- includes brief information about the

name of the service and its seven

exposed operations

- provides the possibility to “try” the

operations by example (by clicking

on any operation presented)

- provides a reference to a WSDL file

which can be downloaded by a

prospective consumer in order

to generate a proxy (by clicking on

Service Description one can see

contents of XML encoded WSDL

file)

Fig. 1 CurrencyServer Web Service

2. CURRENTLY USED METHODS

AND METHODOLOGIES FOR

SEARCHING WEB SERVICES

Thousands of Web Services

implementing software solutions of tasks

used in business, education, banking,

commerce, etc, whether free or licensed

are available and published on the Web.

However the problem is how to find a

WS suitable for a particular Client

application. [9][11].

Although there are places in form of

dedicated tags both in the Web Service

presentation file and WSDL file, this

information is unstructured, often

incomplete and unsystematic therefore

current methods for search vary and can

be basically categorized to the :

- dedicated servers storing information

about published web services (e.g.

UDDI)

- Web crawling applications

attempting to search for WSDL files

Reference to WSDL file

http://www.currencyserver.de/webservice/currencyserverwebservice.asmx



105

and trying to “dig out” the

information within dedicated tags.

This is sort of data mining based on

revelation of similarities between the

Client description and the one in

WSDL file

- Proprietary Web portals presenting

references to a predefined categories

of published web services

2.1 UDDI (Universal Description,

Discovery and Integration)

UDDI is a service that lets a Web

Service provider to register its services

in a directory so that consumers have a

central place to find their needed

services. A UDDI directory is split into

three major categories which are:

White Pages – contain contact

information about the service owner

such as address, email and

ownership.

Yellow Pages – contain information

about the business classification

according to recognized standards

such as the North American Industry

Classification System.

Green Pages – list the protocols and

the technicalities of the service, e.g.

the service, its binding details, and

the parameters [12].

A common place where all the web

services can be deposited and searched

for is a central directory in which the

services could be registered under a

specific service category including the

contact details of the individual

responsible. This registry was placed on

the Internet to make it available to

consumers interested in using the

service.

The problem UDDI had to solve was

how to present the service information in

a standard way. OASIS has designed a

model where the information is stored in

structures called tModels. Refer to

specification document [8].

tModels represent unique constructs used

to describe compliance with a

specification, a concept, a category or

identifier system, or a shared design.

tModels types:

- Specification tModels are used to

represent service type definitions

- Category systems and identifier

systems tModels, together known as

"value sets", enable the

categorization and identification of

entities registered in UDDI in

accordance to these value sets.

Despite all this effort the UDDI Service

has not succeeded:

- Yu, J.J. & Zhou [3] criticize the service

that due to the complex classifications

and information stored in a UDDI

system, a client can not perform search

query efficiently to find the service

needed.

- Mintchev [4] argues that the information

held by UDDI is mostly insufficient and

is not needed by the WSDL consumers,

stressing that the only necessary

information in the tModels is the name

of WS.

- Rosanova [5] stressed that UDDI never

caught up as a major public registry for

the web services available but rather

remained used by organizations to act as

a register for their own services.

- Due to the fact that UDDI is missing

clear important features, WS providers

implement their own non-standard

functionality which results in loss of

interoperability between systems due to

these proprietary features [4].

As a result of the above stated problems

the three major drivers in the project

(Microsoft, SAP, and IBM) that

provided a free public UDDI service

have shut this public service down

completely (Microsoft).


106

2.2 Searching for Web Service

description in a WSDL file

Another currently used approach

attempts to search for web services by

finding the associated WSDL files and

retrieving as much information as

possible from them. Apart from

technical tags necessary for creation of a

client proxy, the WDSL provides some

tags allowing to describe function of the

web service such as the documentation,,

include and import tags. The

documentation tag can be placed

anywhere within the document and

contains human readable information

describing the functionality of the

service. The include tag and import tag

can be used to modularize the

description of a WSDL document.

However, this occurs in rather

unstructured manner without offering the

possibility to reveal the category of the

web service [13].

2.3 Proprietary Web portals

presenting Web Services

Although these portals attempt to

provide search by categories the

problem is :

- That the categories are predefined

and often missing the category

requested by the consumer

- That they do not allow a “fuzzy”

search based on similarities of WS

descriptions of operations

3. PROPOSED MODEL

The aim of this paper is to propose a

model providing an easy but efficient

way to search for Web Services.

The model is based on a uniform

classified description of a web service

applicable to any brand of the service.

Fundamental features of the model are:

a) on side of Web Service Publisher

- transparent and simple standards to

be followed

- flexibility in advertising of the Web

Service on any, non-dedicated, web

server host

b) on side of Web Service Consumer

- easy implementation of a web

searching application runable on any

web browser

- search of web services by non-

restricted categories and operations

3.1 Web Service Description File - the

core of the model

The core of the model is an XML

encoded file providing all the details of

the web service exposed by a Web

Service provider in a defined way. A

suffix suggested for this file is .WSDF

(Web Service Description File).

This file is to be associated with the Web

Service, similarly to the WSDL file. The

WSDF file is to comply with the XML

schema specification [7]

The WSDF file defines compulsory

XML tags for the specification of:

a) web service name with a

description of its function

b) web service operations (methods)

with a brief description of their

activity

c) web service category (e.g. science,

banking, education, travel, …)

with multiple categories allowed

d) further description of any length

and details

e) URL of the published presentation

web page including the WSDL

reference

f) name and e-mail address of the

web service vendor

It is up to the Web Service provider

where to publish the file, whether on the


107

web host running the Web Service or at

any other accessible web server. The

WSDF files (with .WSDF suffix) can be

easily found by any web crawler and

parsed for retrieving information of web

service by category as well by exposed

operations/methods.

a) WSDF schema

The XML structure of the WSDF file

consists of a root element whose name

must be servicedescription. The root

element must contain all the four top

level child elements which are:

documentation

company

categoryList

operationList.

The documentation tag provides

human readable information regarding

the capabilities of the web service

retrieved. Documentation of a service is

essential by the person providing the

service so that potential clients can

check whether the service found meets

their desired functional criteria. In the

proposed schema the user must provide

documentation on the service in general,

on each operation provided by the

service, and on the input-output

parameters.

The company tag provides brief

information about the entity providing

the service. In the schema being

proposed, the name of the company and

its email address are set as compulsory

information which must be specified.

Other information can easily be included

so as to provide useful information

needed in order to start using the web

service provided.

The categoryList and operationList

tags enable the provider of the service to

specify an unrestrained number of

categories and information on operations

offered by the service. The categoryList

element may contain an unbounded

number of child elements all with the tag

<category>. Within each tag, the

publisher can determine any category

describing the function of the web

service. This allows for the specification

of the function of the web service by

multiple categories. Similarly the

operationList may contain an unbounded

number of child elements with the tag

<operation>. The operation tag has an

attribute used to specify the name of the

operation. A documentation element

must also be designated within the

operation element providing human

readable information regarding the

semantics of this single operation.

There are two types of operation tags.

One type has a compulsory input tag

followed by optional output and fault

tags. The other type has compulsory

output tag and optional input and fault

tags. These operation tags were created

to reflect all the possible message

exchange patterns specified in WSDL:

Request- response operation (input

parameter followed by output

parameter)

Solicit-response operation (output

parameter followed by input

parameter)

One-way operation (input

parameter only)

Notification operation (output

parameter only)

For every parameter, or fault specified,

the name of the element must be

provided, and some documentation

regarding the meaning of the parameter

or the cause of the fault that was

generated must be specified in order for

the user to have a complete reference of

the capabilities and functionality of the

service being provided.


108

The schema defining the structure of the

proposed WSDF file is specified in the

Appendix.

b) WSDF example -

CurrencySeverWebService.WSDF file

The following is an example of a WSDF

file for the CurrencyServerWebService

mentioned previously as an example.

The XML file shown complies with the

WSDF XML schema proposed. The file

is shortened to only two out of seven

operations, the remaining operations

would be described similarly.

<servicedescription>

serviceURI="http://www.currencyserver.de/webservice/currencyserve

rwebservice.asmx"

name="CurrencyServerWebService"> <documentation>Currency Server

Web Service performing 7 basic

operations

</documentation>

<company name="XYZ IT">

<email>[email protected]</email>

</company>

<categoryList>

<category>Banking</category>

<category>Currency</category>

<category>Currency

Provider</category>

<category>Currency

conversion</category>

</categoryList>

<operationList>

<operation

="getCurrencyValue">

<documentation>Calculates

the currency factor for

specified currencies.

Example: dstCurrency

=f*srcCurrency

</documentation>

<input name =

"CurrencyValueIn">

<documentation>The three

values to be submitted:

Provider, Source

currency and Destination

Currency

</documentation>

</input>

<output name = "

CurrencyValueOut">

<documentation>The value

of currency returned

</documentation>

</output>

</operation>

<operation name="getDataSet">

<documentation>Retrieves the

currencies in a Dataset for

the specified Provider

</documentation>

<input name="DataSetIn">

<documentation>Name of

the Provider

</documentation>

</input>

<output name=" DataSetOut">

<documentation>The

result after submitting

the ame

</documentation>

</output>

</operation>

… etc. for remaining

operations

</operationList>

</servicedescription>

3.2 Search for Web Service using

WSDF file Provided the Web Service provider

creates and publishes the WSDF file of

the exposed Web Service the Web

Service consumer is to write a Web

application consisting of two parts:

- user interface enabling to specify a

category or operation(s) or both for

required Web Service

- a Web crawler searching for all

.WSDF files on Web, parsing the

XML of each WSDF while

analyzing the <categoryList> and

<operationList> tags in order to find

out whether they contain (or are

similar to) the category and

operation entered by user.

WSFinder

The WSFinder is suggested web

searching tool for a Web Service





109

consumer to find out a narrow list of

web services by analysing WSDF files

found by the web crawler on the Web.

The WSFinder.HTML file provides an

interface for the consumer to enter data

for fuzzy search by category as well as

by operation. This results in the

consumer receiving a list of applicable

services to choose from.

Example of the WSFinder page

Fig. 2 Layout of Web Finder: GUI Interface web

page with query by predefined category

Combined fuzzy search by user defined

category and operation is possible as

well. Ref. To Fig 3

Fig. 3 Web Service fuzzy search query for user

defined category combined with operation

Principle of WSFinder operation

Referring to the query in Fig. 3, the web

crawler is invoked in an attempt to find

those .WSDF files with CATEGORY

matching the substrings “currencies” or

“currency providers” and OPERATION

matching the string “list” or “list

currencies”. The search results in the

form of the list of possible applicable

web services found, each item

containing the below information.

List of Web Services returned by

WSFinder

- Name of Web Service

- Description of Function

- List of Operations with their

descriptions

- URL of Web Service presentation

page

- URL of .WSDF file

- Name and e-mail address of web

service vendor

By selecting the URL of a particular

Web Service, the standard presentation

page of that web service can be

downloaded. This page is to have, apart

from the prescribed reference to WSDL,

also a reference to WSDF file as a

standard. Here the consumer can use the

example of the provided operation(s),

and, by downloading and parsing the

WSDF file, the complete information

about the selected web service.

E.g. Should the Consumer opt for the

CurrencyServerWebService then the

web page with an incorporated reference

to the WSDF will be downloaded. Ref.

to Fig 4:


110

Fig. 4 CurrencyServerWebService Web Service

with additional reference to WSDF file

3.3 Publishing Web Service using the

proposed model

The task to publish a web service by

Web Service vendors (publishers) is

simple. The steps are as follows:

a) create .WSDF XML file complying

to the wsdf_schema.xsd schema,

b) place it on any web site and either

leave it to be “found” by web search

engines (e.g. Google) automatically

or explicitly apply for the publishing,

c) incorporate a reference to the WSDF

description file to the Web Service

presentation page (refer to Fig. 4)

4. PERFORMANCE

The ultimate goal of the proposed

system is to enable a user to find a web

service (or narrow list of candidate web.

services) to be incorporated into a client

application program.

A part of the proposed model is the

WSFinder searching program consisting

of a web crawler (any classical web

crawling program) and an XML parser.

The crawler searches the web for .WSDF

files (the proposed XML encoded files

which must be associated with each web

service complying with the proposed

model).

After each .WSDF file is downloaded it

is parsed in order to find out whether it

contains matching string(s)/substring(s)

corresponding to the user specification

of the web service. It is the two XML

child elements the categoryList and

operationList with the corresponding

<category> and <operation> tags (refer

to the pargraph of the PROPOSED

SYSTEM above) that contain web

service area/operation description and

guarantee a correct decision whether the

currently analysed web service is to be

accepted or ignored. The performance is

enhanced by a fuzzy search within these

tags to compensate for the user

abbreviated, not exactly matching,

specifications.

The time facor of the search is not

critical as it happens during the process

of the client application development,

and also, it is desirable to download

several applicable web services to

choose from.

5. CONCLUSION

The suggested model has the advantage

of providing a systematic search for Web

Services available world-wide without

the constraints of having to search on a

particular server(s). The model provides

two phases of operation:

Added reference to WSDF file


111

Phase 1: The consumer searches for a

web service by category/operation while

getting a list of the possible services.

Phase 2: The choice is narrowed by

selecting a particular Web Service

having a reference to ALL details about

the web service.

Its advantage is that the Web Service

provider can make a FULL description

of the web service to any depth in a

structured yet flexible way (because of

XML encoding) without affecting the

standards adopted for presenting Web

Services on Web.

APPENDIX

The XML schema of WSDF (wsdf_schema.xsd

file)

<?xml version="1.0" encoding =

"ISO-8859-1" ?>

<xs:schema xmlns:xs =

"http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified">

<xs:element

name="servicedescription"

type="tservicedescription"/>

<xs:complexType

name="tservicedescription">

<xs:all>

<xs:element

name="documentation"

type="xs:string" />

<xs:element name="company"

type="tcompany"/>

<xs:element

name="categoryList"

type="tlist"/>

<xs:element

name="operationList"

type="toperationlist"/>

</xs:all>

<xs:attribute name="serviceURI"

type="xs:anyURI"

use="required"/>

<xs:attribute name="name"

type="xs:NCName"

use="required"/>

</xs:complexType>

<xs:complexType name="tlist">

<xs:sequence>

<xs:element name="category"

type="xs:string"

minOccurs="0"

maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="tcompany">

<xs:sequence>

<xs:element name="email"

type="xs:string"/>

<xs:any

minOccurs="0"


</xs:sequence>


type="xs:string"

use="required"/>

</xs:complexType>

<xs:complexType

name="toperationlist">

<xs:sequence>

<xs:element name="operation"

type="toperation"

minOccurs="0"


</xs:sequence>

</xs:complexType>

<xs:complexType

name="toperation" >

<xs:sequence>

<xs:element


type="xs:string" />

<xs:choice>

<xs:group ref="request-

response-or-one-way-

operation" />

<xs:group ref="solicit-

response-or-notification-

operation" />

</xs:choice>

</xs:sequence>


type="xs:NCName"

use="required" />

</xs:complexType>

<xs:group name="request-

response-or-one-way-

operation" >

<xs:sequence>

<xs:element name="input"

type="param"/>

<xs:sequence minOccurs="0">


112

<xs:element name="output"

type="param"/>

<xs:element name="fault"

type="param" minOccurs="0"


</xs:sequence>

</xs:sequence>

</xs:group>

<xs:group name="solicit-

response-or-notification-

operation" >

<xs:sequence>

<xs:element name="output"

type="param"/>

<xs:sequence minOccurs='0'>

<xs:element name="input"

type="param"/>

<xs:element name="fault"

type="param" minOccurs="0"


</xs:sequence>

</xs:sequence>

</xs:group>

<xs:complexType name="param">

<xs:sequence>

<xs:element


type="xs:string"/>

</xs:sequence>


type="xs:NCName"

use="required" />

</xs:complexType>

</xs:schema>

REERENCES

1. http://www.w3.org/TR/soap/

2. http://www.w3.org/TR/wsdl

3. Yu, J.J., Zhou, G.: Dynamic Web Service

Invocation Based on UDDI at E-Commerce

Technology for Dynamic E-Business, IEEE

International Conference in 2004

4. Mintchev, A., Interoperability among Service

Registry Implementations: Is UDDI Standard

Enough? , IEEE International Conference on

Web Services.(ICWS), Beijing, China, 2008.

Available at:

http://ieeexplore.ieee.org/lpdocs/epic03/wrapp

er.htm?arnumber=4670242

5. Rosanova Dan: Why UDDI is Important ,

http://advice.cio.com/dan_rosanova/why_uddi

_is_important?page=0%2C0

6. Membrane: http://www.service-

repository.com/

7. http://www.w3.org/TR/xmlschema-1/

8. UDDI OASIS Standard, tModels,

http://uddi.xml.org/tmodels

9. Al-Masri Eyhab, Qusay Mahmoud H.:

Investigating Web Services on the World

Wide Web, Proceeding of the 17th

international conference on World Wide

Web, pp. 795-804, Beijing, 2008

10. Hicks Janette, Govindaraju Madhusudhan,

Meng Weiyi. Enhancing Discovery of Web

Services through Optimized Algorithms in

Proceedings of the 2007 IEEE International

Conference on Granular Computing, , pp.

695-698, Washington DC, 2007

11. Fan Jianchun, Subbarao Kambhampati.: A

Snapshot of Public Web Services,

SIGMOD Rec., vol. 34, no. 1, pp. 24-32,

March 2005.

12. Garofalakis John, Panagis Yannis,

Sakkopoulos Evangelos, Tsakalidis

Athanasios.: Web Service Discovery:

Looking for a Needle in a Haystack?,

International Workshop on Web

Engineering, 2004.

13. Lausen Holger, Steinmetz Nathalie. Survey

of Current Means to Discover Web Services,

Technical Report at Semantic Technology

Institute, Innsbruck, August 2008.

14. Currency Server Web Service by daenet:

http://www.currencyserver.de/portal/default

_english.html

http://www.w3.org/TR/soap/

http://www.w3.org/TR/wsdl

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4670242

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4670242

http://www.service-repository.com/

http://www.service-repository.com/

http://www.w3.org/TR/xmlschema-1/

http://www.oasis-open.org/specs/index.php#uddiv3.0.2

http://uddi.xml.org/tmodels

publishing web services which enable systematic search

Documents