A Secure Multiagent Intelligent Conceptual ... - Semantic Scholar

Chapter 30

A Secure Multiagent Intelligent Conceptual Framework for Modeling Enterprise Resource Planning Kaveh Pashaei, Farzad Peyravi, and Fattaneh Taghyareh

30.1 Introduction Facing the challenge of responding more rapidly to changing markets, manufacturing industries have been motivated to explore many exciting innovations in their business practices and procedures such as MRP, ERP, EIS, CIM, and the like [1–3]. However, economic globalization is forcing companies to look further for worldclass manufacturing levels. The limitation of resources, such as technology, people, or money, makes enterprises focus on their own competence as well as try to get involved with others. The core idea here is that enterprises should share their resources and abilities without owning them, in order to exploit the market opportunity that is beyond the ability of a single enterprise [4–6]. In the late 1970s and early 1980s, the need for enterprisewide integrated systems intensified as global competition became inevitable, and product customization and innovation became important factors to retain customers and subsequently to gain market share [7]. Systems thinking-based management philosophies such as total quality management and just-in-time systems were introduced, which necessitated the management of relationships among functional areas and cross-organizational processes. The development of such systems slowly evolved from standalone systems (e.g., a standard inventory control system) to material requirement planning/ manufacturing resource planning (MRP I and MRP II) systems, and subsequently, to enterprisewide systems to include other functional areas such as sales and marketing, financial accounting, and human resource management. However, attempts to provide a complete enterprisewide software solution were not successful until the mid-1990s due to technical complexity, lack of resource availability, and unclear vision [8]. In the mid-1990s, the Gartner Group coined the term “ERP” to refer to nextgeneration systems which differ from earlier ones in the areas of relational database management, graphical user interface, fourth generation languages, client– server architecture, and open system capabilities [9]. The integration is normally Oscar Castillo et al. (eds.), Trends in Intelligent Systems and Computer Engineering. c Springer Science+Business Media, LLC 2008

427

428

K. Pashaei et al.

implemented through the use of a common database among subsystems. The information is updated as changes occur, and the new status is available for everyone to use for decision making or for managing their part of business. The decisions made in different functional areas are based on the same current data to prevent nonoptimal decisions from obsolete or outdated data. Expected benefits from ERP implementation include lower inventory, fewer personnel, lower operating costs, improved order management, on-time delivery, better product quality, higher productivity, and faster customer responsiveness [10]. Multiagent enterprise resource planning is an area that has indeed received a lot of attention amongst researchers in the past two decades. The MetaMorph II agentbased architecture, a distributed intelligent environment that integrates manufacturing enterprise was proposed in Shen and Norrie [11]. The AARIA (Autonomous Agents for Rock Island Arsenal) architecture [12] describes the capabilities of a distributed manufacturing complex to configure itself in order to satisfy an individual customer’s desires. Agent-based techniques were developed in Turoski [13] for coordinating activities of e-commerce and an Internet-based supply chain system for mass customization markets. Agent-based architectures were proposed in Li and Fong [14] to facilitate the formation and organization of virtual enterprises for order management. An approach is presented in Zhang et al. [15] that would enable manufacturing organizations to dynamically and cost-effectively integrate their own manufacturing systems in a coordinated manner to cope with the dynamic changes occurring in a global market. Furthermore in Wong and Sycara [16], Soshi and Maekawa [17], and Thirunavukkarasu et al. [18] the general analysis and classifications of attacks and possible countermeasures for securing agent technology as part of published agent systems is described. The security requirement and design for mobile agents is addressed in Corradi et al. [19] and Korba [20]. Several challenges remain and there has not been work on developing a security model for multiagent ERP systems. Furthermore, there is not an evaluating factor for measuring the data migration time in secure and nonsecure modes. In this context, security mechanisms are used to capture the privileges and part of security policies required in distributed applications which can then be used as a dynamic capability in providing distributed authorization and confidentiality. The purpose of this chapter is to investigate the use of software agents to achieve the secure system integration of ERP software packages. A secure multiagentbased intelligent ERP (SMAIERP) architecture is proposed to take advantage of the existing information systems and security techniques to simulate the secure ERP system using capabilities and characteristics of the software agent-based computer systems. The rest of the chapter is organized as follows. In the next section, we discuss the MetaMorph I as a model that describes two architectures of the multiagent system, namely, the brokering and recruiting mechanisms for selecting our model. Next architecture of SMAIERP system is provided to highlight its properties, various types, and applications in order to establish its viability for developing an ERP type system. In Sect. 30.4, security issues are discussed. Section 30.5 shows how agents communicate and synchronize with each other. Experimental environment

