A Project Report on

Semantic Web Service-Oriented Model for E-Commerce

Under the guidance of

Prof. Swati Ringe

Submitted by
Name

Roll No.

Shazia Ali
Kunal Thakur
Saras Joshi

5029
5036
5371

Certificate

This is to certify that Miss. Shazia Ali, Mr. Kunal Thakur

and Mr.Saras Joshi have completed their project report on
Semantic Web Service-Oriented Model For E-commerce
satisfactorily in partial fulfillment under the department of
ComputerEngineering during academic year 2010-2011.

_______________________________
_______________________________
Internal Guide
InternalExaminer

_______________________________
_______________________________
External Examiner

Head of
Department

________________________________
Principal

Submission date : November --------- , 2010

Acknowledgement

We would like to express our sincere thanks and gratitude to

our guide Mrs.Swati Ringe for her valuable guidance and
suggestions. We are highly indebted to her for providing us an
excellent opportunity to learn and present our studies in
theform of this project report.
We take this opportunity to thank the members of the teaching
and non-teaching staff of Fr.C.R.C.E.for the timely help
extended by them.Lastly thanking our parents for their morale
support andencouragement.

TABLE OF CONTENTS
Sr No.

Contents

Pg
No.

1.

Preface

2.

Introduction

2.1

Abstract

2.2

Problem Definition

2.3

Scope of Project

3.

Review Of Literature

3.1

Methods of implementing Ecommerce

3.2

Comparison of technologies

11

4.

Design

16

4.1

Diagrams

16

5.

Implementation

22

5.1

Architecture

22

5.2

Working

30

6.

Future Scope

31

7.

Conclusion

32

8.

References

33

1. Preface:
E-commerce on the internet provides a high level of flexibility and
openness, but it still has many drawbacks due to the heterogeneity of
the exchanged information. Web Services have added a new level of
functionality on top of current Web, enabling the use and combination
of distributed functional components within and across company
boundaries, but they offer only syntactical description that are hardly
amenable to automation. Developments in the field of Semantic Web
Services (SWS) show the opportunity of adding higher semantic levels
to the existing frameworks, to improve their usage and ease scalability.
In this paper, we outline a Semantic Web e-commerce in which data
sources and services are made available through SWS, described by
ontologies, allowing interoperability as well as reasoning to create a
comprehensive response adapted to user goals. We present a semantic
web service oriented model for e-commerce, aiming to integrate the
development of Semantic Web services using the OWL-S into JAVA
framework,it can also be applied to e-government.

2. Introduction:

2.1 Abstract:
Semantic Web shows great potentials in the e-commerce. A key word searching in current
online shopping is not only tedious and time-consuming but also often results in large
amounts of irrelevant information. Current Web services offer only an inflexible interface
with some human oriented metadata that describes what the service does, and which
Organization developed it. Web Services are typically intended for applications consumption,
in contrast with contemporary Web applications which are meant for human users. However,
the lack of machine readable semantics is hampering their usage in complex business
Environment. Semantic Web Services (SWS) come along and provide a solution with rich
formal descriptions of their capabilities, thus facilitating automated discovery, dynamic
binding, and invocation of services within an open environment, which can be utilized by
applications or other services without human assistance and immune to highly constrained
agreements on interfaces or protocols. According to a semantic specification in ontology, a
commercial infrastructure can be featured for a better communication between buyer and
seller. The rest of the documentation provide a general overview of semantic web serviceoriented model for e-commerce.

2.2 Problem Definition:

A SEMANTIC WEB-SERVICE-ORIENTED MODEL FOR ECOMMERCE

Create a E-commerce based website. (E-shop).

Include web services in the E-commerce based website which provides a mechanism
To connect applications regardless of the underlying software/hardware platform and
their location.
Commercial organizations can thus use web services technology to expose elements
of their business processes.
OWL-S provides a framework for the description of Semantic Web Servicesthat
enables seamless business integration through formal descriptions, maximal
decoupling of components and strong mediation support.
6

2.3 Scope Of Project:

A complete E-commerce-based website will be developed based on Semantic Web
Service-oriented model which will have following features:
Allow Customers to search Electronic devices of their choice(for ex:
mobile phones,laptop,T.V, music players etc).
Allow Customers to make payment through credit and debit cards.
Receive purchased product within 1 month of the purchased date.
Allow customers to make comparison of various products before
buying.
Sending Receipt through an e-mail to customer.
Generating monthly payment reports.
Customer management.
Products Management.

