《畢業(yè)設(shè)計(jì)論文 外文文獻(xiàn)翻譯 電子商務(wù)專(zhuān)業(yè) 引入第三方物流企業(yè)的以代理人為基礎(chǔ)的電子商務(wù)系統(tǒng)模型 中英文對(duì)照》由會(huì)員分享，可在線閱讀，更多相關(guān)《畢業(yè)設(shè)計(jì)論文 外文文獻(xiàn)翻譯 電子商務(wù)專(zhuān)業(yè) 引入第三方物流企業(yè)的以代理人為基礎(chǔ)的電子商務(wù)系統(tǒng)模型 中英文對(duì)照（17頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、濟(jì)南大學(xué)畢業(yè)設(shè)計(jì)外文資料翻譯 - 16 - 2007 IEEE/WIC/ACM International Conference on Intelligent Agent Technalogy Introducing Commodity Flow to an Agent-Based Model E-commerce System Tomasz Serzysko Department of Mathematics and Information Science, Warsaw University of Technology,Poland Maria Ganzha,

2、Maciej Gawinecki,Pawel Kobzdej,Marcin Paprzycki System Research Institute,Polish Academy of Sciences,Poland Costin Badica Department of Computer Science,University of Craiova,Romania Abstract In our model agent-based e-commerce system [2] we have assumed that a certain number of items of a

3、given product is available for sale. In this note we introduce a model logistics subsystem and discuss how it will be integrated with the system. Keywords: e-commerce;logistics system;agent 1. Introduction Currently, we are developing and implementing a model agent-based e-commerce system (see

4、[2] and references collected there). In this system multiple buyer agents attempt at making purchase by participating in price negotiations in e-stores and selecting the best o?er, while e-stores attempt at maximizing profit resulting from product sales.Thus far our attention was focused on buyer-se

5、ller interactions. By assuming that products are in the warehouse we have omitted the question where do they come from. The aim of this work is to describe how our system can be extended to include product restocking processes. Before proceeding let us make a few observations. First, the propose

6、d logistics subsystem is not “stand alone” (e.g. similar to that considered in [3, 1, 6]). Instead, it has been created within the context of our e-commerce system, which has directly influenced its design. Second, while somewhat similar, processes involved in e-store restocking a warehouse diffe

7、r from client making a purchase in an e-store (e.g. in product demand prediction, interactions with wholesalers, methods of price negotiations that involve more “conditions,” offer selection criteria, etc.) Therefore we have created a separate logistics subsystem (instead of reusing already modeled

8、 functions; e.g. price negotiations). Third, this note is devoted to the agent structure and agent interactions and, due to the space limitations, we omit important topics like:forecasts derivation, o?er evaluation etc.However, these functions can be encapsulated into modules that can become a part

9、of an appropriate agent. Therefore readers should envision that, for instance, when we write that “received o?ers are evaluated,”then their favorite method of o?er evaluation has been utilized. To proceed, first, we briefly describe our e-commerce system.We follow with assumptions that underline th

10、e logistics subsystem and description of new agents that were introduced. Finally, we present the sequence diagram of restocking and use it to discuss in detail how this process will take place in our system. 2. System Description Our system is a distribute

11、d marketplace in which software agents perform e-commerce functions (see [2] for details, the Use Case diagram in particular). User-Client is represented by the Client Agent (CA). The CA is autonomous and when a purchase order is communicated by the User-Client, it works until either it is complete

12、d, or purchase is abandoned. The CA communicates with the Client Information Center (CIC), which facilitates information which e-stores sell which products (yellow-page matchmaking).For each store that sells the requested product, the CA delegates a Buyer Agent (BA) to participate in price negotiati

13、ons and if successful, possibly attempt at making a pur- chase (successful price negotiations result in a product reservation for a specific time; after which products that have not been purchased are available for sale again).Since multiple BAs representing the same CA can win price negotiations th

14、e CA makes the decision if either of available o?ers is good enough to make a purchase. Buyer Agents can participate in negotiations only if the Gatekeeper Agent (GA) admits them (if they are trusted; e.g. BAs that win price negotiations but do not make a purchase may be barred from subsequent negot

15、iations). The GA represents a given e-store and is created by the Shop Agent (SA). The SA is the central manager and facilitating the selling process it utilizes the GA, and a set of Seller Agents (SeA) that negotiate price with incoming BAs, as well as a Warehouse Agent (WA) that is responsible for

16、 inventory and reservation management. Thus far, the WA was responsible for managing product reservations and the inventory. Specifically, (1) before a new price negotiation the WA “reserved” a given product—so that if negotiation ended successfully there was an item that could be sold; (2) when a

