CHAPTER 1

INTRODUCTION
1.1 PROJECT DEFINITION
As a greater number of Web Services are made available today, automatic
discovery is recognized as an important task. To promote the automation of service
discovery, different semantic languages have been created that allow describing the
functionality of services in a machine interpretable form using Semantic Web
technologies. The problem is that users do not have intimate knowledge about semantic
Web service languages and related toolkits. We have proposed a discovery framework
that enables semantic Web service discovery based on functional parameters represented
in an XML file. We describe a novel approach for automatic discovery of semantic Web
services which employs IOPE to match a user request, expressed in XML, with a
semantic Web service description.
1.2 WEB SERVICES ARCHITECTURE
The Web services architecture is based upon the interactions between three roles:
service provider, service registry and service requestor. The interactions involve publish,
find and bind operations. Together, these roles and operations act upon the Web services
artifacts: the Web service software module and its description. In a typical scenario, a
service provider hosts a network-accessible software module (an implementation of a
Web service). The service provider defines a service description for the Web service and
publishes it to a service requestor or service registry. The service requestor uses a find
operation to retrieve the service description locally or from the service registry and uses
the service description to bind with the service provider and invoke or interact with the
Web service implementation.
Figure 1.2 illustrates these operations, the components providing them and their
interactions.
The roles in Web services architecture are service provider, service requestor and service
registry.

Service provider: From a business perspective, this is the owner of the service.
From an architectural perspective, this is the platform that hosts access to the

service.
Service requestor: From a business perspective, this is the business that requires
certain functions to be satisfied. From an architectural perspective, this is the
application that is looking for and invoking or initiating an interaction with a
service. The service requestor role can be played by a browser driven by a person

or a program without a user interface, for example another Web service.

Service registry: This is a searchable registry of service descriptions where service
providers publish their service descriptions. Service requesters find services and
obtain binding information (in the service descriptions) for services during
development for static binding or during execution for dynamic binding. For
statically bound service requestors, the service registry is an optional role in the
architecture, because a service provider can send the description directly to service
requesters.

Figure 1.2 Web Services roles, operations and artifacts

The operations in a Web service architecture are publish, find and bind.

Publish: To be accessible, a service description needs to be published so that the

service requestor can find it.

Find: In the find operation, the service requester retrieves a service description
directly or queries the service registry for the type of service required. The find

operation can be performed at runtime to retrieve the services binding and location
description for invocation.
Bind: A service needs to be invoked. In the bind operation the service requestor

invokes or initiates an interaction with the service at runtime using the binding
details in the service description to locate, contact and invoke the service.

1.3 NEED FOR PROPOSED SYSTEM

The existing systems are not an automated discovery of services rather they are
semi automated or static. To discover a service automatically, our project plays the role
of proposed system. In this system, the services are created with all the user requirements
and those services are published by the Service Providers in the form of WSDL file to the
UDDI Registry.
Service Providers publishes the services along with their Constraints to the UDDI
registry. Services are then searched in the UDDI registry and it is processed through four
phases such as exact match, similar match, constraint reasoning and best first match.
Using the match making algorithm the services are matched. After filtering out all
unmatched services, a best matched service is discovered. A URL is discovered from the
UDDI and it is invoked by the service client and finally binded to the service provider.
1.4 APPLICATIONS OF PROPOSED SYSTEM
In this proposed system, end user gives the requirements for booking flight tickets
and the searching will be performed UDDI. Based on match making algorithmic process,
a best service is finally discovered to the service client. The features of this system are,

To enable the ontology and constraint-based modelling of the distributed

services and semantic annotation of the acquired services.

To facilitate efficient, accurate, and automatic retrieval of the required services
based on semantic matchmaking of service capabilities.

CHAPTER 2
LITERATURE SURVEY
2.1 USING THE WEB SERVICE MODELING ONTOLOGY TO ENABLE
SEMANTIC E-BUSINESS
Jos de Bruijn, Dieter Fensel, Uwe Keller
Digital Enterprise Research Institute, December 6, 2005.
Jos de Bruijn, Dieter Fensel and Uwe Keller proposes a methodology for higher
degree of automation in the location and use of Web Services that can be achieved by
adding explicit semantics to Web Service descriptions. Such semantically enriched
descriptions are usually referred to as Semantic Web Services and they are expected to
enable businesses to dynamically locate partners which provide particular services, and to
facilitate (semi-)automated cooperation with them. The Web Service Modeling Ontology
(WSMO) follows this direction and defines an explicit conceptual model for Semantic
Web Services based on the Web Service Modeling Framework (WSMF). The major aim
of WSMO is to provide the necessary technology to achieve flexible and cost-effective
integration within and across business boundaries.
2.2 DISCOVERING AND INTEGRATING DISTRIBUTED MANUFACTURING
SERVICES WITH SEMANTIC MANUFACTURING CAPABILITY PROFILES
Buhwan Jeong, Jungho Jang, Boonserm Kulvatunyou, Jaegyong Chang and
Hyunbo Cho
Department of Industrial and Management Engineering, Pohang University of
Science and Technology (POSTECH) San 31, Hyoja, Pohang, 790-784, South Korea.
This present paper aims to extend the UDDI registry specification to include
semantic descriptions about manufacturing services and to support reasoning about those
descriptions for service discovery. Specifically, we provide OWL-based definitions for
manufacturing service capability profiles and a DL-based reasoning procedure for
matching queries to service descriptions.

OWL is chosen to describe the manufacturing service capability profile because it