3. Review of Literature:
Ecommerce
The Internet and other new technologies (e.g. agent systems, mobile computing etc.) have
created a number of interesting and innovative ways to deliver value to the customer while
increasing the income potential of the merchant.The Web, as a place for e-commerce, brings
both advantages and challenges. While e-commerce has the same goal as any other form of
commerce, to maximize the amount of sold commodities and thus the generated income, it
differs from it in many respects.
(1)While the conventional stores carry only a limited supply of (typically most popular)
items, e-shops can offer an almost unlimited number of items, including specialty products
targeted for only relatively few customers. In particular, agglomerations of e-merchants (e.g.
www.totu.pl, www.amazon.com), acting as intermediaries between sellers and customers
generate a very large commodity search space (e.g. [MABA00], [VALE01]). This allows
customers to comparison-shop and select their favorite brand without leaving their chairs.
(2) By the same token, traditional store can reach mainly customers who live in the
neighborhood, whereas the e-store makes it possible to pursue global sales. In addition,
keeping a physical store open 24 hours a day is rather expensive (with nightly operation
generating only minimal income), while the computer system supporting e-commerce can run
non-stop with almost no overhead. These features generate a potential advantage for the emerchants.
(3) while the traditional commerce is limited by time and space, the Internet commerce is
characterized by an almost unlimited availability.
(4) An additional benefit of e-commerce is that it allows the seller a natural opportunity to
gather information about the behavioral patterns of visiting customers (including their
transaction records). There is a number of ways that such an information can be applied: (a)
to better meet individual customer expectations (resulting in the increased number of
transactions and thus in increased profits), (b) to study the behavior of the entire client
population (mining knowledge that can be then fed-back to the e-commerce support systems),
(c) to study the current market trends (e.g. to assure that fashionable commodities are
available to the clients), (d) to exchange information with (to sell it to) other businesses1 (as a
source of additional information applicable in own system and/or source of additional
income). The e-commerce system brings also about some challenges.
(5) While it is relatively easy to gather information, its amount may lead to an information
overload2. It is only processed information that can be useful to the user (merchant).
(6) When considering the case of an e-store, we notice a small paradox, which needs to be
appropriately addressed. On the one hand, it is easy to provide the potential customer with
more information about product(s) and service(s) that we try to sell (and large amount of such
8

information is also available in a multitude of additional, Internet based, repositories). On the

other hand, e-stores have to convince the customer to shop without the support of a human
(and without a physical contact with the merchandise)3. Therefore, it is important to develop
an environment such that when buyers make their purchasing decisions, they can feel like
being in a traditional small store.
In response to these opportunities and challenges, the development of successful e-commerce
initiatives requires creation of an appropriate infrastructure that will support the required
functionality. Such an infrastructure has to play two major roles. On one hand, it should help
the customer to purchase goods in the time frame in the way that he/she is inclined to do it.
On the other hand, it should help the merchant to maximize the total number of purchases
completed by her e-business, thus increasing her income. This infrastructure should provide
assistance by dealing with the vastness of the search space and offering recommendations
based on the knowledge of individual customers acquired, among others, through analysis of
their earlier/other purchases . We have 2 goals here. First, to present an overall infrastructure
of an e-commerce endeavor. Second, to discuss the required functionalities to satisfy the
client and support the merchant. While pursuing this goal, we have to make it clear, that we
are approaching this problem form the merchants perspective (the ultimate goal of the
system being profit maximization). Here, the maximization of profits is achieved through the
satisfaction of clients needs, and in this way increasing the likelihood of client purchasing
goods.
The e-commerce system can be described in a number of ways. We have decided to proceed
with the functional decomposition first, as it gives us a natural way of presenting the highest
level of abstraction of the system design. At this level of detail we have combined some more
specific functions into joint units, which will have to be concretized during the system
development process. The summary of the system functional decomposition is presented in
Figure (all of the references in the form block n below refer to this figure). We will
proceed first, to describe the customer part of the system and follow with the description of
the sales-and-supply-related functionalities. Finally, in the next section, we discuss the ecommerce infrastructure necessary to support it. E-COMMERCE SYSTEM Customer
System (CS) Supply System (SS) WEB communication channel environment. When the
customer is ready to complete a transaction, the transaction module will process her order and
when the interaction with the system is completed (regardless if transactions took place or
not), information of the session is sent to the cleaner agent, which prepares the data to be
stored in the customer database. At the same time, the transaction information is sent to the
commodity database. Both these databases store the current data about commodities,
transactions and customer behavior. This data is analyzed and the results are sent to the
supply module, as well as the expert system responsible for the sale strategy generation. As
the data in the customer and commodity databases becomes old, it is then send to the data
warehouse where it is further analyzed in search for long-term trends and rules for the expert
systems. Results from mining of the data warehouse are then sent to the supply module,
where they are combined with the market scouting reports and participate in supply chain
management and business partner selection. Finally, the system-manager exchange module is
responsible for the interactions between the managers and the system.

Methods used to Implement Ecommerce.

EContemporary component model development is getting more and more important in an
industrial world. But there are many divergences between industrial view and academical
view on component model. Large companies implement theirs component models directly
and pushes users to use as-is. On the other hand academic world is spending long time
9

