基於智慧型代理人的自動化商業協同合作 AUTOMATIC ELECTRONIC BUSINESS COLLABORATION BASED ON INTELLIGENT AGENT TECHNOLOGY

Transcription

1 基於智慧型代理人的自動化商業協同合作 AUTOMATIC ELECTRONIC BUSINESS COLLABORATION BASED ON INTELLIGENT AGENT TECHNOLOGY 研究生 : 呂賴誠 (Lai-Chen Lu) 指導教授 : 葉慶隆 (Prof. Ching-Long Yeh) 大同大學 資訊工程研究所 博士論文 Ph.D. Dissertation Department of Computer Science and Engineering Tatung University 中華民國九十八年六月 June 2009

2 ii

3 ACKNOWLEDGMENTS( 謝誌 ) 銘傳大學現任教務長王金龍教授是我研究所同學兼好友, 他一直鼓勵我去拿一 個博士學位 他認為以我在業界豐富的經驗及口才對學生一定很有幫助 剛好 我對教書也很有興趣, 於是就毅然的報考母校大同大學資工所博士班 一邊工 作一邊進修, 今年終於要畢業了 回想起讀博士班的這些日子, 雖然在公司經 營與學業間兩頭忙碌, 但也是人生收穫最豐富的時光 首先我最要感謝的是我 的指導教授葉慶隆老師, 没有他的教導與協助, 我今天没有辦法畢業 謹此再 向敬愛的恩師致上最深的感謝 再來要感謝同學施國琛教授及王金龍教授他們 在我念博士班期間給予我的協助與指導 我特別要感謝加拿大 New Brunswick University 的 Harold Boley 教授及希臘 Aristotle University 的 Nick Bassiliades 教授在 RuleM 及 DR-DEVICE 的技術上給予熱心的協助 此外感謝所 上的師長們在學問及智慧上的啟蒙 還要感謝校內外口試委員 : 陳煇煌教授 謝忠健教授 虞台文教授 王永心教授 葉耀明教授等, 對於論文不足之處加 以指正與建議, 使本論文更加完善, 在此致上深忱的謝意 特別要感謝公司全 体員工以及我事業生活上主要支柱的老婆大人, 一肩扛起所有工作, 讓我在大 同攻讀博士學位期間無後顧之憂 最後致上我最深的感激給我的家人, 期盼將 來能有小小的成就, 以回報家人對我的付出 呂賴誠 2009 年 06 月 i

4 ABSTRACT E-business is currently the most important business activity around the world. It provides a cost-effective method for companies to do the business trade. ebxml is widely accepted as the electronic collaboration business platform. It described in formal specification using XML, for connecting heterogeneous business systems. This thesis is composed of two parts for electronic business collaboration ebxml researches. One is an agent mediated front-end system for ebxml. The other is an agent mediated ebxml CPA negotiation. In the first part of the thesis is implementing an ebxml system in front of the back-end system. The ebxml system is divided into the upper business process level, account for business interactions, and the lower message service level for necessary technological support for the upper level. In this thesis, we employ agent technology to implement the ebxml system. We design and implement business service agent and message service agents for the upper and lower levels, respectively [129]. In particular we use a declarative approach to design the business service agent, which separate the business collaboration knowledge from the control engine. This results in automatic transformation from design artifacts into executable code. We implement a prototype system using open agent architecture. We carry out experiments by connecting two systems at different sites, based on the system. User interfaces are provided to control and monitor the process of collaborations. The system shows promising result in gaining insight on ebxml collaborations. It provides an excellent basis for further investigation on industry business collaborations. In the second part we propose an agent mediated ebxml CPA negotiation using defeasible logic reasoning. Rule based declarative web service negotiation is ii

5 the trend for automatic negotiation. Defeasible reasoning is nonmonotonic rule based reasoning. It is a simple, but often more efficient approach than other nonmonotonic reasoning systems. We propose, and report on a prototypical implementation of a semantic ebxml CPA negotiation agent, exhibiting the described functionality, in OAA plateform. In particular we use a declarative rule based defeasible logic approach to design the ebxml CPA negotiation agent. Expression of CPA negotiation strategies is also of great importance in electronic business collaboration. We exploit the use of defeasible logic reasoning for expressing ebxml CPA negotiation strategies. This results in automatic business collaborative negotiation. In this thesis we describe the related technologies and concepts. We indicate the advantages of using defeasible logic reasoning in ebxml CPA negotiation. We also compare our research with other ebxml CPA negotiation researches. We believe that defeasible logic reasoning is promising to be used in practical applications. Because it is simple, sufficiently efficient, declarative, portability in the B2B environment and the reusable of rule base system. Keyword: ebxml, Agent, business collaboration, RosettaNet, Web Service, Defeasible Logic iii

6 中文摘要 電子商務無疑是當今世界上最重要的商業活動 電子商務為公司行號在商業交易下提供了一個有效節省成本的方法 在現今各種不同的商業電腦系統平台上,ebXML( 電子商務 XML) 是一個廣為大家所接受的 XML 電子商務架構 在本論文中我們將有關 ebxml 電子協同商務的研究分成兩部份 一個為以理人技術為基礎的 ebxml 商業協同前端的研究, 另一部份為以代理人技術為基礎的 ebxml CPA 協商 第一部份為在各個商業應用系統的前端架設一套 ebxml 系統作為電子交易平台 ebxml 系統分為上層的企業間商業處理流程及為上層商業系統服務的訊息服務層 本論文我我們利用代理人技術實作一套 ebxml 系統 我們為 ebxml 上層及底層系統設計並實作一套商業服務代理人和訊息服務代理人程式 我們特別使用宣告式研究方法設計一套商業服務代理人程式, 此程式可將商業協同服務知識和控制引擎分開 此一設計可自動轉換商業流程設計成為可執行的程式碼 我們利用開放式代理人系統實作一套原型系統 我們在此系統架構下實驗連接二個不同地方的系統, 使用者介面可控制及監督協同合作的交易流程 本系統方法可提昇 ebxml 內部交易系統的效率並為未來商業協同合作提供一個絶佳的基礎 本論文的第二部份我們提出一個以使用可廢止邏輯推論 (Defeasible Logic Reasoning) 作為代理人媒介的 ebxml CPA 協商 使用網路資訊服務計算技術規則條件宣告式協商是自動化協商的趨勢 可廢止邏輯推論是一種基於非單調性規則條件的推論, 但它比其他的非單調性的規則條件推論更加簡單而有效率 我們在 OAA 的平台上設計並實作一個 ebxml CPA 協商代理人, 我們特 iv

7 別使用規則條件宣告式可廢止邏輯推論方法來設計 ebxml CPA 協商代理人 CPA 協商策略在協同電子商務中是很重要的, 我們開發使用可廢止邏輯推論作為 ebxml CPA 協商策略 本論文中我們敘述了相關技術和觀念, 我們指出了使用可廢止邏輯推論作為 ebxml CPA 協商的優點, 我們也將我們的研究和其他 ebxml CPA 協商的研究作了比較 我們相信能將可廢止邏輯推論用在其他特別的應用系統上 因為它簡單 有效率 宣告式導向 在 B2B 環境中可移轉而且可重覆使用 關鍵詞 :ebxml, 代理人, 商業協同合作,RosettaNet, 網頁服務, 可廢止邏 輯 v

8 TABLE OF CONTENTS( 目次 ) ACKNOWLEDGMENTS... i ENGLISH ABSTRACT... ii CHINESE ABSTRACT... iv TABLE OF CONTENTS... vi LIST OF FIGURES... xiii LIST OF TABLES... xvi CHAPTER 1. INTRODUCTION Motivation and Goal Research Methodology Overview of System Architecture Contribution of the Research Thesis Organization... 9 CHAPTER 2. BACKGROUND AND RELATED RESEARCHES An Overview of Electronic Commerce RosettaNet: A Vertical Integration of Business Collaboration vi

9 2.2.1 RosettaNet Overview RosettaNet Interface Comparisons RosettaNet PIP (Partner Interface Processes) Overview ebxml (electronic business extensible Markup Language) ebxml Technical Overview ebxml System Overview ebxml Business Process Choreography Core Components ebxml Message Service ebxml Registry and Repository ebxml Collaboration-Protocol Profile (CPP) and collaboration Protocol Agreement (CPA) overview Intelligent Agent Technology Agent-to-Agent Communications The Open Agent Architecture (OAA) vii

10 2.6 Rule Technology on Semantic Web Web services technology Metadata Layer of Semantic Web Ontology Policy and Rule Languages RDF RDF (Resource Description Framework) Defeasible Logic Technology A Language of Defeasible Reasoning Formal Definition Proof Theory Related ebxml CPA Negotiation Researches Related Defeasible Logic Researches CHAPTER 3. AGENT-MEDIATED ARCHITECTURE FOR EBXML FRONT-END-SYSTEM CHAPTER 4. TRANSFORMATION OF EBXML CPAS INTO EXCUTABLE CODE USING FINITE STATE MACHINE viii

11 4.1 Structure of CPA Establishing Business Collaboration Two-Level Finite State Model for BPSS Creating Business Service Agents based on the Two-level Model CHAPTER 5. BUILDING EBXML CPA NEGOTIATION AGENT BASED ON DEFEASIBLE LOGICTECHNOLOGY Negotiation Theory Negotiation Techniques Game-theoretic techniques Heuristic Approaches Argumentation-Based Approaches Fuzzy Logic Approaches Ontology Approaches ebxml CPA Automatic Negotiation Technique Collaboration Protocol Agreement (CPA) negotiation System Overview ix

12 5.3.3 Components of CPA Negotiation Defeasible Logic Rule-Based Negotiation Use DR-DEVICE as Defeasible Logic Reasoning Inference Engine for ebxml Negotiation SOA Architecture of ebxml negotiation CHAPTER 6. SYSTEM IMPLEMENTATION Implementation of ebxml Front-End system Using OAA Agents in the Front-End System Business Collaborations for RosettaNet Implementation of ebxml CPA Negotiation Agent based on Defeasible Logic technology ebxml CPA Negotiation Scenario ebxml CPA Negotiation Architecture Using Defeasible Logic Inference Engine ebxml CPA Negotiation Strategies Defeasible Logic Negotiation Rules ebxml CPA Negotiation use DR-DEVICE Rule x

13 Inference Engine Implementation and Demonstration CHAPTER 7. ANALYSIS AND DISCUSSION Discussions of ebxml Front-End system Advantages of using Defeasible Theory for ebxml Negotiation Compare with other ebxml CPA Negotiation researches CHAPTER 8. CONCLUSION AND FUTURE WORK REFERENCES A.1 Appendix A. Example of NDD Instance Document (Non-Normative) A.2 Appendix B, ebxml CPA Negotiation of Defeasible Logic RDF Ontology Format Definition. (ebxml01.rdf) A.3 Appendix C. ebxml CPA Negotiation Defeasible Logic RuleML Negotiation Rules. (ebxml01.ruleml) A.4 Appendix D. ebxml CPA Negotiation RDF Import file of xi

14 Buyer s Proposal. (ebxml01_ex.rdf) A.5 Appendix E. ebxml CPA Negotiation RDF file of Negotiation Result. (export_ebxml01.rdf) xii

15 LIST OF FIGURES( 圖目錄 ) Figure 1.1: Conceptual diagram of ebxml technical architecture..4 Figure 1.2: Overview of System Architecture..6 Figure 2.1: RosettaNet Interface Comparisons...14 Figure 2.2: ebxml Technical Architecture frameworks 17 Figure 2.3: ebxml Trading Scenario.19 Figure 2.4: Business Process Specification and Business Service Interface Configuration..20 Figure 2.5: Typical Relationship between ebxml Message Service Handler Components Figure 2.6: Overview of Working Architecture of CPP/CPA with ebxml Registry...25 Figure 2.7: Agent Communication Figure 2.8: Typical structure of OAA..34 Figure 2.9: Architecture of the metadata layer of the Semantic Web..36 Figure 2.10: Semantic Web Service Layer Cake Figure 2.11: RDF Graph...44 Figure 2.12: Definite Provability in Defeasible Logic...50 Figure 2.13: Definite Non-provability in Defeasible logic..51 Figure 2.14: Defeasible Provability in Defeasible Logic Figure 2.15: Defeasible Non-provability in DefeasibleLogic...52 Figure 3.1: Agent architecture for ebxml application Figure 4.1: Conceptual diagram of business transaction...67 Figure 4.2: A finite state machine for the choreography of a business collaboration xiii

16 Figure 4.3: Structure of business service agent and message service agent...73 Figure 5.1: main components of CPA negotiation Figure 5.2: A high-level view of the negotiation process...85 Figure 5.3: Architecture of the DR-DEVICE system Figure 5.4: The basic Service Oriented Architecture Figure 6.1: Company A issues a purchase order request with Company B...96 Figure 6.2: (Top) Company B responds accepting the request; (bottom) success of purchase order request at UIA of Company A.. 97 Figure 6.3: (Top) Company B responds with pending the request; (bottom) Company A accepts the purchase order update 98 Figure 6.4: ebxml CPA Negotiation Architecture Using Defeasible Logic Inference Engine Figure 6.5: NDD instance document Figure 6.6: RDF ontology for rule format definition.109 Figure 6.7: Defeasible Logic RuleML Negotiation Rules Figure 6.8: The DR-DEVICE inference engine process graph..111 Figure 6.9: The RDF file of Buyer s Import proposal a Figure 6.10: Proposal a1 negotiation result RDF file Figure 6.11: Activated agent on OAA platform Figure 6.12: User interface for Agent mediated defeasible logic ebxml CPA negotiation program Figure 6.13: Defeasible Logic ebxml CPA negotiation sequence Figure 6.14: Proposal a1 negotiation result Figure 6.15: Proposal a2 negotiation result Figure 6.16: Proposal a5 negotiation result Figure 6.17: Combination of CPA. 119 xiv

17 Figure 6.18: CPA negotiation result document.119 xv

18 LIST OF TABLES( 表目錄 ) Table 2.1: CPA Elements.28 Table 2.2: Agent properties (Source from Georgakarakou, Agent and Web Service Technologies in Virtual Enterprises) [19]..30 Table 2.3: Comparing XML-based policy languages.43 Table 2.4: RDF Classes...45 Table 6.1: Finite state model table...91 Table 6.2: Seller s Strategies 103 Table 6.3: Buyer s Strategies Table 6.4: Negotiation Result xvi

19 CHAPTER 1 INTRODUCTION 1.1 Motivation and Goal E-commerce is currently the most important business activity around the world. Online retail sales in the U.S. are expected to grow about $20 billion to $30 billion each year from 2008 to 2012, reaching somewhere between $215 billion and $335 billion by 2012, according to the released reports on e-commerce [1]. E-commerce provides a cost-effective method for companies to do the business trade. In the ordinary e-commerce applications, buyers and sellers are humans who typically browse the web page and find the products, usually by means of or special shopping car in web. These kinds of business buying processes are time consuming. Thus, most of the research today is conducted towards the automatic e-commerce applications, which will be realized through the use of automated methods of information technology. Trading partners will be represented by Software Agents. However, as software agents start to engage in e-commerce, new issues arise. Information must be organized in a way that can be manipulated by machines. Additionally, machines must be able to access, process and interpret the information. An electronic business information interchange standard has to be made by international organization. Electronic Business using Extensible Markup Language (ebxml) is widely accepted as the electronic collaboration business platform. These standards provide a B2B e-marketplace using Extensible Markup Language (XML) technology. Using ebxml trading partners can do the business in an automatic and standard environment. Users on company can find the products on ebxml registry, they do not have to browse from the Web or find the yellow page like past way. Then the buyer can send invoices and 1

20 statements electronically to a seller intaiwan using ebxml, through which the buyer can access procurement from the seller in a timely and efficient fashion. They can negotiate the trading conditions in an automatic way by intelligent agent. Negotiation automation represents a special type of business process for manipulate dynamic human decisions. The basic dimensions of negotiation are Negotiation Protocols and Negotiation Strategies. Negotiation protocol is a set of rules that govern the interaction and negotiation strategy is a decision making by trading partners. The negotiation purpose is achieving mutual agreement goals between trading partners. We are interested in the negotiation strategy dimension. We propose use declarative rule based defeasible logic approach as our negotiation strategies. Rule based declarative web service negotiation is the trend for automatic negotiation. Defeasible reasoning is nonmonotonic rule based reasoning. It is a simple, but often more efficient approach than other nonmonotonic reasoning systems. We create and implement defeasible logic reasoning based negotiating agents on OAA platform. Declarative rule based defeasible logic approach is plug-and-play negotiation strategy. When the negotiation items or negotiation criterion changed, user does not have to change the negotiation programs. It just has to change the negotiation rules. The defeasible logic reasoning based negotiating strategies are portability and reusable. To validate the viability of our approach, we apply a negotiation scenario and provide a prototype implementation of such agent architecture using OAA platform. We do not implement a complete ebxml CPA negotiation platform, but rather a fundamental infrastructure, which hosts defeasible logic-based negotiating agents. 1.2 Research Methodology In ebxml service-oriented architecture, service requester finds out desired services or counterparts through the aid of public registry [3]. According to the content of service 2

21 profile, programs of both sides interact to each other, by exchanging XML documents using SOAP protocol [3], to achieve service automation. The forms of interactions range from simple remote procedure calls to complicated ones such as execution of business processes. The former kind of services is represented using the standard service description language, WSDL [4]. The companies participate in complicated business processes have their profiles listing their business information and the business protocols and the message services they are capable of, for example, CPP [5] in ebxml [6]. A pair of potential trading partners can negotiate based on their CPPs to come out an agreement of business protocols and the accompanied message services, CPA [5]. Both sides implement their front end programs according to the content specified in the agreement. Then both the partners back-end systems, that implement their private processes respectively, can interact to each other through their respective front end programs as shown in Figure 1.1 In this thesis we have two aims one aim at developing a front end system for the enterprise back-end system in order to get involved in ebxml business collaboration. The other aim is make the ebxml business collaboration CPA negotiation by rule based defeasible reasoning. As shown in Figure 1.1, the front-end system consists of two layers, business processes and message services. A business process in the former layer provides interfaces for the backend system to enter the common process with the target collaborative partner. The business process in turn calls the message services to realize the interactions with the collaborative partner. In both layers, there are processes in the system dealing with specific business processes and the corresponding message services, respectively. The processes in the system are created when demanded by the backend system or user, and remain alive for specific periods of time as indicated in the CPAs. Therefore we need some mechanism to manage the processes of both layers during their life-cycle. 3