is the standard markup language for expressing semantics for semantics web ontologies
and it provides powerful reasoning capability among ontologies. An extended UDDI
registry is used to mediate contracts between designers and manufacturers, the OWL
language to augment manufacturer's capability profiles, and DL-reasoning to discover
such profiles. Specifically, Buhwan Jeong, Jungho Jang, Boonserm Kulvatunyou,
Jaegyong Chang and Hyunbo Cho [3] have added a new semantics container, the service
Profile, and described how to represent and to reason about manufacturing service
capabilities in a semantic manner; in particular, we used OWL and DL for the latter
purpose. The extensions to the UDDI specification and implementation described here
could be used to advertise and discover services (and providers as well) in domains other
than manufacturing.
2.3 OWL RULES: A PROPOSAL AND PROTOTYPE IMPLEMENTATION
Ian Horrocks, Peter F. Patel-Schneider, Sean Bechhofer, Dmitry Tsarkov
February 28, 2005.
This paper proposes a methodology towards OWL (Web Ontology Language)
rules that adds considerable expressive power to the Semantic Web it does have
expressive limitations, particularly with respect to what can be said about properties.
SWRL (the Semantic Web Rules Language), a Horn clause rules extension to OWL that
overcomes many of these limitations. SWRL extends OWL in a syntactically and
semantically coherent manner. The basic syntax for SWRL rules is an extension of the
abstract syntax for OWL DL and OWL Lite SWRL rules are given formal meaning via an
extension of the OWL DL model-theoretic semantics. SWRL rules are given an XML
syntax based on the OWL XML presentation syntax; and a mapping from SWRL rules to
RDF graphs is given based on the OWL RDF/XML exchange syntax.
Ian Horrocks, Peter F. Patel-Schneider, Sean Bechhofer, Dmitry Tsarkov add a
new kind of axiom to OWL DL, namely Horn clause rules, extending the OWL abstract
syntax and the direct model-theoretic semantics for OWL DL to provide a formal
semantics and syntax for OWL ontologies including such rules. Names in the abstract
syntax are RDF URI references.

2.4 AUTOMATING INTEGRATION OF MANUFACTURING SYSTEMS AND

SERVICES: A SEMANTIC WEB SERVICES APPROACH
Zhonghua Yang, Robert Gay, Chunyan Miao, Jing-Bing Zhang, Zhiqi Shen and
Liqun Zhuang, and Hui Mien Leem
School of Electrical and Electronics Engineering, Nanyang Technological University,
Singapore 639798.
This paper provides a methodology to achieve automated integration based on
semantic web services architecture. Service-oriented integration architecture, enhanced
with semantics, is presented which construct a service-oriented environment via
virtualization by taking a WS-Resource Framework approach. All Web services are
semantically enhanced using service upper ontology OWL-S and manufacturing domain
ontologies which are written in standard Web Ontology Language (OWL). Within this
semantic rich environment, integration is achieved by Web services composition, and
automation is accomplished via the combination of Semantic Web and software agents.

Figure 2.4.1 Automated Integration Architecture based on Semantic Web Services

approach
The main theme of this paper is the Semantic Web services based architecture that
enables automated integration. The key to the Semantic Web services-based approach to
enterprise integration is that the business process modeling transforms an integrated
enterprise into a VE (virtualized enterprise), which is then dynamically and automatically
constructed out of available semantic enhanced Web services as needed at runtime using
intelligent software agents. i.e., the service-orientation is achieved via virtualization in a
6

WS-Resource Framework approach, the integration is via services composition, the

service semantics enhancement uses the OWL and OWL-S, and automation is achieved
by software agents who manipulate the semantics of Web services in a service-oriented
environment.
2.5 A FRAMEWORK FOR SEMANTIC WEB SERVICES DISCOVERY
Jyotishman Pathak, Neeraj Koul, Doina Caragea,Vasant G Honavar
Artificial Intelligence Research Laboratory, Department of Computer Science, Iowa
State University.
This paper describes a framework for ontology-based flexible discovery of
Semantic Web services. The proposed approach relies on user-supplied, context-specific
mappings from user ontology to relevant domain ontologies used to specify Web services.
It show how a user's query for a Web service that meets certain selection criteria can be
transformed into queries that can be processed by a matchmaking engine that is aware of
the relevant domain ontologies and Web services. It also describe how user-specified
preferences for Web services in terms of non-functional requirements (e.g., QoS) can be
incorporated into the Web service discovery mechanism to generate a partially ordered list
of services that meet user- specified functional requirements.
2.6 PROPOSED SYSTEM
To discover a service automatically, our project plays the role in automated service
retrieval. In this system, the services are created with all the user requirements and those
services are published by the Service Provider in the form of WSDL file to the Service
Broker (UDDI). Service Providers publishes the services along with their Constraints
to the UDDI registry. Services are then searched in the UDDI registry and it is processed
through four phases such as exact match, similar match, constraint reasoning and best
first match. Using the match making algorithm the services are matched. After filtering
out all unmatched services, a best matched service is discovered. A URL is discovered
from the UDDI registry and it is invoked by the service client and finally binded to the
service provider.

CHAPTER 3
PROBLEM FORMULATION
3.1 MAIN OBJECTIVE
To develop online ticket reservation application for flights in such a way that it
supports dynamic searching and retrieval of flight based on exact match.
3.2 SPECIFIC OBJECTIVE
To discover the requested service for the end-user based on semantic match
making process and automatic discovery of services at run time.
3.3 PLATFORM REQURIEMENTS
3.3.1 HARDWARE REQUIREMENTS