on development and tenement of theirs component models, and rarely they implement it
and with pure support and development environment.
We use a component and architectural model of the EJB .A key idea is to introduce Enterprise
Object Adapter (EOA), that control lifecycle and service employment of the component
types. This approach is seamlessly incorporated into current EJB specification with respect to
backward compatibility and functionality. Thismodel will be tuned and implemented as a part
of project.
Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular
construction of enterprise applications .The EJB specification is one of several Java APIs in
the Java EE specification. EJB is a server-side model that encapsulates the business logic of
an application. The EJB specification was originally developed in 1997 by IBM and later
adopted by Sun Microsystems (EJB 1.0 and 1.1) in 1999and enhanced under the Java
Community Process as JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0) and JSR 318
(EJB 3.1).
The EJB specification intends to provide a standard way to implement the back-end 'business'
code typically found in enterprise applications (as opposed to 'front-end' interface code). Such
code was frequently found to address the same types of problems, and it was found that
solutions to these problems are often repeatedly re-implemented by programmers. Enterprise
JavaBeans were intended to handle such common concerns as persistence, transactional
integrity, and security in a standard way, leaving programmers free to concentrate on the
particular problem at hand.
Accordingly, the EJB specification details how an application server provides:

Transaction processing

Integration with the Persistence services offered by the Java Persistence API (JPA)

Concurrency control

Events using Java Message Service

Naming and directory services (JNDI)

Security (Java Cryptography Extension (JCE) and JAAS)

Deployment of software components in an application server

Remote procedure calls using RMI-IIOP.

Exposing business methods as Web Services.

10

Additionally, the Enterprise JavaBean specification defines the roles played by the EJB
container and the EJBs as well as how to deploy the EJBs in a container. Note that the current
EJB specification does not detail anymore how an application server provides persistence (a
task delegated to the JPA specification), but instead details how business logic can easily
integrate with the persistence services offered by the application server.
An ontology defines a common vocabulary for researchers who need to share information in
a domain. It includes machine-interpretable definitions of basic concepts in the domain and
relations among them. We use ontologies because
To share common understanding of the structure of information among people or
software agents
To enable reuse of domain knowledge
To make domain assumptions explicit
To separate domain knowledge from the operational knowledge
To analyze domain knowledge
In practical terms, developing an ontology includes:
defining classes in the ontology,
arranging the classes in a taxonomic (subclasssuperclass) hierarchy,
defining slots and describing allowed values for these slots,
filling in the values for slots for instances.
We can then create a knowledge base by defining individual instances of these classes filling
in specific slot value information and additional slot restrictions.
There is no single correct ontology for any domain. Ontology design is a creative
process and no two ontologies designed by different people would be the same. The potential
applications of the ontology and the designers understanding and view of the domain will
undoubtedly affect ontology design choices. The proof is in the puddingwe can assess
the quality of our ontology only by using it in applications for which we designed it.
Inconsistency and incompleteness are important problems that affect the Semantic Web
therefore ontology mapping systems that operate in this environment should have the
appropriate mechanisms to cope with these issues. Mapping ontologies with high precision
on the Semantic Web is a challenging problem that needs to be addressed in various domains.
One of the main problems with any mapping process, which needs to be applied on different
domains is that it always has a certain degree of uncertainty associated with it. In this paper
we introduce a method based on Dempster-Shafer theory that use uncertain reasoning over
the possible mappings in order to select the best possible mapping without using any heuristic
or domain specific rules.
OWLS V/S WSMO:

Features
Goals

WSMO

OWL-S

Actual goal, specific

application
Domains.

11

Without
explicit goal,
does not focus
on
concrete
application

domains.
Principles

based on the
conceptual work
done in WSMF.

Discovery

Web Services
(capability),goal.

Compositio
n

Orchestration +
choreography.

Invocation

Grounding+WSDL/S
OAP.

Vague,
development
based set of
tasks to be
Solved.
Profile.

Process
Model.
Grounding+WSDL/S
OAP.

WSDL:
Introduction: the need for adding semantics to WSDL
Web services have primarily been designed for providing inter-operability between business
applications. Current technologies assume a large amount of human interaction, for
integrating two applications. This is primarily due to the fact that business process integration
requires understanding of data and functions of the involved entities. Semantic Web
technologies, powered by description logic based languages like OWL[1], aim to add greater
meaning to Web content, by annotating the data with ontologies. Ontologies provide a
mechanism of providing shared conceptualizations of domains. This allows agents to get an
understanding of users Web content and greatly reduces human interaction for meaningful
Web searches. A similar approach can be used for adding greater meaning to Web service
descriptions, which will in turn, allow greater automation, by reducing human involvement
for understanding the data and functions of the services,
Several standards have been proposed for creating semantic Web services. Primarily, OWLS[2][8], WSMO[3] and METEOR-S [4] have proposed various solutions for creating for
expressive descriptions for Web services. In this draft, we present WSDL-S, a lightweight
approach for adding semantics to Web services. This draft is based on the ongoing METEOR12