22 Figure 1.1: Conceptual diagram of ebxml technical architecture The basic dimensions of negotiation are Negotiation Protocols and Negotiation Strategies. Negotiation protocol is a set of rules that govern the negotiation processes and negotiation strategy is a decision making by trading partners. The negotiation purpose is achieving mutual agreement goals between trading partners. We are interested in the negotiation strategy dimension. There are several techniques for creating negotiation strategies such as game-theoretic, heuristic, argumentation-based, fuzzy logic and ontology based theory. We propose use declarative rule based defeasible logic approach as our negotiation strategies. We create and implement defeasible logic reasoning based negotiating agents on OAA platform. Declarative rule based defeasible logic approach is plug-and-play negotiation strategy. When the negotiation items or negotiation criterion changed, user does not have to change the negotiation programs. It just has to change the negotiation rules. The defeasible logic reasoning based negotiating strategies are portability and 4

23 reusable. To validate the viability of our approach, we apply a negotiation scenario and provide a prototype implementation of such agent architecture using OAA platform. We do not implement a complete ebxml CPA negotiation platform, but rather a fundamental infrastructure, which hosts defeasible logic-based negotiating agents. OAA is a framework for integrating a community of heterogeneous software agents in a distributed environment. With this platform, we can develop our front-end ebxml business collaborations and CPA negotiation. It possible for software services to be provided through the cooperation between agents that are brokered by one or more facilitators, which are responsible for matching requests, from user and agents. 1.3 Overview of System Architecture Figure 1.2 shows the overview of system architecture. It represents the system architecture of our researche. The trading partner, Companies A, B and C, are simply represented in boxes, which mean they may have their own implementations of ebxml systems. The business service agents and message service agents are used to realize the business process and message service layer, respectively. In ebxml, business collaboration consists of business protocol and the message service [7]. The back-end system contacts the Facilitator agent to invoke new business collaboration, which in turn creates a Business Service Agent. The Business Service Agent invokes the Message Service Agent to for sending and receiving message the counterpart. User can invoke the UI agent to access through graphical user interface the services provided by the ebxml agent architecture. 5

24 ebxml Back-End System Facilitator Agent CPP Agent Discovery Agent Message Service Agent Business Service Agent Business Information Agent OAA Platform UI Agent CPA Negotiation Agent Company A Company B Internet DR-DEVICE Inference Engine JENA Parser Company C Ontology Knowledge Base ebxml Registry Figure 1.2: Overview of System Architecture The Business Information Agent provides business information in CPA or BPSS for other agents. The CPP Agent is used to manage the collaboration protocol profile. The CPA Negotiation Agent is used when negotiating with a potential trading partner to achieve an agreement of collaboration protocol. The Discovery Agent is used to find out potential trading partner and search the ebxml registry. In ebxml CPA negotiation, we propose use the defeasible logic rule based reasoning. We use the DR-DEVICE as our negotiation inference engine and JENA as RDF ontology parser. In this thesis, we focus on the design of the UI, Message Service, Business Service, and Business Information 6

25 Agents for ebxml front-end system. Develop the ebxml CPA negotiation using defeasible logic reasoning and leave the rest agents in the architecture for future study. 1.4 Contribution of the Research In this thesis we employ the agent technology as the basis to implement the front-end system of ebxml technical architecture. According to the official web site of ebxml tools [8], it is quite a new idea of bringing the agent technology to build up the front-end for ebxml. We implement the agent-mediated ebxml system on open agent architecture, which makes it able to include entries of both layers obtained from open source. In the design we separate the business collaboration knowledge and the control engine. The former is represented as a finite state model, which in practice is easy to be implemented using two-dimensional array. The finite state model of business collaboration is constructed automatically from the formal specification of process in BPSS. Thus it is automatic to transform the newly created or updated business collaborations into executable code. In other words, the transformation phase between the design phase and run-time phase is fully automated and the programming effort is greatly reduced. We also spend much effort in the design and implementation of message service agent and the behavior of prototype system encourage us moving forward along this development. Agent technology has been used in other ebxml research. An investigation has been made on how to enhance business process on the framework using ebxml [9]. Agent technology is used to look for potential trading partners from ebxml registries and used in the framework to manage the business processes. In our thesis, we also employ agent technology to manage the processes of business collaborations between trading partners. In this thesis, we design a two-layered model for the transformation of business process specification described in CPA into executable code. We provide the detail design and implementation. 7

26 The work we present in this thesis provides preliminary result of developing agent-based ebxml system. In addition to enhancing the functions of the system, we propose to carry out research of ebxml implementation based the agent-based ebxml system. First is to finish the functions of discovery and design phases in the agent-based system, in other words, to design and implement the Discovery agent, CPP agent and CPA negotiation agent. Second is to carry out horizontal integration cross industries using the agent-based ebxml system. We employ the experience to making the finite state model agent-based ebxml front-end system. We believe that users can extend the electronic business collaborations for heterogeneous domains. In the second parts of the thesis, the focus of our work is on the Negotiation stages of the ebxml CPA negotiation that we have already described. We use rule-based declarative defeasible logic, agent-based and semantic web-based technologies for ebxml CPA negotiation. Many approaches provide a set of simple pre-defined strategies [8], [20]. These kinds of pre-defined strategies have the advantage of easily explainable and predictable. However, these approaches will restrict the possibilities of the users for expressing their preferences. In the other researches each trading partner in a negotiation must develop his own negotiating agent using a general-purpose design methodology. But these kind approaches will unavoidable need a very complex strategies and its systematic use leads to time-consuming and hard-to-reuse the negotiation codes. In addition, agents developed under these kinds approach often not possible to modify their behavior without having to rebuild the agent codes. The introduction and compare of the other ebxml CPA negotiation will discuss in the last chapter. We propose a simple yet expressive framework for specifying negotiating agents' strategies, that their decisions are predictable and explainable. Specifically, we explore the use of defeasible logic programming for ebxml CPA negotiation agents. The Defeasible 8

27 Logic Programming is more suitable for user preferences representation than the utility quantity function. Rule based negotiations with exceptions are a useful feature in negotiation. Using rule system we can describe our goal by rule, don t have to revise the program of negotiation system. To validate the viability of our approach, we apply a negotiation scenario and provide a prototype implementation of such agent architecture using OAA multiagent framework. We believe that defeasible reasoning is promising to be used in practical applications. Because it is simple, sufficiently efficient, declarative, portability in the B2B environment and the reusable of rule base system. It can solve the multi-attribute negotiation problems and some other complicate problems. Users can extend the agent technology and defeasible logic technology in other applications. 1.5 Thesis Organization This thesis is organized as follows. In Chapter 2, a brief introduce our research background knowledge such as the e-commerce, RosettaNet: a vertical integration of Business Collaboration, ebxml (electronic business extensible Markup Language), Agent technologies, OAA framework, Semantic web service, Ontology, RDF (Resource Description Framework, Policy and Rule Languages and Defeasible Logic Technique. Chapter 3 describes the agent-mediated architecture for front-end ebxml. It presents the system architecture about the mediation agents on OAA platform and brief describe the functions of the agents. Chapter 4 we have described how to create agents for business services and message services from the specification of collaboration protocol between a pair of trading partners. We also describe how to development and transform the ebxml CPAs into executable code using finite state machine technology. We model the collaborative business process into finite state machine and then create some service agents based on 9

28 the finite state machine. Chapter 5 proposes building ebxml CPA negotiation agent based on Defeasible Logic technology. In this chapter we describe the negotiation theories and ebxml CPA negotiation technique. We also indicate how to use the DR-Device defeasible logic inference engine. Subsequently we explain how our work seems to fulfill the SOA architecture. Chapter 6 in first section of this chapter, we described an implementation of the agent architecture to show how it works in the ebxml platform. First of all we describe the implementation of agents serving for business collaboration, i.e., the business service agents and message service agents. Then we demonstrate the implementation of agent mediated business collaboration on OAA platform. In the second section of this chapter we described the ebxml CPA negotiation scenario. Then we propose how to use defeasible logic technology in ebxml CPA negotiation. Finally we demonstrated the implementation of agent mediated defeasible logic CPA negotiation. Chapter 7 is analysis and discussion. In first section we discussed our research about ebxml Front-End system. Second, we study some related ebxml CPA negotiation researches. Third, we also study some related Defeasible Logic researches. Fourth, we indicate the advantages of using defeasible theory for ebxml negotiation. Finally, we compare our research with other ebxml CPA negotiation researches. Finally, Chapter 8 presents a conclusion and directions for future work. 10

29 CHAPTER 2 BACKGROUND AND RELATED RESEARCHES 2.1 An Overview of Electronic Commerce Electronic commerce is defined as any type of business, or commercial transaction over the Internet, with or without online payment, excluding private networks. It covers many different types of businesses, from consumer based retail sites, through auction or music sites, to electronic business trading and services between corporations. Electronic commerce is currently the most important business activity around the world. Online retail sales in the U.S. are expected to grow about $20 billion to $30 billion each year from 2008 to 2012, reaching somewhere between $215 billion and $335 billion by 2012, according to the released reports on electronic business [1]. Electronic commerce provides a cost-effective method for companies to do the business trade. The electronic marketplaces provide a business framework for suppliers and potential customers are brought together to conduct mutually beneficial trade. Business-to-Business (B2B), Business-to-Consumer (B2C), and Consumer-to-Consumer (C2C) electronic business models describe the target buyer market and the target seller market. B2B describes online transactions between one business, institution, or government agency and another. Examples of B2B include ebxml, RosettaNet and Alibaba. B2C describes online transactions between a business and a consumer. Examples of B2C sites include Amazon, Google, Skype, Youtube and Yahoo. Although the most part major electronic business sites fall into either B2B or B2C, but some company include both business target. Dell Computer, for example, is both a B2C and B2B site. 11

30 2.2 RosettaNet: A Vertical Integration of Business Collaboration RosettaNet Overview RosettaNet is a self-funded, not-for-profit consortium of major information Technology, Electronic Components and Semiconductor Manufacturing companies working to create and implement industry-wide open e-business process standards. These standards form a common e-business language, aligning processes between supply chain partners on a global basis [10][11][12]. RosettaNet's drives collaborative development and rapid deployment of internet-based business standards, creating a common language and open e-business processes that provide measurable benefits and are vital to the evolution of the global, high-technology trading network. Developed with the collaboration and expertise of leading high-tech companies, RosettaNet standards offer a robust non-proprietary solution, encompassing data dictionaries, implementation framework, and business message schemas and process specifications, for e-business standardization. Available to the public free of cost at RosettaNet standards include the RosettaNet Business Dictionary, RosettaNet Technical Dictionary, RosettaNet Implementation Framework (RNIF) and RosettaNet Partner Interface Processes (PIPs) RosettaNet Interface Comparisons Figure 2.1, illustrates the parallel between a human-to-human business exchange and a server-to-server e-business exchange. Starting with the basic element on the left side of the figure 2.1, in order to communicate in a human-to-human business exchange, humans interact or produce and hear sound. In building a transaction, they must agree on a common alphabet, used to create individual words. Grammatical rules are then applied to 12

31 the words to create a dialog. That dialog forms the business process, which is conducted (or transmitted) through an instrument such as a telephone RosettaNet PIP (Partner Interface Processes) Overview Cluster 1: Partner, Product and Service Review [10][11][12] 1. Segment 1A: Partner Review 2. Segment 1B: Product & Service Review Cluster 2: Product Introduction 1. Segment 2A: Preparation for Distribution 2. Segment 2B: Product Change Notification Cluster 3: Order Management 1. Segment 3A: Quote and Order Entry 2. Segment 3B: Transportation and Distribution 3. Segment 3C: Returns and Finance 4. Segment 3D: Product Configuration Cluster 4: Inventory Management 1. Segment 4A: Collaborative Forecasting 2. Segment 4B: Inventory Allocation and Replenishment 3. Segment 4C: Inventory Reporting 4. Segment 4D: Inventory Replenishment 5. Segment 4E: Sales Reporting 6. Segment 4F: Price Protection CLUSTER 5: Marketing Information Management 1. Segment 5A: Lead/Opportunity Management 2. Segment 5B: Marketing Campaign Management 3. Segment 5C: Design Win Management (Electronic Components) 13

32 4. Segment 5D: Ship From Stock and Debit (Electronic Components) CLUSTER 6: Service and Support 1. Segment 6A: Provide and Administer Warranties, Service Packages, and Contract Services 2. Segment 6B: Provide and Administer Asset Management 3. Segment 6C: Technical Support & Service Management Figure 2.1: RosettaNet Interface Comparisons 2.3 ebxml (electronic business extensible Markup Language) The ebxml is a set of specifications for electronic business interoperability. It is one of the most ambitious and important specification development efforts in electronic business. The two organizations OASIS and UN/CEFACT (United Nations Center for Trade Facilitation and Electronic Business) started and managed the ebxml project. The ebxml framework first delivered in the summer of The ebxml was intended to offer an open technical framework to enable XML to be utilized in a consistent and 14

33 uniform manner for the exchange of electronic business data in internet. The ebxml is an advanced framework for e-business, rather than for application integration. It provides a flexible, business process tier oriented approach to BtoB interactions. The ebxml framework includes declarative, executable language to express e-business collaborations (BPSS) and Collaboration Protocol Profile (CPP) / Collaboration Protocol Agreement (CPA) for trading company negotiation. The building block for ebxml software (Core components) can be reused by software. The ebxml messaging services offers a standards-based e-business messaging system for secure message transmission. In the following section we will introduce the detail of ebxml [6] ebxml Technical Overview The main components of the ebxml architecture include [13]: Business Process Specification Schema: BPSS is an XML-based specification language that formally defines public business processes. It is focuses on Meta model defines the deliverables needed to describe a business process. It can be expressed using UML and then recast in XML. The business process specification schema (BPSS) deals with the rules for the actual business process. Core components: The Core component is the basic building block for ebxml software. It assumes that objects provide the fundamental building blocks of all business models. These fundamental building blocks can be reuse by software. Message service: The ebxml Message Service defines robust, yet basic, functionality to transfer messages between trading parties using various existing communication protocols. The ebxml message Service is structured to allow for messaging reliability, persistence, security, and extensibility. Registry and Repository: The Registry manages and maintains the shared information as objects in a repository. Repositories provide trading partners with the shared 15

34 Collaboration Protocol Profile, BPSS, documents and other objects that enable data interchange between companies. Collaboration Protocol Profile (CPP) / Collaboration Protocol Agreement (CPA): The CPP/CPA defines the capabilities of a trading partner to perform a data interchange and how this data interchanges agreement can be formed between two trading partners. The CPP/CPA deals with the technical aspects of a handshake between systems prior to conducting e-business [13]. Figure 2.2, is Functional service view of ebxml ebxml System Overview There has a company A, seeks for collaborate supplier partner to buy personal computer. We can see the trading scenario about two collaborate partner using ebxml standard. Figure 2.3 shows the trading scenario [6]. Step 1: Company A and B public their Collaboration Protocol Profile (CPP), Document, Business Process Schema to ebxml Registry/Repository. Step 2: Search ebxml Registry/Repository and discovery of information about each participant including: The Business Processes they support. The Business Service Interfaces they offer in support of the Business Process. The Business Messages that are exchanged between their respective Business Service Interfaces. The technical configuration of the supported transport, security and encoding protocols. Step 3: Execution of a mutually agreed upon business arrangement which can be derived from information provided by the Collaboration Protocol Profile (CPP) found above and then produces a Collaboration Protocol Agreement (CPA). Step 4: Trading partner uses CPA doing business transaction. CPA defines Business Process Specification Schema (BPSS) and BPSS defines the choreography of 16

35 Business Transactions between Business Collaborations. System using BPSS choreography can do the business transaction automatically. Step 5: Trading partner uses Message Service transfer messages between each other. The ebxml message Service is structured to allow for messaging reliability, persistence, security, and extensibility. Process reengineering Business process, core components Process definition Registry/ Repository Collaboration Protocol Profile Process evolution Eletronic Business Collaboration Partner discovery Business process management Process management Process execution Electronic plug-in Partner sign-up Collaboration Protocol Agreement Message service, Business service iterface Figure 2.2: ebxml Technical Architecture frameworks 17

36 ebxml Business Process Business Process Goal Business process models describe interoperable business processes that allow business partners to collaborate. Business process models for e-business must be turned into software components that collaborate on behalf of the business partners. The goal of the ebxml Specification Schema is to provide the bridge between e-business process modeling and specification of e-business software components. The ebxml Specification Schema provides for the nominal set of specification elements necessary to specify a collaboration between business partners, and to provide configuration parameters for the partners runtime systems in order to execute that collaboration between a set of e-business software components [13][14][15]. Business Process System Overview The ebxml Business Process Specification Schema provides a standard framework for business process specification. As such, it works with the ebxml Collaboration Protocol Profile (CPP) and Collaboration Protocol Agreement (CPA) specifications to bridge the gap between Business Process Modeling and the configuration of ebxml compliant e-commerce software, e.g. an ebxml Business Process Specification and Business Service Interface Configuration, as depicted in Figure

37 Figure 2.3: ebxml Trading Scenario 19

38 Figure 2.4: Business Process Specification and Business Service Interface Configuration Choreography A Choreography is an ordering and sequencing of Business Activities within a Binary Collaboration. The choreography is specified in terms of Business States, and transitions between those Business States. The purpose of Choreography is to order and sequence Business Transaction Activity and/or Collaboration Activity within a Binary Collaboration, or across Binary Collaborations within a Multiparty Collaboration Core Components Core Components Technical Specification provides a way to identify, capture and maximize the reuse of business information to support and enhance information interoperability across multiple business situations. The specification focuses both on human-readable and machine-processable representations of this information. Using Core Components as part of the ebxml framework will help to ensure that two trading partners using different syntaxes (e.g. XML and EDIFACT) are using business semantics 20

39 in the same way on condition that both syntaxes have been based on the same Core Components. This enables clean mapping between disparate message definitions across syntaxes, industry and regional boundaries. [13][15][16] ebxml Message Service System Overview The ebxmlmessage Service defines the message enveloping and header document schema used to transfer ebxml Messages over a communication protocol such as HTTP, SMTP, etc. This document provides sufficient detail to develop software for the packaging, exchange and processing of ebxml Messages. The ebxml Message Service is defined as a set of layered extensions to the base Simple Object Access Protocol [SOAP] and SOAP Messages with Attachments [SOAPATTACH] specifications that have a broad industry acceptance, and that serve as the foundation of the work of the W3C XML Protocol Core working group. The ebxml Message Service provides the security and reliability features necessary to support international electronic business that are not provided in the SOAP and SOAP Messages with Attachments specifications. [7][13][15] Message Service Purpose The ebxml Message Service defines robust, yet basic, functionality to transfer messages between trading parties using various existing communication protocols. The ebxml Message Service is structured to allow for messaging reliability, persistence, security and extensibility. The ebxml Message Service is provided for environments requiring a robust, yet low cost solution to enable electronic business. It is one of the four "infrastructure" components of ebxml. The other three are: Registry/Repository, Collaboration Protocol Profile/Agreement and ebxml Technical Architecture. 21

40 Packaging Specification An ebxml Message is a communication protocol independent MIME/Multipart message envelope, structured in compliance with the SOAP Messages with Attachments [SOAPATTACH] specification, referred to as a Message Package. There are two logical MIME parts within the Message Package: A MIME part, referred to as the Header Container, containing one SOAP 1.1 compliant message. This XML document is referred to as a SOAP Message for the remainder of this specification, zero or more MIME parts, referred to as Payload Containers, containing application level payloads [7]. The SOAP Message is an XML document that consists of the SOAP Envelope element. This is the root element of the XML document representing the SOAP Message. The SOAP Envelope element consists of the following [7]: One SOAP Header element. This is a generic mechanism for adding features to a SOAP Message, including ebxml specific header elements. One SOAP Body element. This is a container for message service handler control data and information related to the payload parts of the message [7]. The general structure and composition of an ebxml Message is described in the following figure ebxml Registry and Repository Role of ebxml Registry The Registry provides a stable store where information submitted by a Submitting Organization is made persistent. Such information is used to facilitate ebxml-based Business to Business (B2B) partnerships and transactions. Submitted content may be XML schema and documents, process descriptions, ebxml Core Components, context descriptions, UML models, information about parties and even software components. 22

41 [13][15][17] Registry Services A set of Registry Services that provide access to Registry content to clients of the Registry is defined in the ebxml Registry Services Specification. This document does not provide details on these services but may occasionally refer to them. The Registry Information Model provides a blueprint or high-level schema for the ebxml Registry. Its primary value is for implementers of ebxml Registries. It provides these implementers with information on the type of metadata that is stored in the Registry as well as the relationships among metadata Classes. The Registry information model [17]: Defines what types of objects are stored in the Registry Defines how stored objects are organized in the Registry Figure 2.5: Typical Relationship between ebxml Message Service Handler Components [7] 23

42 ebxml Registry Architecture The ebxml Registry architecture consists of an ebxml Registry Service and ebxml Registry Clients. The ebxml Registry Service provides the methods for managing a repository. An ebxml Registry Client is an application used to access the Registry. The main purpose of the LifeCycleManagement service is to manage the life cycle of repository items ebxml Collaboration-Protocol Profile (CPP) and collaboration Protocol Agreement (CPA) overview Using CPP in Registry two parties of trading partner must negotiate to produce a CPA. Figure 2.6 shows the working architecture about two collaborate parties negotiate to produce a CPA. Party A and Party B use their CPPs to jointly construct a single copy of a CPA by calculating intersection and negotiation of the information in their CPPs. Figure 2.6 illustrates the entire process [18]. 1. Any Party may register its CPPs to an ebxml Registry. 2. Party B discovers trading partner A (Seller) by searching in the Registry and downloads CPP (A) to Party B s server. 3. Party B creates CPA (A,B) and sends CPA (A,B) to Party A. 4. Parties A and B negotiate and store identical copies of the completed CPA as a document in both servers. This process is done manually or automatically. 5. Parties A and B configure their run-time systems with the information in the CPA. 6. Parties A and B do business under the CPA. 24

43 Figure 2.6: Overview of Working Architecture of CPP/CPA with ebxml Registry Collaboration-Protocol Profile (CPP) Definition A CPP defines the capabilities of a Party to do the electronic Business with other Parties. These capabilities include both technology capabilities, such as Party information, transport Protocol, security protocol, message protocol and Business capabilities in terms of what Business Collaborations it supports. The way each Party can exchange information, in the context of a Business Collaboration, can be described by a Collaboration-Protocol Profile (CPP) [18]. The ProcessSpecification, DeliveryChannel, DocExchange, and Transport elements of the CPP describe the processing of a unit of Business (conversation). These elements form a layered structure somewhat analogous to a layered communication model. Process-Specification layer - The Process-Specification layer defines the heart of the Business agreement between the Parties: the services (Business Transactions) which Parties to the CPA can request of each other and transition rules that determine the order 25

44 of requests. This layer is defined by the separate Process-Specification document that is referenced by the CPP and CPA. Delivery Channels - A delivery channel describes a Party's Message-receiving characteristics. It consists of one document-exchange definition and one transport definition. Several delivery channels MAY be defined in one CPP. Document-Exchange layer - The document-exchange layer accepts a Business document from the Process-Specification layer at one Party, encrypts it if specified, adds a digital signature for nonrepudiation if specified, and passes it to the transport layer for transmission to the other Party. It performs the inverse steps for received Messages. The options selected for the document-exchange layer are complementary to those selected for the transport layer. For example, if Message security is desired and the selected transport protocol does not provide Message encryption, then it must be specified at the document-exchange layer. The protocol for exchanging Messages between two Parties is defined by the ebxml Message Service Specification or other similar messaging service. Transport layer - The transport layer is responsible for Message delivery using the selected transport protocol. The selected protocol affects the choices selected for the document-exchange layer. For example, some transport- layer protocols might provide encryption and authentication while others have no such facility. It should be understood that the functional layers encompassed by the CPP have no understanding of the contents of the payload of the Business documents. CPP Structure Following is the overall structure of the CPP. Unless otherwise noted, CPP elements MUST be in the order shown here [18]. 26

45 <CollaborationProtocolProfile xmlns=" xmlns:ds=" xmlns:xlink=" version="1.1"> <PartyInfo> <!--one or more-->... </PartyInfo> <Packaging id="id"> <!--one or more-->... <Packaging> <ds:signature> <!--zero or one-->... </ds:signature> <Comment>text</Comment> <!--zero or more--> </CollaborationProtocolProfile> CPA Definitions A Collaboration-Protocol Agreement (CPA) defines the capabilities that two Parties must agree upon to enable them to engage in electronic Business for the purposes of the particular CPA. This section defines and discusses the details of the CPA. 27

46 CPA Structure Following is the overall structure of the CPA [18]: <CollaborationProtocolAgreement xmlns=" xmlns:ds = " xmlns:xlink = " cpaid="yoursandmycpa" version="1.2"> <Status value = "proposed"/> <Start> T18:39:09</Start> <End> T18:40:00</End> <!--ConversationConstraints MAY appear 0 or 1 times--> <ConversationConstraints invocationlimit = "100" concurrentconversations = "4"/> <PartyInfo> </PartyInfo> <PartyInfo> </PartyInfo> <Packaging id="n20"> <!--one or more-->... </Packaging> <!--ds:signature MAY appear 0 or more times--> <ds:signature>any combination of text and elements </ds:signature> <Comment xml:lang="en-gb">any text</comment> <!--zero or more--> </CollaborationProtocolAgreement> CPA Elements: Table 2.1: CPA Elements [18] Elements Name CollaborationProtocolAgreement Element Status Element 28 Properties cpaid type [XML] CDATA version attribute. indicates the version of the CPA Status element records the state of the composition/negotiation process. possible values: proposed: meaning that the CPA is still being negotiated by the Parties, agreed: meaning that the contents of the CPA have been agreed to by both Parties.

47 Signed: meaning that the CPA has been "signed" by the Parties. CPA Lifetime The lifetime of the CPA is given by the Start and End elements. The syntax is: <Start> T18:39:09</Start> <End> T18:40:00</End> ConversationConstraints Element The ConversationConstraints element places limits on the number of conversations under the CPA. PartyInfo Element PartyInfo element specifies the Parties' agreed terms for engaging in the Business Collaborations. ds:signature Element A CPA document MAY be digitally signed by one or more of the Parties for information integrity. It is strongly RECOMMENDED that [XMLDSIG] be used to digitally sign the document. Comment element The CollaborationProtocolAgreement element MAY contain zero or more Comment elements. An example of a Comment element follows: <Comment xml:lang="en-gb">yadda yadda, blah blah</comment> 2.4 Intelligent Agent Technology A software agent is a software entity that design for special tasks. It has autonomous, social ability, Responsiveness and Proactiveness [19]. A software agent can be view as a software task perceives its environment through sensors and automatic acting upon the environment feedback the situation. In general agents can monitor the environment situation and automatic response the action from environment instance. Mathematically speaking, we say that an agent s behavior is described by the agent function that maps any given percept sequence to an action. The use of intelligent agents can be very useful to address complex dynamic problems. The agent is used to denote a hardware or software-based computer system that has the following properties: 29

48 Table 2.2, Agent properties (Source from Georgakarakou, Agent and Web Service Technologies in Virtual Enterprises) [19] Property Definition 1. Autonomy It means that the agent can act without direct intervention by humans or other agents and that it has control over its own actions and internal state (Sycara, 1998)[ 21]. 2. Reactivity or It means that the agent receives some form of sensory input situatedness or from its environment, and it performs some action that sensing and acting changes its environment in some way (Chira, 2003; Sycara, 3. Proactiveness or Goal directed behavior 1998). [21][20] It means that the agent does not simply act in response to its environment; it is able to exhibit goal-directed behavior by taking the initiative (Chira, 2003; Wooldridge & Jennings, 1995; Odell, 2000). [20][22][23] 4. Social ability It means that the agent interacts and this interaction is marked by friendliness or pleasant social relations; that is, the agent is affable, companionable or friendly (Odell, 2000). [23] 5. Coordination It means that the agent is able to perform some activity in a shared environment with other agents. Activities are often coordinated via plans, workflows, or some other process management mechanism (Odell, 2000). [23] 6. Cooperation or collaboration It means that the agent is able to coordinate with other agents to achieve a common purpose; non-antagonistic agents that succeed or fail together (Odell, 2000). [23] 7. Flexibility It means that the system is responsive (the agents should perceive their environment and respond in a timely fashion to changes that occur in it), pro-active and social (Jennings et al., 1998). [24] 8. Learning or adaptivity It means that an agent is capable of i) reacting flexibly to changes in its environment; ii) taking goal-directed initiative, when appropriate; and iii) learning from its own experience, its environment, and interactions with others (Chira, 2003; Sycara, 1998). [20][21] 9. Mobility It means that the agent is able to transport itself from one machine to another and across different system architectures and platforms (Etzioni & Weld, 1995). [25] 10. Temporal continuity It means that the agent is a continuously running process, not a "one-shot" computation that maps a single input to a single output, then terminates (Etzioni & Weld, 1995). [25] 11. Personality An agent has a well-defined, believable "personality" and or character emotional state (Etzioni & Weld, 1995). [25] 12. Reusability Processes or subsequent instances can require keeping instances of the class agent for an information handover or to check and to analyze them according to their results (Horn et al., 1999).[26] 30