30 Modeling Enterprise Resource Planning

429

and simulation results in a secure and nonsecure manner is described in Sect. 30.6. Finally, the implications of the SMAIERP system and future research directions are provided.

30.2 MetaMorph I MetaMorph (now referred to as MetaMorph I) [21] is a multiagent architecture for intelligent manufacturing developed at The University of Calgary. The architecture has been named MetaMorphic, because a primary characteristic is its changing form, structure, and activity as it dynamically adapts to emerging tasks and changing environment. Additionally, mediator agents assume the role of system coordinators by promoting cooperation among intelligent agents and learning from the agents’ behavior. Mediator agents provide system associations without interfering with lower-level decisions unless critical situations occur. Mediator agents are able to expand their coordination capabilities to include mediation behaviors, which may be focused upon high-level policies to break decision deadlocks. Mediation actions are performance-directed behaviors. Mediator agents can use brokering and recruiting communication mechanisms [22] to find related agents for establishing collaborative subsystems. The brokering mechanism consists of receiving a request message from an intelligent agent, understanding the request, finding suitable receptors for the message, and broadcasting the message to the selected group of agents. This mechanism is shown in Fig. 30.1. The recruiting mechanism is a superset of the brokering mechanism, because it uses the brokering mechanism to match agents. However, once appropriate agents have been found, these agents can be directly linked. The mediator agent then can step out of the scene to let the agents proceed with the communication themselves. This mechanism is shown in Fig. 30.2. Both mechanisms have been used in MetaMorph I. To efficiently use these mechanisms, mediator agents need to have sufficient organizational knowledge to match agent requests with needed resources. Organizational knowledge at the mediator level is basically a list of agent-to-agent relationships that is dynamically enlarged.

Fig. 30.1 Brokering mechanism

430

K. Pashaei et al.

Fig. 30.2 Recruiting mechanism

The brokering and recruiting mechanisms generate two relevant types of collaboration subsystems. The first corresponds to an indirect collaboration subgroup, because the requester agent does not need to know about the existence of other agents that temporarily match the queries. The second type is a direct collaboration subgroup, because the requester agent is informed about the presence and physical location of matching agents to continue with direct communication. One common activity for mediator agents involved in either type of collaboration is interpreting messages, decomposing tasks, and providing processing times for every new subtask. These capabilities make mediator agents very important elements in achieving the integration of dissimilar intelligent agents. Federation multiagent architectures require a substantial commitment to supporting intelligent agent interoperability through mediator agents. In MetaMorph I [21], mediators were used in a distributed decision-making support system for coordinating the activities of a multiagent system. This coordination involves three main phases: subtasking, creation of virtual communities of agents (coordination clusters), and execution of the processes imposed by the tasks. These phases are developed within the coordination clusters by distributed mediator agents together with other agents representing the physical devices. The coordination clusters are initialized through mediator agents, which can dynamically find and incorporate those other agents that can contribute to the task.

30.3 Architecture of SMAIERP System The proposed SMAIERP architecture uses the recruiting mechanism from MetaMorph I and is composed of a set of five software agents: a coordinating agent, a planning agent, an interface agent, a data collecting agent, and a set of task agents. We propose that this set of software agents within each functional area (say, department A and department B) interacts through a coordinating agent. Figure 30.3 illustrates the abstract level of the SMAIERP system architecture with coordination agents serving as the representatives of each department and communicating with each other over the company’s network. There is a user interface agent who serves

