The eCommerce domain needs more and more automation, speed and security for its customers. That's why the number of B2B applications handling electronic ...
Transforming a Secure eCommerce Application into ∗ a Multi-Agent based Solution for eContracting ∗ B. Gateau ˆ
D. Mathevon ∗∗
D. Khadraoui
(∗) CRP-Henri Tudor - CITI 29, bld J.F. Kennedy L-1359 Luxembourg-Kirchberg Tel: +352 42 59 91 - 206 Fax: +352 42 48 99 {benjamin.gateau,djamel.khadraoui,eric.dubois}@tudor.lu
ABSTRACT The eCommerce domain needs more and more automation, speed and security for its customers. That’s why the number of B2B applications handling electronic contracts and digital signatures is still increasing. These ones are based on certificates and use secure communication protocols. Nevertheless most of them don’t take into account negotiation regarding to contracts clauses and arbitration of potential conflicts. In the Multi-Agent System (MAS) domain contract notion exists too. Social contracts make social control and management of cooperation between agents possible. This paper will consist in combining notions of electronic contract and social contract in order to integrate agents within an eCommerce platform for the automation and autonomous negotiation of electronic contracts terms. We experiment our proposal in the context of secure eBusiness application trading intangible assets where we consider a specific business case related to the translation sector.
Keywords multi-agent systems, eCommerce, security, certificates, contracts, negotiation, arbitration
1.
INTRODUCTION
In the eBusiness domain one of the major interest of SMEs is to trade services on the Internet. These services like accounting, translation or transcription for instance require certain criteria such as speed, robustness, flexibility, proactivity, cost/price and security which help to make transactions. These requirements are an obstacle for the SMEs which want to start an eServices activity because of the lack of internal knowledge and of infrastructure. In fact available ∗This paper concerns the preliminary works of a P.h.D. thesis
∗
O. Boissier ∗∗
E. Dubois ∗
(∗∗) SMA/SIMMO/ENSM Saint-Etienne 158, cours Fauriel 42023 Saint Etienne Cedex 02 Tel: +33 4 77 42 66 14 Fax: +33 4 77 42 66 66 {damien.mathevon,olivier.boissier}@emse.fr
tools on the market are to much expensive and the architectures proposed are frequently not adapted to SMEs needs previously described. The basis of our studies and experimentation is related to an eCommerce platform, called hereafter EBSME1 . This application is dedicated for eServices using the concept of electronic contracts. The experimentation of our application showed a number of limitations regarding the execution and the automation of electronic contracts management. In order to improve the execution of the contracts with complex scenarios the use of MAS technologies would be more appropriate. This would be the case, more particularly dealing with the creation, the execution and the monitoring of the electronic contracts including negotiation and arbitration. This takes into account the local autonomy and the ability of the contracts participants to be dynamic. This paper is organized as follows. In the following section we will present the electronic contracts principles and then the way they are used in EBSME and the reasons that led us to use MAS technologies in section 3. After a survey of contracts in MAS in section 4, section 5 is dedicated to the presentation of the first sketch which is mainly our multiagent system architecture.
2. CONTEXT The evolution of the Internet triggers a need of large and complex Web applications in order to create new businesses. They are considered as means to connect all activities and functions of the company. An example of this evolution could be the eBusiness domain notably Business-to-Business (B2B). A kind of eBusiness is the commerce of services via Internet (electronic services). Several studies and applications are achieved in the context of eServices and eContracting in general. For instance we can quote COSMOS [1] which is an Internet-based electronic contracting service that facilitates commercial partners with offer catalogues, a brokerage service, contract negotiation and signing as well as contract execution. Another example is [2] which is an approach provides a flexible way of modifying rules of enforcement, as trading arrangement change. In our case, we will mainly consider the electronic commerce of intangible assets (B2B 1
Electronic Business for Small and Medium Enterprises
kinds) dedicated such as translation, accounting and online transcription. All these examples are based on contracts. More generally contracts are used to have a paper support to be handled by human beings. In order to reduce the handling costs (in speeding up and in automating the process) and to keep the efficiency, the contract support has evolved in an electronic format [3]. It leads to gain in time and space constraints reduction since Internet allows distant companies to reach these objectives. In this kind of applications, a contract, called hereafter electronic contract, is a digital agreement between two contractual parts. In fact, the rights and duties in terms of deliverables, costs and delays of the participants are explicitly represented. However such contracts often lead to inflexible relations between participants. Consequently the obtained result is in contrary to the need of an open and dynamic system which make autonomous negotiations impossible. As a consequence the dematerialization and the automation of traditional process have made that the companies become able to identify electronic means. Our objectives is to provide the same guarantees and proofs with more security and flexibility.
Client Presentation
Server Presentation
Server Business Logic
Browser
Web Server
EJB Container
JSP
Entity Bean
Java Servlet
Session Bean
J2EE Platform
J2EE Platform
HTML
Java Applet
Desktop Java Application
Others J2EE Client
Figure 1: J2EE Application server The use of SOAP is necessary for making those services in SSL mode available in order to support the https protocol useful within our application (see Fig. 2). Finally the management of the certificates and the sessions enhanced the security of the application access control (user authentication) and the exchange between clients and servers.
The next section will highlight these context in the framework of the eBusiness platform that we developed. This platform is based on the management of electronic contracts.
Secure environment
RMI
SECURE EBUSINESS AND ELECTRONIC CONTRACTS 3.1 Application description
3.
The application we consider here offers a toolkit dedicated to the eServices domain. It allows the execution of activities, translation in our testbed, between an employer and an employee. This is done through the implementation of electronic contracts based on a electronic signature and online execution [4]. Three types of participants are considered hereafter: • a tele-worker who looks for job and has specific knowledge, • a tele-employer who want to engage employees having got specific knowledge, • an arbitrator who take part in the contract and being viewed as a judge in order to resolve conflicts between the tele-worker and the tele-employer. The platform is built on a J2EE architecture (Fig. 1) and offers a lot of evolution perspectives where the commercial transactions execution are secure. The security technologies used are: • the symmetric and asymmetric encryption on behalf of using SSL (Secure Sockets Layer) 128 bits, • the electronic signature, • the certificates (to guarantee a signature’s authentication).
Information System
Client/Applet
SOAP/SSL
Payment server
SOAP servlet
RMI
EJB Container
Data base
Figure 2: Components architecture
3.2 Electronic contract execution Given the model of contract defined in this application (Fig. 3), the management of a contract can be done basically as follows: • Registrar step (or pre-contractual step): Clients and suppliers identify the products/services that they want to buy or to sold and broadcast their catalog. • Creation step (or contractual step): A formal relation is created between a buyer and a solder. This step implies the negotiation concerned by two points: the price and the delivery time. At the end of the negotiation, the contract’s signature can take place. • Execution step (or post-contractual step): The assets are delivered and validated (an arbitrator acts eventually at this time).
Currency
Deliverable 1
1 Document
0..n Contract 1
1 0..n
Signature
0..n
1..n
0..3
1
NewDeliverable [no arbitration]
[Employe: deliverable execution]
3 Participant
[Employer: unsatisfaction] Provided
Rejected
[Employer: satisfaction]
1
Figure 3: EBSME Contract Model
Validated
[Arbitrator: request rejected] [Employer or Employee: arbitration request]
[Arbitrator: request accepted] ArbitrationRequest
Employee
requests
Figure 5: Deliverable state diagram Matching process Services
Contract
the deliverable is rejected, a conflict appears and then the arbitrator decides if the rejection is justified or not.
offers
The current application presents some lacks because it does have:
Employer Registration
Negotiation / Creation
Execution Signature procedure
Figure 4: Execution procedure in EBSME
• reasoning mechanisms • policies/clauses formalisms • automatic arbitration
At the end of the process, the bill will be generated and the payment procedure is done. Figure 4 shows the execution procedure within EBSME. We distinguish five main modules as presented in the following. • Registration within the system – Proposed or researched skills specification – Personnel certificate submission which will be used for the identification during the signature step • Research of an employer/employee • Negotiations about deliverables and commitments (in terms of cost and deadline; it consists of a choice in a limited list) • Contract creation by one of the participants – Participants choice: the contractual part with whom the creator has negotiated, and the arbitrator – Approval text addition (no particular format) – Deliverables previously negotiated addition • Electronic signature of the contract by three parts to identify and prove their agreement. Then, the monitoring of the contract is done with the contract execution graphical interface. The contract is executed by modifying the state of the associated deliverables that could be accepted or rejected by the consumer (Fig. 5). If
• powerful negotiation mechanisms In order to improve the quality of electronic services provided by our platform we think that we need to allocate more autonomy to the software components that assist users in the management of contracts. Thanks to this increase of autonomy, the user would be able to delegate a part of his control in the management and monitoring of the contract. In order to answer to such a requirement, we turn to multiagent technologies. The objective is to transform components able to assist users into agents that are able of managing the execution of electronic contracts by reasoning on contract clauses. Before presenting our proposition, the following section will present some related works in multi-agent domain that propose architectures using contract concepts.
4. MODEL AND MANAGEMENT OF CONTRACTS IN MAS The social dimension in multi-agent systems is very important [5]. Each of the agents has to take into account the others and to reason while respecting the objectives of each. Relations between agents are numerous and dynamic: dependence relations for instance existing between two agents may transform into agreements thanks to delegation/adoption of goals between local autonomous agents. Lots of work in MAS are interested in the modelling of agreements between agents [6, 7]. In the AMEC community such agreements tend to be modelled by contracts in which commitments (clauses) could be respected or not. The contracts (called social contracts to distinguish them from electronic contracts used in the eCommerce domain) allow to organize relations by defining agents’ commitments
required for action within a system. They are the means to explain interactions (rights and duties) with (it is the social control) or within (agreements between agents) the society [8, 10]. The social contracts are composed by a set of clauses defining the behaviour constraints of contractual parts. One can consider that a contract is basically a set of constraints (clauses) associated with a state transition graph to define the contract execution. But formally a contract can be defined by several expressions. In the following we present three examples to illustrate the contract concept. • In the CAS (Contract Agent Society) concept [8] the activities emerge from a set of negotiated social contracts which are monitored and executed with social control mechanisms. The main objective is to obtain a dynamic organization within an agents society. A contract is a set of clauses and a clause gathers the contracting agents, the context group, the body of the contract and the state transition graph representing all the possible evolutions of the contract. • The Electronic Contract Framework (ECF) [9] goal is to automate the life cycle of the contractual relations between agents. For this collaborations within virtual commerce companies have to be specified and the contracts execution have to be automated. The behaviour specifications are defined by a set of normative states. • In [10] the contract model is presented within an organizational structure. From a contractual perspective, organizations can be seen as sets of agreements for satisfying diverse interests of self-interested individuals. Social order emerges from the negotiation of the rights and duties of participants. Besides the parties directly involved in the contract, contracts can also indicate a third agent-based party, which is in charge of monitoring the execution of the contract and apply sanction whenever needed.
These applications show us different advantages of using multi-agent systems. Agents are able to manage and execute contracts because they are able to reason on the different clauses. Although agents have to respect obligations, their autonomy may lead them to violate them to cancel a contract and create another with a more interesting partner (in taken in account penalties of course). EBSME is considered as a basis platform because its architecture is enforced regarding the main eCommerce demands like security, digital signature, etc. Regarding these definitions and the solutions found in different research domain we have defined our own contract description presented in the next section. We have deduced from this contract formal definition an agent architecture and a system architecture in which agents evolve.
5. SOLUTION PROPOSAL Our goal is to “agentify” our eCommerce platform in order to automate the contract execution process with a clear and contract adapted formalism. For this the first step is to model the information and the functions which define a contract in order to make agents able to execute them. In this system one autonomous agent will assist one user and will manage a set of contracts (after registration into the system; Fig 6). New User (employer/employee)
Agent A Creation
Agent B Agent C
Agent n
Contracts Repository
Registration Services
Systems that make modelling of contractual agents societies provide in general specialized agents [8, 11] like the following: a - Registrar agent It is used to register new agents which want to go in the marketplace and to locate agents which have skills to do something if they need. b - Notary agent It is used to negotiate and create contracts. c - Monitor agent It follows the execution of contracts and can apply sanction (by acting on the reputation of the agents) if a conflict takes place [11]. d - Reputation agent It provides trustworthiness of agents in marketplaces. The reputation notion allows contractual agents to define their behaviour regarding to contracts negotiation, creation and execution.
Figure 6: Agent architecture - Registration step
5.1 Contract formal definition We propose a definition of a contract C as follows: C = (Ag, Arb, NegOb). where: • Ag is Agents. It represents the agents involved into the agreement. We suppose that they can be two or more. • Arb is Arbitrator. It is a special agent able to monitor and follow the contract execution. For the moment he will not be used but in a short-term, it will be able to resolve potential conflict.
• NegOb is Negotiated Object. It is basically the electronic contract as it was defined in the B2B platform. But the agents have to understand the clauses of it in order to execute them. That’s why we intend to represent contracts with the definition of [9] seen above. The contract could be considered as a set of normative states. A formal representation of a normative statement is given below: ns: ϕ → θs,b (α < ψ) where: • ns is a label referencing this normative statement. • ϕ is the condition under which θ obtains. • θ is a deontic operator, Obligation (O), Permission (P) or Prohibition (F).
execution regarding to their priority (calculated regarding several parameters like deadline or penalties incurred for instance). At last the “Fulfilment” component creates tasks regarding normative statements and executes them inside the B2B framework. As a consequence the agents and the existing B2B platform have to communicate together. But how the agents work and cooperate? How the multi-agent system is designed? These questions are answered in the next section.
5.3 System architecture We saw that the contract notion is different depending on whether the domain is eCommerce or Multi-Agent System. Nevertheless we consider that the electronic contract is the social contract reification [11]. And the main goal is to satisfy both concepts of contract: electronic contracts used within eCommerce applications and social contracts relating to MAS. Consequently our objective is to integrate agents within an eCommerce platform for the automation and autonomous negotiation of electronic contracts terms. We propose a multi-agent architecture on the Fig. 8 able to accept new agents (open system) and providing specialized agents like the notary agent, the matchmaker agent or the reputation agent.
• s is the subject of θ, or the role that assumes θ. New agent admission
• b is the beneficiary of θ, or the role to whom θ is owed.
Community formation
Regulated transaction
A
Y
B
• α is the action to perform or the state-of-affair to bring about.
C
A
X
Mutually untrusted agents
Z
• ψ is a deadline. The agents have thus a special architecture to understand clauses (normative statements) and transform them into actions.
Socialization service
Notary
Matchmaker
Reputation service
Mutually trusted agents
Active contracts
5.2 Agent architecture
Contract repository
In the Fig. 7 we can see how an agent is able to act regarding to a contract in which it is involved.
Figure 8: System architecture
Enterprise Systems
Arbitrator
Contractual Agent
Agent A Agent B
Contractual Peers
CFP Manager
Reasoner
Scheduler
Fulfilment
Agent C
B2B Frameworks
Contracts Repository
3 - Negotiation (agent x, service s)
Contract Repository
2 - Respond (agent x) Agent n 1 - Request (service s) Services
Figure 7: Contractual agent architecture
Figure 9: Agent architecture - Negotiation step
2
The “CFP manager” is responsible for communications with other agents. The “Reasonner” analyses contracts regarding to believes and makes a selection of normative states to execute. The “Scheduler” organizes the normative statements 2
Contract Fulfilment Protocol
As shown on the Fig. 9 Agent n created by a user and registered in the system requests an agent with specific skills able to do what it is not able to do in order to cooperate with it. When it finds a partner it negotiates with it to create a contract (an agreement). This one is executed by
contractual parts and supervised by a special agent namely the Arbitrator (Fig. 10). There is not ever need of a third contractual part directly implied into the contract (a user assisted by a software for instance) for conflicts resolution.
Agent A Arbitrator
Agent B
Execution / Arbitration
Agent x
Agent C
Creation / Execution Storage Contracts Repository
Services
Figure 10: Agent architecture - Contract creation/execution step
6.
CONCLUSION AND PERSPECTIVES
We have proposed in this paper a multi-agent architecture based on an existing eCommerce platform for the trade of translation services built around the electronic contracts concept. One of our goals has been to match the notion of electronic contract in eCommerce and the one concerning social contract used by multi-agent systems. The formal definition and the architectures proposed come from existing works and are adapted in order to catch our application specificities. Even so in order to improve automation and autonomy characteristics all the processes of contract creation and execution will be treated online by agents. Hence the future works will be dedicated to the modelling of negotiation and arbitration (resolution of potential conflicts) mechanisms within a multi-agent system. Negotiation process’ are necessary in order to define contracts clauses and to model information needed for the contracts execution. They must make able the management and the doubt of contracts. Our research works will be based on several proposals existing in the MAS [12, 13] domain dedicated to electronic commerce such as auctions or “argumentation” interactions. In the MAS arbitration existing works propose two sorts of architectures: some architectures which avoid that conflicts appear or some architectures which accept the apparition possibility of conflicts but don’t provide mechanisms to resolve the problem. To compensate to this problem one way that we will investigate will be the one related to trust or reputation and furthermore penalties policies which will be applied at the time of non-respect of commitments. Finally expected results will be validated in our B2B application. Thus the autonomous negotiation, arbitration and execution of electronic contracts will become possible.
7.
[2] A. Goodchild, C. Herring and Z. Milosevic. Business Contracts for B2B. Proceedings of the CAISE*00 Workshop on Infrastructure for Dynamic Business-to-Business Service Outsourcing, Stockholm, June 5-6, 2000. [3] S. Angelov, P. Grefen. B2B eContract Handling - A Survey of Projects, Papers and Standards. CTIT Technical Report 01-21. University of Twente, 2001.
Creation / Execution Contract C
Agent n
the Internet. In Proc. 2nd International Workshop on Enterprise Distributed Object Computing, San Diego, Nov. 1998.
REFERENCES [1] F. Griffel, M. Boger, H. Weinreich, W. Lamersdorf, and M. Merz. Electronic contracting with COSMOS - How to Establish, Negotiate and Execute Electronic Contracts on
[4] D. Khadraoui and E. Dubois. B2B eContract Solution for Teleservices. In International Conference on Intelligent Agents, Web Technologies and Internet Commerce (IAWTIC2003), ISBN 1740880692, 12-14 february 2003, Vienna, Austria. [5] C. Castelfranchi. Modelling social action for AI agents. Artificial Intelligence, no. 103, pp157-182, 1998. [6] C. Castelfranchi. Commitments: From individual intentions to group and organizations. In Proceedings of the First International Conference on Multi-Agent System (ICMAS95), pages 41-48, Menlo Park, California, June 1995. [7] M.P. Singh. Commitments Among Autonomous Agents in Information-Rich Environments. In 8th European Workshop on Modelling Autonomous Agents in a Multi-Agent World (MAAMAW), Ronneby, Sweden, 1997. [8] C. Dellarocas. Contractual Agent Societies: Negotiated shared context and social control in open multi-agent systems. Proc. WS on Norms and Institutions in Multi-Agent Systems, Autonomous Agents-2000, Barcelona (2000). [9] M. Sall´e. Electronic Contract Framework for Contractual Agents. In the proceedings of the Eighteenth National Conference on Artificial Intelligence, pages 349-353, July 28-August 1, Edmonton, Alberta, Canada, 2002. [10] V. Dignum, J.J. Meyer, and H. Weigand. Towards an organizational model for agent societies using contracts. In C. Castelfranchi and W.L. Johnson, editors, 1st International Joint Conference on Autonomous Agents and Multi-Agents Systems (AAMAS 02), pages 694-695, Bologna Italy, 2002. ACM Press. [11] M. Morciniec, M. Salle, and B. Monahan. Towards regulating electronic communities with contracts. In 2nd Workshop on Norms and Institution in Multiagent Systems, May 28-June 1, 2001.
[12] Agent Mediated Electronic Commerce, Lecture Notes in Artificial Intelligence 1991, F. Dignum and C. Sierra, Eds. Springer Verlag, 2001. [13] Agent Mediated Electronic Commerce III (LNAI), F. Dignum and U. Cortes, Eds. Springer Verlag, 2001.