49 13. Resource limitation An agent can only act as long as it has resources at its disposal (Horn et al., 1999). These resources are changed by its acting and possibly also by delegating (Horn et al., 1999).[26] 14. Veracity It is the assumption that an agent will not knowingly communicate false information (Wooldridge & Jennings, 1995; Wooldridge 1998). [22][27] 15. Benevolence It is the assumption that agents do not have conflicting goals and that every agent will therefore always try to do what is asked of it (Wooldridge & Jennings, 1995; Wooldridge 1998). [22][27] 16. Rationality It is the assumption that an agent will act in order to achieve its goals, and will not act in such a way as to prevent its goals being achieved at least insofar as its beliefs permit (Wooldridge & Jennings, 1995; Wooldridge 1998). [22][27] 17. Inferential capability 18. Knowledgelevel communication ability 19. Prediction ability An agent can act on abstract task specification using prior knowledge of general goals and preferred methods to achieve flexibility; goes beyond the information given, and may have explicit models of self, user, situation, and/or other agents (Bradshow, 1997). [28] The ability to communicate with persons and other agents with language more resembling humanlike speech acts than typical symbol-level program-to-program protocols (Bradshow, 1997). [28] An agent is predictive if its model of how the world works is sufficiently accurate to allow it to correctly predict how it can achieve the task (Goodwin, 1993) [29] 20. Interpretation An agent is interpretive if can correctly interpret its sensor ability readings (Goodwin, 1993).[29] 21. Sound An agent is sound if it is predictive, interpretive and rational (Goodwin, 1993).[29] 22. Proxy ability An agent can act on behalf of someone or something that is, acting in the interest of, as a representative of, or for the benefit of, some entity (Odell, 2000) [23]. 23. Intelligence The agent s state is formalized by knowledge and interacts with other agents using symbolic language (Odell, 2000).[23] 24. Unpredictability An agent is able to act in ways that are not fully predictable, even if all the initial conditions are known. It is capable of nondeterministic behaviour (Odell, 2000).[23] 25. Credibility An agent has a believable personality and emotional state (Odell, 2000). [23] 26. Transparency An agent must be transparent when required, but must provide and accountability a log of its activities upon demand (Odell, 2000). [23] 27. Competitiveness An agent is able to coordinate with other agents except that the success of one agent implies the failure of others (Odell, 2000). [23] 28. Ruggedization An agent is able to deal with errors and incomplete data robustly (Odell, 2000). [23] 29. Trustworthiness An agent adheres to laws of robotics and is truthful (Odell, 31

50 2000) [23] Agent-to-Agent Communications The agents must have the ability to pass the message between agents. Thus the agent facilities for sharing of data/information among agents in the environment are very important. In figure 2.7 shows agent data object that needs to be transmitted to another agent and converts it to a message format understood by the receiving agent. The message format that is used can be KQML (Knowledge Query and Manipulation Language) [30], FIPA (Foundation for Intelligent Physical Agents) [31] or some other Agent Communication Language (ACL) [32]. The message is then transmitted to the appropriate agent through the use of an agent messaging protocol/ software. The use of an ACL results in loosely coupled open systems, which only use message passing for collaboration and operation. The protocol/messaging software could be simple TCP/IP, IIOP or HTTP or other communications software. Figure 2.7: Agent Communication 32

51 2.5 The Open Agent Architecture (OAA) The Open Agent Architecture (OAA), developed by SRI International. It supports software services and facilitators for autonomous agents [33]. OAA provides access to agent-based applications through an intelligent, cooperative, distributed, and multimodal agent-based user interface. Communication and cooperation between agents are brokered by one or more facilitators, user or agent not need to know the identities, locations, or number of other agents involved in satisfying a request. OAA will minimize the effort involved in creating new agents in agent mediated applications. OAA supports different kinds of programming languages and platforms. Applications written in different languages and operating on different platforms can be encouraged to reuse of existing agents. It allows for dynamism and flexibility in the makeup of agent communities. Distinguishing features of OAA include extreme flexibility in using facilitator-based delegation of complex goals, triggers, and data management requests. The Inter agent Communication Language (ICL) of OAA is a logic-based declarative language capable of representing natural language expressions. Agents communicate with each other can use simultaneous multiple (natural) input modalities; humans can point, speak, draw, handwrite, or use standard graphical user interface when trying to get a point across to a collection of agents. Using ICL expression, agents themselves will compete and cooperate in parallel. These techniques, in combination with the use of special class of agents called Facilitator agents allow human users to closely interact with the ever-changing community of distributed agents. Figure 2.8, presents the structure that is typical for an OAA system, showing a user interface agent and several application agents and meta-agents, organized as a community of peers by their common relationship to facilitator agent. 33

52 Figure 2.8: Typical structure of OAA The goals of OAA may be categorized under three main headings, as follows [33]: 1. Versatile mechanisms of interoperation and coordination 2. human-oriented user interfaces 3. Realistic software engineering requirements 2.6 Rule Technology on Semantic Web Web services technology The Web service architectures involve several layered and interrelated technologies [34], such as XML, SOAP, WSDL (Web Service Description Language). Extensible Markup Language (XML) is a simple and very flexible text format derived from Standard Generalized Markup Language (SGML) [35]. It significantly reduces the burden of deploying several technologies to ensure the success of Web services. XML is a simplified subset of SGML. Its primary purpose is to facilitate the sharing of data across different information systems, particularly systems connected via the Internet [36]. SOAP [37] is 34

53 a lightweight protocol to exchange of information in a decentralized and distributed environment. It is an XML based protocol that consists of three parts: a)an envelope that defines a framework for describing what is in a message and how to process it, b)a set of encoding rules for expressing instances of application-defined data types, and c)a convention for representing remote procedure calls and responses. SOAP can be used in a large variety of systems ranging from messaging systems to RPC, like Web service. WSDL [38] is an XML format for describing network services as a set of endpoints operated on messages containing either document-oriented or procedure-oriented information. WSDL is extensible and allows description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. However, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME. UDDI [39] is a registry and repository for Web service discovery. Using UDDI the requester agent, the provider agent or some other agent can find an appropriate Web service. Figure 2.9, is Web services architecture Metadata Layer of Semantic Web Semantic Web is an extension of the current Web where information is given well-defined meaning, better enables computers and people to process in cooperation. Resources on the Web are given explicit meaning using markup language to make up a metadata layer in addition to the current information pool as summarized in Figure 2.9. The Web Ontology Language (OWL) [40] provides rules for defining knowledge structures, i.e., ontology, in order that instances of knowledge can be created based on the common structures. OWL is an extension to the Resource Description Framework (RDF) [41] by adding vocabularies used to define the knowledge structures instead of the tree structures in XML documents. 35

54 The Semantic Web framework can be summarized as providing a metadata layer in content-interoperable languages, mainly in RDF, which intelligent or automatic services can be made by machines based on the layer. The typical architecture for managing the metadata layer, for example, KA2 and Sesame, consists of an ontology-based knowledge warehouse and inference engine as the knowledge-based system to provide intelligent services at the front end, such as conceptual search and semantic navigation for user to access the content [128]. Figure 2.9: Architecture of the metadata layer of the Semantic Web 36

55 Figure 2.10: Semantic Web Service Layer Cake [42] In the backend is the content provision component, consisting of various tools for creating metadata from unstructured, semi-structured and structured documents Ontology What is Ontology There are a number of vocabulary terms we use, and sometimes abuse, in the AI community. These terms become even more confusing when we interact with other communities, such as web toolkit developers, who abuse some of the very same terms. One example of such a term is ontology, which was traditionally defined as 'the science or study of being' (Oxford English Dictionary). In AI, usually attributed to the notion of ontology is, essentially, "the specification of a conceptualization" -- that is, defined terms and relationships between them, usually in some formal (preferably machine-readable) manner. Even more complicated is the relationship between ontology and logics some people treat ontology as a subset of logic, some treat logic as a subset of ontological reasoning, and other uses have been bandied about.[43][44] 37