17、reservation ended in purchase, it adjusted product counters; and (3) when a reservation expired it also adjusted products counters. However, the WA was always envisioned as the “gateway” between the store and suppliers, which is one of the foci of this note. 3. Assumptions behind the logistics syst

18、em Let us now specify assumptions that underline design of the logistics subsystem: 1.Nowadays, except of largest store-chains (e.g. TESCO, WalMart), companies outsource transportation activities (considered non-core business activities) to specialists (e.g. UPS, Mayflower). However, we assume

19、 here that suppliers are still responsible for facilitating transportation. Therefore, we omit transportation related processes and focus only in interactions between e-stores and suppliers 2. As a result of (1), transportation costs are assumed to be paid by the supplier and included directly in p

20、roduct price (e.g. discount on delivery costs, will manifest itself in the total price). 3. While in the original system auction-based price negotiations were used, here we opted for the simplicity of the FIPA Contract Net Protocol [4]. Therefore, in the logistics subsystem, a single round of n

21、egotiations consisting of a call for proposals and evaluation of responses, is used. 4. New functions and agents In order to perform logistics-related tasks, several new roles were introduced; some of them have been delegated to agents existing in the system, while others warranted adding new agen

22、ts. Specifically: ? demand estimation—to draw information from sales data and/or external premises to predict future sales of products, ? warehouse monitoring—to observe supply levels and react in case of a risk of dropping below values considered su?cient to satisfy estimated demand, ? order

23、 management—to coordinate issuing orders for goods, to assist in evaluating received o?ers, ? ordering goods—to contact suppliers for their of- fers and to select the best o?er, ? selling goods—in the system suppliers were also modeled; while goods are acquired without extensive price negotiations

24、, “someone” has to deliver proposals to ordering components, ? logistics yellow pages—the role of the “l(fā)ogistics CIC” is very similar to the original CIC ([2]); it has to provide lists of potential suppliers of products; obviously, it is possible for a shop to become a sup- plier for another shop a

25、nd to suggest that the two CICs could be joined, but we decided to clearly separate the client-side from the shop and from the supply-side. Another reason for this separation was that while some shops may not be interested in becoming wholesaler, we would have to make changes to the original CIC da

26、ta structure (e.g. wholesaler—yes/no). Finally, since the logistics subsystem does not involve auctions, the separation is even more warranted. Let us now see how these tasks/roles could be placed in our system. The demand estimation role was attributed to the existing Shop Decision Agent (SDA), re

27、sponsible for the “knowledge management” functions (e.g. trust management, sales trend data mining, etc.) in the shop. The warehouse monitoring role is already a part of the existing WA. The di?erence is that now WA becomes a proactive manager of supplies; acting on predictions supplied by the SDA

28、. Fulfillment of the order management role required introduction of the Logistics Agent (LA), which became the “central manager” of the logistics subsystem. It is responsible for contacting the logistics CIC for the list of potential suppliers and managing a pool of agents responsible for ordering

29、goods from “wholesalers.” Finally, it collects and manages data related to supplier reliability. This data, in turn, will be one of factors in selecting the supplier. The ordering goods process is facilitated by the Ordering Agent (OA), which is also a new agent. Its task is to issue a call for pro

30、posals, collect responses and select the best o?er taking into account factors such as: price, delivery time, reliability etc. Let us recall that due to the modularity of agent design ([2]), our system is flexible enough so that any method of selecting an o?er can be applied (it can be encapsulated

31、in a module and plugged into the OA). The selling goods role is realized by a very simple Wholesale Agent (WhA). Its role is to respond to CFP’s incoming from OAs.Currently we assume that WhAs receive instructions in what way to generate a stream of responses to the CFPs. Finally, logistics yellow

32、 pages are facilitated by the logistics CIC Agent. Its role is to store a complete list of suppliers and products that they sell. Obviously, the logistics CIC uses the original product ontology ([2]), extended by the logistics ontology. When the system is initialized, each WhA registers with the log

33、istics CIC and provides it with a list of products for sale. What was described thus far is summarized in an UML use case diagram presented in Figure 1. Figure 1. Use Case of the logistics subsystem 5. Typical Product Restocking Process Let us now describe the processes involved in restocking

34、the warehouse. Here, we skip the description of system initialization, and start with the Shop Decision Agent sending a forecast to the Warehouse Agent. The sequence of actions resulting form such a forecast is depicted, as a UML sequence diagram in Figure 2. The SDA communicates the forecast to th

35、e WA by sending a FIPA Inform message containing the PredictionDescription (which contains all necessary data such as: product ID, amount of predicted sales, standard deviation of sales, expected purchase price, period for which this forecast is valid, etc.). We assume that the SDA forecasts are o