Processor Required:
RAM Size:
Hard disk Capacity:

PENTIUM DUAL CORE/Above

2 GB/Above.
80GB/Above.

3.3.2 SOFTWARE REQUIREMENTS

Java Development Kit 7(JDK)

IBM Rational Application Developer 7.0
Programming Language : Core Java
My SQL Server 4.1
NeOn Toolkit 2.5.2
Protg 4.2

CHAPTER 4
8

SYSTEM ANALYSIS AND DESIGN

System analysis is a process of collecting factual data, understand the processes
involved, identifying problems and recommending feasible suggestions for improving the
system functioning. This involves studying the business processes, gathering operational
data, understanding the informational flow, finding out the bottlenecks and evolving the
solutions for overcoming the weaknesses of the system so as to achieve the organizational
goals.
4.1 EXISTING SYSTEM
This system is not capable of discovering the services automatically at run time.
Here the service client request for a service and searching operation is performed in
UDDI registry before the service has been invoked. For statically bound service
requestors, the service registry is an optional role in the architecture, because a service
provider can send the description directly to service requestors. The interaction takes
place only between service client and service provider.
DRAWBACKS

Fail to discover the services automatically at run time.

No communication between service client and service registry on static
process.

4.2 PROPOSED SYSTEM

To discover a service automatically, our project plays the role of proposed system.
In this system, the services are created with all the user requirements and those services
are published by the Service Providers in the form of WSDL file to the Service Broker
called UDDI. Service Providers publishes the services along with their Constraints to
the UDDI registry. Services are then searched in the UDDI registry and it is processed
through four phases such as exact match, similar match, constraint reasoning and best
first match. Using the match making algorithm the services are matched. After filtering
out all unmatched services, a best matched service is discovered. A URL is discovered
from the UDDI registry and it is invoked by the service client and finally binded to the
service provider.

4.3 SYSTEM ARCHITECTURE:

Figure 4.3 System Architecture Diagram

The services are created with all user requirements and N no. of service
providers publishes their N no. of services in the form of WSDL file to UDDI registry.
Service Providers publishes the services along with their Constraints to the UDDI
registry. A WSDL to OWL converter tool is used to convert from WSDL to OWL which
in turn generates profile, process, and grounding. Using these, a domain ontology is
created for the airline system and that is stored in a repository called ontology repository.
On Service clients request, ontology for airline service which was present in
ontology repository is parsed to get the information about the services. Services are then
searched in the UDDI registry and it is processed through four phases such as exact
match, similar match, constraint reasoning and best first match. Using the match making
10

algorithm the services are matched. After filtering out all unmatched services, a best
matched service is discovered. A URL is discovered from the UDDI and it is invoked by
the service client and finally binded to the service provider.
4.4 USECASE DIAGRAM: ONLINE FLIGHT RESERVATION SYSTEM
Use case diagram presents a graphical overview of the functionality provided by a
system in terms of actors, their goals and any dependencies between those use cases.
Service that we wish to provide is the online flight reservation system where anyone can
book ticket, check for availability, cancel the ticket, and check status of the ticket. The

11

Figure 4.4 shows the functional requirements of online flight reservation system.

login

Service client

booking
discovering
discovering URL
binding

Service EndUser
payment

UDDI

cancellation

publising a service

Service Provider

refund status

Figure 4.4 Use Case Diagrams - Online Flight Reservation System

4.5 DATA FLOW DIAGRAM:
The service provider creates a service with all user requirements. There are
number of services available such as booking service, payment service, cancellation
service, refund status service, etc., Each service operations mapped to an operation
12

element WSDL which contains no information on the semantics of the described web
service. A formal description of web service is the key in automating the task of locating
required service.
The Service Provider publishes the service such as booking, payment, and
cancellation, refund status along with a WSDL file, Business and Service detail for
respective service to the UDDI registry. The WSDL to OWL converter will be used to
convert the WSDL file to OWL.Therefore the conversion process generates Service
Grounding, Service Process and service profile. The services are matched through four
phases such as exact match, similarity match, constraint reasoning and best match.
In exact match phase, the strategy of an exact match is implemented. Domain
name and Service name will be given as inputs for this phase. As a result, a list of N
services is discovered in this phase.
The similarity match is the second phase of the service matchmaking. In this
phase, the strategy of the similar match is implemented. Based on Input and Output
parameters, the services are matched using semantic matchmaking algorithm.
The constraint reasoning is the third phase of the service matchmaking. Constraint
knowledge has been formalized using SWRL. Based on constraints like input type, field
and value the services are matched.
After filtering out the unmatched service from first three phases, a best matched
service is obtained in best matching phase and URL is discovered. Then service client and
service provider are binded together and required service from the service provider is
given to service client and execution of service take place by method invocation. Service
client finally response to end-user by providing discovered URL.

13

Figure 4.5 Data Flow Diagram

4.5.1 CREATION OF SERVICES
The service provider creates a service with all user requirements. There are
number of services available such as booking service, payment service, cancellation
service, refund status service, etc., Each service operations mapped to an operation
element WSDL which contains no information on the semantics of the described web
service. A formal description of web service is the key in automating the task of locating
required service.

Figure 4.5.1 DFD for Creation of service

14

4.5.2 PUBLISHING SERVICES

The Service Provider publishes the service such as booking, payment, and
cancellation, refund status along with a WSDL file, Business and Service detail for
respective service. The WSDL to OWL converter will be used to convert the WSDL file
to OWL.Therefore the conversion process generates Service Grounding, Service Process
and service profile.