56 Protégé Protégé is a free, open-source platform that provides a growing user community with a suite of tools to construct domain models and knowledge-based applications with ontologies. Protégé implements a rich set of knowledge-modeling structures and actions that support the creation, visualization, and manipulation of ontologies in various representation formats. Protégé can be customized to provide domain-friendly support for creating knowledge models and entering data. Further, Protégé can be extended by way of a plug-in architecture and a Java-based Application Programming Interface (API) for building knowledge-based tools and applications. [45] The Protégé platform supports two main ways of modeling ontologies: The Protégé-Frames editor and The Protégé-OWL editor. The Protégé-Frames editor enables users to build and populate ontologies that are frame-based, in accordance with the Open Knowledge Base Connectivity protocol (OKBC) [46]. Protégé-OWL editor enables users to build ontologies for the Semantic Web, in particular in the W3C's Web Ontology Language (OWL). Protégé is a frame-based environment for knowledge based system development. Its knowledge model has been re-factored to meet the requirements of the recent OKBC standard [46]. Ontology in Protégé consists of classes, slots, facets and axioms [47]: Ontology consists of a set of classes organized in a subsumption hierarchy to represent the domain concepts. There a set of slots associated to classes to describe their properties and relationships, and a set of instances of those classes - individual exemplars of the concepts that hold specific values for their properties. Class: Ontology together with a set of individual instances of classes constitutes a knowledge base. Classes are the focus of most ontologies. Class frames specify domain concepts and are organized in a sub assumption hierarchy, which allow for multiple in 38

57 heritance. Classes are templates for individual instance frames. A class can have subclasses that represent concepts that are more specific than the super class. For example, we can divide the class of all wines into red, white, and rosé wines. Alternatively, we can divide a class of all wines into sparkling and no sparkling wines [48]. Slots: are special frames that can be attached to classes to define their attributes, with specific value type restrictions. Own slots define intrinsic properties of class or individual instance frames that do not get propagated either by inheritance or instantiation. Template slots are attached to class frames to define attributes of their instances, which in turn define specific values for slots. Slots in Protégé are first class objects. They can be specified both globally for the ontology and locally as attached to classes, where their properties are overridden. Each slot is an instance of a Meta slot class that defines its properties [49]. Facets: are properties of slots, which specify constraints on their allowed values. Examples are the cardinality of a slot value, its type (primitive, such as string or integer, or complex, such as instance of a class), range and default values, etc. Axioms are additional constraints that can be defined on frames, for example to link the values of a group of template slots attached to a class. As a very recent addition to Protégé, a constraint language enables developers to represent constraints throughout an ontology as sentences expressed in KIF-based [46] predicate logic. Protégé defines a set of built-in predicates and functions that can be used to express constraints. Protégé also provides functionality to evaluate the constraints and check that the individual instances in a knowledge base conform to those constraints [49]. In practical terms, developing an ontology includes: defining classes in the ontology, arranging the classes in a taxonomic (subclass super class) hierarchy, defining slots and describing allowed values for these slots, filling in the values for slots for instances [48]. 39

58 2.6.4 Policy and Rule Languages Policy languages constitute the first step in defining trust and security for semantic web resources. They define a framework for allowing web services to express their constraints and requirements. The main advantage in using policies is the possibility to dynamically change the behavior of a system by adjusting the policies without interfering with the internal code of the system [50]. Several policy languages have been proposed to protect the privacy of information and authorizing requesters by providing different levels of access control. The following paragraphs are a brief description of several well-known policy languages. Ponder2 [51, 52] Ponder is a policy language for specifying security and management policies for distributed systems. It provides a common unified framework for specifying management policy for heterogeneous platforms. Ponder supports following policy types: Authorization policies, Obligation policies, Refrain policies, Delegation policies, Composite policies, Constraints and Meta-policies. Ponder supports a complete toolkit for use of the language. Available components include: Ponder Compiler, Ponder Policy Editor and Ponder Management Toolkit. Ponder2 is designed by Java and XML. It is not a semantic policy language. XACML [53]: OASIS Extensible Access Control Markup Language (XACML) is a declarative access control policy language implemented in XML. It has a standard format describing how to interpret the policies and can control access to any type of resource. XACML contains an extremely flexible language for expressing access control. Its request and response protocols are Request Entry Point, Policy Storage Point, Policy Decision Point and Policy Enforcement Point (PEP). The process flows of XACML as following first send the incoming request from subject to the Request Entry Point, second converting the XACML request in XML form, third retrieval the XML policies from 40

59 Policy Storage Point, fifth making the decision and sending XACML response to PEP, last the PEP enforces decision on subject. XACML can support large-scale environments where resources are distributed and policy administration is federated. WS-Policy [54]: Web Services Policy Framework (WS-Policy) provides a general purpose model and corresponding syntax to describe and communicate the policies of a Web Service. WS-Policy has a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web Services-based system. WS-Policy defines three components policy expressions, policy assertions and policy operations. The Policy Expressions can be used as a container for application specific policies definition. Policy Assertions conveys a requirement, preference, or capability of a given policy. Policy operators describe policy identification mechanisms and provide a way to group assertions. KAoS [55]: KAoS is a set of platform-independent services that people can define policies for agents and traditional distributed systems. KAoS is one of the first efforts for representing policy using a Semantic Web language. KAoS uses ontology-based approach to semantic policy specification. KAoS policy s OWL definition is an instance of one of these four basic policy classes: PositiveAuthorization, NegativeAuthorization, PositiveObligation, or NegativeObligation. It converts the policy components to the RDF instances. KAoS has several important features Homogeneous policy representation, Maturity, Comprehensiveness, Pluggability, Scalability and performance. KAoS provides capabilities for verifying and enforcing user-defined policy when automatically planning and executing semantically described process workflows. Rei [56, 57]: Rei is a policy language based in OWL and RDF that allows policies to be specified as constraints over allowable and obligated actions on semantic web resources. The Rei policy language has some domain independent ontologies and users require 41