S project, LSDIS Lab, University of Georgia, which aims to add semantics to the complete
lifecycle of Web processes.
Section 2 outlines WSDL and how semantics can further enhance it. Section 3 discusses on
adding semantics to web services. Section 4 describes the WSDL-S Meta-Model while
Section 5 explains a step-by-step approach of adding semantics. Appendices provide further
details and corroborating information. Appendix I shows an example WSDL-S file while an
example of corresponding annotated source code is provided in Appendix II. Appendix III
details the interim step between WSDL and WSDL-S. Appendix IV lists the tools that are
being built under METEOR-S to support WSDL-S while Appendix V shows the WSDL-S
support in METEOR-S
.
2. WSDL
The WSDL specification began with WSDL 1.0 in 2000. This was quickly followed by
WSDL 1.1[5] which has
been used in many Web service tools. A effort to enhance it, WSDL 1.2, has been renamed
WSDL 2.0[6], as it includes some major changes. Draft releases of the WSDL 2.0 standard
have been available since March of 2004 and are expected to become W3C recommendation
in 2005.
A central purpose of WSDL is to describe interfaces (formerly known as port-types) to Web
services. Actual Web services may then be viewed as remote implementations of these of
interfaces. In general, service providers/implementers could use a standard interface, extend a
standard interface or develop there own.
Broadly speaking, an interface contains a set of operations. Each operation has a signature
which includes an operation name, input, output and exception messages. These messages
have types that are defined using some XML-based schema language. The schema language
that is commonly used is XSD[7], although OWL is an alternative. In WSDL 2.0, types are
pushed more completely outside the standard. This makes sense on the onehand, since types
systems are complex to define and there exist at least two well-accepted type systems in the
XML world: XSD and OWL. On the other, this makes it difficult for WSDL interfaces to be
first-class citizens (i.e., types) which they would be under an object-oriented approach.
A client of a Web service will look to the interface to find out what it will do. Indeed,
interface descriptions may be used to find candidate Web services. Such descriptions are
therefore critical to proper discovery and use of Web services. Hence, adding semantics to
interfaces is very important. To illustrate this idea, more semantics is added to Web service
interface in a step by step fashion. Note, the examples are based on Java source for brevity.
1. Minimal semantics.
interface Interface1WS
{
String operation1 (String param);
String operation2 (String param);
} // Interface1WS
2. Use meaningful argument names and more specific types.
interface BookWS
{
double getPrice (String isbn, String title, int year)
boolean buy (String ISBN);
} // BookWS
13

3. Require types to be from (or extend) standard libraries. Upcast to existing types is
automatic, while one must supply a method for downcast. For language independence, these
types need to be standardized for an XML based schema language, such as XSD or OWL.
Conversion from one type system (XSD, OWL and Java) to another is currently an open
problem.
import BookTypes.*;
interface BookWS
{
double getPrice (BookID isbn, BookTitle title, Date year)
boolean buy (BookID ISBN);
} //BookWS
4. Add Design-By-Contract (nominally pre and post conditions)
import BookTypes.*;
interface BookWS
{
@post (return > 0.0);
double getPrice (BookID isbn, BookTitle title, Date year);
@pre (isbn != null);
boolean buy (BookID isbn);
} //BookWS
3. Adding Semantics to Web services
The OWL-S (formerly DAML-S) project defines an ontology for the domain of Web
services. This ontology provides tags which can be used for describing actual Web services.
The ontology consists of three sub ontologies, service profile, service grounding and the
process model, which are tied together using a service ontology. The service profile defines
the functional and non-functional properties of the services. Service grounding contains
information about invocation. In an effort to align with industry standards, service grounding
provides mapping OWL atomic processes to WSDL operations. The process model describes
the ordering of the operations of the service.
Due to the late alignment of OWL-S to WSDL, the design of OWL-S may be unnecessary
complex. WSDL-S aims to provide a lightweight approach for creating semantic Web service
descriptions. We call our approach lightweight because:
We provide simple extensions to WSDL to add semantics, thereby allowing semantic
descriptions of Web services.
We have designed the WSDL-S service ontology, which is more aligned with WSDL 2.0
and more compact than OWL-S, without losing significant expressivity. In particular,
we were not convinced on separating the service grounding from the service profile.
An important feature of our approach is that we automatically populate our ontology
from WSDL 2.0 descriptions. We view our ontology as an intermediate entity and
plan to shield the users from interacting with it.
Our approach allows integration of semantic and non semantic descriptions of Web
services, as users using special types must specify translation to OWL
4. WSDL-S Meta Model
In this section, we present a meta-model for WSDL 2.0. Our extensions have been shown in
red and green. In near future, we will present further refinements to this metamodel and an
approach to represent the process model.
14

The tags in red are our proposed extensions. We explain them in detail in the next section.
WSDL 2.0 draft already discusses using different type systems for Web services. We have
shown OWL and XMI as possible type systems, along with XSD in the meta-model. Since
WSDL 2.0 partially supports this, we have shown them in green. We are still investigating
efficient ways for transforming from one type system to the other.
5. Adding Semantics: Step by step
In this section, we will explain our approach of adding semantics to WSDL 2.0.
5.1. Referencing Ontologies in WSDL-S
We present examples using an ontology based on the Rosetta net PIP directory. An initial
draft on the ontology is available at http://webster.cs.uga.edu/~azami/pips.owl. We use the
namespace feature of WSDL to reference classes and properties from this ontology. Below,
we show an example of creating the namespace rosetta for the Rosetta Net ontology.
<definitions
.
.
xmlns:rosetta = http://webster.cs.uga.edu/~azami/pips.owl# />