30 Modeling Enterprise Resource Planning Users in Department A

Users in Department B

Interface Agent A

Interface Agent B

Coordination Agent A

Company Network

431

Coordination Agent B

Company Network

Planning Agent B

Planning Agent A

Execution Agents A Data Collection Agents A

Company Network

Execution Agents B Task Agent A1

Task Agent An

Data Collection Agents B

Task Agent B1

Task Agent Bn

Fig. 30.3 Architecture of SMAIERP system

as a communication tool between the user and the SMAIERP system, and there is a collection of execution agents which is composed of several task agents and data collecting agents that perform specific tasks within the department. Furthermore, there is a planning agent who establishes its plan and broadcasts this to execution agents. Next, various functions/responsibilities undertaken by each type of software agent are discussed.

30.3.1 The Coordination Agent The coordination agent is the heart of this multiagent intelligent ERP architecture, is the representative of the department when communicating with other coordination agents, and is the controller of the other agents within the department. A department can have one or many coordination agents depending on the nature of task complexity. The major responsibilities for the coordination agent include: • Receiving instructions and reporting to the human user through an interface agent • Communicating with execution agents and exchanging data with them through planning agent • Communicating with and providing requested data to other coordination agents With their domain knowledge, the coordination agents have the ability to monitor, communicate, and collaborate with other agents, as well as react to various requests.

432

K. Pashaei et al.

30.3.2 The Planning Agent The planning agent is in charge of department planning functions. To keep the agents relatively simple, it is desirable to limit the number of functions encapsulated to a small number. In pinpointing the planning agents in the department, we need to first identify the main planning intensive functions and processes in the planning level of the organization. These are selected from a complete set of planning processes which are tasked to the various resources. As highlighted by Huin et al. [23], there are usually only a limited number of planning agents in a department. However, if one looks at the interface between any two operational departments, it can be seen that the information transmitted between the agents is in the form of “orders” (e.g., purchase order, material issue vouchers, firmed planned orders, etc.), and the “commitment” to the orders (e.g., confirmed sales orders). These are the “Demands” and “Production Orders” which the departments must react to quickly to fulfill the needs of their customers. These should be matched as quickly as possible to ensure the competitiveness of the organization. Therefore the responsibilities of planning agent include: • Assigning data collection to and receiving data from a data collection agent • Relaying the dataset, assigning tasks to, and receiving feedback from task agents • Assign tasks to proper task agents and data collection agents

30.3.3 The Data Collection Agent The objective of the data collection agents is to query specific database(s) within the department and obtain the information requested by its own coordination agent. It possesses specific domain knowledge needed to carry out its tasks. The “intelligence” in the data collection agents identifies invalid data and missing values so that the data are complete and applicable when being returned to the coordination agent. However, the structures or abilities of data collection agents need not be the same in different departments because each department may have a different database management system (DBMS) or data warehouse. The responsibility of a data collection agent is to: • Retrieve information requested by its own planning agent. • Query specific database(s) within the department. • Perform data warehousing and prepare dataset upon request from planning and coordination agent.

30.3.4 The Task Agent The task agents usually possess mobility and can act autonomously within their own domain knowledge without the intervention of coordination agents. For example, a


433

task agent that is assigned to monitor price change would go to and stay in a supplier’s site to monitor the supplier’s price and report any price change that crosses given threshold values with or without the instruction from its coordination agent. The number of task agents varies by the number and complexity of tasks within a department. The functions of a task agent may also vary from department to department depending on what needs to be accomplished. In general, the responsibilities of a task agent include: • Receiving data from the planning agent • Performing data analysis by running specific program and/or algorithm

30.3.5 The Interface The interface agent possesses the ability to learn and store preferences of users and the ability to monitor and inform users when tasks have been completed without the inquiry of users. With enhancement, the interface agent may observe and record the user’s disposition to follow the recommendations of coordination agents and invoke machine learning to determine many of the user’s preferences. The primary responsibilities of an interface agent include: • Communicating between human users and coordination agents • Interpreting results • Preparing reports for human users