60 specific domain ontologies. Rei supports positive and negative authorization policies, obligation policies, delegation policies and revocation policies. Associated with the policy language, is a policy engine that interprets and reasons over the policies and speech. The core of the Rei policy language is the constructs that describe the demotic concepts of rights, prohibitions, obligations, and dispensations. The policy language also describes speech acts and the speech acts are based on the FIPA specifications [58]. RuleML [59,60]: RuleML has been conceived as a markup language for policies [ regulations, etc., building a hierarchy of rule sublanguages upon XML, RDF, OWL, and XSLT for publishing and sharing rule bases on the web. The RuleML language has been developed to express both forward (bottom-up) and backward (top-down) rules in XML. It is especially oriented towards four currently commercially important families of rule systems: SQL (relational databases), Prolog, production rule systems (cf. OPS5, CLIPS, Jess) and Event-Condition-ActRuleML [59, 60] RuleML has been conceived as a markup language for policies [ regulations, etc., building a hierarchy of rule sublanguages upon XML, RDF, OWL, and XSLT for publishing and sharing rule bases on the web. The RuleML language has been developed to express both forward (bottom-up) and backward (top-down) rules in XML. It is especially oriented towards four currently commercially important families of rule systems: SQL (relational databases), Prolog, production rule systems (cf. OPS5, CLIPS, Jess) and Event-Condition-Action rules (ECA). RuleML encompasses a hierarchy of rules, including reaction rules (event-condition-action rules), transformation rules (functional-equation rules), derivation rules (implicational-inference rules), also specialized to facts ('premiseless' derivation rules) and queries ('conclusionless' derivation rules), as well as integrity-constraints (consistency-maintenance rules) [59]. RuleML queries are thus regarded as headless implications, symmetrically to regarding facts as 42

61 bodiless implications. They enumerate the bindings of all their free (existentially interpreted) variables. Several rule engines have been developed for executing (different subsets of) RuleML. These include Mandarax [61], Prova [ OO jdrew, NxBRE [ and VDR-Device (version 0.27) [62]. RuleML largely grew out of the design approaches and criteria of pre-2000 rule markup languages such as RFML [ and BRML [ and has since co-evolved with similar efforts by DARPA, OASIS, OMG, and W3C. The above policy languages are all XML-based policy languages but in Table 2.4 we can see that KAoS, Rei and RuleML are also semantic policy languages. Ponder2, XACML and WS-Policy are non-semantic policy language. RuleML has been described as a leading approach to semantic policy languages [73]. Table 2.3: Comparing XML-based policy languages Semantic Language KAoS Rei RuleML Non-Semantic Language Ponder2 XACML WS-Policy 2.7 RDF RDF (Resource Description Framework) The resource description framework (RDF) [41] is a W3C standard for data interchange in World Wide Web. RDF is a XML type data to provide a mechanism for describing data and resource on the Web. RDF provides a model that we can describe Web information in a standard and machine readable format. It represents Web resource in a set of RDF 43

62 statements (triples). The RDF triples consist of three parts: a subject, a predicate and an object. A set of such triples is called an RDF graph. This can be illustrated by a node and directed-arc like following graph. Figure 2.11: RDF Graph To imagine trying to state that someone named Laichen Lu created a particular Web page. A straightforward way to state this in a natural language such as English would be in the form of a simple statement such as: has an Author whose value is Laichen Lu The RDF terms for the various parts of the statement are the subject is the URL the predicate is the word "Author" the object is the phrase "Laichen Lu" Representing in XML becomes as follows. <rdf:rdf xmlns:rdf= xmlns:t= > <rdf:description about= > <t:author>laichen Lu</t:author> </rdf:description> </rdf:rdf> The information layer represented by using RDF is a generic relational data model, describing the relationship between resources or between resource and atomic values 44

63 [130]. The meaning of the resources can then be found in the domain knowledge base, that is, ontology. The representation of ontology in the Semantic Web is an extension of RDF, OWL [40]. The RDF enables Web information to be expressed in a formal way that computer software can read, process and store. The Web can be annotated to a RDF metadata then we can use the knowledge base technology to manipulate it. The basic data model consists of three object types: Table 2.4 : RDF Objects [41] Resources All things being described by RDF expressions are called resources. Properties A property is a specific aspect, characteristic, attribute, or relation used to describe a resource. Statements A specific resource together with a named property plus the value of that property for that resource is an RDF statement. 2.8 Defeasible Logic Technology A Language of Defeasible Reasoning The Semantic Web will bring structure to the meaningful content of Web pages and creating an environment where software agents can manipulate sophisticated tasks for users. One of the issues that have recently attracted the concentration of the developers of the Semantic Web is the nature of the rule systems. Monotonic rule systems have already been studied and accepted as an essential part of the Semantic Web. Defeasible logic is an inheritance networks expressed in a logic rule language. Classical logic is monotonic, while new information add to our mind, it will compare with our early experiences and ability to retract or revise previous conclusions is 45

64 one of the essential features of commonsense reasoning. Nonmonotonic reasoning provides formal methods that enable intelligent systems to operate with incomplete or changing information. In particular, it provides rigorous mechanisms in the presence of new information turn out to be wrong and for deriving new, alternative conclusions instead. Nonmonotonic reasoning methods provide rigor similar to that of classical reasoning; they form a base for validation and verification and therefore increase confidence in intelligent systems that work with incomplete and changing information [63]. In a monotonic logic system: If we given a collection of facts F that for some sentence s (s is a logical conclusion of F), there has a collection of facts F such that F F, F also involves s. In other words: s is also a logical conclusion of any superset of F. In a nonmonotonic system: The addition of new facts can reduce the set of logical conclusions. So, if s is a logical conclusion of F, it is not necessarily a conclusion of any superset of F. Nonmonotonic systems are capable of adding and retracting beliefs as new sets of information is available, and reasoning with an incomplete set of facts. Defeasible logic, which was introduced by Donald Nute [64], is a representative language of nonmonotonic reasoning. In general, a defeasible theory (a knowledge base in defeasible logic) consists of five different kinds of knowledge: facts, strict rules, defeasible rules, defeaters, and a superiority relation. Facts: Facts are indisputable statements, for example, Dr. Yeh is a Professor. Written formally, this would be expressed as: professor(yeh). 46

65 Strict: Strict rules are rules in the classical sense: whenever the premises are indisputable (e.g. facts) then so is the conclusion. An example of a strict rule is professors are faculty members. Written formally: professor(x) faculty(x) Defeasible rules: Defeasible rules are rules that can be defeated by contrary evidence. An example of such a rule is Faculty members are typically tenured ; written formally: faculty(x) => tenured(x) The idea is that if we know that professors are faulty members and then we may conclude that they are typically tenured, unless there is other evidence suggesting that they are not tenured. Defeaters: Defeaters are rules that cannot be used to draw any conclusions. Their only use is to prevent some conclusions. In other words, they are used to defeat some defeasible rules by producing evidence to the contrary. An example is Assistant professors may be not tenured ; written formally: assistantprof(x) ~> tenured(x) The main point is that the information that an assistant professor is not sufficient evidence to conclude that it doesn t tenured. It is only evidence against the conclusion that assistant professors are tenured. In other words, we don t wish to conclude tenured if an assistant professor, we simply want to prevent a conclusion tenured. superiority relation: The superiority relation among rules is used to define priorities among rules, that is, 47

66 where one rule may override the conclusion of another rule. For example, given the facts Professor visiting and the defeasible rules r: Professor(X) => tenured(x) s: visiting(x) => tenured(x) Which contradict one another, no conclusive decision can be made about whether a visiting professor is tenured. But if we introduce a superiority relation > with s > r, then we can indeed conclude that the visiting professor is not tenured. The superiority relation is required to be acyclic. For each literal p we define the set of p-complementary literals (C(p)), that is, the set of literals that cannot hold when p does. Let us consider an example; let us suppose we have the predicates married and bachelor. Here, we define, for any constant x, C(married(x)) ={ married(x),bachelor(x)}. We know that, under the usual interpretation of the predicates they cannot be true at the same time for one and the same individual. We stipulate that the negation of a literal is always complementary to the literal. Another point worth noting is that, in Defeasible Logic, priorities are local in the following sense: two rules are considered to be competing with one another only if they have complementary heads. Thus, since the superiority relation is used to resolve Background Theory and Related Work conflicts among competing rules, it is only used to compare rules with complementary heads; the information r > s for rules r, s without complementary heads may be part of the superiority relation, but has no effect on the proof theory [65] Formal Definition In this thesis we restrict attention to essentially propositional Defeasible Logic. Rules with 48

67 free variables are interpreted as rule schemas, that is, as the set of all ground instances. If q is a literal q denotes the complementary literal (if q is a positive literal p then q is p; and if q is p, then q is p). Rules are defined over a language (or signature) Σ, the set of propositions (atoms) and labels that may be used in the rule. In cases where it is unimportant to refer to the language of D, Σ will not be mentioned. A rule r: A(r) C(r) consists of its unique label r, its antecedent A(r) (A(r) may be omitted if it is the empty set) which is a finite set of literals, an arrow (which is a placeholder for concrete arrows to be introduced in a moment), and its head (or consequent) C(r) which is a literal. In writing rules we omit set notation for antecedents, and sometimes we omit the label when it is not relevant for the context. There are three kinds of rules, each represented by a different arrow. Strict rules use, defeasible rules use =>, and defeaters use ~>. Given a set R of rules, we denote the set of all strict rules in R by Rs, the set of strict and defeasible rules in R by Rsd, the set of defeasible rules in R by Rd, and the set of defeaters in R by Rdft. R[q] denotes the set of rules in R with consequent q. A superiority relation on R is a transitive relation > on R. When r1 > r2, then r1 is called superior to r2, and r2 inferior to r1. Intuitively, r1 > r2 expresses that r1 overrules r2, should both rules be applicable. Typically we assume > to be acyclic (that is, the transitive closure of > is irreflexive). A defeasible theory D is a triple (F, R, >) where F is a finite set of literals (called facts), R a finite set of rules, and > an acyclic superiority relation on R. D is called decisive if the atom dependency graph of D is acyclic [65]. 49

68 2.8.3 Proof Theory A conclusion of a defeasible theory D is a tagged literal. There are for tags, so a conclusion has one of the following four forms: + Δq which is intended to mean that q is definitely provable in D. Δq which is intended to mean that we have proved that q is not definitely provable in D. + q which is intended to mean that q is defeasibly provable in D. q which is intended to mean that we have proved that q is not defeasibly provable in D. If we are able to prove q definitely, then q is also defeasibly provable. This is a direct consequence of the formal definition below. It resembles the situation in, say, default logic: a formula is skeptically provable from a default theory T = (W, D) (in the sense that it is included in each extension) if it is provable from the set of facts W. Provability is defined below. It is based on the concept of a derivation in D = (F,R,>). A derivation is a finite sequence P = (P(1),,P(n)) of tagged literals satisfying the following conditions (P(1..i) denotes the initial part of the sequence P of length i): + Δ : If P(i + 1) = +Δ q then either q F or r Rs[q] a A(r):+Δ a P(1..i). Figure 2.12: Definite Provability in Defeasible Logic [65] That means to prove + Δ q we need to establish a proof for q using facts and strict rules only. This is a deduction in the classical sense - no proofs for the negation of q need to be considered (in contrast to defeasible provability below, where opposing chains of reasoning must be taken into account, too) [65]. To prove Δ q, i.e., that q is not definitely provable; q must not be a fact. In addition, 50

69 we need to establish that every strict rule with head q is known to be inapplicable. Thus for every such rule r there must be at least one antecedent a, for which we have established that a is not definitely provable ( Δ a, Figure 2.13). It is worth noticing that this definition of nonprovability does not involve loop detection. Thus if D consists of the single rule p p, we can see that p cannot be proven, but Defeasible Logic is unable to prove Δ p [65]. Δ: If P(i + 1) = Δ q then q F and r Rs[q] a A(r): Δ a P(1..i). Figure 2.13: Definite Non-provability in Defeasible logic [65] + : If P(i + 1) = + q then either (1) + Δ q P(1..i) or (2) (2.1) r Rsd [q] a A(r): + a P(1..i) and (2.2) Δ q P(1..i) and (2.3) s R[ q] either (2.3.1) a A(s): a P(1..i) or (2.3.2) t Rsd [q] such that a A(t):+ a P(1..i) and t > s. Figure 2.14: Defeasible Provability in Defeasible Logic [65] To show that q is provable defeasibly (+ q Figure 2.14) we have two choices: (1) We show that q is already definitely provable; or (2) we need to argue using the defeasible part of D as well. In particular, we require that there must be a strict or defeasible rule with head q, which can be applied (2.1). But now we need to consider possible attacks, i.e., reasoning chains in support of q. To be more specific: to prove q defeasibly we must show that q is not definitely provable (2.2). Also (2.3) we must consider the set of 51

70 all rules which are not known to be inapplicable and which have head q. Essentially each such rule s attacks the conclusion q. For q to be provable, each such rule s must be counterattacked by a rule t with head q with the following properties: (i) t must be applicable at this point, and (ii) t must be stronger than s. Thus each attack on the conclusion q must be counterattacked by a stronger rule [65]. The definition of the proof theory of Defeasible Logic is completed by the condition. It is nothing more than a strong negation of the condition +. : If P(i + 1) = q then (1) Δ q P(1..i) and (2) (2.1) r Rsd [q] a A(r): a P(1..i) or (2.2) + Δ q P(1..i) or (2.3) s R[ q] such that (2.3.1) a A(s):+ a P(1..i) and (2.3.2) t Rsd [q] either a A(t): a P(1..i) or t s. Figure 2.15: Defeasible Non-provability in Defeasible Logic [65] To prove that q is not defeasibly provable, we must first establish that it is not definitely provable. Then we must establish that it cannot be proven using the defeasible part of the theory. There are three possibilities to achieve this: either we have established that none of the (strict and defeasible) rules with head q can be applied (2.1); or q is definitely provable (2.2); or there must be an applicable rule s with head q such that no possibly applicable rule t with head q is superior to s (2.3). The elements of a derivation P in D are called lines of the derivation. We say that a 52

71 tagged literal L is provable in D = (F, R, >), denoted D L, if there is a derivation in D such that L is a line of P. When D is obvious from the context we write L [65]. 2.9 Related ebxml CPA Negotiation Researches There are many researches about ebxml CPA negotiation. In this section, we present a survey of previous contributions in these areas. Hsun-Ming Lee et al [100]: They propose use the semantic web and rule base technologies for ebxml CPA negotiation. The semantic Web rules, which represent human logic, allow the negotiation agents to exchange documents and make strategic decisions with rules. The use of rules allows XML-formatted agenda and explanation information to be communicated effectively to facilitate the B2B negotiation process. The agenda information strategy specifies the order in which issues are negotiated in multi-issue negotiation. The explanations information strategy comprises additional information that explains why an offer is made or rejected in the argumentation-based negotiation model. They use the SWRL [101], OWL [102] and RuleML [103] as their rule based negotiation language. A key advantage of their application is the mobility of semantic Web rules in the B2B environment and the reusable of rule base system. Hung-Wen Tung et al 2005 [104]: They propose implementing a mediation protocol based on a solid game-theoretic work to the problem of ebxml CPA negotiation. They create a mediator to analyze the CPPs of the negotiation parties to identify the conflicts between parties. These conflicts provide the negotiation issues. The mediator uses these them to generate the proposals for the negotiating parties. After receiving proposals, the software agent uses the utility function of the representing business party to assess each proposal and rank the proposal. When the mediator has received the preferred proposals of each party, then it recombined and mutated to create a new set of proposals. The concepts of the recombination and mutation are borrowed from the Genetic 53

72 Algorithm [105] and applied to the set of contracts. Finally, the parties and the mediator will perform the sequential-voting mediation protocol (SVMP) in [106]. In SVMP, the mediator permits both agents to simultaneously choose their preferred contracts by giving them a vote. If one or two contracts receive two votes, the mediation ends and the mediator randomly selects one of the contracts as the final agreement. The offer-counter-offer approach in current ebxml is not adequate enough for complex contract negotiations under two-sided uncertainty due to the recursive Bayesian update problem and the delaying agent problem. Besides, it is difficult for the negotiation to achieve a win-win agreement without mediation. Their research solves the above problem in ebxml CPA negotiation. Michael Rebstock et al 2003 [107]: Main objective in their research is the definition of a generic protocol for bilateral multi-attribute electronic negotiations using ebxml. They are modeling and specification of the negotiation process and negotiation objects. The negotiation process is modeled using the ebxml Business Process Specification Schema (BPSS). UML diagrams are used for graphical representations. They add data models (class diagrams) to the process models. Their approach is to put the necessary reference information into the documents exchanged. They developed ebxml process and object definitions and suggest modifications of and additions to the current ebxml standard. Within their models, there are two different types of conditions: Condition Guards and Condition Expressions. Condition Expressions can be defined freely within ebxml. Condition Guards are used with simple Boolean results. With Condition Expressions, more complex expressions can also be implemented. Their approach is process-oriented: it primarily supports the process of the negotiation as an exchange of structured documents, but leaves the final decision about a contract to human actors. They also focus on bilateral and interactive, multi-attribute negotiation, as this kind of 54

73 negotiation is pre-dominant in the business domain. The formalized exchange process of structured, well-defined documents is one of the key elements of their approach. The negotiation semantics is a key factor for the success of electronic markets and electronic commerce. Their approach copes with semantic variety, i.e., the concurrent existence of multiple semantic reference systems. Their concept and prototype deal with a limited situation for electronic negotiations. Hioual and Boufaida 2006 [108]: They suggest integrating a protocol of negotiation as heuristic negotiation in conjunction with the intelligent agent approach, in order to negotiate the CPP's parameters to lead to an accepted CPA. They indicate that the negotiation can be seen as a Constraint Satisfaction Problem (CSP) and in particular as a Distributed CSP (DCSP). CSPs are defined by a set of variables with associated domains, and a set of constraints on those variables. The objective is to find an instantiation of all variables while meeting all the constraints at the same time. A DCSP is a version of a CSP where variables are distributed among different agents [109]. The proposed protocol in their research is based on the principle of the heuristic model of negotiation. Each rejection of a negotiator agent will be accompanied by an informational message in the form of a criticism indicating the reasons for which a proposition was disallowed. According to the contents of a criticism there will be two possible cases of figure: either the receiving agent reformulates a new proposition or counter-proposition by taking into account the received criticism, or it announces the end of the process of negotiation with failure. Thus, the internal evaluation function of a criticism is in the form of a list of conditions and results. Propositions' generation is the main process of decision-making. It directs the negotiation's progression. It includes the search for perspective solutions towards an agreement of the negotiation. In order to generate a proposition (counterproposition), the negotiator agent uses the Constraints Satisfaction Problem (CSP) 55

74 reasoning in order to lead to a possible solution. Based on this model of reasoning, each agent has values' constraints on which the attributes (negotiable parameters) must take. So a proposition which does not check these constraints will be disallowed without evaluation. Their solution for CPA negotiation can optimize the negotiation process by minimizing time and distance. Yu-Liang Chi et al [110]: Based on a negotiation protocol model from OASIS, their research developed several algorithms, such as combination, intersection of negotiation items, and barging procedure, to improve the negotiation process especially in automatic purpose. They also integrate these algorithms into a Web-based platform, called Automated Collaboration and Negotiation Platform (ACNP). The ACNP provides a robust and efficient solution for accelerating a negotiation process within ebxml CPA. The ACNP has following architecture: 1) ebxml registry and search engine, 2) CPP/NDD creator/editor, they create a web based CPP/NDD creator and editor for CPP/NDD produce and editor. 3) CPP and INDD (Initial NDD) combination tools, combines ebxml INDD to CPA template. 4) CPA negotiation engine, negotiation engine for CPA negotiation. For ebxml CPA negotiation, they create following algorithms: First, Combination algorithm, this algorithm combines two ebxml CPP into one CPA Template. Second, INDD intersection algorithm, in ebxml CPA negotiation there has the INDD document between two parties. We have to find out the intersection parts between two INDDs and create a new negotiation NDD. So they create an INDD intersection algorithm for INDD combination. Third, Barging algorithm, the items in INDD is the negotiable items between trading partners. They create a negotiable Barging algorithm for ebxml CPA negotiation. The Web-based platform ACNP doing following procedures: First, a CPP create and search platform, which can create and edit ebxml CPP and INDD. Second, Combine the CPA Template and INDD documents. Third, 56

75 Execute the CPA negotiation process. Their researches propose a negotiation environment and some negotiation algorithm for ebxml CPA negotiation Related Defeasible Logic Researches We propose use defeasible logic approach for ebxml CPA negotiation. In this section, we present a survey of previous contributions in these areas. Nick et al. [111], developed a defeasible logic inference engine called DR-DEVICE, it is capable of reasoning about RDF metadata over multiple Web sources using defeasible logic rules. The DR-DEVICE has following features: Full implementation of defeasible logic, including strict and defeasible rules and defeaters, priorities among rules, conflicting literals, two types of negation and multiple variants regarding ambiguity. The reasoning can manipulate incomplete and inconsistent information. It is compatible with the RuleML syntax and processing of information in the Semantic Web standards of RDF and RDF Schema. DR-DEVICE is Efficiency, due to the low computational complexity of the formalism. The system is freely available for downloading and experimentation (including the test case presented above). Grigoris, Antonis and Gerd [112]: Implementation of a defeasible reasoning system for reasoning on the Web. Its main characteristics are: first, its user interface is compatible with RuleML, the main standardization effort for rules on the semantic web. Second, the core of the system consists of a translation of defeasible knowledge into Prolog. However, the implementation is declarative because it interprets the not operator using Well-Founded Semantics [113]. Third, strict and defeasible rules and priorities are part of the implementation. Also, a number of variants were implemented (ambiguity blocking, ambiguity propagating, conflicting literals). Governatori et al. [114]: propose an application of defeasible logic for automated negotiation. They describe some defeasible logic theory and propose two case studies, one 57

76 small and one more comprehensive for defeasible logic negotiation. They demonstrate the defeasible logic theories and some case studies for defeasible negotiations. They shows that how defeasible logic can be used to describe both protocols and strategies. Skylogiannis et al. [115], reports on a system for automated agent negotiation using defeasible logic. It uses the JADE agent framework, and its major distinctive feature is the use of declarative negotiation strategies. The negotiation strategies are expressed in a defeasible logic rules language. They use the DR-DEVICE as inference engine and demonstrate some example about automated agent negotiation. Grigoris Antoniou and Antonis Bikakis [116], It presents an implemented defeasible reasoning system (DR-Prolog), which has been tested, evaluated, and compared with existing similar implementations. They also show how we can combine the expressive power of a nonmonotonic logic (defeasible logic) with the Semantic Web technologies (RDF(S), OWL, and RuleML) to build applications for the logic and proof layers of the Semantic Web. The main characteristics of DR-Prolog are the following: First its user interface is compatible with RuleML, the main standardization effort for rules on the Semantic Web. Second, it is based on Prolog. The core of the system consists of a well-studied translation [117] of defeasible knowledge into logic programs under Well-Founded Semantics [118]. Third, the main focus is on flexibility. Strict and defeasible rules and priorities are part of the interface and the implementation. Fourth, the system can reason with rules and ontological knowledge written in RDF Schema (RDFS) or OWL. Antoniou et al. [119], extend defeasible logic with modal and demotic operators, and make the implementation. They also model the policies of defeasible reasoning. Policies play crucial roles in enhancing security, privacy and usability of distributed services and extensive research has been done in this area, including the Semantic Web 58

77 community. It encompasses the notions of security policies, trust management, action languages and business rules. There system provides a Graphical User Interface based on Java Foundation Classes (Swing) and use the DR-POLOG as their inference engine. 59

78 CHAPTER 3 AGENT-MEDIATED ARCHITECTURE FOR EBXML FRONT-END SYSTEM The development of ebxml applications is divided into three phrases, discovery, implementation, and run-time. In the discovery phase, a pair of potential partners finds out each other through a registry and negotiates to reach an agreement specified in an XML document, CPA. In the implementation phase, the content of CPA is transformed into executable code at both sides which is used in the run-time phase. The transformation of CPA document into executable code can be done in either manual or automatic ways. The relationship of collaboration between trading partners in EB is dynamic, in other words, a new CPA may be created for a new trading partner or an existing one may be updated when needed. Thus, we employ a declarative approach for the design of the collaboration program to account for the dynamic situation. The idea is to separate the business collaboration knowledge and control engine in the collaboration program. The former part is constructed from CPA. The collaboration program for a CPA is therefore formed by combining the control engine with the specific business collaboration knowledge. Having the collaboration program built, the system also needs functions for managing the run-time status of the collaboration programs engaging with various counterparts. The management functions include creating a new collaboration issued by the back-end system, modifying or deleting existing collaborations, and querying the status of the running collaborations. In this thesis we employ a facilitator agent in agent architecture, OAA [66], for example, to implement the management functions. Each 60

79 collaboration program is therefore wrapped as a collaboration agent in the agent architecture. This results in agent architecture for ebxml application as shown in Figure 3.1. Compared with the conceptual structure shown in Figure 3.1, the ebxml agent architecture in Figure 3.1 corresponds to the front-end system of a party. The counterparts, Companies A, B and C, are simply represented in boxes, which mean they may have their own implementations of ebxml systems. The business service agents and message service agents are used to realize the business process and message service layer, respectively. In ebxml, business collaboration consists of business protocol and the message service [7]. The back-end system contacts the Facilitator agent to invoke new business collaboration, which in turn creates a Business Service Agent. The Business Service Agent invokes the Message Service Agent to for sending and receiving message the counterpart. User can invoke the UI agent to access through graphical user interface the services provided by the ebxml agent architecture. The Business Information Agent provides business information in CPA or BPSS for other agents. 61

80 Figure 3.1: Agent architecture for ebxml application In the ebxml agent architecture, CPP Agent, CPA Negotiation Agent and Discovery Agent are used in the discovery phase in ebxml application development. The CPP Agent is used to manage the collaboration protocol profile. The CPA Negotiation Agent is used when negotiating with a potential trading partner to achieve an agreement of collaboration protocol. The Discovery Agent is used to find out potential trading partner. In this thesis, we focus on the design of the UI, Message Service, Business Service, and Business Information Agents for ebxml front-end system. The rest agents in the architecture will be study in the future. 62

81 CHAPTER 4 TRANSFORMATION OF EBXML CPAS INTO EXCUTABLE CODE USING FINITE STATE MACHINE As described in previous chapter a business service agent is created to take care of a business dialogue with the counterpart using the same common business processes. The specification of the common business processes agreed by a pair of trading partners is documented in a CPA file. The agent is created according to the content of the CPA. In this chapter, we describe how to create the agent from the CPA document. 4.1 Structure of CPA The top level of a CPA document is a CollaborationProtocolAgreement element, having embedded elements about status, life time, and limits on the conversation under the CPA, information of both parties of the agreement, packaging, and security information. Within these embedded elements, the PartyInfo element is used to build the business agent and message service agent. The overall structure of the PartyInfo element is as follows. <PartyInfo partyname=... defaultmshchannelid=... defaultmshpackageid=... > <PartyId tp:type=... >... </PartyId> <PartyRef xlink:href=... /> <CollaborationRole>... </CollaborationRole> <Certificate>... </Certificate> <!-- one or more --> <SecurityDetails>... </SecurityDetails> <!-- one or more --> <DeliveryChannel>... </DeliveryChannel> <!-- one or more --> <Transport>... </Transport> <!-- one or more --> <DocExchange>... </DocExchange> <!-- one or more --> 63

82 <OverrideMshActionBinding>... </OverrideMshActionBinding> <!-- zero or more --> </PartyInfo> The PartyInfo element contains three required attributes, partyname, defaultmshchannelid, and defaultmshpackageid indicates the human readable name of the organization, and identify the default channel and packaging method to be used when sending message service handler level messages. The PartyId and PartyRef provide logical identifiers for the organization and pointers to more information about the party, respectively. The CollaborationRole element contains information about the specific role the party plays in the business collaboration. It is main source of information for the creation of business service agents in Figure 3.1. Following elements provide information used to construct the message service agents, including the certificate and security information, and the specifications of delivery channels and the transport and document exchange methods used in the channels. In this thesis we focus on the creation of business service agent, while leave the message service agent realized using existing technology. 4.2 Establishing Business Collaboration As mentioned previously, the CollaborationRole element provides information for the creation of business service agents. A sample structure of the element is shown as below. <CollaborationRole> <ProcessSpecification version= 2.0a name= PIP3A4RequestPurchaseOrder xlink:type= simple xlink:href= /> <Role name= Buyer xlink:type= simple xlink:href= /> <ApplicationCertificateRef certid= CompanyA_AppCert /> <ServiceBinding> </ServiceBinding> </CollaborationRole> 64

83 The first nested element links to the file containing business process specification, here the RosettaNet business process PIP 3A4 1, i.e., creating purchase order request. The second element indicates the role the party plays in the PIP 3A4 business collaboration, here the buyer. The third element specifies the certificate the party used in the business collaboration. Finally is the detailed information about the services of document and acknowledgement sending and receiving in the business collaboration. Consider the situation that a request issued from the GUI (or the backend system) of Company A that Company A wants to do the business collaboration with a company, say Company B. A UI agent is then created in response to the request. The UI agent obtains the CPA information of Company B, CPP B, from the BIA. It extracts from the PartyInfo element all the business process specifications and presents for user to choose the one desired. After choosing the business collaboration, it then asks user the content of business collaboration. For example in the purchase order request collaboration as mentioned above, user indicates the XML file of the purchase order document. After collecting the necessary information, a business service agent is created by the facilitator agent according to the specified process specification, 3A4.xml in the above example. The process specification is created based on the schema of BPSS [14]. In the following we devise a two-level finite state model for BPSS and then create business service agents and the associated message service agents based on the model. 1 We assume the existence of the destination shown here. The file 3A4.xml is represented in BPSS. 65

84 4.3 Two-Level Finite State Model for BPSS In ebxml infrastructure, the collaborations between a pair of companies are defined using the business process schema, BPSS. We start from the business transaction element in the BPSS that is the most essential part describing the business dialogue. A business transaction consists of a pair of business activities, requesting and responding, with the exchanged document and the required reliability level indicated within each business activity. Figure 4.1, shows the conceptual diagram of business transaction. An example of business transaction based on RosettaNet PIP 3A4 [12] is shown as below. <BusinessTransaction name= NewPurchaseOrder > <RequestingRole name="buyer" nameid="requester-bt"/> <RespondingRole name="seller" nameid="responder-bt"/> <RequestingBusinessActivity name= isauthorizationrequired= true isintelligiblecheckrequired= true isnonrepudiationreceiptrequired= true isnonrepudiationrequired= true timetoacknowledgereceipt= PT2H timetoacknowledgeacceptance= PT24H > <DocumentEnvelope businessdocument= PurchaseOrderRequest /> </RequestingBusinessActivity> <RespondingBusinessActivity name= isauthorizationrequired= true isintelligiblecheckrequired= true isnonrepudiationrequired= true > <DocumentEnvelope businessdocument= PurchaseOrderConfirmation ispositiveresponse= true /> </RespondingBusinessActivity> </BusinessTransaction> 66

85 Figure 4.1: Conceptual diagram of business transaction. A business transaction activity refers to a business transaction and adds the initiating and reacting roles of the transaction. For example, the following business transaction activity refers to the above business transaction, NewPurchaseOrder. <BusinessTransactionActivity name= CreatePurchaseOrder businesstransaction= NewPurchaseOrder > <Performs currentroleref="buyerid" performsroleref=" requester-bt"/> <Performs currentroleref="sellerid" performsroleref=" responder-bt "/> </BusinessTransactionActivity> The content of business collaboration is a flow of business states, each of which is a business transaction activity or business collaboration activity, and pseudo states. An example of business collaboration, ManagePurchaseOrder as shown below, first of all creates purchase order by buyer, and the seller may either accept the order or notify the buyer to change the order if there are items pending. In this example, there are two business transaction activities, namely, CreatePurchaseOrder and 67

86 UpdatePurchaseOrderNotitification, and a transition from the former activity to the latter one. <BusinessCollaboration name= ManagePurchaseOrder timetoperform= P5D > <Role nameid="buyerid" name="companya"/> <Role nameid="sellerid" name="companyb"/> <Start> <ToLink tobusinessstateref="createpurchaseorder"/> </Start> <BusinessTransactionActivity name= CreatePurchaseOrder businesstransaction= NewPurchaseOrder > <Performs currentroleref="buyerid" performsroleref=" requester-bt"/> <Performs currentroleref="sellerid" performsroleref=" responder-bt "/> </BusinessTransactionActivity> <BusinessTransactionActivity name= UpdatePurchaseOrderNotification businesstransaction= UpdatePurchaseOrderNotification > <Performs currentroleref="sellerid" performsroleref="requester-bt"/> <Performs currentroleref="buyerid" performsroleref="responder-bt"/> </BusinessTransactionActivity> <Transition name="bc-transition" nameid="bc-requestpurchaseorder-1"> <FromLink frombusinessstateref="createpurchaseorder"/> <ToLink tobusinessstateref="updatepurchaseordernotification"> <ConditionExpression expressionlanguage="xpath" expression= //PurchaseOrderConfirmation/PurchaseOrder[@GlobalPurchaseOrderSta tuscode=pending] /> </ToLink> </Transition> <Success name="bc-success" nameid="bc-createpurchaseorder-success"/> <Failure name="bc-failure" nameid="bc-createpurchaseorder-failure"/> <Success name="bc-pending-success" nameid="bc-updatepurchaseordernotification -Success"/> <Failure name="bc-pending-failure" nameid="bc-updatepurchaseordernotification -Failure"/> <Decision> <FromLink frombusinessstateref=" CreatePurchaseOrder "/> <ToLink tobusinessstateref="bc-createpurchaseorder-success"> <ConditionExpression expressionlanguage=" XPath " expression="//purchaseorderconfirmation/purchaseorder[@globalpurchaseordersta tuscode=accept]"/> </ToLink> <ToLink tobusinessstateref="bc-createpurchaseorder-failure"> <ConditionExpression expressionlanguage=" XPath " expression="//purchaseorderconfirmation/purchaseorder[@globalpurchaseorderstat uscode=failure]"/> </ToLink> </Decision> <Decision> <FromLink frombusinessstateref="updatepurchaseordernotification "/> <ToLink tobusinessstateref="bc-pending-success"> <ConditionExpression expressionlanguage=" XPath " expression="//purchaseorderconfirmation/updatepurchaseorder[@globalpurchaseor derstatuscode=accept]"/> </ToLink> <ToLink tobusinessstateref="bc-pending-failure"> <ConditionExpression expressionlanguage=" XPath " expression="//purchaseorderconfirmation/updatepurchaseorder[@globalpurchaseord erstatuscode=failure]"/> </ToLink> </Decision> </BusinessCollaboration> In BPSS, five pseudo states are defined as auxiliaries for specifying choreography, including the start (Start), the completion (Success and Failure) and the concurrent 68

87 execution (Fork and Join). A Start state leads to the initial state CreatePurchaseOrder in this example. A business state can lead to either Success or Failure state, depending on the kind of response documents received and the specific content in the document in the business transaction activity. In the above example, the CreatePurchaseOrder activity leads to successful completion if the positive response document PurchaseOrderConfirmation is received and the path specified in the nested ConditionExpression element is evaluated to Accept. If the negative responsive document is received, it leads to the failure state. In brief, the choreography of the above example can be represented as a finite state machine as shown in Figure 4.2 (Grimaldi 2004). Figure 4.2: A finite state machine for the choreography of a business collaboration Based on the above description about business collaboration, we thus formulate a finite state machine to model the business collaboration. The finite state machine, M, for the business collaboration, BC, consists of the following parameters: Q: a finite set of states, consisting of the pseudo states and business states in BC Σ: a set finite input condition symbols from the transition conditions, including empty input 69

88 Start: the start pseudo state F: the set of final states, {Failure, Success} δ(q, i): the transition function between states defined as follows: for empty input, δ(start, ε) returns the initial business state in BC, and for an input symbol i Σ, δ(q, i) returns a new state q Q. The transitions over the finite state machine represent the higher level workflow of the business collaboration, i.e., the choreography in the business collaboration. On entering a business state, it calls for the execution of a lower level workflow, i.e., the actual document flows between the collaboration parties. In the lower level workflow the states are adapted formed from the semantics of business transaction in BPSS as described earlier in this chapter. 4.4 Creating Business Service Agents based on the Two-level Model As described previously, a business service agent is created to account for the business protocol specified in the process specification. In the preceding section, we devise a two-level finite state model to describe the business collaboration in BPSS. The creation of a business service agent is thus achieved through the implementation of the two-level model. The implementation of the two-level model is divided into two tasks. First is to build up the finite state machine of the upper model by extracting the relevant elements from the BPSS file. Second is to design a parametric business transaction program that is invoked given the requesting and responding roles when entering a business state in the upper model. Given a process specification, PS, the finite state machine, FSM PS, of the upper model is made by the following steps. Step 1: Select all the business states from business transaction activities under business collaborations in PS. The resulting set of business states is combined with the set 70

89 of pseudo states, Start, Success, Failure, Fork, and Join to become the finite set of states, Q, of FSM PS. For example the set of states shown in Fig. 4.2 is formed from the business collaboration in Sec Step 2: Collect the set of finite input condition symbol Σ and establish the transition function of FSM PS. A condition symbol consists of two parts: one is the value of conditionguard of the transition element (Transition, Decision) and completion (Success and Failure) elements and the other is the evaluation result of the ConditionExpression elements embedded in the former elements. The source and destination states of transition can be obtained from the element on constructing a condition symbol. For example, in Figure 4.2, the transition from BTA cpo to BTA upon is from the transition element of the business collaboration in Sec In the upper mode, when the flow in the finite state machine enter a business state, it further enters the flow of the lower model and waits for the responding result to determine what the next state is. The flow of the lower level is based on the business transaction as shown in Figure 4.3. Recall that a business transaction consists of a pair of activities, requesting and responding. Each of the activity is performed by a role as indicated in the business transaction activity in business collaboration. We thus design two modules, named RequestingActivityModule and RespondingActivityModule, which are used to realize the flow of the requesting and responding activities in business transaction, respectively. In BPSS, each activity in business transaction may have its specific reliability and security levels as specified in the attributes of the activity elements. Thus each module is associated with a set of parameters for specifying the reliability and security levels need to be taken into account when performing the actual flow of documents and acknowledgement signals. The actual flow in each module is realized by invoking the accompanied message service agent of the business service agent. 71

90 The complete message services in ebxml consists of the core functionality and additional features as defined in ebms 2.0 [67]. A message service handler of ebxml must support the core functionality, including the security, error handling and synchronous reply modules. The additional features may be selected to implement, including reliable messaging module, message status service, ping service for message service handler, message order service and multi-hop service. The message service agents in the architecture shown in Figure 4.3 perform the message services as defined in ebms 2.0. In this thesis, we do not implement the message service handler for the message service agents. Instead we choose from open sources the implementations of message service handler or SOAP module as the engines and wrap them to be the message service agents. Here we simply treat the structure of message service agent as sending and receiving message modules. Zooming in the business service agent and the message service agent in Figure 4.3, the structures of both agents along with the business information service agent is summarized as shown in Figure

91 Figure 4.3: Structure of business service agent and message service agent 73

92 CHAPTER 5 BUILDING EBXML CPA NEGOTIATION AGENT BASED ON DEFEASIBLE LOGIC TECHNOLOGY 5.1Negotiation Theory Negotiation is a process by which two or more parties make a joint decision [69]. If we hope to achieve our own goals about personal benefit and outcomes, we have to negotiate with others. Negotiating is a process of exchange, a give and take between two or more parties to resolve a conflict and reach an outcome that can be perceived as mutually beneficial. The goal of negotiation is a preservation of the relationship and also a mutually acceptable outcome. Typically, negotiation takes place informally: over the telephone, at a quick meeting and using the computer. Cooperative negotiation is a particular kind of negotiation where agents cooperate and collaborate to obtain a common objective. This kind of negotiation has been currently adopted in resource and task allocation fields [68][69]. An agent negotiation is a group of agents come to a mutually acceptable agreement on some matter. The automated negotiation research can be considered to deal with three broad topics [70][71]: Negotiation Protocols: The negotiation protocol is the way and manner that interact and exchange information between negotiating parties. It includes the permissible types of negotiation parties, the negotiation states, the events that cause negotiation states to change and the valid actions of the negotiation parties in particular states. Negotiation Objects: The range of issues over which agreement must be reached. The object may contain a single issue such as price, while on the other hand it may cover hundreds of issues (related to price, quality, timings, penalties, terms and conditions, etc.). 74

93 The negotiation parties have the flexibility to change the values of the issues in the negotiation object and the negotiation parties might be allowed to dynamically alter the structure of the negotiation object. Agents Decision Making Models: For accomplish the mutual acceptance between the negotiation parties. The sophistication of the negotiation models, as well as the range of decisions has to be made. Agents Decision Making Models are influenced by the protocol in place, by the nature of the negotiation object, and by the range of operations that can be performed on it [71]. Because the negotiation environment changes or the negotiation condition changes, the negotiation parties may change the agreement spaces may change during the negotiation process. The negotiation terminates when the required number of negotiation parties fined a mutually acceptable point in the agreement space or when the protocol dictates that the search should be terminated without making an agreement. There are some properties that are generally considered desirable for a negotiation mechanism [71][72]. Computational efficiency: We seek a negotiation mechanism that is computationally efficient. Communication efficiency: We would seek some mechanism that handles communication among the agents in an efficient way. Broadcasting to all the agents in the system, may be ideal with this respect. Individual rationality: A mechanism should be individually rational for all the agents involved. In other words, it should be in an agent s independent interest to participate in negotiation. If considerations of group utility need to be taken into account, they can be made a component of each agent s private utility. Distribution of computation: Mechanisms that distribute the computation over the 75

94 agents at disposal are preferable the ones in which one server are performing all the computation for the whole system. This is preferred for many reasons, including the desire to avoid the disruptive effects of a single point failure, and performance bottlenecks. Social welfare maximization: All other things being equal, a system that guarantees that social welfare is maximized will be preferable to one which does not. Social welfare is usually captured by adding all the agents payoffs. Symmetry: Generally in e-commerce settings, no one agent has complete control of the game. Therefore we prefer mechanisms that guarantee symmetry in terms of power of the agents. 5.2 Negotiation Techniques There are many agent negotiation techniques and strategies to accomplish mutual acceptance. Jennings et al. [71] identify three different techniques or approaches to express and model negotiation strategies: Game-theoretic Models, Heuristic Approaches and Argumentation-Based Approaches Game-theoretic techniques Game-theoretic techniques model brings two important considerations about the negotiation and bargaining. First game theoretic studies typically assume that agents are allowed to select the best strategy from the space of all possible strategies in negotiation. It proves that the search space of strategies and interactions will become exponential growth, which means that the problem of finding an optimal strategy is in general computationally hard. In computer science, the study of such problems is the domain of computational complexity theory [73]. In design of protocols for governing multi-agent interactions, game theoretic techniques have following properties, Guarantee success, Maximum social welfare, Pareto efficiency, Individual rationality, Stability and 76

95 Distribution [71]. But there are a number of problems associated with the use of game theory when applied to automated negotiation: First, Game theory assumes that user will provide an agent s preferences with respect to possible outcomes. But it is extremely hard for human to consistently define their preferences over outcomes. In a simple preference game theoretic techniques may work well. With more complex preferences, it is much harder to use them. Second, Game theory has failed to generate a general model governing rational choice in interdependent situations [74]. It has to produce a number of highly special models for specific types of interdependent decision making. Third, game theory models often assume perfect computational rationality and assumed the negotiation agent fully known the potential outcome values. In most real world cases; agents typically know their own information space, but they do not know that of their opponent. Therefore, the notion of perfect rationality, although useful in designing, predicting and proving properties of a system, is not altogether useful in practice [71] Heuristic Approaches Heuristic method is based on a linear combination of simple tactics functions to manipulate the utility of contracts. The tactics functions are subdivided into trade-off and issue manipulation mechanisms [75]. The trade-off mechanism, like persuasive argumentation, is to make proposals that are more attractive to the opponent. The issue manipulation mechanism wants to reach the mutually agreement by adding and removing issues into the negotiation set. It does negotiation either by increasing the set of possible outcomes (adding) or removing noisy issues that are obstructing the negotiation progress. Heuristic methods will search the negotiation space in a non-exhaustive fashion. It aims to produce good, rather than optimal solutions. The key advantages of the heuristic approach are first, the models are based on realistic assumptions; hence they can be used in a wider variety of application domains. Second, the designers of agents can use 77

96 alternative, and less constrained, models of rationality to develop different agent architectures. There also have some disadvantages for heuristic method. First, the models often select outcomes (deals) that are sub-optimal. Second, the models need extensive evaluation and it is usually impossible to predict precisely how the system and the constituent agents will behave in a wide variety of circumstances Argumentation-Based Approaches Argumentation-based techniques are an extension of heuristic approaches. It allows additional information to be exchanged, over and above proposals. When rejecting a proposal, an agent can offer a critique argument of the proposal, explaining why it is unacceptable. Similarly, when accepting a proposal, an agent can accompany an argument which says why the other agent should accept it. These kind of forceful argumentations do not have to be tied directly to proposals either. Thus when valuating an argument, the recipient needs to assess the argument and evaluate it and then modify the argument for appropriate response Fuzzy Logic Approaches Walaa H. et al. [76] propose their fuzzy logic method for e-business negotiation. Negotiation methods such as game theory, which makes a number of assumptions, are not able to deal with an open environment such as web-based systems. The information is sparse and full of uncertainty, while the fuzzy approaches are suitable to deal with this problem. The main reason for using a fuzzy logic based expert system is the human preferences are vague and uncertain [77]. When evaluate the acceptance of the incoming offer is too complicated by using conventional mathematical methodology then we can use the fuzzy logic method. The number of negotiation issues grows and the complicity of conventional model increases dramatically. Both the incoming offer from the opponent negotiation agent and the counter offer are scaled by fuzzy function value. Through the 78

97 fuzzy logic function can make the negotiation decision Ontology Approaches Maricela C. [78] and C assia Trojahn et al. [79] propose their ontology mapping method for web service negotiation. Traditional negotiation systems impose several requirements on the type and format of negotiation messages; as a consequence negotiation agents have to be reprogrammed according to the protocol and message specifications. For example, if a new agent wants to participate in a negotiation process, it has to be reprogrammed according to the protocol and message specifications. Negotiation messages in this ontology have been organized according to their meaning. Agents should not be forced to commit to a specific negotiation language. Negotiation is a process whose transitions and states are described by the negotiation protocol that agents have to follow for interaction. 5.3 ebxml CPA Automatic Negotiation Technique Collaboration Protocol Agreement (CPA) negotiation In the real world business trade, one trade partner wants to find the other trade partner for business collaborations. They have to find the company name, telephone, , fax, products and other trading information. In ebxml require each Party to know the other Party's supported Business Collaborations, the other Party's role in the Business Collaboration, and the technology details about how the other Party sends and receives Messages. The way each Party can exchange information, in the context of a Business Collaboration, can be described by a Collaboration-Protocol Profile (CPP). The agreement between the Parties can be expressed as a collaboration-protocol Agreement (CPA). CPPs MAY be stored in a repository provided by the ebxml for example the ebxml Registry/Repository. By search the ebxml Registry/Repository Party can discover the other Party s Collaboration-Protocol Profile (CPP). Other Party MAY then use the 79

98 facilities of the repository to find Business Partners. For business trade, it is necessary for the two Parties to reach agreement on some of the details. The way each Party can exchange information, in the context of a Business Collaboration, can be described by a Collaboration-Protocol Profile (CPP). Then through negotiation between two Parties they can get agreement between the Parties, and can be expressed as a Collaboration-Protocol Agreement (CPA). Here we will propose using Defeasible Logic technology for ebxml Collaboration-Protocol Agreement (CPA) negotiation [18] System Overview When one trading partner makes an initial offer to other trading partners then the ebxml CPA negotiation process will begin. The initial offer consists of a CPA template and a Negotiation Descriptor Document (NDD) that describes what is negotiable in the CPA template. The CPA template constitutes a proposal about Business Process of CPA negotiation and the negotiation items between trading partners. The NDD identifies what items have to be negotiated and defines ranges or sets of acceptable values for those items. In the CPA negotiation process, a CPA template is verified by agent system and doing the negotiation until a mutual agreement CPA is constructed. In some situations the negotiation items in CPA template cannot be mutually agree by each trading partners then it have to change negotiation descriptions by each party[80]. CPA Template The CPA template constitutes a proposal about Business Process of CPA negotiation and the negotiation items between trading partners. The NDD identifies what items have to be negotiated and defines ranges or sets of acceptable values for those items. Using the CPA template and NDD is a good ideal for ebxml CPA negotiation. They can put the mutual agreement items in CPA template and put the negotiable items in NDD. Then the agents only have to negotiate the items in NDD for each party. After the negotiation process 80

99 between each party agent only has to combine the negotiated items in NDD with CPA template and forms to CPA. The process of composing a CPA template from two CPPs can be done by find the non controversial items of the CPPs. The CPA template will often narrow down the amount of negotiation processes and simplify the negotiating process. The negotiation process operates on a smaller set of items and will make the negotiation more rapidly. Eliminating the non controversial items from the negotiation process simplifies the ontology and system can focus attention on the items to be negotiated. The two Parties can make the CPA template by human to human contact or through the automatic agent negotiation process. Negotiation CPA (NCPA) The NCPA is a standard ebxml CPA that defines a minimal set of function that all Parties can be expected to support without Parties having to negotiate the NCPA before negotiating the CPA for their Business collaboration. It identifies the BPSS instance document that defines the negotiation choreography. The two partners must agree on what negotiation process to follow, i.e. what NCPA to use for negotiation. Negotiation Descriptor Document The Negotiation Descriptor Document (NDD) describes what is negotiable in the accompanying CPP or CPA template. It describes the negotiable elements and omits those elements and attributes need not negotiate. The NDD identifies the CPP or CPA template. The CPP or CPA template does not identify the NDD since a party may have many different NDDs associated with the same CPP or CPA template. There could have different negotiation processes for different categories of partner. An NDD can be placed in a registry along with the CPP. The NDD and CPP would have to be connected by registry metadata. Alternatively, a Party might choose not to include an NDD in the 81

100 registry. System permits a Party to send an NDD that it considers appropriate for the particular prospective trading partner [80]. Negotiation Messages A negotiation Message includes the details of a counter offer, identification of the NDD and CPA template being negotiated, and information that controls the negotiation protocol. Some Messages include the NDD and/or the CPA or their URLs Components of CPA Negotiation Figure 5.1, illustrates the main components of CPA negotiation. The following are shown [80]: NCPA: The Negotiation CPA controls the negotiation process. Negotiation BPSS instance document: An ebxml Business Process Specification Schema [ebbpss] instance document that MAY be used to define the negotiation collaborative protocol. This BPSS instance document is referenced from an NCPA. CPP: Parties A and B publish their CPPs in an ebxml Registry [ebrs] or otherwise exchange them when they discover each other. CPA template: A CPA in which some items remained to be filled in by one or the other Party, or negotiated between them. NDD: The Negotiation Descriptor Document, a document associated with a CPP or a CPA template that defines what is negotiable, ranges of numeric values, etc. The NDD is used in the negotiation protocol. Negotiation Messages: The messages used to exchange offer and counter-offer information between negotiating Parties. Negotiation Protocol: The collaborative protocol that produces a negotiated CPA. Although shown as a single box in figure 5.1, the negotiation protocol is executed between the two Parties or between each Party and an intermediary. 82

101 NCPA the Negotiation CPA controls the negotiation process that combines the CPA template, NDD and CPP of party A and party B then forms to a CPA. CPA Template (A or B) NDD(A) CPP(A) NCPA Negotiation BPSS Document Negotiation Protocol NDD(B) CPP(B) CPA(A,B) Figure 5.1: main components of CPA negotiation Figure 5.2, is a high-level view of the negotiation process. The details of the negotiation process illustrated as following [80]: Phase 1: Party A and Party B suppose the CPPs and the associated NDDs or a CPA template and NDD that one partner provides to a prospective partner. The partners can negotiate about which BPSS instance document to use based on the name of the BPSS instance document. Phase2: Negotiation system combines the CPP, NDD and CPA template between parties to a new CPA template and negotiation NDD. Phase 3: One Party prepares a CPA template and an NDD that describes what is 83

102 negotiable and submits the CPA template and NDD to the other Party as an initial offer. Phase 4: The two Parties then exchange counter offers until they arrive at a mutually acceptable CPA. Offer and counter-offer information is in negotiation messages exchanged using negotiation business transactions defined in the NCPA and BPSS instance document. Phase 5: Result of negotiation: 1) A successful result is a CPA that is ready to sign and use, possibly subject to human approval. 2) An unsuccessful result means that agreement was not possible on some items in the CPA. Possibly, further human interaction could resolve the incompatibilities. 84

103 Party A Party B CPP, NDD CPA,template NCPA CPP, NDD CPA, NCPA NCPA references negotiation BPSS... Similar To Party A at left PHASE 1 No CPA Template Party B fills in Party A s CPA Template Party B Discovers Party A Is it a CPP? Yes CPPs, NDDs, NCPAs CPA templates Party B creates CPA template From 2 CPPs PHASE 2 Party B prepares NDD and template PHAS Party B submits offer to Party A PHASE 4 PHASE 5 No - rejects Partner Counter pending Agreed Party A sends Sending Party is recipient of offer or last counter offer. Signed if signing agreed to. Unsuccessful Yes One Party sends completed, Receiving Party Counter pending B Party B sends reject Unsuccessful Yes Agreed CPA No Sign? Yes Yes OK? Reject Unsuccessful Counter pending A reject Unsuccessful Receiving Party signs, returns Yes Agreed CPA Successful Figure 5.2: A high-level view of the negotiation process. 85

104 5.4 Defeasible Logic Rule-Based Negotiation Rules base system is a promising technique for formalizing multi-agent negotiations ([81, 82, 83]). When we design an automated negotiation system we should distinguish between negotiation protocols between participants and negotiation strategies that define behaviors aiming at achieving a desired outcome. Negotiation rules are used for enforcing the negotiation mechanism. There are following Rules for negotiation: rules for negotiation party admission, rules for checking validity of proposals, rules for protocol enforcement, rules for updating negotiation status and informing participants, rules for agreement formation and rules for controlling negotiation termination [84]. We suggest use ontology for expressing negotiation protocols. When we doing the negotiation process agent can obtains a specification of the negotiation rules in terms of the shared ontology. A formal executable approach for defining strategy of agents participating in negotiations using defeasible logic programs will describe in following section. This approach was demonstrated multiple ebxml trading partner using agent negotiation to form a CPA by indicating sets of rules for describing strategies of participating agents. However, we will implementation results using the defeasible logic technology and OAA framework. We will claims to address both protocol and strategy representation in defeasible logic. The implementation is demonstrated with two trading partner negotiation scenario involving one buyer and one seller agent. The buyer strategy and seller strategy are defined by a defeasible logic program Use DR-DEVICE as Defeasible Logic Reasoning Inference Engine for ebxml Negotiation We use the DR-DEVICE as our Defeasible Logic inference engine. DR-DEVICE is capable of reasoning about RDF metadata over multiple Web sources using defeasible 86

105 logic rules [85]. The system is implemented on top of CLIPS(C Language Integrated Production System) production rule system and builds upon R-DEVICE [86], [87], an earlier deductive rule system over RDF metadata. Rules of DR-DEVICE can be expressed either in a native CLIPS-like language, or in an extension of the OO-RuleML syntax. The DR-DEVICE support for multiple rule types of defeasible logic, such as strict rules, defeasible rules, and defeaters. It support for classical (strong) negation, negation-as-failure and conflicting literals. It can direct import from the web of RDF ontologies and from the Web of defeasible logic programs in XML compliant rule syntax (RuleML). It will export to the Web of the results (conclusions) of the logic program as an RDF document. The DR-DEVICE system consists of two major components (Figure 5.3): the RDF loader/translator and the rule loader/translator. The RDF triple loader downloads the RDF document from the Internet and uses the ARP parser to translate it to triples in the N-triple format. The transformed RDF triples are fed to the RDF triple translator which maps them into COOL objects and then deletes them. The rule loader accepts from the user a URI that contains a defeasible logic rule program in RuleML notation and forwarded to the RDF loader. When the translation ends, CLIPS runs the production rules and generates the objects that constitute the result of the initial rule program or query. Finally, the result objects are exported to the user as an RDF/XML document through the RDF extractor [88]. The DR-DEVICE has the GUI user interface and do batch file interface. The process of Dr-DEVICE as following: 1) Accessing Remote rule and RDF files from the URI of the RDF files. 2) System translating rules between different rules formats (RuleML, R-DEVICE, R-DEVICE, CLIPS) 87

106 3) Loading and translating RDF files 4) Running rules 5) System exports the RDF RuleML results. Figure 5.3: Architecture of the DR-DEVICE system [85]. 5.5 SOA Architecture of ebxml negotiation Service Oriented Architecture (SOA) which is a way of reorganizing software applications and infrastructure into a set of interacting services. [89]. In a SOA, applications are essentially distributed in some registry service database (Figure 5.4). SOA functions can be anything from simple requests to complicated business processes. SOA Services allow organizations to expose their core competencies programmatically over the Internet (or intra-net) using standard (XML-based) languages and protocols. A SOA functions can be implemented in many different ways via a self-describing interface based on open standards, e.g. web services. Web services exchange SOAP messages over 88