Figure 4.5.2 DFD for Publishing Services

4.5.3 DISCOVERING A SERVICE
A service is discovered through four phases. They are,
Exact Match
The exact match is the first phase (Subsumption Reasoning) of the service
matchmaking. In this phase, the strategy of an exact match is implemented. A tool is used
to perform (Subsumption Reasoning). Domain name and Service name will be given as
inputs for this phase. As a result, a list of N services is discovered in this phase.
Similarity Match
The similarity match is the second phase of the service matchmaking. In this
phase, the strategy of the similar match is implemented. Based on Input and Output
parameters, the services are matched using semantic matchmaking algorithm.
Constraint Reasoning
The constraint reasoning is the third phase of the service matchmaking. Constraint
15

knowledge has been formalized using SWRL. Based on constraints like input type, field
and value the services are matched. A rule engine is used (eg.JESS) to perform constraint
reasoning.
Best-First Reasoning
The strategy of the best first match is implemented to select the best one among
all candidate services that sufficiently match the required service.
Selects a best matched service

Figure 4.5.3 DFD for Discovering a Service

4.5.4 EXECUTION OF SERVICE
A best service is discovered from four phases of matching, then service client and
service provider is binded together and required service from the service provider is given
to service client and execution of service take place by method invocation. Service client
finally response to end-user by providing discovered url and this happens automatically
while comparing with existing system.
response

Figure 4.5.4 DFD for Execution of Service

16

4.6 TABLE DESIGN

Table 4.6.1 Login table
S.NO

FIELDNAM

1.
2.
3.

E
Username
Password
Email

4.

Phoneno

CONSTRAINT
Primary key

DATATYPE

SAMPLE VALUE

varchar
varchar
varchar

Karthick
******
karthick@gmail.com

Int

9012356565

Table 4.6.2 Search flights table

S.N
O
1
2.
3.
4.
5.
6.

FIELD NAME

CONSTRAINT

Flight No
Origin
Destination
Type
NoofPass
Depart_date

Primary Key

DATATYPE
Int
varchar
varchar
varchar
Int
varchar

SAMPLE VALUE
111
Chennai
Delhi
Business
5
3/28/2013

Table 4.6.3 Ticket Status table

S.NO
1.
2.
3.
4.
5.
6.
7.
8.
9.
10
.
11.

FIELD NAME
ticketid
username
noofpass
origin
destination
flightname
Date
Price
bankname
cardno

CONSTRAINT
Primary key
Primary key

Primary key

Type

DATATYPE
Int
varchar
Int
varchar
varchar
varchar
varchar
Int
varchar

SAMPLE VALUE
123435
Karthick
5
Chennai
Delhi
Kingfisher
3/28/2013
7200
Sbi

varchar

123465123456

varchar

Business

Table 4.6.4 Airindia table

S.NO
1.

FIELD NAME
Flightno

CONSTRAINT
Primary key
17

DATATYPE
Int

SAMPLE VALUE
111

2.
3.
4.
5.
6.

Flightname
Origin
Destination
Economic price
Business price

varchar
varchar
varchar
Int
Int

airindia
Chennai
Delhi
7000
5000

Table 4.6.5 Kingfisher table

S.NO
1.
2.
3.
4.
5.
6.

FIELD NAME
Flightno
Flightname
Origin
Destination
Economic price
Business price

CONSTRAINT
Primary key

DATATYPE
Int
varchar
varchar
varchar
Int
Int

SAMPLE VALUE
222
kingfisher
Chennai
Delhi
7000
5000

Table 4.6.6 Spice jet table

S.NO
1.
2.
3.
4.
5.
6.

FIELD NAME
Flightno
Flightname
Origin
Destination
Economicprice
Businessprice

CONSTRAINT
Primary key

DATATYPE
Int
varchar
varchar
varchar
Int
Int

SAMPLE VALUE
333
spicejet
Chennai
Delhi
7000
5000

Table 4.6.7 Passenger table

S.NO
1.
2.
3.
4.
5.

FIELD NAME
Ticketid
Firstname
Lastname
Age
Gender

CONSTRAINT
Primary key

DATATYPE
Int
varchar
varchar
Int
varchar

SAMPLE VALUE
123440
Karthick
Eg
22
male

Table 4.6.8 Canara table

S.NO

FIELD NAME

CONSTRAINT
18

DATATYPE

SAMPLE VALUE

1.
2.
3.
4.

Cardno
Cardname
Expirydate
Cvvno

Primary key

Int
varchar
varchar
varchar

Primary key

123465123456
Kanna
28-02-2013
123

Table 4.6.9 sbi table

S.NO FIELD NAME
1.
Cardno
2.
Cardname
3.
Expirydate
4.
Cvvno

CONSTRAINT
Primary key
Primary key

DATATYPE
Int
varchar
varchar
varchar

SAMPLE VALUE
123465654321
Kanna
30-02-2013
321

CHAPTER 5
FUNCTIONAL DESCRIPTION
5.1 MODULES
The various modules of the system are as follows:

Creation of services
Publishing services
Discovering a service
Execution of service

5.1.1 CREATION OF SERVICES

Service Provider creates the services for Airline reservation such as Booking,
Cancellation and Ticket Status using bottom up approach. Similarly create the services for
banking domain. WSDL file for each service has been created which provides the details

19