5.2. Adding semantics to operations

In WSDL 2.0, each interface consists of a number of operations. Each operation can be seen
as a unit of functionality of the service. It is imperative to capture the functionality of the
each operation. In order to illustrate our extensions, let us consider an operation which allows
users to cancel an order. WSDL 2.0 fragment for this particular operation is shown below.
<operation name = "checkStatus" pattern="mep:in-out" >
<action element = "rosetta:QueryOrderStatus />
<input messageLabel = statusQuery element = "xsd:PurchaseOrderStatusQuery" />
<output messageLabel = status element = "xsd:PurchaseOrderStatusResponse" />
</operation>
In this section, we show the corresponding WSDL-S representation for the above fragment. A
complete WSDL-S interface is shown in Appendix I. We have used extensibility of WSDL
2.0 to add two child (shown in red) tags to the operation tag. They are:

15

1. Action tag depicts the action the operation performs. This operation which allows a
client to cancel an order, is depicted using PIP 3A9 Request Purchase Order
Cancellation. We use the action tag to point to the corresponding class in the Rosetta
Net ontology.
2. Constraint tag is used to depict pre and post conditions. In this case the
confirmation number must be greater than zero for the operation to be executed. So it
is depicted using the pre tag.
<operation name = "checkStatus" pattern="mep:in-out" >
<action element = "rosetta:QueryOrderStatus />
<input messageLabel = statusQuery element = "rosetta:PurchaseOrderStatusQuery" />
<output messageLabel = status element = "rosetta:PurchaseOrderStatusResponse" />
<pre condition=PurchaseOrderStatusQuery.orderStatusDoc.?PurchaseOrder !=null />
</operation>
In addition, we depict the inputs and outputs using OWL types (shown in bold) from the
Rosetta Net ontology instead on XML schema types (XSD).

4.Design:
4.1 Diagrams:
1)Use-Case Diagram:

16

2)Sequence Diagram:

17

3)Collabration Diagram:
18

4)Database(Ontology) Diagram:
19

5)GUI-Login Page:
20

6)GUI-Registration Page:

7)GUI-Payment Page:
21

5.Implementation:
5.1 Architecture:

22

E-commerce Website: Electronic Virtual Shop

Platform for website: JAVA(jsp,servlets)
Server: GlassFish 3
Platform for web services: Java
Other platforms: EJB, Ontology, jena framework, glassfish.
E-shop web site consists of electronic devices like
Mobiles,Laptops,T.V, Music Players etc.
Customer can shop any device of his choice.
5 web services will be created for ex:
1. searching.
2. payment.
3. comparison of devices etc.
All the java web services will be created in wsdl.
All the created wsdl web services will be registered to
juddi.

Javascript:

JavaScript is an implementation of the ECMAScript language standard and is typically used

to enable programmatic access to computational objects within a host environment. It can be
characterized as a prototype-based object-oriented scripting language that is dynamic, weakly
23

typed and has first-class functions. It is also considered a functional programming language
like Scheme and OCaml because it has closures and supports higher-order functions.
JavaScript is primarily used in the form of client-side JavaScript, implemented as part of a
web browser in order to provide enhanced user interfaces and dynamic websites. However, its
use in applications outside web pages is also significant.
JavaScript uses syntax influenced by that of C. JavaScript copies many names and naming
conventions from Java, but the two languages are otherwise unrelated and have very different
semantics. The key design principles within JavaScript are taken from the Self and Scheme
programming languages.

Servlets:

A Servlet is a Java class in Java EE that conforms to the Java Servlet API, a protocol by
which a Java class may respond to HTTP requests. Thus, a software developer may use a
servlet to add dynamic content to a Web server using the Java platform. The generated
content is commonly HTML, but may be other data such as XML. Servlets are the Java
counterpart to non-Java dynamic Web content technologies such as CGI and ASP.NET.
Servlets can maintain state in session variables across many server transactions by using
HTTP cookies, or URL rewriting.
The servlet API, contained in the Java package hierarchy javax.servlet, defines the
expected interactions of a Web container and a servlet. A Web container is essentially the
component of a Web server that interacts with the servlets. The Web container is responsible
for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring
that the URL requester has the correct access rights.
A Servlet is an object that receives a request and generates a response based on that request.
The basic servlet package defines Java objects to represent servlet requests and responses, as
well as objects to reflect the servlet's configuration parameters and execution environment.
The package javax.servlet.http defines HTTP-specific subclasses of the generic servlet
elements, including session management objects that track multiple requests and responses
between the Web server and a client. Servlets may be packaged in a WAR file as a Web
application.
Servlets can be generated automatically from JavaServer Pages (JSP) by the JavaServer
Pages compiler. The difference between Servlets and JSP is that Servlets typically embed
HTML inside Java code, while JSPs embed Java code in HTML. While the direct usage of
Servlets to generate HTML (as shown in the example below) is relatively rare nowadays, the
higher level MVC web framework in Java EE (JSF) still explicitly uses the Servlet
24