107 standard Internet protocols and use open XML standards format [90]. A web service is a specific kind of service that is identified by a URI and exposes its features programmatically over the Internet using standard Internet languages and protocols. The ebxml registry is a directory service that contains service publications and enables web-service clients to locate trading partner s services and discover their details. SOA has following advantage: First, it can save the IT cost. If you can reuse services you've already built, then you don't have to spend as much time and money developing new applications. Second, SOA can increase a business's flexibility and lets it more quickly adapt to changing business needs. Third, in today most Web services are being used primarily to solve point-to-point integration problems. But these solutions can't solve the larger integration problems in converting hundreds of systems to a single enterprise. In this thesis we use the DR-DEVICE as our negotiation reasoning engine. The negotiation rules will translate to RuleML RDF type format and store it in specific URL. When two ebxml trading partner do the negotiation process, system will extract the negotiation rule from web service URL this situation follow the SOA specification. Figure 5.4: The basic Service Oriented Architecture 89

108 CHAPTER 6 SYSTEM IMPLEMENTATION 6.1 Implementation of ebxml Front-End system Using OAA In chapter 4, we have described how to create agents for business services and message services from the specification of collaboration protocol between a pair of trading partners. In first section of this chapter, we described an implementation of the agent architecture to show how it works in the ebxml platform. First of all we describe the implementation of agents serving for business collaboration, i.e., the business service agents and message service agents. Then we describe the environment we use to test the implementation Agents in the Front-End System We describe in order the implementation of agents, including the User Interface Agent, Business Information Agent, Business Service Agent, Message Service Agent. User Interface Agent User interface agent (UIA) serves user to manage the business collaborations with the counterparts. User interacts with other agents in the system through UIA. We implement the following functions in UIA for user. First it provides the list of current trading partners and the business processes available with the selected one. Second, it displays the status of agents and the information of business transaction activities. Third, user can create new business activities, and stop the existing ones. Business Information Agent Business Information Agent (BIA) provides business information in the database for other agents during the course of carrying out business collaborations. The business information database (BID) stores the information extracted from the documents of CPAs and BPSS in the CPAs. The information is created after finishing the discovery phase as 90