such as target namespaces, binding details, Input and Output message type, and Service
name with invocation details.
5.1.2 PUBLISHING SERVICES
The Service Provider publishes the service such as booking, payment, and
cancellation, refund status along with a WSDL file, Business, Service, IOPE detail for
respective service. When the service has published in the UDDI Registry, it has been
updated into domain ontology by the UDDI administrator.
5.1.3 DISCOVERING A SERVICE
CREATING DOMAIN ONTOLOGY USING NeON TOOL
For discovering a service, ontology is created for an airline domain called a
domain ontology using the NeON tool. This tool is an extensible environment for creating
and editing ontologies and knowledge bases. It is very easy-to-use graphical user
interface. Therefore the domain ontology is created with number of relationships and
properties.

USING SPARQL QUERY

SPARQL stands for SPARQL Protocol and RDF Query Language. It is a Query
Language for RDF. The SPARQL Protocol for RDF specification: it defines the remote
protocol for issuing SPARQL queries and receiving the results. The SPARQL Query
Results XML Format specification: it defines an XML document format for representing
the results of SPARQL queries. SPARQL is based on matching graph patterns against
RDF graphs.
A triple pattern is like an RDF triple, but with the option of a variable in place of
RDF terms (i.e., IRIs, literals or blank nodes) in the subject, predicate or object
positions.
SPARQL Graph Patterns
A basic graph pattern (BGP) is a set of triple patterns written as a sequence of
triple patterns. A group graph pattern is a set of graph patterns delimited with braces { }.
Simple SPARQL Query for airline service:
Data: <http://cmdairways.com/airline/service>
20

<http://airlines.com/dc/elements/1.1/servicename>
Reservation service".
Query: SELECT ?servicename
WHERE { <http://cmdairways.com/airline/service>
<http://airlines.com/dc/elements/1.1/servicename>
?servicename. }
Result: servicename
"Reservation service"
5.1.4 EXECUTION OF SERVICE
A best service is discovered from four phases of matching, then service client and
service provider is binded together and required service from the service provider is given
to service client and execution of service take place by method invocation. Service client
finally response to end-user by providing discovered url and this happens automatically
while comparing with existing system.

CHAPTER 6
SYSTEM DEVELOPMENT, IMPLEMENTATION AND TESTING
6.1 SYSTEM DEVELOPMENT
System development defines the sequence of steps or phases in which each phase
use the result of previous one. Implementation is the stage of the project when the
theoretical design is turned into a working system. If the implementation stage is not
carefully planned and controlled, it can cause chaos. Thus it can be considered to be the
most crucial stage in achieving a successful new system and in giving the users
confidence that the new system will work and be effective.
The existing systems are not an automated discovery of services rather they are
semi automated or static. To discover a service automatically, our project plays the role of
proposed system. In this system, the services are created with all user requirements and

21

N no. of service providers publishes their N no. of services in the form of WSDL file
to UDDI.
Service Providers publishes the services along with their Constraints and QoS to
the UDDI registry. A WSDL to OWL converter tool is used to convert from WSDL to
OWL which in turn produces profile, process, and grounding. Using these, domain
ontology is created and that is stored in a repository called ontology repository.
On Service clients request, ontology for airline service which was present in
ontology repository is parsed to get the information about the services. Services are then
searched in the UDDI registry and it is processed through four phases such as exact
match, similar match, constraint reasoning and best first match. Using the match making
algorithm the services are matched. After filtering out all unmatched services, a best
matched service is discovered. A URL is discovered from the UDDI and it is invoked by
the service client and finally binded to the service provider.

6.1.1 INPUT DESIGN

Input design is the process of converting user originated inputs to a computer
based format in database. Input design is one of the most expensive phases of operation of
computerized system and is the often major problem of system. In this application, input
required for the project is given by end user to book flight tickets. The inputs may be
origin, destination, departure date and class to search for flights.
6.1.2 OUTPUT DESIGN
Output design is generally refers to result and information that are generated by
the system for the client. Output is the main reason for developing the system and basis
on which they evaluate usefulness of the system. Based on the given input, the number of
flights available will be displayed to service client. The Output is to get the discovered url
form the uddi and given to service client. Finally the service provider and service client
are bounded.
6.2

IMPLEMENTATION
22

6.2.1 CREATION OF SERVICES

Steps to create a Web Service:

Create a class file for the particular service.

Right click on the class file and choose Web Services

(see fig 6.2.1)

To create Web Service, in the Web Service window, click next

Figure 6.2.1.1)
Web Service is created and thus WSDL file is generated for created Web Service.
Like the same N number of service are created for example booking, reservation,
cancel ticket, ticket status, banking, searching flights.

Figure 6.2.1 creating a web service

23

Create Web service