technology for the low level request/response handling via the FacesServlet. A somewhat
older usage is to use servlets in conjunction with JSPs in a pattern called "Model 2", which is
a flavour of the model-view-controller pattern.

Why JSP?

JSP pages perform with no issues on any platform .

They can be accessed from any web server.

JSP technology emphasizes on reusing the components that helps

to develop more purposeful page designs.

The features portability, reusability and logic components of java

language can be utilized across platforms.
Memory management and exception management is optimized.
Provide a large range of API to increase the result oriented
functionality
Easily deployable and performance is robust on multiple requests.

Why Java?

Write Once, Run Anywhere

Security
Network-centric Programming
Dynamic, Extensible Programs
Internationalization
Performance
Programmer Efficiency and Time-to-Market

What is an Ontology?

An ontology is a specification of a conceptualization that is designed

for reuse across multiple applications and implementations. a
specification of a conceptualization is a written, formal description of
a set of concepts and relationships in a domain of interest.
An ontology defines a common vocabulary for researchers who need
to share information in a domain. It includes machine-interpretable

25

definitions of basic concepts in the domain and relations among

them.
In practical terms, developing an ontology includes:
defining classes in the ontology,
arranging the
hierarchy,

classes

in

taxonomic

(subclasssuperclass)

defining slots and describing allowed values for these slots,

filling in the values for slots for instances.

Why we want to develop an ontology?

To share common understanding of the structure of information

among people or software agents.
To enable reuse of domain knowledge.
To make domain assumptions explicit.
To separate domain knowledge from the operational knowledge.
To analyze domain knowledge.

Packages to be used for Implementation:

Jena-2.5.6
ARQ-2.8.5
Owl-s-1.1.0-beta
Pellet-1.3

Jena Framework:
Jena is a Java framework for building Semantic Web applications. It
provides a programmatic environment for RDF, RDFS and OWL,
SPARQL and includes a rule-based inference engine.
Jena is open source and grown out of work with the HP Labs
Semantic Web Programme.
The Jena Framework includes:
A RDF API
26

Reading and writing RDF in RDF/XML, N3 and N-Triples

An OWL API
In-memory and persistent storage
SPARQL query engine.

ARQ:
ARQ is a query engine for Jena that supports the SPARQL RDF Query
language. SPARQL is the query language developed by the W3C RDF
Data Access Working Group.
ARQ Features:
Standard SPARQL
Free text search via Lucene
SPARQL/Update
Access and extension of the SPARQL algebra
Support for custom filter functions
Property functions for custom processing of semantic relationships
Aggregation, GROUP BY and assignment as SPARQL extensions
Support for federated query
Support for extension to other storage systems
Client-support for remote access to any SPARQL endpoint
OWL-S:
OWL-S is an ontology built on top of Web Ontology Language (OWL)
by the DARPA DAML program. It replaces the former DAML-S
ontology. "OWL-S is an ontology, within the OWL-based framework
of the Semantic Web, for describing Semantic Web Services. It will
enable users and software agents to automatically discover, invoke,
compose, and monitor Web resources offering services, under
specified constraints.
Development of OWL-S aims to enable the following tasks:
Automatic Web service discovery: with the development of the
Semantic Web, many Web Services will be available on the Web,
performing the most various tasks. OWL-S will help software agents
to discover the Web Service that would fulfill a specific need within
some quality constraints, without the need for human intervention.
Automatic Web service invocation: it is necessary to write a specific
program to invoke a Web Service, using its WSDL description. OWL-S
will open the possibility for a software agent to automatically read
the description of the Web Service's inputs and outputs and invoke
the service.

27

 Pellet Reasoner:
Pellet is an open-source Java based OWL DL reasoner. It can be used
in conjunction with both Jena and OWL API libraries and also
provides a DIG interface.Pellet API which provides functionalities to
see the species validation, check consistency of ontologies, classify
the taxonomy, check entailments and answer a subset of RDQL
queries (known as ABox queries in DL terminology).
Pellet is an OWL DL reasoner based on the tableaux algorithms
developed for expressive Description Logics. It supports the full
expressivity OWL DL including reasoning about nominals
(enumerated classes). Therefore, OWL constructs owl:oneOf and
owl:hasValue can be used freely. Currently, Pellet is the first and only
sound and complete DL reasoner that can handle this expressivity.
Pellet ensures soundness and completeness by incorporating the
recently developed decision procedure for SHOIQ (the expressivity
of OWL-DL plus qualified cardinality restrictions in DL terminology).
Ontology analysis and repair OWL has two major dialects, OWL
DL and OWL Full, with OWL DL being a subset of OWL Full. All OWL
knowledge bases are encoded as RDF/XML graphs. OWL DL imposes
a number of restrictions on RDF graphs, some of which are
substantial (e.g., that the set of class names and individual names
be disjoint) and some less so (that every item have a rdf:type
triple). Ensuring that an RDF/XML document meets all the
restrictions is a relatively difficult task for authors, and many
existing OWL documents are nominally OWL Full, even though their
authors intend for them to be OWL DL. Pellet incorporates a number
of heuristics to detect "DLizable" OWL Full documents "repair"
them. Species Validation Here is a write-up by one of the Pellet
programmers that explains how we process an OWL file for species
validation.
Entailment In Semantic Web, entailment is the key inference
whereas the Description Logic community have focused on
satisfiability and subsumption. While entailment can be reduced to
satisfiability, most DL systems do not support it. In part to pass a
large portion of the OWL test suite, we implemented entailment
support in Pellet.
Conjunctive ABox query Query answering is yet another
important feature for Semantic Web. We have implemented an ABox
query answering module in Pellet using "rolling-up'' technique. We
have devised algorithms to optimize the query answering by
changing how likely candidates for variables are found and tried.
28