36、f the type: until a new fore- cast, weekly sales are expected to be 45 items of a given product. Forecasts can be issued at specific times (e.g. once a week or once a month) and their frequency de- pends on the information found in data analyzed by the SDA to derive forecast(s). The WA starts by e

37、xamining current stock of a given product, and if current supplies are su?cient, it sets up to check their levels at the end of the time unit specified in the forecast (i.e. forecasts specified on weekly basis are checked once a week). If stocks are insu?cient, the WA utilizes the FIPA Request Pro

38、tocol (FIPA specification SC00026) and FIPA SL language [4] (used in all agent interactions), to com- municate with the Logistics Agent. The initial message from the WA is the FIPA Request message sent to the LA and it contains OrderRequest action with the Or- derRequestDescription. The OrderRequest

39、Description contains the necessary information specifying the order to be made: product ID, preferred delivery time, amount and maximum price. Delivery time and amount are computed based on the current product level, predicted delivery time and an overall inventory strategy. Upon receiving the re

40、quest, the LA dispatches a query to the logistics CIC to obtain a list of suppliers of a given product. Ensuing conversation conforms to the FIPA Query Protocol, starting with the FIPA Query-Ref message containing the CICQuery action with the Product ID. The logistics CIC responds with the FIPA Info

41、rm-Ref message containing the CICResponse with a list (possibly empty) of suppliers. Empty list results in a FIPA Failure message (with OrderRequestResult set to failure) send by the LA to the WA. Similar response is sent when the logistics CIC cannot be contacted. When the non-empty list was recei

42、ved, the LA removes these suppliers that have their reliability value below a certain threshold. Then the LAAgentDescriptions list is formed by supplementing each CICAgentDescription received from the logistics CIC with the reliability information. If a given WhA’s is not known a default trust

43、value is used. After preparing the list, the LA utilizes the FIPA Request Protocol to find a free OA. Busy agents will re- spond with FIPA Refuse messages. If all agents respond in such a way, this process may need to be repeated un- til a free OA is found and responds with the FIPA Agree message.

44、The LA then sends the ordering request to the selected OA and awaits for the result of the ordering pro- cess. LA’s message contains the IssueOrder action with the OrderDescription and the LAAgentDescriptions. After obtaining the request from the LA, the OA engages in the FIPA ContractNet Protocol

45、interactions with WhAs from the list. It sends the FIPA CallForProposal message, containing CFPRequest with OrderDescription to the WhAs. WhAs evaluate the CFP and submit their o?ers by sending FIPA Propose messages containing the CFP Response action with O?erDescription or, if terms contained in th

46、e CFP are unacceptable/not interesting, respond using the FIPA Refuse message. Responses must arrive within a timeframe speci- fied by the OA, after which the OA proceeds to evalu- ate them. First, it filters unacceptable o?ers. Note that it is possible that some WhAs may respond knowingly with pro

47、posals that violate some of the conditions and in special circumstances when no better o?ers were found the OA may need to accept such o?ers. In the next step, o?ers are ranked and the winner is determined. Winner is sent a FIPA AcceptProposal message containing the ConfirmationRequest action with i

48、ts offer quoted. The winning WhA must in turn reply with the FIPA Inform message containing Confirmation Response action with the OrderConfirmation which has unique orderID generated by the supplier. This successfully completes the ordering process. The winner can also withdraw the o?er by sending

49、a FIPA Failure message. In this case, runner-ups are contacted in an iterative manner. In case when there are no more o?ers left or there were no o?ers to begin with, the OA sends a FIPA Failure message to the LA, which, in turn, forwards it to the WA. When the winner confirms the order, the OA sen

50、ds to the LA a FIPA Inform message containing the InformResult action with the WhA-received Order Confirmation, thus completing the protocol. At this time the LA sends information to the WA, inside a message of the FIPA Agree type. This performative is used in compliance with the protocol to indicat

51、e that the LA is performing the desired task (ordering), but its e?orts do not guarantee success (ordering success order success), and thus sending the final response (FIPA Inform) is inappropriate at this stage. Meanwhile the OA returns to the pool of available Ordering Agents. Now the purchase en

52、ters the delivery monitoring stage. Here, the LA waits for the delivery from the WhA to be registered with the WA. When a delivery arrives the WA sends (to the LA) a plain FIPA Inform message containing the WADelivery action with the DeliveryDescription, which has supplier’s AgentID and the alread

53、y mentioned orderId. The LA does not need to respond to this message, but it checks the messages to see if it is currently awaiting a delivery with the given orderId coming from a supplier AgentID. If it finds a match, the ordering process is completed. As a result, the reliability value of supplied