finish(see

Figure 6.2.1.1 web service operation window

6.2.1.2 LOGIN FORM
Application Home Page:
To obtain a login service, the user should complete the registration process. The
registration requires fields such as username, password email-id etc., After successful
registration, a login facility is provided to the user. All the deatails will be stored in
database. The system is connected with a database and during login process the details are
checked in database and gets successful login only for the registered user.

24

Figure 6.2.1.2 Login Form

6.2.1.3 SERVICES OF THE SYSTEM

The services of the system are,

Booking
Payment
Check status
Cancellation

Booking service is used to book the flight tickets. To book flight tickets, the user
should search for the flights with the inputs. So a search is made to know about the
25

available flights. This service search for the given inputs and reply back if there are
flights available or not. Payment is a banking gateway to book the flight tickets.
Check status service is used to get the status of the ticket by giving ticket id as the
input. With the help of this service, the user can view about the ticket details that has
been booked.
Cancellation service is created to cancel the ticket by giving ticket id as the user
input.

Figure 6.2.1.3 Services of the system

6.2.1.4 SEARCH FLIGHTS
This search flights service is created to search for flights with user inputs. This
service consists of no. of fields and is used to give inputs for searching flights. The user
inputs are From, To, Departure date, class of the flight and no. of passenger. Flights are
searched on the basis of user inputs and the no. of flights available for the requested
service is obtained. Only the flights that match the user inputs are displayed and if the
requested service is not available, then no flights available page is displayed. After
successful search the no. of flights available is displayed and the tickets are booked for
any one of the available flights.
26

Figure 6.2.1.4 Search Flights

6.2.1.5 CHECK STATUS

The check status service is created to check the status of the ticket that has been
booked. Here, the ticket id is used as an input to check the status of the ticket. This
service displays the total amount, origin, destination, flight no., flight name and no. of
tickets.

27

Figure 6.2.1.5 Check Status

6.2.1.6 CANCELLATION
The cancellation service is created to cancel the ticket that has been booked. Here,
a ticket-id is used as an input to cancel the ticket. If ticket-id is lost or forgotten, a new
facility is available to the user. It can be canceled by login to the system and could able to
see the history of tickets booked. There the user can view the ticket-id and cancel the
ticket easily.

28

Figure 6.2.1.6 Cancellation

6.2.2 PUBLISHING SERVICES
The Service Provider publishes the service along with an WSDL file, Business
and Service detail for respective service. The WSDL to OWL converter will be used to
convert the WSDL file to OWL.Therefore the conversion process generates Service
Grounding, Service Process and service profile.
The business name, business id, service name and discovery url for the particular
service are published to the uddi registry by the service provider.

29

Figure 6.2.2 publishing services

Figure 6.2.2.1 publish

30

6.2.3 CREATION OF DOMAIN ONTOLOGY

Using NeOn toolkit, domain ontology is created. The OWL Editor of NeOn
Toolkit is a modeling tool for the creation and maintenance of semantic models (often
referred to as "ontologies") written in the Web Ontology Language OWL.
6.2.3.1 STEPS TO CREATE AN ONTOLOGY PROJECT
The following steps should be followed to create an ontology project.
1. Create an ontology project.
Select File >> New >> Project. The New Project dialog opens.
2. Select Ontology Development Project
Open the folder Ontology and select Ontology Development Project.
3. Click Next.
Enter the name of the project in the text box.
4. Click Finish.
The ontology project will be created. To discard your changes, click Cancel.
6.2.3.2 STEPS TO CREATE A CLASS
The following steps should be followed to create a class.
1. Select ontology.
Select ontology in the Ontology Navigator.
2. Select the Classes folder.
Right-click the Classes folder and select New Class or press CTRL-N.
3. Rename the class.
The class will be created with an automatically generated name. Rename the
class by changing its name in the Ontology Navigator.
4. Press Return.
The class will be renamed.
5. Edit the class.
The newly created class will be displayed in the Entity Properties panel. Here
we can now continue to specify the characteristics of the class.

31

Figure 6.2.3.2 creating a class for domain ontology

6.2.3.3 STEPS TO CREATE AN OBJECT PROPERTY
The following steps should be followed to create a object property.
1. Select ontology.
Select ontology in the Ontology Navigator.
2. Select the Object Properties folder.
Right-click the Object Properties folder and select "New Object Property" or
press CTRL-N.
3. Rename the object property.
The object property will be created with an automatically generated name.
Rename the object property by changing its name in the Ontology Navigator.
4. Press Return.
The object property will be renamed.
5. Edit the object property.
The newly created object property will be displayed in the Entity Properties
panel. We can now continue to specify the characteristics of the object property.
32

Figure 6.2.3.3 creating object property for domain ontology

6.2.3.4 STEPS TO CREATE A DATATYPE PROPERTY
The following steps should be followed to create data type property.
1. Select ontology.
Select ontology in the Ontology Navigator.
2. Select the Data Properties folder.
Right-click the Data Properties folder and select "New Data Property" or press
CTRL-N.
3. Rename the data type property.
The data type property will be created with an automatically generated name.
Rename the data type property by changing its name in the Ontology Navigator.
4. Press Return.
The data type property will be renamed.
5. Edit the data type property.
The newly created data type property will be displayed in the Entity
Properties panel.
33

Figure 6.2.3.4 creating datatype property for domain ontology

Figure 6.2.3.5 illustrates the domain ontolgy for airline service system.
This ontology represents the relationship and properties of reservation services.

Figure 6.2.3.5 creating domain ontology for airline service

34

DOMAIN ONTOLOGY FOR AIRLINE SERVICE:

The domain ontology can also be created with protg ontology editor. Using the
protg tool, the OntoGraf

of airline service is gathered together and a complete

relationship and properties of the system is created.

Figure 6.2.3.6 Domain Ontology

Steps to open an ontology in protg tool:

Click file
open and choose the path to load an ontology into protg tool.
Select OntoGraf tab and expand the owl file to view all classes and properties.
Finally, complete domain ontology for airline service is generated.

6.2.4 DISCOVERING A SERVICE

For discovering a service, ontology is created for an airline domain called a
domain ontology using NeOn tool. This NeOn tool is an extensible environment for
creating and editing ontologies. It is very easy-to-use graphical user interface. Therefore
the domain ontology is created with number of relationships and its properties.
USING SQARQL QUERY
35

Then the requested services are queried from the database using an SPARQL
query can make the collection look like one big database. SPARQL enables us to reap the
benefits of federation.

Figure 6.2.4 SPARQL Query

So that the requested service is queried in four matching methods. They are,
Exact Match
The exact match is the first phase (Subsumption Reasoning) of the service
matchmaking. In this phase, the strategy of an exact match is implemented. A tool is used
to perform (Subsumption Reasoning). Domain name and Service name will be given as
inputs for this phase. As a result, a list of N services is discovered in this phase.

Similarity Match
36

The similarity match is the second phase of the service matchmaking. In this
phase, the strategy of the similar match is implemented. Based on Input and Output
parameters, the services are matched using semantic matchmaking algorithm.
Constraint Reasoning
The constraint reasoning is the third phase of the service matchmaking.

constraint knowledge has been formalized using SWRL. Based on constraints like input
type, field and value the services are matched. A rule engine is used (eg.JESS) to perform
constraint reasoning.
Best-first reasoning
The strategy of the best first match is implemented to select the best one among
all candidate services that sufficiently match the required service.
After finding the exact matched services, the corresponding target namespace,
operation name, port type, url are fetched from uddi registry which are already published
and it is sent to the service client. Finally the execution of that service takes place.
6.3 TESTING
Testing is the major quality control measure employed during software
development. Its basic function is to detect the errors in the software. For this, different
levels of testing are used, which performs different tasks on the aim to test different
aspects of the system.
6.3.1 UNIT TESTING
In this testing we test each module individually. Unit testing focuses on the
verification of the smallest units of the software design the module. This is known as unit
testing. The modules of the system are tested separately. This test is carried out during
programming stage itself. Each module should work satisfactorily as regards to the
expected from the module. There are validation checks for the fields.

6.3.1.1 Unit testing for registration form

37

Table 6.3.1.1 Registration

Project Name : Semantic Web Ontology For Automated Web Services
Discovery in SOA System
Test Case :1

Test Type : Unit Test

Test unit : User

Registration Form
Test description : User Registration Form Validation

Test Id

Input

Test
Status

Action

Result

Msg:You
UF-1

UF-2

UF-3

Username=

have not
Invalid

typed

Pass

anything in

Username=2
54

username
Msg:only
Invalid

character in

Pass

username

Username=kart
hik

Valid

Msg:

Pass

Msg:Passwo
UF-4

Password=

Invalid

rd should not

Pass

be empty
Password=karth
ick
UF-5

Retype

Msg:passwo
Invalid

password=kart
UF-6

hik
Password=karth

rd does not

Pass

match
Valid

ik
Retype
38

Msg:

Pass

password=kart
hik

UF-7

UF-8

E-mail=

Email=karthi
kgmail.com

Invalid

Invalid

Msg: email
is empty
Msg:Enter
valid email

Pass

Pass

Email=karthi
UF-9

k@gmail.com

Valid

Msg:

Pass

UF-

PhoneNo=as

10

is

UF-

PhoneNo=87

11

98784545

UF-

PhoneNo=95

12

55512345

Msg;enter
Invalid

numeric

Pass

value
Msg:it
Invalid

should start

Pass

with 9
Valid

39

Msg:

Pass

Figure 6.3.1.1.1 Unit Testing for registration form1

Figure 6.3.1.1.2 Unit Testing for registration form2

40

Figure 6.3.1.1.3 Unit Testing for registration form3

6.3.1.2 Unit Testing for login form
Table 6.3.1.2 Login
Project Name : Semantic Web Ontology For Automated Web Services
Discovery in SOA System
Test Case :2

Test Type : Unit Test

Test unit :

Login Form
Test description : Login Form Validation

Test
Id
LF-1

Input
Username

Test Status

Action

Result

Invalid

Msg:userna

Pass

me should
not be
41

empty

LF-2

Username
= 234

Msg: only
Invalid

characters in

Pass

username

Username
LF-3

=karthick

Valid

Msg:

Pass

LF-4

LF-5

Password=

Password=
karthick

Msg:Passwo
Invalid

rd should not

Pass

be empty
Valid

Msg:

Figure 6.3.1.2.1 Unit Testing for login form1

42

Pass

Figure 6.3.1.2.2 Unit Testing for login form2

6.3.1.3 Unit Testing for Search Flights form

Table 6.3.1.3 Search Flights
Project Name : Semantic Web Ontology For Automated Web Services
Discovery in SOA System
Test Case :3

Test Type : Unit Test

Test unit :

Search Flights Form

Test description : Search Flights Form Validation
Msg: please
FS-1

From=

Invalid

select
FROM

43

Pass

FS-2

From=chen
nai

Valid

FS-3

To=

Invalid

FS-4

To=delhi

Valid

From=chen
FS-5

nai
To=chennai

FS-6

date=

Msg:please
select TO

Msg:

Pass

Pass

Pass

Msg:FROM
Invalid

is same as

Pass

TO

Departure

Msg:

Msg:depart
Invalid

ure date is

Pass

empty

Departure
FS-7

date=

Valid

Msg:

Pass

3/28/2013
Msg:select
FS-8

Class=

Invalid

one from

Pass

class
FS-9

Class=busines
s

Valid

Msg:

Pass

Msg:
FS-10

No.of.Passan
ger=

Invalid

no.of.passan
gers field is

Pass

empty
Msg: Enter
FS-11

No.of.Passan
ger=p

only
Invalid

numbers in
No.of.passan
gers field

44

Pass

FS-12

No.of.Passan
ger=5

Valid

Msg:

Figure 6.3.1.3.1 Unit Testing for Search Flights form1

45

Pass

Figure 6.3.1.3.2 Unit Testing for Search Flights form2

Figure 6.3.1.3.3 Unit Testing for Search Flights form3

46

6.3.1.4 Unit Testing for Passenger details form

Table 6.3.1.4 Passenger details
Project Name : Semantic Web Ontology For Automated Web Services
Discovery in SOA System
Test Case :4

Test Type : Unit Test

Test unit :

Passenger details Form

Test description : Passenger details Form Validation
Msg: First
TB-1

Firstname=

Invalid

name should
not be

Pass

empty
TB-2

Firstname=
karthik

Valid

Msg:

Pass

Msg: last
TB-3

Lastname=

Invalid

name should
not be

Pass

empty
TB-4

Lastname=
eg

Valid

TB-5

Age=

Invalid

TB-6

Age=22

Valid

47

Msg:

Msg:Enter
the age

Msg:

Pass

Pass

pass

Figure 6.3.1.4.1 Unit Testing for Passenger details form1

Figure 6.3.1.4.2 Unit Testing for Passenger details form2

48

Figure 6.3.1.4.3 Unit Testing for Passenger details form3

CHAPTER 7
CONCLUSION AND FUTURE ENHANCEMENT
7.1 CONCLUSION

49

How to give up the proper service description in UDDI and how to match
customer service request with service description, become the major challenges in Web
Service discovery. Development of Web Service matching model proposed in this work
uses semantic description and quality description of Web Service based on ontology as
the basis of service matching, and its matching algorithm is based on this logic that when
a notice can satisfy a request that ever functions provides request service. The service
matching method composed of four phases. In the first phase, the profile matcher, and in
the second phase, the semantic matcher, matching of services is done based on semantic,
and third and fourth involve constraint and best service match, based on the constraints
given by the service provider services are filtered out and finally best service is chosen
and given to service client. Using these descriptions and matching phases, the
performance of Web Service matching can be improved effectively.
7.2 FUTURE ENHANCEMENT
In future, fault tolerance can be implemented in the system and Quality of Service
is considered for further improvement of system for providing best service based on the
match making process.

CHAPTER 8
BIBLIOGRAPHY
8.1 BOOKS
Java 2: The Complete Reference, Fifth Edition by Herbert Schildt.
JSP: A Beginner's Guide (Beginner's Guides) by Gary Bollinger, second edition.
50