30.4 Security Implications In this architecture, security mechanisms should be considered for agent communications, for example, when the planning agent of the accounting department requests the planning agent of the inventory department to send its prediction about the costs of goods that were provided for the whole organization for the next year, it is necessary to make sure that other agents could not access this report or guarantee authentication of this message. Thus to ensure the security issues for agent communications we use one of the cryptography techniques, namely, RSA. This algorithm provides these following security properties [23]. • Confidentiality: Assurance that communicated information is not accessible to unauthorized parties • Data integrity: Assurance that communicated information cannot be manipulated by unauthorized parties without being detected • Authentication of origin: Assurance that communication originates from its claimant • Availability: Assurance that communication reaches its intended recipient in a timely fashion

434

K. Pashaei et al.

Fig. 30.4 Encryption/decryption of messages using PGP toolkit

• Nonrepudiation: Assurance that the originating entity can be held responsible for its communications We use open the PGP tool for encrypt and decrypt messages in the planning agent of each department. This process is done as shown in Fig. 30.4 [23]. The encryption/decryption process of messages between data communicating agents has the following steps 1. 2. 3. 4. 5. 6.

7. 8. 9. 10. 11.

Sender agent creates a message M. SHA-1 is used to generate 160 bit hash code of message. Hash code of message is encrypted using sender agent’s private key. This encrypted message concatenates with original message M and then zips them. The zipped message is encrypted using session key that produced by sender agent. Session key is encrypted with receiver’s public key and concatenates with the message produced in step 5. The message produced in this step contain two parts; the first part is the session key which is encrypted with receiver public key and the second part contains the encrypted message using the sender agent private key for determining authentication of sender agent and the original message that was zipped and encrypted with session key. Receiver agent decrypts the first part using its private key to obtain session key. Decrypt the second part using session key. Unzip the message. This message contains the original message M and a header for authentication check. The header is decrypted with the sender public key and compared to H(M) which denotes the hashed initial message for authentication check.

We use this process for important messages such as critical reports for each department and current inventory status to guarantee the authentication and confidentiality of important messages.

30.5 Communication and Synchronization of Agents The four types of agents have the same logical structure. They exchange information with internal entities and the outside world by receiving and dispatching messages through independent interfaces. Action is taken upon the reception of the


435

Communication Channel

Agent A Agent Dispatch

Agent B

Agent Reception

Action

Action

Agent Reception

Agent Dispatch

Fig. 30.5 Communication and interface of the various resources agents within department. indicates outflow of information. indicates the inflow of information

corresponding message. The changed state, particularly for the execution agents, is transmitted to other agents. Also the planning results from each planning agent may affect the planning process of other agents. Agents need to exchange information in order to adapt to each other processes (see Fig. 30.5). This helps ensure that essential project information is collated and communicated at the various levels. There are two possibilities for exchanging messages. The agents can broadcast information about their intended actions to each other. This incurs a large amount of system overhead because more information must be exchanged and because agents may duplicate each others’ rational decisions. Such weakness can bog down any ERP project management in the organization. In this four-tier architecture, the agents transfer their plans to the coordinating agents only before it converges. This arrangement transforms the traditional organizational dynamics of a multilateral affair between the agents involved into a set of bilateral negotiations. In this case, the planning agents do not only interact directly with each other but each agent must communicate his final plans with the coordination agent. In Fig. 30.4, the messages exchanged between the planning agents are simply the outcome of the plans as and when they are processed, such as changes to the orders. No other internal information is normally exchanged except that from the execution agents which are submitted and kept with the planning agents. The information that a planning agent submits to the coordination agent is the final project plan information provided to the adjacent planning agent. In this manner, the information confidentiality and transfer problems are properly handled within the system. The coordination agent is in full control and has knowledge of the project plans and actions. There are two approaches in representing events and their effects on the execution phase: state-based representation [24] and event-based representation [25]. Actions taken by the execution agents are triggered by the messages from the department planning agents. After execution, the systems states are dispatched back to the planning agents for further actions. The various agents act as controller whose responsibility is to ensure that the plans are executed properly and the systems states are well maintained. The agents transfer their plans to the coordinating agents only before it converges.