109 described in previous chapter. UIA obtains from the BIA the information in CPA and BPSS for user to choose trading partners and business processes. When a business service agent is created to deal with business collaboration as described later on, it contacts BIA to get the BPSS information for creating the finite state model. The message service agent needs the information in CPA create the reliability parameters. Business Service Agent The Business Service Agent (BSA) is composed of a business collaboration program and the agent initialization procedure to wrap the former part as an agent program on OAA. In the following we omit the agent initialization procedure and focus on the other. The business collaboration program is further divided into the upper part, a finite state machine, and the lower part, business transaction module. The upper part consists of a finite state model and a control engine according to the steps described in chapter 4. For example, from the case of business collaboration in chapter 4, we constructed a table for the finite state model as shown in Table 6.1. For convenience of displaying the content of the finite state model table, we compact the current states and the conditions of their next states in one column. Table 6.1: Finite state model table Current State \ Condition Next State START CreatePurchaseOrder\Pending CreatePurchaseOrder\Accept CreatePurchaseOrder\Failure UpdatePurchaseOrderNotification\Accept UpdatePurchaseOrderNotification\Failure CreatePurchaseOrder UpdatePurchaseOrderNotification BC-CreatePurchaseOrder-Success BC-CreatePurchaseOrder-Failure BC-Pending-Success BC-Pending-Failure The control engine operates on the model to set up the sequence of business dialogue with the other end over network. The procedure is summarized as follows. Note 91

110 that when calling BT, the Input is the business document in XML from the backend system. Current_state=START; Output=null; Condition=null NextState GetNextState(Current_State, Condition) If NextState= Completion type then Return Finish with Output else begin call BT( Input, Output); /* invoking the business transaction module */ end Condition GetCondition(Current_State, Output) /* compute the condition from*/ /* the output */ Repeat Step 2 /* Business transaction module */ BT(Input, Output) PlayRole = MappingRole(Input); if PlayRole = RequestingRole then begin invoke MSA (Sending, RequestingDocumentLocation); wait MSA (Receiving, ReceiptAcknowledgeSignal); wait MSA (Receiving, AcceptanceAcknowledgeSignal); wait MSA (Receiving, RespondingDocumentLocation); invoke MSA(Sending, ReceiptAcknowledgeSignal); Output = RespondingDocument; end; if PlayRole = RespondingRole then begin wait MSA(Receiving, RequestingDocumentLocation); invoke MSA(Sending, ReceiptAcknowledgeSignal); invoke MSA (Sending, AcceptanceAcknowledgeSignal); invoke UIA(RequestingDocumentLocation, Decision) wait UIA(Responding, Decision) invoke MSA (Sending, RespondingDocumentLocation); wait MSA (Receiving, ReceiptAcknowledgeSignal); Output = RequestingDocument; end; At the current implementation, BSA can be created by user through the UIA. Also the backend application system can initiate a BSA, when it intends to do business collaboration with trading partner. It calls for creating a BSA by giving the following parameters. Originator:This is used to indicate the request of initiating the BSA either from UIA or, here, the backend application system. PartnerName: The company to collaborate with BCName: The business collaboration to carry out BPSSFile: Indicating the location of the BPSS file containg the business 92

111 collaboration specification BusinessId: The unique identifier for the BSA. This identifier along with the ConversationID used in the delivery of business message, BusinessID(ConversationID) is used during the execution of the business collaboration. Message Service Agent This agent provides the functions of message services for all the business service agents in the front end system. In this thesis, we focus on automatic execution of business collaborations in BPSS. We only implement part of the ebxml Message Service Specification using SOAP technology in Java [91]. In the future, we will replace the message service functions using Message Service Handler from open source, like [80]. At present, we implement the following function modules in the message service agent (MSA). Message packaging module: This module puts the business document to be sent in SOAP with attachment MIME envelop to form a message package. Reliable message delivery module: This module performs the functions message sending and resending, acknowledgement receipt notification according to the parameters defined in CPA and BPSS to make reliable message delivery. Message analyzing module: This module performs the inverse function of the message packaging module that analyzing the message and sending to the appropriate agent for further processing. 93

112 The MSA consists of the sending and receiving parts, summarized as below. MSA(ServcieRequest, Message) if ServcieRequest = Sending then being call MessagePackaging(Message, PackagedMessage) call ReliableMessageSending(Message, URL); end; if ServcieRequest = Receiving then being call ReliableMessageReceiving(PackagedMessage, URL); call UnpackageMessage(PackagedMessage, Message) if called from BSA then return Message else notify UIA to create a BSA for handling the incoming Message. end; Business Collaborations for RosettaNet RosettaNet is an electronic business standard platform designed for supply chain management in high-tech industry, including computer manufacturing [81]. According to the ebxml framework described in chapter 3, RosettaNet defines the specifications necessary for building up the front end system. This includes the business process specification, in RosettaNet term, Partner Interface Processes (PIPs TM ), and the message service specification, RosettaNet Implementation Framework (RNIF TM ). A PIP defines the business protocol between a pair of trading partners. The PIPs are organized in a hierarchical manner [92]. In the top level they are divided into seven clusters, numbered from 1 to 7: Partner Product and Service Review, Product Information, Order Management, Inventory Management, Marketing Information Management, Service and 94

113 Support, and Manufacturing. Each cluster is further divided into a number of segments each of which consists of a number of PIPs. The segments within a cluster are ordered using letters. For example, PIP3A4, Request Purchase Order, is the fourth PIP in segment A of cluster 3. The specifications of PIPs are developed by using the Open-EDI Reference Model (ISO/IEC 14662) [93]. The business collaboration in each PIP is constructed from business operational view, functional service view, and implementation framework view. In this thesis, we create business collaborations from RosettaNet PIPs. For example, PIP3A4 and PIP3A7 (Notify of Purchase Order Update), are used to create the business collaboration described in chapter 4. We use the following examples to illustrate how the agent-based system we developed works in ebxml environment. We assume that both parties, Companies A and B, have already finished the discovery and negotiation phases in the technical architecture and both agree on a CPA. In Figure 6.1, user (Company A) selects PIP3A4 (Purchase Order Request) as the business collaboration with Company B. The greens buttons at the right end indicate that the facilitator, business information agent, and message service agent are on. After being notified of the purchase order request from Company A, the UIA of Company B displays the information for user to make further decision about the request. For convenience of illustration, assume that user responds with accepting the request. This decision is delivered to Company A through the BSA and MSA of Company B as shown in the left of Figure 6.1. After user of Company A acknowledges the decisions, the UIAs of both sides display the result of success as shown in the bottom of Figure

114 Figure 6.1: Company A issues a purchase order request with Company B According to the business collaboration specification of PIP 3A4, if the responder, here Company B, responds with pending the purchase order request, and then the process of business collaboration enters PIP3A7 (Notify of Purchase Order Update), as shown in Figure 6.2. In Figure 6.3, Company B responds with pending the purchase order and Company A accepts the purchase order update. 96

115 Figure 6.2: (Top) Company B responds accepting the request; (bottom) success of purchase order request at UIA of Company A 97

116 Figure 6.3: (Top) Company B responds with pending the request; (bottom) Company A accepts the purchase order update. 98

117 6.2 Implementation of ebxml CPA Negotiation Agent based on Defeasible Logic technology ebxml CPA Negotiation Scenario Here we will propose our ebxml CPA Negotiation scenario. Suppose Asctec Company wants to buy some computer. It searches the ebxml Registry and finds the profile of Tatung Company. The detail of ebxml business trade process has been discussed in the previous paragraph. In this section we only discuss about ebxml CPA negotiation. 1. Asctec Company (Agent A) finds the CPP, NDD and CPA Template of Tatung Company (Agent B) from ebxml Registry and Asctec Company has to prepare the CPP about their company. 2. The Asctec Company check the CPP, NDD and CPA Template of Tatung Company, then it has to prepare its NDD and CPA Template for negotiation. The Asctec Company also has to prepare their negotiation strategies. 3. In this thesis we suppose that Asctec Company will follow the NDD of Tatung Company. 4. Asctec Company sends initial negotiation proposal to Tatung Company according the NDD. 5. The two Parties then exchange counter offers until they arrive at a mutually acceptable CPA. Offer and counter-offer information is in negotiation messages exchanged using defeasible logic inference engine by automatic agent mediated. 6. Result of negotiation: 1) A successful result is a CPA that is ready to sign and use, possibly subject to human approval. 2) An unsuccessful result means that agreement was not possible on some items in the 99

118 CPA. Possibly, further human interaction could resolve the incompatibilities. 7. Concluding negotiation 1) The negotiation gets a successful result then the Asctec Company will combine the negotiation result and the CPA Template to a final CPA. Then it sends the CPA to the Tatung Company. 2) The Tatung Company verifies the contents of the completed CPA including, perhaps validation of the first Asctec Company s signature. If these tests are successful, that Tatung Company signs the new CPA. 3) The two Parties now deploy the new CPA and begin doing business. The concluding negotiation will not discuss in this thesis ebxml CPA Negotiation Architecture Using Defeasible Logic Inference Engine The two basic roles that we identify in the negotiation case are two ebxml trading partners the Buyer and the Seller. There has an ebxml registry service for the negotiation and we make the assumption that buyer that starts the negotiation knows the address of the seller. The technical solution we provide is based on the following key ideas: The buyer and the seller are represented by software agents. Agent A as buyer and Agent B as seller. There has a control module for active the agent negotiation and display the negotiation results. We use the OAA as our agent negotiation platform. We use the JENA as our ontology knowledge base parser. The negotiation strategies of trading partner agents are expressed using defeasible logic rules. The knowledge base of the agent consists of a set of facts and a number of defeasible and strict rules. 100