Service-oriented Architecture: Concepts, Technology, and Design by Thomas Erl.

8.2 REFERENCES
[1] Alexander Maedche and Steffen Staab,Ontology Learning for the Semantic Web,
Institute AIFB, D-76128 Karlsruhe, Germany.
[2] Alireza Zohali, Dr.Kamran Zamanifar, Matching Model For Semantic Web
Services Discovery,Dept. of Computer Engineering, Sama Technical&Vocational
Training School, Khorasgan Branch, Isfahan, Iran.
[3] Buhwan Jeong, Jungho Jang, Boonserm Kulvatunyou, Jaegyong Chang and
Hyunbo Cho,Discovering and integrating distributed manufacturing services with
semantic manufacturing capability profiles, Department of Industrial and
Management Engineering, Pohang University of Science and Technology
(POSTECH) San 31, Hyoja, Pohang, 790-784, South Korea.
[4] Fang-Fang Chua, Syahrul Amri Bin Ngazizan, and Musa Bin Hassan,Design and
Implementation of Airline Reservation Web Services Using Service-oriented
Architecture Proceedings of the World Congress on Engineering 2010 Vol I WCE
2010, June 30 - July 2, 2010, London, U.K.
[5] Hartwig Gunzer, Introduction to Web Services ,Borland, March 2002.
[6] Ian Horrocks, Peter F. Patel-Schneider, Sean Bechhofer, Dmitry Tsarkov, OWL
Rules: A Proposal And Prototype Implementation, February 28, 2005.
[7] Jos de Bruijn, Dieter Fensel, Uwe Keller Using the Web Service Modelling
Ontology to enable Semantic eBusiness Digital Enterprise Research Institute,
December 6, 2005.
[8] Jyotishman Pathak, Neeraj Koul, Doina Caragea,Vasant G Honavar, A
Framework for Semantic Web Services Discovery, Artificial Intelligence
Research Laboratory, Department of Computer Science, Iowa State University.
[9] Massimo Paolucci, Takahiro Kawamura, Terry R.Payne, Katia Sycara,Semantic
Matching of web services capabilities Carnegic Mellon University Pittsburgh,
PA, USA.
[10] Rohallah Benaboud, Ramdane Maamri, and Zadi Sahnoun, Semantic Web Service
Discovery Based on Agents and Ontologies, International Journal of Innovation,
Management and Technology, Vol. 3, No. 4, August 2012.
[11] Uwe Keller, Ruben Lara, Holger Lausen and Dieter Fensel Semantic Web Service
51

Discovery in the WSMO Framework,Digital Enterprise Research Institute (DERI),

Leopold-Franzens-Universitat Innsbruck, Austria.
[12] Zhonghua Yang, Robert Gay, Chunyan Miao, Jing-Bing Zhang, Zhiqi Shen an
Liqun Zhuang, and Hui Mien Leem, Automating Integration of Manufacturing
Systems and Services: A Semantic Web Services Approach, School of Electrical
and Electronics Engineering, Nanyang Technological University, Singapore
639798.
8.3 WEBSITES

www.ibm.com
www.roseindia.net
www.stackoverflow.com
www.wikipedia.org
http://www.w3.org/standards/semanticweb/
www.w3schools.com

52