436

K. Pashaei et al.

30.6 Experimental Environment and Simulation Results In order to illustrate the proposed SMAIERP system in a manufacturing firm, we demonstrate our model and implement it in a secure manner, and then we compare our result in nonsecure mode, secure mode, and a combination secure and nonsecure mode. We use time factor versus data size to exemplify our results. We assume that one coordination agent is assigned to the marketing (i.e., Coordination Agent M), accounting (i.e., Coordination Agent A), inventory (i.e., Coordination Agent I), and logistics/distribution (i.e., Coordination Agent D) departments. Due to the numbers and complexity of tasks, two coordination agents are assigned to the production department for the product mix optimization system (i.e., Coordination Agent PO) and for the master production scheduling system (i.e., Coordination Agent PS). Furthermore, for each coordination agent, there is one interface agent, and one execution agent which consists of the data collection agent, and several tasks agents. Figure 30.6 provides an overview of SMAIERP system. In our model the encryption/decryption process is done in the coordination agent of each department. Each coordination agent uses the PGP toolkit for decryption of messages that must be sent in secure mode. For implementation we assume that these agents are distributed nodes and we simulate them according to Fig. 30.7

Logistic / Distribution Department

Marketing Department Order Acceptance/Demand Market demand forecast system forecast system

Interface Agent L /D

Interface Agent M

Coordination Agent L /D

Coordination Agent M

Database Database Inventory Management Department

Planning Agent L /D

Planning Agent M

Execution Agents L/D Execution Agents M Data Collection Agent L/D

Task Agent L/D

Task Agent L/D

Task Agent M1

Data Collection Agents M

Database

Communication Channel

Task Agent Mn

Production Department Product Mix Optimization system

Interface Agent IM Interface Agent P Coordination Agent IM

Planning Agent IM Execution Agents IM Data Collection Agents IM

Task Agent IM1

Database

Task Agent IMn

Planning Agent P

Planning Agent A

Accounting Department Interface Agent A Database

Execution Agents P

Execution Agents A Data Collection Agents A

Manufacturing Production System

Coordination Agent P

Coordination Agent A

Task Agent A1

Task Agent An

Data Collection Agents P

Fig. 30.6 An SMAIERP system application in a manufacturing firm

Task Agent P1

Task Agent Pn

Master Production Scheduling System


437

Fig. 30.7 Coordination agents in our topology

350 Secure Data Non Secure Data Secure & Non Secure Data Expon. (Secure & Non Secure Data)

300 250 200 150 100 50

00

0 10 0 50 11 0 50 12 0 50 0

Data Size

95

00

85

00

75

00

65

00

55

00

45

00

35

25

0 50

15

00

0

Fig. 30.8 Average time spent for data migration in secure, nonsecure, and secure and nonsecure manner

topology. Each of these nodes accesses other nodes through the communication channel, so in the topology we connect these coordination agents directly. We developed software to simulate secure and nonsecure environments and compare them. This simulator is configurable for testing data transmission in a security manner and nonsecurity manner and different data request conditions. Our simulator marks each data send and receive time. In our experiments, we consider two factors: average time spent for moving data from one coordination agent to another (data migration time) and response time which is the sum of waiting for processing request, processing request, waiting for communication channel, and data migration time. We investigate the effect of different data sizes on these factors. First we sent data from one coordination agent to another in a secure manner and then we sent data in a nonsecure manner. We assume that from 110 messages interchanged between agents, 10 messages must send in secure manner and 100 messages must send in nonsecure manner. Figure 30.8 shows the effect of data size versus time factor. According to Fig. 30.8 for all data sizes the average time spent for data migration in the secure manner is much larger than the nonsecure manner. The reason is that

438

K. Pashaei et al.

Fig. 30.9 Delay of response in secure manner