Exploiting the dependencies between different variable bindings

helps us to reduce the total number of satisfiability tests thus
speeding up the answer significantly.
Datatype Reasoning XML Schema has a rich set of basic
datatypes including various numeric types (integers and floats),
strings, and date/time types. It also has several mechanism, both
standard and unusual for creating new types out of the base types.
For example, it's possible to define a datatype by restricting the
integers to the set of integers whose canonical representation has
only 10 digits, or whose string representation matches a certain
regular expression. Currently, XML Schema systems tend toward
validation of documents and generation of PSVI instead of type
checking (though, with the advent of XQuery, this might change).
Pellet can test the satisfiability of conjunctions of thus constructed
datatypes.
User-defined Simple Datatypes The main problem of having
user-defined datatypes is how to define URI's for XML Schema
definitions. SWBPD working group at W3C discusses the problem
and several different solutions in detail. In Pellet, we adopt the
DAML+OIL solution which says a datatype URI is constructed from
the URI of the XML schema document and the local name of the
simple type. We parse the XML schema document from the given
URI and locate the type using name attribute of the definitions.
Example ontology that refers to the datatype descriptions in the
XML schema document.
Multi-Ontology Reasoning using E-Connections An EConnection is a knowledge representation language defined as a
combination of other logical formalisms. We use E-Connections as a
language for defining and instantiating combinations of OWL-DL
ontologies, i.e. as a way of combining KBs, rather than logics. This
approach provide an alternative to owl:imports will always bring all
the axioms from the imported ontology, lets us to identify sub-parts
of an ontology and gives a well-founded logical framework for
reasoning with multiple ontologies.Pellet provides support for
reasoning with E-connected ontologies through both Jena and OWLAPI interfaces.
Ontology Debugging Detection of unsatisfiable concepts in an
ontology is a straright-forward task. However, the diagnosis and
resolution of the bug is generally not supported at all. For example,
29

no explanation is given as to why the error occurs (e.g., by

pinpointing the root clash, or axioms in the ontology responsible for
the clash) or how dependencies between classes cause the error to
propagate (i.e., by distinguishing root from derived unsatisfiable
classes). Pellet, provides support for both kinds of tasks by
pinpointing axioms that cause an inconsistency and the relation
between unsatisfiable concepts.

Softwares to be used for Implementation:

Netbeans 6.9.1
Protg 4.0.2
Graphviz 2.26.3

Netbeans:
NetBeans refers to both a platform framework for Java desktop
applications, and an integrated development environment (IDE) for
developing with Java, JavaScript, PHP, Python, Ruby, Groovy, C, C+
+, and others.
The NetBeans IDE is written in Java and runs everywhere where a
JVM is installed, including Windows, Mac OS, Linux, and Solaris. A
JDK is required for Java development functionality, but is not
required for development in other programming languages.
The NetBeans Platform allows applications to be developed from a
set of modular software components called modules. Applications
based on the NetBeans platform (including the NetBeans IDE) can
be extended by third party developers.
Benefits of Netbeans:

Extensible and easy modular design

Vast API of commonly used tasks
Easy to design Swing GUI using Netbeans IDE
Pre-defined update center and automatic update notification

30

 Protg:
Protg is a free, open source ontology editor and knowledge-base
framework.The Protg platform supports two main ways of
modeling ontologies via the Protg-Frames and Protg-OWL
editors. Protg ontologies can be exported into a variety of formats
including RDF(S), OWL, and XML Schema.
Protg is based on Java, is extensible, and provides a plug-and-play
environment that makes it a flexible base for rapid prototyping and
application development.
One of the most well known advantages of Protg is its plug-ability.
Graphviz:
Graphviz (short for Graph Visualization Software) is a package of
open source tools initiated by AT&T Research Labs for drawing
graphs specified in DOT language scripts. It also provides
libraries for software applications to use the tools.
Graphviz consists of a graph description language named the
DOT language and a set of tools that can generate and/or
process DOT files:
dot a command-line tool to lay out directed graphs into a variety
of output formats (PostScript, PDF, SVG, annotated text and so
on). neato for "spring model" layout (in Mac OS version called
"energy minimised") twopi for radial graph layouts. circo for
circular graph layouts. fdp another layout engine for undirected
graphs. dotty a graphical user interface to visualize and edit
graphs. lefty a programmable (in a language inspired by EZ)
widget that displays DOT graphs and allows the user to perform
actions on them with the mouse. Lefty can therefore be used as
the view in a model-view-controller GUI application that uses
graphs.
Working Of the Project:

Customer will open the web-site.

Customer can register, login etc.
If customer decides to search, compare etc then
respective web services will be called.
Java agent will search related information in the
ontology.

31

After retrieving information from ontology, java agent

will called requested web service from the java web
services created in WSDL.
Get the results in Java agent.
Display the results received by java agent in terms of
GUI/JSP page.

6. Future Scope:
Our Semantic web service-oriented web site will answer the following
future requirements like:
Web compliance
Ontology-based
32

 Strict decoupling
Centrality of mediation
Ontological role separation
Description vs. implementation
Execution semantics
Service vs. Web service

7. Conclusion:
Web services provide a mechanism to connect applications
regardless of the underlying software/hardware platform and their location
.Commercial organizations can thus use web services technology to
expose elements of their business processes. Semantic Web Services
enable the formal specification of services, allowing their automated, goal33

driven, location and usage. OWL-S provides a framework for the

description of Semantic Web Services that enables seamless business
integration through formal descriptions, maximal decoupling of
components and strong mediation support. In this work, we propose
an e-commerce model and make an attempt to integrate the development
of Semantic Web services using the OWL-S into Java framework. This
model can also betaken into e-government consideration.

8.References:
[1] Mitra, N., SOAP Version 1.2 Part 0: Primer, W3C
34

Recommendation,
http://www.w3.org/TR/soap12-part0/, 2003
[2] UDDI Consortium, UDDI Specification,
http://www.uddi.org/specification.html, 2000
[3] Christensen, E., Curbera, F., Meredith, G.,
Weerawarana, S., Web Services Description
Language (WSDL) 1.1, W3C Note 15 March 2001,
http://www.w3.org/TR/2001/NOTE-wsdl-20010315
[4] Cabral L., Domingue J., Motta E., Payne T.,
Hakimpour F., Approaches to Semantic Web
Services: An Overview and Comparisons, Lecture
Notes in Computer Science, Vol.3053, pp.225-239,
2004.
[5] Antoniou, G. and van Harmelen, F., A Semantic
Web Primer, Cambridge, Ma: The MIT Press, 2004
[6] Passin, T. B., Explorer's Guide to the Semantic
Web. Greenwich, CT: Manning Publications
Co. ,2004
[7] Singh, M. P. , Introduction to web semantics, The
Practical Handbook of Internet Computing,
pp29-1-29-13, Chapman & Hall/CRC2005, 2005
[8] Martin, D., Burstein, M., Hobbs, J., Lassila, O.,
McDermott, McIlraith, S., Narayanan, S., Paolucci,
P.,Parsia,B.,Payne,T.,Sirin,E.,Srin ,E.,Sirnivasan,N.,
Sycara,K., OWL-S Semantic Markup for Web
Service, http://www.w3.org/Submission/OWL-S/,2003
[9] McGuinness, D., and Harmelen, F. D., Owl Web
Ontology Language Overview,
http://www.w3.org/TR/owl-features/,2004
[10] Lausen H.,Polleres A.,RomanD., Web Service
Modeling Ontology
(WSMO)Http://www.w3.org/Submission/WSMO/,
2005
[11] Domingue, J.; Cabral, L.; Hakimpour, F.; Sell D.;
Motta, E., IRS III: A Platform and Infrastructure for
Creating WSMO-based Semantic Web Services.
Proceedings of the Workshop on WSMO
Implementations Frankfurt, Germany, September
29-30, 2004, CEUR Workshop Proceedings, ISSN
1613-0073..
[12]Sun Microsystems \JavaBeans" http://java.sun.com/beans
[13] Sun Microsystems \Java Messaging System" http://java.sun.com/jms
[14] G. Kiszales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.M. Loing, J. Irwin,
\Aspect-Oriented Programming", Xerox Palo Alto Res
ea.

[15] Brickley, D. and Guha, R.V. 1999. RDF Schema Specification

(draft). W3C (World Wide Web Consortium). At
35

http://www.w3.org/TR/1999/PR-rdf-schema-19990303.html.
[16] Farquhar, A.; Fikes, R.; and Rice, J. 1997. Tools for
Assembling Modular Ontologies in Ontolingua. In Proceedings
of the Fourteenth National Conference on Artificial Intelligence
(AAAI-97), 436-441. Menlo Park, CA: AAAI Press.
[17] Fensel, D.; Decker, S.; Erdmann, M.; and Studer, R. 1998.
Ontobroker: How to enable intelligent access to the WWW. In
AI and Information Integration, Technical Report WS-98-14,
36-42. Menlo Park, CA: AAAI Press.
[18] Foo, N. 1995. Ontology Revision. In Conceptual Structures;
Third International Conference, 16-31. Berlin: Springer-Verlag.
[19] Guarino, N. and Giaretta, P. 1995. Ontologies and Knowledge
Bases: Towards a Terminological Clarification. In N. Mars (ed.)
Towards Very Large Knowledge Bases: Knowledge Building
and Knowledge Sharing, 25-32. Amsterdam: IOS Press.

36