54、 AgentID is increased. If a delivery notification does not come within time agreed in the OrderConfirm, actions must be undertaken (recall, that receiving supplies is vital to the e-Shop as its warehouse is likely to run out of stock Those actions are: (1) retry the ordering (sending reminder to the

55、 WhA / choosing new WhA), if there is still time, and (2) marking that a retry has been made. If there is still time before the deadline (established by the WA), then order can be retried. If it is the first time an attempt to retry the order is made, a reminder is sent to the WhA. To this end, LA

56、 contacts a free OA with a FIPA Request Protocol message with a Reminder action containing AgentID of the WhA and the orderId. The OA accepts the job (the FIPA Agree) and contacts the WhA (also using FIPA Request Protocol), sending it the exact same action. The WhA is expected to reply within a tim

57、eframe using either a FIPA Failure (o?er is withdrawn) or a FIPA Inform providing new Order Confirmation with a new delivery time, which is forwarded to the LA unchanged. In the case of an agreement, the LA returns to awaiting delivery, in the case of failure, the LA removes this WhA from the LA Ag

58、ent Description list and locates an OA to perform entirely new search for a supplier. New search is also ordered if a reminder to the supplier whose delivery we were waiting resulted in a failure. The monitoring stage ends when: (1) delivery is received, or (2) reminder to the supplier was made, bu

59、t it was refused, while deadline has already passed. Note that we assume that the actual order failure occurs only when the delivery deadline has passed and the reminder failed.This is because it is possible that there is an order delay and goods may arrive late. This information can be obtained fro

60、m the WhA, and thus the need for the reminder. Figure 2. Restocking process: sequence diagram When the monitoring stage ends, the WA is notified about the result by the FIPA Inform or the FIPA Failure message to complete the FIPA Request protocol. The message will contain the OrderRequest acti

61、on with the OrderRequestResult set appropriately. Furthermore, at this stage the reliability bonuses and/or penalties are calculated and applied. Finally, in the case of a successful order, the WA sends to the SDA a FIPA In- form message containing status information about the re-stocking of the war

62、ehouse. 6. Concluding remarks In this note we have discussed the way in which the logistics subsystem is being introduced into our model agent-based e-commerce system. We have presented used UML’s use case and sequence diagrams to formally depict and discuss the most important features of our appr

63、oach. Due to the lack of space, we have focused our attention on agents and their interactions. The proposed system has been implemented and is in the final testing phase. References [1]AgentisSoftware,2007. [2] C. Bdic, A. Bdit, M. Ganzha, M. Paprzycki, Developing a Model Agent-based E-commerce

64、System. In: Jie Lu et. al. (eds.) E-Service Intelligence—Methodologies, Technologies and Applications, Springer, Berlin, 2007,555–578 [3] C. A. Butler and J. T. Eanes. Software agent technology for large scale, real-time logistics decision support. US Army Research Report ADA392670, 2001. 23 pages.

65、 [4] FIPA: Foundation for Physical Agents.http://www.fipa.org [5] JADE: Java Agent Development Framework.http：//jade.cselt.it [6]W.Ying and S.Dayong. Multi-agent framework for third party logistics in e-commercestar. Expert Systems with Applications, 29(2):431–436, August 2005.

66、 International Conference on Intelligent Agent Technalogy,2007, 78(7): 294-298 引入第三方物流企業(yè)的以代理人為基礎(chǔ)的電子商務(wù)系統(tǒng)模型 Tomasz Serzysko 數(shù)學(xué)信息科學(xué)部門(mén)，波蘭華沙工業(yè)大學(xué) Maria Ganzha,Maciej Gawinecki,Pawel Kobzdej,Marcin Paprzycki 波蘭研究院 Costin Badica 羅馬尼亞大學(xué)計(jì)算機(jī)科學(xué)部門(mén) 摘要 在我們的模型以代理人為基礎(chǔ)的電子商務(wù)系統(tǒng)[2]的基礎(chǔ)上,我們假定一定數(shù)量的物品的某一特定的產(chǎn)品是適合出售的。摘要本文我們介紹了模型的物流系統(tǒng)并且討論了如何將它與系統(tǒng)結(jié)合。 關(guān)鍵詞:電子商務(wù)；物流系統(tǒng)；代理 1. 簡(jiǎn)要 目前,我們正在開(kāi)發(fā)和實(shí)施模式以代理人為基礎(chǔ)的電子商務(wù)系統(tǒng)(參見(jiàn)[2]的基礎(chǔ)上,參考文獻(xiàn)收藏)。在該系統(tǒng)中當(dāng)網(wǎng)上商店試圖獲得產(chǎn)品銷(xiāo)售利潤(rùn)最大化的時(shí)候，多買(mǎi)方代理試圖通過(guò)在電子商店參與價(jià)格談判做出購(gòu)買(mǎi)