for secure data we use PGP software and the RSA algorithm to encrypt/decrypt messages. In the case of combination of secure and nonsecure data according to our assumption the average time spent for data migration is close to the nonsecure condition. As shown in Fig. 30.8, the equation of exponential regression of data migration to data request in secure and nonsecure manner is: y = 12.749e01367x For calculating the delay of response to a data request from the coordinator agent we consider two factors: data size and data request rate. As the data request rate increased, the delay of response time for fixed data size increased. This effect is demonstrated in Fig. 30.9. Additionally the delay of response for fixed data request rate is increased when the data size is enlarged. We calculate this delay for evaluation of response time to a data request from the coordination agent of each department. Furthermore our experiments show that the data request rate from the coordinator agent of each department has a Poisson distribution which has an average λ = 23 in the 100 min intervals. Figure 30.10 illustrates the response time for nonsecure, secure, and secure and nonsecure manner versus data size according the Poisson distribution of data requests. Figure 30.10 depicts that for data size between 500 and 3,500 the response time in secure manner is relatively close to nonsecure manner. For data size larger than 3,500 response time for secure manner is larger than nonsecure manner. The reason is that for secure data we use processing time to encrypt/decrypt messages. Figure 30.11 represents the processing time for encrypt/decrypt message in secure manner. In the case of combination of secure and nonsecure data according to our


Secure Data

Response Time

10000 9000 8000 7000 6000 5000 4000 3000 2000 1000 0

439

Non Secure Data

12500

Data Size

11500

10500

9500

8500

7500

6500

5500

4500

3500

2500

500

1500

Secure & Non Secure Data

Power (Secure & Non Secure Data)

300 250 200 150 100 50

Processing Time

11 0 50 12 0 50 0

50

10

00

95

00

85

00

00

75

00

65

55

00

45

00

35

00

00

25

15

0

0 50

Processing Time in secure manner

Fig. 30.10 Response time in secure, nonsecure, and secure and nonsecure manner

Data size

Fig. 30.11 Processing time in secure manner

assumption the response time is close to nonsecure condition. As shown in Fig. 30.9, the equation of power regression of response time to data request in secure and nonsecure manner is: y = 326.16x1.1981 The results show that there is little difference between nonsecure manner and the combination of secure and nonsecure manner in both data migration time and response time, so we can use this model to transfer agents’ important messages and ensure the security of our model.

30.7 Conclusion In this chapter, we present a secure multiagent system that is capable of providing enterprisewide integration. With this approach, we demonstrate that a set of software agents with specialized expertise can be quickly assembled to gather relevant information and knowledge, and more important, to cooperate with each other in a

440

K. Pashaei et al.

secure manner in order to arrive at timely decisions in dealing with various enterprise scenarios. We introduce four types of agents, namely, interface agent, coordination agent, planning agent, and execution agent which cooperate with one another to handle the process of the organization. Furthermore, we introduce a mechanism that ensures the security of our architecture. This mechanism uses public key, private key, and session key for encrypting and decrypting important messages interchanged between agents. Using this security mechanism in our topology demonstrates that if we use the combination of secure and nonsecure mode, the average time spent for data migration and response time to a data request is close to the nonsecure mode. Thus we can send our important messages through the secure mode. In this agentbased model each department has its own set of agents. This secure four-level model can thus be applied to solve organizational dynamics issues in enterprise resources planning projects in organizations. Further research is needed to extend the current work and to address its limitations.