119 We use the DR-Device defeasible logic inference engine as our negotiation inference engine. We suppose that DR-Device defeasible logic inference engine already knows the address (URI) of buyer s strategy RDF file. Figure 6.4, shows the negotiation architecture. First the control module active the agent A sends the negotiation proposal. Then agent A prepares the negotiation RDF file and sends to the agent B. When the agent B receives a negotiation proposal from Agent A, it will call the DR-Device inference engine. Then the DR-Device inference engine will update the knowledge base with the inference result, according to the strategy rules. Then the agent B use the Jena parser retrieves the result and sent to the control module. The control module will show the result and posts it to the communication module of the agent B. The detail implementation will present in the following paragraphs. Figure 6.4: ebxml CPA Negotiation Architecture Using Defeasible Logic Inference Engine. 101

120 6.2.3 ebxml CPA Negotiation Strategies Negotiation Strategy is a decision making model, which participants trading partner in order to achieve their goal in line with the negotiation protocol. The strategy of a potential buyer or seller during a negotiation scenario is very critical for the outcome of the negotiation proposal. The ebxml CPA negotiation strategies are according to the contents of NDD. In Figure 6.5 and appendix A shows the NDD instance document for automated negotiation. Through the contents of NDD instance document we conclude the following negotiation strategies. In the previous section we had mentioned about that buyer will follow the strategies of seller. Here we will describe the negotiation strategies of seller. We arrange the negotiation items to table for clear represent the strategies. The ID is the identity of negotiation item. The xpath means the XML name space in ebxml CPA documents. The Type item is the data type of negotiation identity. The value is the limit negotiation value. The Negotiation strategy means the strategy for the identity. 102

121 <?xml version="1.0" encoding="utf-8"?> <NegotiationDescriptor xmlns=" xmlns:xsi=" xsi:schemalocation=" NDD1.xsd" xmlns:xsd=" documentlocation="c:\documents and Settings\nkartha\My Documents\ebxml\negotiation\cpa-example-2_0a.xml"> <NegotiableInformationItem <OrderedValue preference="earlierpreferred"> <Value> 1.0 </Value> <Value> 2_0.a</Value> </OrderedValue> </NegotiableInformationItem> Figure 6.5: NDD instance document Seller s Strategies ID xpath Type Value Negotiation strategy Table 6.2: Seller s Strategies cpaid /CollaborationProtocolAgreement/@cpaid anyuri uri:negoinit-and-negoresp-cpa Cpaid= uri:negoinit-and-negoresp-cpa ID version xpath /CollaborationProtocolAgreement/@version Type OrderedValue Value 1.0 2_0.a Negotiation Version=2_0.a strategy 103

122 ID xpath Type Value Negotiation strategy ConversationConstraints /CollaborationProtocolAgreement/ConversationConstraints integer 2<=ConversationConstraints<=8 2<=ConversationConstraints<=8 ID invocationlimit xpath ionlimit Type integer Value invocationlimit <=5 Negotiation invocationlimit <=5 strategy ID PartyId xpath /CollaborationProtocolAgreement/PartyInfo/PartyId Type Reference pointer Value PartyId <=5 Negotiation PartyId <=5 strategy ID xpath Type Value Negotiation strategy ID xpath Type Value Negotiation strategy ID xpath Type Value isnonrepudiationrequired /CollaborationProtocolAgreement/PartyInfo/CollaborationRole/Servi cebinding/service/cansend/thispartyactionbinding/businesstransa Boolean True False isnonrepudiationrequired=true timetoacknowledgereceipt /CollaborationProtocolAgreement/PartyInfo/CollaborationRole/Servi cebinding/service/cansend/thispartyactionbinding/businesstransa Duration MinimumDuration = PT5M MaximumDuration =PT6M PT5M<=timeToAcknowledgeReceipt<=PT6M syncreplymode /CollaborationProtocolAgreement/PartyInfo/DeliveryChannel/Messag ingcharactersitcs/@syncreplymode NMTOKEN "mshsignalsonly" "responseonly" 104

123 Negotiation strategy "signalsandresponse" "signalsonly" "none" syncreplymode="signalsonly" Buyer s Strategies Suppose that buyer will propose following 5 proposal for CPA negotiation. The following abbreviations express the ID of negotiation items. P: Proposal ID CC: ConversationConstraints IL: PI: invocationlimit PartyId NRR: isnonrepudiationrequired TAR: timetoacknowledgereceipt RM: syncreplymode Table 6.3: Buyer s Strategies P cpaid version CC IL PI NRR TAR RM a1 uri:negoinit-a 1_ false PT6M signalsonly nd-negorespcpa a2 uri:negoinit-a 2_0a false PT6M signalsonly nd-negorespcpa a3 uri:negoinit-a 2_0a false PT6M signalsonly nd-negorespcpa a4 uri:negoinit-a 2_0a false PT6M signalsonly nd-negorespcpa a5 uri:negoinit-a nd-negorespcpa 2_0a True PT6M signalsonly An agreement is reached when both buyer and seller get the mutual agreement about the 105

124 negotiation Defeasible Logic Negotiation Rules In the above sections we introduced the ebxml negotiation architecture and ebxml negotiation strategies. In this section we will translate ebxml NDD negotiation items to defeasible logic negotiation rules. r1: => acceptable(x) r2: cpaid (X,Y), Y " uri:negoinit-and-negoresp-cpa " => acceptable (X) r3: version (X,Y), Y "2_0a" => acceptable(x) r4: ConversationConstraints (X,Y), Y < 2 or Y > 8 => acceptable(x) r5: invocationlimit (X,Y), Y>5 => acceptable(x) r6: PartyId (X,Y), Y>5 => acceptable(x) r7: isnonrepudiationrequired (X,Y), Y True => acceptable(x) r8: timetoacknowledgereceipt (X,Y), Y<PT5M or Y>PT6M => acceptable(x) r9: syncreplymode (X,Y), Y signalsonly => acceptable(x) r9,r8,r7,r6,r5,r4,r3,r2> r1 We firstly examine the rules of the seller. X means the proposal ID. Rule r1 is the general case and the proposal is considered to be acceptable. Rule r2 defines that if cpaid is not equal to " uri:negoinit-and-negoresp-cpa " then it is not acceptable. Rule r3 defines that if version is not equal "2_0a" then it is not acceptable. Rule r4 defines that if ConversationConstraints is less than 2 or greater than 8 then it is not acceptable. Rule r5 defines that if invocationlimit is greater than 5 then it is not acceptable. Rule r6 also defines that if PartyId is greater than 5 then it is not acceptable. Rule r7 defines that if isnonrepudiationrequired is not equal to TRUE then it is not acceptable. Rule r8 defines that if timetoacknowledgereceipt is less than PT5M or greater than PT6M then it is not 106

125 acceptable. Rule r9 defines that if syncreplymode is not equal to signalsonly then it is not acceptable. The rule r9, r7, r6, r5, r4, r3 and r2 are superior to r1. All these rules indicate that if no proposal items meet the rules from r2 to r9 the proposal will acceptable. If any proposal items meet the rules from r2 to r9 will get a negative acceptable. Trace the buyer s strategies with seller s defeasible logic rules, we will get the Table 6.3. The negotiation result shows that only proposal a5 is acceptable. P: Proposal ID CC: ConversationConstraints IL: PI: invocationlimit PartyId NRR: isnonrepudiationrequired TAR: timetoacknowledgereceipt RM: syncreplymode Table 6.4: Negotiation Result P cpaid version CC IL PI NRR TAR RM Result a1 uri:negoinit-and -NegoResp-cpa 1_ false PT6M signalsonly Negative acceptable a2 uri:negoinit-and 2_0a false PT6M signalsonly Negative -NegoResp-cpa acceptable a3 uri:negoinit-and 2_0a false PT6M signalsonly Negative -NegoResp-cpa acceptable a4 uri:negoinit-and 2_0a false PT6M signalsonly Negative -NegoResp-cpa acceptable a5 uri:negoinit-and 2_0a True PT6M signalsonly acceptable -NegoResp-cpa ebxml CPA Negotiation use DR-DEVICE Rule Inference Engine The above defeasible logic rules have to translate to RuleML format and then the DR-DEVICE defeasible logic rule inference engine can manipulate it. The figure 6.8 is the DR-DEVICE inference engine process graph. 107

126 First, we have to define the RDF rule format ontology file for negotiation defeasible logic rule file. Figure 6.6 and appendix B are the RDF ontology for rule format definition. Second, we will translate above negotiation defeasible logic rules to RuleML format file. Figure 6.7 and appendix C are the Defeasible Logic RuleML Negotiation Rules. Third, we need prepare the buyer s import RDF file. Figure 6.9 and appendix D is the RDF file of buyer s import proposal. As Figure 6.8 if we feed the RDF ontology format define RuleML negotiation rule file and buyer s import RDF file then we get the result RDF file. Figure 6.10 and appendix E are the negotiation RDF result. In the real negotiation process of this thesis we create a Localhost IIS web site. The file ebxml01.rdf (appendix B) is the RDF ontology for rule format definition. The file ebxml01.ruleml is the RuleML negotiation rule file. The file ebxml01_ex.rdf is the import file of buyer s proposals. We can put these files in the remote web site. DR-Device inference engine will get the URI of these files for inference process. The DR-Device inference process can be fired by a batch file. 108

127 <?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rdf:rdf [ <!ENTITY rdf " <!ENTITY ebxml01 " <!ENTITY rdfs " <!ENTITY xsd " ]> <rdf:rdf xmlns:rdf="&rdf;" xmlns:ebxml01="&ebxml01;" xmlns:rdfs="&rdfs;" xmlns:xsd="&xsd;"> <rdfs:class rdf:about="&ebxml01;proposal_id" rdfs:label="proposal_id"> <rdfs:subclassof rdf:resource="&rdfs;resource"/> </rdfs:class> <rdf:property rdf:about="&ebxml01;cpaid" rdfs:label="cpaid"> <rdfs:domain rdf:resource="&ebxml01;proposal_id"/> <rdfs:range rdf:resource="&rdfs;literal"/> </rdf:property> <rdf:property rdf:about="&ebxml01;version" rdfs:label="version"> <rdfs:domain rdf:resource="&ebxml01;proposal_id"/> <rdfs:range rdf:resource="&rdfs;literal"/> </rdf:property> </rdf:rdf> Figure 6.6: RDF ontology for rule format definition. 109

128 <?xml version="1.0" encoding="utf-8"?> <RuleML rdf_export="export_ebxml01.rdf" rdf_export_classes="acceptable" rdf_import="" xmlns=" xmlns:xs=" xmlns:ebxml01_rb=" xmlns:ebxml01=" xmlns:xsi=" xsi:schemalocation=" <oid> <Ind type="defeasible">ebxml01-rules</ind> </oid> <Assert> <Implies ruletype="defeasiblerule"> <oid> <Ind uri="r1">r1</ind> </oid> <head> <Atom> <op> <Rel>acceptable</Rel> </op> <slot> <Ind>proposal_ID</Ind> <Var>x</Var> </slot> </Atom> </head> <body> <Atom> <op> <Rel uri="ebxml01:proposal_id"/> </op> <slot> <Ind uri="ebxml01:name"/> <Var>x</Var> </slot> </Atom> </body> </Implies> <Implies ruletype="defeasiblerule"> <oid> <Ind uri="r2">r2</ind> </oid> <head> <Neg> <Atom> <op> <Rel>acceptable</Rel> </op> Figure 6.7: Defeasible Logic RuleML Negotiation Rules 110

129 Figure 6.8: The DR-DEVICE inference engine process graph. <?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rdf:rdf [ <!ENTITY rdf " <!ENTITY ebxml01 " <!ENTITY ebxml01_ex " <!ENTITY rdfs " <!ENTITY xsd " ]> <rdf:rdf xmlns:rdf="&rdf;" xmlns:ebxml01="&ebxml01;" xmlns:ebxml01_ex="&ebxml01_ex;" xmlns:xsd="&xsd;" xmlns:rdfs="&rdfs;"> <ebxml01:proposal_id rdf:about="&ebxml01_ex;a1"> <ebxml01:cpaid>uri:negoinit-and-negoresp-cpa</ebxml01:cpaid> <ebxml01:version>1_0</ebxml01:version> <ebxml01:conversationconstraints rdf:datatype="&xsd;integer">5 </ebxml01:conversationconstraints> <ebxml01:invocationlimit rdf:datatype="&xsd;integer">6</ebxml01:invocationlimit> <ebxml01:partyid rdf:datatype="&xsd;integer">6</ebxml01:partyid> <ebxml01:isnonrepudiationrequired>false</ebxml01:isnonrepudiationrequired> <ebxml01:name>a1</ebxml01:name> <ebxml01:timetoacknowledgereceipt>pt6m</ebxml01:timetoacknowledgereceipt> <ebxml01:syncreplymode>signalsonly</ebxml01:syncreplymode> <rdfs:label>a1</rdfs:label> </rdf:rdf> Figure 6.9: The RDF file of Buyer s Import proposal a1. 111

130 <?xml version='1.0' encoding="utf-8"?> <!DOCTYPE rdf:rdf [ <!ENTITY rdf " <!ENTITY rdfs " <!ENTITY xsd " <!ENTITY defeasible " <!ENTITY export_ebxml01 " ]> <rdf:rdf xmlns:rdf='&rdf;' xmlns:rdfs='&rdfs;' xmlns:defeasible='&defeasible;' xmlns:export_ebxml01='&export_ebxml01;' > <rdfs:class rdf:about='&export_ebxml01;acceptable'> <rdfs:label rdf:resource='acceptable'/> <rdfs:subclassof rdf:resource='&defeasible;defeasibleobject'/> </rdfs:class> <rdf:property rdf:about='&export_ebxml01;proposal_id'> <rdfs:domain rdf:resource='&export_ebxml01;acceptable'/> </rdf:property> <export_ebxml01:acceptable rdf:about='&export_ebxml01;acceptable1'> <export_ebxml01:proposal_id>a1</export_ebxml01:proposal_id> <defeasible:truthstatus>defeasibly-proven-negative</defeasible:truthstatus> </export_ebxml01:acceptable> </rdf:rdf> Figure 6.10: Proposal a1 negotiation result RDF file Implementation and Demonstration In this section we will propose our implementation of agent mediated defeasible logic CPA negotiation. We use the OAA as our agent negotiation platform, JENA [94] as our ontology knowledge base parser and DR-Device defeasible logic inference engine as our rule engine. The JAVA is our programming language. Here we suppose that the DR-Device inference engine already know the address (URI) of the buyer s strategy RDF files. In the following paragraph we will demonstrate our implementation Negotiation Agents We use the JAVA code call the OAA facilitator and create three agents, the Agent A, Agent B and Control Center. Figure 6.11 is the screen of OAA monitor function that shows the activated agent on OAA platform. 112

131 Figure 6.11: Activated agent on OAA platform. Agent A: Agent A is buyer agent. The main functions of Agent A are preparing the negotiation proposal and fire the negotiation activity. The buyer s negotiation strategy RDF file will put in a special area of buyer web site. The DR-Device defeasible logic inference engine knows the URI of that import RDF file. For the same negotiation project agent A has to prepare the negotiation proposal and copy it to the web area. For example the URI of import RDF file in there have five proposals a1.rdf to a5.rdf. When Agent A propose the a1 proposal then it just have to rename the a1.rdf to ebxml01.rdf and copy to directory then Agent a1 fire the proposal. We also can put the proposal a1 to a5 together, then 113

132 DR-Device defeasible logic inference engine will inference the import RDF file and make five inference results (See the appendix C). In the begin, Agent A will call the JENA function and parser the import RDF file, then it will find the proposal ID a1 and send it to Agent B for proposal a1 negotiation. Agent B: Agent B is seller agent. The main function of Agent A is calling the DR-Device inference engine and getting the results. When Agent B receives the proposal from Agent A, then it calls the DR-Device inference engine. The DR-Device inference engine will read remote proposal RDF file ( ), Defeasible Logic RuleML Negotiation Rules (appendix D ebxml01.ruleml) and RDF ontology for rule format definition (appendix B ebxml01.rdf) then get the proposal results (appendix E export_ebxml01.rdf). In our experiment for user convenience, we put five proposals together and get five inference results at one time. After get inference result, Agent B will call the JENA function with proposal ID and parser the result RDF file. Then it will find the inference result of proposal ID and send it to Control Center Agent. Control Center Agent will display the result and send it to Agent A. The Control Center Agent: The Control Center Agent is a mediator between Agent A and Agent B. Figure 6.12 is our user interface for Agent mediated defeasible logic ebxml CPA negotiation program. We have a send request button for agent proposal fire and trace. When we push the send request, Control Agent will trigger the Agent A. Agent A will find the negotiation proposal and send it to Agent B. When Agent B gets the negotiation result, it will send the negotiation result to Control Center. Then Control Center will display the negotiation result on user interface. 114

133 Figure 6.12: User interface for Agent mediated defeasible logic ebxml CPA negotiation program Negotiation Trace In this section we demonstrate the operation of the system and we examine a negotiation trace between a buyer agent and a seller agent. In OAA platform we create a special-purpose agent that is called Control Center. Control Center can monitor the exchanged messages of two or more agents in the OAA agent platform. The specific negotiation strategy RDF file is given in the table x. As we can see in Figure 6.13 the buyer initially issues a Proposal a1 and send it to seller. After the inference form DR-Device inference engine, seller sends a defeasible-proven-negative counter proposal to buyer. Figure 6.14 shows proposal a1 negotiation result of our Agent mediated defeasible logic ebxml CPA negotiation program. We can see that proposal ID is a1 and get a defeasibly-proven-negative result. When buyer gets a defeasibly-proven-negative result, then it sends the proposal a2 to seller. Seller receives the proposal a2 and calls 115

134 the DR-Device inference engine again. It also gets a defeasibly-proven-negative result and sends the result to buyer. Figure 6.15 is the negotiation result for proposal a2. The negotiation processes still go on till the proposal a5. We can find that proposal a5 gets a defeasibly-proven-positive. The buyer receives a defeasibly-proven-positive counter proposal and the negotiation will stop. Figure 6.16 is the negotiation result for proposal a5. Figure 6.13: Defeasible Logic ebxml CPA negotiation sequence. 116

135 Figure 6.14: Proposal a1 negotiation result. Figure 6.15: Proposal a2 negotiation result. 117

136 Figure 6.16: Proposal a5 negotiation result Complete the CPA Document After the ebxml defeasible logic CPA negotiation, we have to combine the NDD negotiation result with CPA template and produce a mutual agreement CPA document. Figure 6.17 represents the combination of CPA. One Party will completed the CPA and signed it, then send the CPA to other party. When other party receives the CPA, it has to verify contents and sign the agreement of CPA. It also has to send the message of agree of CPA or deny of CPA to the other party. If two parties mutual agree of CPA, then they will complete the CPA negotiation. Figure 6.18 is part of CPA about negotiation result. 118