Project Report

A Project Report on Semantic Web Service-Oriented Model for E-Commerce Under the guidance of Prof. Swati Ringe Submitted by NameRoll No.Shazia Ali5029Kunal Thakur5036Saras Joshi5371 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.ContentsPg No.1.Preface52.Introduction62.1Abstract62.2Problem Definition62.3Scope of Project63.Review Of Literature73.1Methods of implementing Ecommerce93.2Comparison of technologies114.Design164.1Diagrams165.Implementation225.1Architecture225.2Working306.Future Scope317.Conclusion328.References33 ,[object Object],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. ,[object Object],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 service-oriented model for e-commerce. 2.2 Problem Definition: A SEMANTIC WEB-SERVICE-ORIENTED MODEL FOR ECOMMERCE ,[object Object]

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.2.3 Scope Of Project: ,[object Object]

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.

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 e-merchants. (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 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 e-commerce 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 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. 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 ,[object Object]

To enable reuse of domain knowledge

To make domain assumptions explicit

To separate domain knowledge from the operational knowledge

To analyze domain knowledgeIn practical terms, developing an ontology includes: ,[object Object]

arranging the classes in a taxonomic (subclass–superclass) 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 designer’s understanding and view of the domain will undoubtedly affect ontology design choices. “The proof is in the pudding”—we 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. ,[object Object]

FeaturesWSMOOWL-SGoalsActual goal, specific applicationDomains. Without explicit goal, does not focus onconcrete application domains. Principlesbased on the conceptual work done in WSMF.Vague, development based set of tasks to beSolved. DiscoveryWeb Services (capability),goal. Profile.CompositionOrchestration + choreography. Process Model. InvocationGrounding+WSDL/SOAP. Grounding+WSDL/SOAP.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, OWL-S[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 METEOR-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 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 meta–model and an approach to represent the process model. 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 = quot;
checkStatusquot;
pattern=quot;
mep:in-outquot;
> <action element = quot;
rosetta:QueryOrderStatus” /> <input messageLabel = ”statusQuery” element = quot;
xsd:PurchaseOrderStatusQueryquot;
/> <output messageLabel = ”status” element = quot;
xsd:PurchaseOrderStatusResponsequot;
/> </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: 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 = quot;
checkStatusquot;
pattern=quot;
mep:in-outquot;
> <action element = quot;
rosetta:QueryOrderStatus” /> <input messageLabel = ”statusQuery” element = quot;
rosetta:PurchaseOrderStatusQueryquot;
/> <output messageLabel = ”status” element = quot;
rosetta:PurchaseOrderStatusResponsequot;
/> <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: 2)Sequence Diagram: 3)Collabration Diagram: 4)Database(Ontology) Diagram: 5)GUI-Login Page: 6)GUI-Registration Page: 7)GUI-Payment Page: 5.Implementation: 5.1 Architecture: ,[object Object]

Platform for website: JAVA(jsp,servlets)

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:

All the java web services will be created in wsdl.

All the created wsdl web services will be registered to juddi.

Project Report

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (13)

Similar to Project Report

Similar to Project Report (20)

More from Kunal Thakur

More from Kunal Thakur (6)

Recently uploaded

Recently uploaded (20)

Project Report