References 1. E. Teicholz and J. Orr, Computer Integrated Manufacturing Handbook. New York: McGrawHill, 1987. 2. AMICE and CIMOSA, Open System Architecture for CIM. New York: Springer Verlag, 1993. 3. P. Bernus and L. Nemes, Modeling and Methodologies for Enterprise Integration: IFIP. New York: Chapman and Hall, 1996. 4. W.H. Davidow and M.S. Malone, The Virtual Corporation: Structuring and Revitalizing the Corporation for the 21st Century. New York: Harper Collins, 1992. 5. J. Browne, “The extended enterprise—Manufacturing and the value chain,” presented at Proceedings of BASYS95, 1995. 6. L.M. Camarinha-Matos and H. Afsarnianesh, Handbook of Life Cycle Engineering: Concepts, Tools and Techniques, Chapter Virtual Enterprise: Life Cycle Supporting Tools and Technologies. New York: Chapman and Hall, 1997. 7. R. Kalakota and M. Robinson, e-Business 2.0: Roadmap for Success. Boston: AddisonWesley, 2000. 8. K. Kumar and J.V. Hillegersberg, “ERP experiences and evolution,” Communication of the ACM, 43(4), pp. 22–26, 2000. 9. C. Dahlen and J. Elfsson, “An analysis of the current and future ERP market with focus on Sweden,” Stockholm: available at http://whitepapers.techrepublic.com.com/whitepaper. aspx?&docid = 3805&promo = 100511, 1999. 10. B. Robinson and F. Wilson, “Planning for the market? Enterprise resource planning systems and the contradictions of capital,” Database for Advances in Information Systems, 32(4), pp. 21–33, 2001. 11. W. Shen and D.H. Norrie, “An agent-based approach for manufacturing enterprise integration and supply chain management,” presented at Globalization of Manufacturing in the Digital Communications Era of the 21st Century: Innovation, Agility, and the Virtual Enterprise, 1998. 12. A.D. Baker, H.V.D. Parunak, and K. Erol, “Manufacturing over the Internet and into your living room: Perspectives from the AARIA project,” ECECS Department, Technical Report 1997. 13. K. Turoski, “Agent-based e-commerce in case of mass customization,” International Journal of Production Economics, 75(1–2), pp. 69–81, 2002.


441

14. T. Li and Z. Fong, “A system architecture for agent based supply chain management platform,” In Proceedings of the 2003 Canadian Conference on Electrical And Computer Engineering (CCECE): Toward a Caring and Humane Technology, 2003. 15. D.Z. Zhang, A.I. Anosike, M.K. Lim, and O.M. Akanle, “An agent-based approach for e-manufacturing and supply chain integration,” Computers & Industrial Engineering, 51, pp. 343–360, October 2006. 16. H.C. Wong and K. Sycara, “Adding security and trust to multi-agent systems,” presented at Autonomous Agents ’99 Workshop on Deception, Fraud and Trust in Agent Societies, 1999. 17. M. Soshi and M. Maekawa, “The Saga security system: A security architecture for open distributed systems,” presented at 6th IEEE Computer Society Workshop on Future Trends of Distributed Computing Systems, 1997. 18. C. Thirunavukkarasu, T. Finin, and J. Mayfield, “Secret agents a security architecture for the KQML Agent communication language,” presented at CIKM ’95 Intelligent Information Agents Workshop, Baltimore, December 1995. 19. A. Corradi, R. Montanari, and C. Stefanelli, “Security issues in mobile agent technology. Distributed Computing Systems,” presented at 7th IEEE Workshop on Future Trends of Distributed Computing Systems, 1999. 20. L. Korba, “Towards secure agent distribution and communication,” presented at 32nd Hawaii International Conference on System Sciences, 1999. 21. F. Maturana and D. Norrie, “Multi-agent mediator architecture for distributed manufacturing,” Journal of Intelligent Manufacturing, 7, pp. 257–270, 1996. 22. K. Decker, “Environment centered analysis and design of coordination mechanisms,” Ph.D. Thesis. Amherst: Massachusetts in Department of Computer Science, 1995. 23. S. Huin, L. Luong, and K. Abhary, “Managing enterprise resources planning systems deployment in SMEs,” presented at Proceedings of the 3rd International Conference on Project Management Society of Project Management, and College of Engineering, Japan, 2002. 24. W. Stalling, Cryptography and Network Security Principles and Practice. Upper Saddle River, NJ: Prentice-Hall, 2003. 25. A. Lansky, “Localized event-based reasoning for multi-agent domains,” presented at SRI International, Stanford University, 1998.