2014 IEEE International Conference on Systems, Man, and Cybernetics October 5-8, 2014, San Diego, CA, USA
JADE-JBossESB Gateway: Integration of MultiAgent System with Enterprise Service Bus Pavel Vrba, Michal Fuksa
Martin Klíma
Czech Institute for Informatics, Robotics, and Cybernetics Czech Technical University in Prague Prague, Czech Republic {pavel.vrba, fuksamic}@fel.cvut.cz
CertiCon, a.s. Prague, Czech Republic
[email protected]
Abstract—The paper presents a framework for integration of JADE-based multi-agent platform with the JBossESB Enterprise Service Bus. The framework provides means for wrapping the JADE agent system in the JBossESB service and transforming the agent messages to ESB messages and vice versa. This enables an agent wrapped in the ESB service to send a message to another ESB service or to another agent residing within a different service. Such framework is used in the ARUM project focused on adaptive production planning and scheduling in complex small-lot manufacturing industries, such as aircraft manufacturing. The scheduler service internally designed as a multi-agent system utilizes the presented gateway to communicate with other services over the ESB, namely with the ontology service providing it with the data from legacy systems. Keywords—multi-agent systems; JADE; FIPA; Web services; Enterprise Service Bus; JBossESB; scheduling
I.
CONTEXT AND MOTIVATION
This paper reports on the design of a framework supporting the integration of two similar software design architectures into a coherent instrument suitable for modeling large-scale complex industrial systems. On one hand it is the multi-agent systems (MAS) technology, in which the complex system is decomposed into smaller units – agents – that autonomously manage their local goals and interact with each other to collectively fulfill the system-wide objectives. On the other hand, it is the Service Oriented Architecture (SOA) representing a standardized architecture for building modular software applications based on reusable and loosely coupled services. Both agents and services have been successfully applied for designing industrial control systems, bringing features like scalability, robustness and reconfigurability and thus far outperforming classical centralized and hierarchical systems [1], [2], [3]. Even though both paradigms show common characteristics – the distribution of functionality among loosely coupled interacting entities – there are some notable differences. Agents are persistent entities that pursue their objectives in a proactive manner; they are able of intelligent reasoning; they are socially and environmentally aware, and can adapt their behavior to changing conditions. Agents break the problem down into sub-tasks and dynamically delegate the execution of subtasks to other agents. The services, in contrast,
978-1-4799-3840-7/14/$31.00 ©2014 IEEE
are transient and stateless processes that are invoked by external calls and exist just during the execution. Complex business processes are implemented as a composition of atomic services, where the logic of message-based interactions is specified from a global perspective using a suitable orchestration language, like BPEL [4]. The orchestration is usually performed by a single entity – the orchestrator – that calls the atomic services following the statically prescribed workflow. The employment of agents in factory automation has much longer history than in case of services, lasting for more than two decades [1]. Industrial agents are typically designed as representatives of either physical or virtual objects of production systems, such as machines, robots, conveyor belts, orders, products, etc. Agents advertise their capabilities to perform different manufacturing operations in a registry called directory facilitator and use communication protocols like contract net [5] to coordinate their execution. Agents use ontologies for semantic representation, sharing and reasoning about the information related to shop floor operations, which further enhances the flexibility and reconfigurability of the control system [6]. The environmental awareness of the agents is ensured by an interface for direct access to the sensory data held in programmable controllers [7]. The application of SOA architectures, mainly the Web services, in production systems control appears to have several common features with multi-agent systems. The sensing and actuating skills provided by the manufacturing equipment are abstracted and exposed as Web services [8], [9], [10]. Such services can be discovered in a registry and invoked by other services or clients by sending specific types of messages. The services can be also semantically described using Semantic Markup for Web Service known as OWL-S [11]. This simplifies the discovery, invocation and composition of associated processes [8], [9]. There is a growing trend towards merging the core features of agents and services. For instance, authors in [8] introduce Web services with internal states representing states of the manufacturing equipment. Others argue for outsourcing the computationally intensive processes such as intelligent reasoning from Web services to industrial agents [9]. It becomes apparent there is a great potential in seeking for a synergy of agents and services, or more precisely, in leveraging
3663
the capabilities of agents concerning reasoning, inference, and learning in service-oriented manufacturing systems. SOA provides basic service discovery and messaging while agents linked with the services can take care of intelligent decision making. First trials of achieving such synergy were already presented, for instance in [12] reporting on the design of service-oriented agents for collaborative production control systems. Such approach has been taken also by the European ARUM research project (http://arum-project.net/) aiming at the adaptive production planning and scheduling for small lot manufacturers of highly complex products such as aircrafts. One of the key software modules developed in ARUM is the Scheduler, which task is to compute detailed schedules for given production line producing very complex assemblies – fuselages of aircrafts. Because of the problem complexity (several production stations, several working shifts per day, some hundreds of workers and thousands of process steps done at each station) it was decided to model the problem by means of multi-agent systems (see more details in Sect. IV). The integration of all developed software pieces as well as legacy systems is achieved by employment of the Enterprise Service Bus (ESB) software architecture model. The ESB environment, based on SOA principles, supports the loosecoupling of services by providing a service directory and a message-oriented middleware in combination with message queues for asynchronous message passing. The Scheduler, designed as the ESB service, is internally implemented as a multi-agent system that takes care of computationally intensive scheduling tasks. The multi-agent system, wrapped by a service, apparently needs to interact with other services, such as the one that is responsible for gathering data from legacy systems or with another one providing the interactivity with users. This was a motivation for development of a framework that allows one to wrap the multi-agent system in the ESB service and to send messages between agents and services. This functionality is ensured by a gateway that transforms the agent messages to ESB messages and vice versa. The framework also extends the ESB messaging itself so that the services can carry out more complex interactions over messages like agents do using the negotiation protocols specified in the agent communication language. II.
RELATED WORK
A. Integration of agents and services in factory automation Convergence of the agent-based technologies and service oriented architectures into a unified concept is a clearly visible trend in factory automation domain. Puttonen et al. [8] propose an approach in which originally stateless services are enhanced with states to express the internal states of corresponding production equipment. The states are described by a semantic model that represents objects in the factory floor, their features and relationships. This model is updated to reflect the current state of the real world. Web service interfaces are also described semantically using OWLS ontology to simplify the service orchestration process. The
3664
Orchestration Engine service takes the BPEL description of process instructions and invokes suitable services to execute the atomic operations. This approach considerably resembles a common agent-based industrial system where agents use semantics to describe their internal states reflecting the actual status of production equipment governed by the agents. Semantic model of production process workflow then drives the behavior of product agents that request suitable resource agents to provide the basic manufacturing operations [6]. It is acknowledged by Puttonen et al. themselves in [8] that systems composed of web services appear to have several common features with multi-agent systems, such as modularity, cooperation and orchestration. Lastra et al. [9] propose a methodology for developing selfconfigurable and autonomous production systems using knowledge-based Service-Oriented Architecture. The services that encapsulate manufacturing skills of equipment are semantically described by OWL-S ontology (type of service, parameters, constraints, pre- and post-conditions, etc.). The ontology also represents product definitions, process representations, and environment conditions. The computationally intensive processes such as complex reasoning can be provided by industrial agents hosted at the Manufacturing Execution System level or can be outsourced by lightweight agents to dedicated reasoners. Lastra et al. also present a generic framework for utilization of Sematic Web services in a distributed scheduling and process execution system based on the multi-agent technology. Up to date one of the most elaborate approaches for integrating agents with services in production control systems is presented in [12]. Mendes at al. propose the concept of Service-oriented Multi-Agent System (SoMAS) that contains so-called service-oriented agents. These agents are software entities acting on behalf of a user or a device that are capable of intelligent reasoning in the pursuit of their own goals. They offer their operations as services in the SOA sense and request other service-oriented agents’ services to perform specific operations. Mendes at al. avoid forcing the use of any particular technology in the SoMAS model. For agents the existing agent platforms such as JADE [13] or JACK [14] can be used. Each agent can be even implemented in a different platform. For the SOA part the Web services framework such as Service-Oriented Architecture for Devices (https://forge.soa4d.org/) can be employed. Shen at al. [15] propose an agent-based service-oriented system architecture, in which software agents are implemented as Web services with different functionalities and roles. The idea is to exploit agents’ capabilities of proactive interactions to enhance Web services’ behaviors. A software prototype for inter-enterprise manufacturing resource sharing was developed to demonstrate how the proposed agent-based service-oriented integration architecture can be used to establish a collaborative environment, which provides dynamic resource scheduling services. B. Gateways for agents-to-services interactions While the previous section described rather conceptual frameworks for integration of multi-agent systems and Web
services, this section reviews some practical software implementations of frameworks that enable one to use both technologies separately and bridge them via kind of a gateway, which translates the messages sent between them. In all the presented solutions the target agent platform is JADE [13], which is one of the most popular open-source toolkits. Nguyen and Kowalczyk [16] implemented WS2JADE framework in which agents and Web services, with separation of concerns in their implementations, can communicate with each other. WS2JADE enables the JADE agents to access Web services through special Web service proxy agents called WSAG. When a client JADE agent issues a request to the directory facilitator (DF) to search for an agent offering a particular service and no such agent is found, the DF forwards this request to WS2JADE to search for suitable service in the Web services environment. If some Web services are found, their corresponding interaction models are generated together with a WSAG capable of accessing the Web service. Any communication between the client agent and the Web service is then routed through WSAG, which takes care of appropriate messages translation. A WS2JADE extension also presented in [16] provides facilities for managing the Web services by agents. The ontology model was developed to translate the agent control actions to management actions available for Web services. Shafiq et al. [17] present AgentWeb Gateway providing a middleware for dynamic integration of multi-agent system and Web Services. The middleware, similarly to WS2JADE, makes the Web services accessible from JADE agents. When the agent performs a search in DF and the requested agent is not found, DF redirects the search to the middleware that transforms it to UDDI search. If the service is discovered, its WSDL description [18] is translated to DF agent description and the Web service is published in the DF. Greenwood at al. [19] present the specifications of the infrastructure required to facilitate interaction between agents compliant with FIPA specifications [20] and W3C compliant Web services. The idea is the same as in case of WS2JADE – use the agents as orchestrators of Web service composition. The result of this effort is the JADE Web Services Integration Gateway (WSIG) that extends the JADE platform with the support for registration and discovery of Web services by JADE agents, and vice versa the registration and discovery of JADE agents services by Web service clients. The gateway performs translations of WSDL service descriptions into DF agent descriptions and FIPA-ACL messages into SOAP messages. Hemayati at al. [21] define yet another framework for integrating Web services and FIPA-compliant multi-agent systems. In the same way as in previous solutions there is a kind of broker that provides the interaction between agents and Web services. It provides linking between the DF agent service registry and the UDDI registry and the ACL2SOAP and SOAP2ACL converter for message conversion. Unlike previous works that focused on integration of agents with Web services, Zhou at al. [22] propose an interface between agents and ESB services. The Web Service-Agent Adapter provides conversion between FIPA Agent
3665
Communication Language (ACL) messages [23] and WSDL/SOAP. The target agent platform is again JADE; however no details are given on the ESB itself so it cannot be verified if the authors really employed some Enterprise Service Bus or if they refer to general Web services technology. Kimlaychuk [24] present a gateway for integrating JADE agents and Oracle ESB platform. The gateway translates FIPA ACL messages to SOAP messages and the DF agent descriptions to WSDL. III.
PROPOSED SOLUTION
This section presents a framework developed in the ARUM project that enhances the ESB service communication and enables one to integrate the multi-agent system with the ESB. The technologies selected for ARUM are the JADE agent platform [13] and the JBoss Enterprise Service Bus (JBossESB) [25]. A. Enhanced JBossESB messaging and service description JBossESB provides surprisingly simple tools for messaging and description of service interfaces. Natively, the communication is based on so-called ESB-aware messages with a very simple structure containing a header and a payload. The header contains routing information that tells the ESB message transport layer what is the name of the sending and receiving service (from and to fields, respectively) and optionally names of the services where to send the reply (ReplyTo) or a fault report (FaultTo). The payload represents the content of the message where the sending service can put arbitrary data. The content is designed as a simple map of key-value pairs, where the key is a String identifier and the value contains arbitrary serialized object or a simple string. It is fully up to the ESB service designer what to fill in the payload. There is also no support for any conversations following specific protocols like it is common in multi-agent system. If the services communicate asynchronously in the common request-response manner there is no implicit support in JBossESB for building the response to a request. The designer has to handle this manually by inserting some extra information in the response message’s content so that the requesting service can link the response with the original request. This is especially crucial if there are more conversations carried out between two services in parallel. To overcome such issue we have decided to enhance the JBossESB message with some additional attributes, which are inserted into the key-value map. Considering the required integration with multi-agent systems the decision was made to apply the FIPA Agent Communication Language specifications [23] to the ESB messaging. FIPA-ACL defines different types of messages, called performatives, such as request, agree, refuse, or not-understood with self-explaining meaning. The messages are then grouped into different interaction protocols that exactly specify the workflow of messages of given performatives. There is for instance a simple fipaquery protocol, by which the initiator requests a participant to provide it with specific information, or more complex fipa-
contract-net protocol for interactions following the contract net protocol [5]. It is important to mention that each conversation following a given protocol is uniquely identified by the conversation-id attribute, which is encoded in the message’s header. It helps distinguishing messages from different conversations being run concurrently among the agents.
The FIPA message structure contains among others the following important attributes: • sender, receiver – name of the sending and receiving agent, respectively; • protocol – name of the interaction protocol; • performative – name of the message performative; • conversation-ID – unique identifier of the conversation; • content – content of the message; • language – language describing the syntax of the message content; and • ontology – ontology used to express semantics of the message content. The FIPA extension of the JBossESB message has been proposed in a way that all the above shown attributes, except the first two that are already contained in the ESB message header, are inserted into the payload’s key-value map. To simplify this process we have developed an API containing the ARUMMessage class that provides getter and setter methods for particular ACL-related attributes. Additionally there is a message factory through which the messages can be easily generated. Fig. 1 shows an example of synchronous sending of the fipa-request message to a service “arumserviceid-1” and receiving the response.
B. JADE-JBossESB Gateway The presented gateway, similarly to gateways discussed in Sect. II.B provides facilities for integrating agents and ESB services. It enables one to create “intelligent” services, which internal behavior is ensured by the multi-agent system capable of complex reasoning. The overall architecture is depicted in Fig. 2. The JADEJBossESB gateway is linked with (wrapped by) the Agentaware ESB service that communicates with other services normally over the ESB. The gateway contains a JADE main container that hosts a single Gateway agent. Other agents performing the business logic of the intelligent service are running on the external JADE container, which is registered to the main container. The external container can be run on an external JVM and even on a different computer separately from the JBossESB. Multiple external containers running on different hosts may be employed to distribute the load and thus to scale the system’s performance up. It should be noted that multiple Agent-aware ESB services might be deployed on the ESB, each of which then contains its own JADE-JBossESB gateway and it own JADE multi-agent system. ESB messages Jboss ESB
External JVM
Agent-aware ESB service
JADE-JBossESB gateway ESB service
E S B
JADE main container
External JADE container (running on different JMV) Agent
Gateway agent
Agent
Agent
agent messages
Fig. 2. Jade-JBossESB gateway architecture
Fig. 1. Example of the use of FIPA-enhanced JBossESB messaging
Apart from formalization of ESB messaging it turned out there is a need for formalizing the description of ESB service interfaces as well. JBossESB does not provide any support for description of operations offered by services. The service just registers its category (type) and name in the registry. Thus, we have decided to use WSDL, designed primarily for description of Web services [18], also for ESB services. Any ARUM service deployed on the JBossESB has to provide its WSDL on a request from other service in order to determine what operations it supports. Additionally, for each operation it specifies the FIPA interaction protocol to be used in communication regarding the operation. The content of the message is structured according to the WSDL description using the SOAP message format.
3666
The Gateway agent is actually routing incoming ESB messages to agents as well as outgoing messages sent by agents to ESB services. During the routing it also performs conversion from ACLMessage to ARUMMessage format, making the use of the proposed FIPA extensions. Fig. 3 displays a typical communication scenario in which an agent sends an asynchronous message to the ESB service and receives a response. First, the agent requests the Gateway agent to get a conversation ID for the ESB communication. It is done by the query-ref message with the following content: . The Gateway agent generates a unique conversation ID and returns it back to the agent. At the same time it inserts a new record into the routing table, which contains the agent name, service name, and the new conversation ID. Second, the agent prepares an ACL message he wants to send to the service. The interaction protocol of this message and the content is set according to the service’s WSDL, and the conversation ID to the one received from Gateway agent. Let us note that the
receiver name in this message cannot be set directly to the name of the service – it must be again the name of the Gateway agent to be properly delivered by the JADE platform. When the Gateway agent receives such message, it checks if the conversation ID is recorded in the routing table. If so, it transforms the ACL message to ARUMMessage, replacing the name of the receiver with the name of the service. Third, the Gateway agent asks the Agent-aware ESB service to send the ARUMMessage to the desired service over the ESB. When the response is received and forwarded to the Gateway agent, the conversation ID is used to retrieve name of the agent to route the message to. Before routing the message is again translated, now back to the ACL format. Gateway agent
Agent
Agent-aware ESB service
ESB service
get convID (serviceName) convID
Generate convID and update routing table
send (ACLmessage) retrieve serviceName, transform message send (ARUMmessage)
ARUMMessage (over ESB) process msg., send resp. ARUMMessage
receive(ARUMmessage)
receive(ACLmessage)
done in each station is decomposed into several hundred work orders, each of which contains several atomic operations. The operations are done mainly manually, requiring specifically skilled workers and various parts to be assembled. The work orders as well as operations have to be done in a given sequence (there is of course a parallel run of multiple work orders possible). The goal for the scheduling is to determine the feasible sequence of operations that satisfies given constraints (operations dependencies and available workers and parts) and optimizes given criteria such as the cycle time length. The result of scheduling is the determination of start and end times of jobs and assignment of particular resources to jobs. Because of the complexity of the scheduling problem it was decided to solve it using multi-agent systems. The problem is decomposed into a set of agents N agents, each being responsible for computing a schedule for one of the N stations in given cycle time. A requirement was to provide schedules not only for the current cycle time but also for more (let say M) cycle times in the future. Thus there is M o such agent sets involved. The agents are thus organized into an MxN matrix, where each cell corresponds to one particular station and one particular cycle time (see Fig. 4).
retrieve agentName, transform message
Cycle times C1
...
CM
S1
In the third supported scenario an agent hosted in one service can send a message to another agent hosted in the second service. In this case both services are implemented as Agent-aware ESB service and the message is transformed twice during its delivery (ACLESB, ESBACL). USE-CASE
One of the primary goals of ARUM project is to significantly improve the day-to-day operations scheduling of highly complex and customized products produced in small lot sizes. Especially challenging is the ramp-up phase (the phase between building a first prototype and reaching a full capacity of the production line), which is almost continually impacted by disruptive events such as late change requests, missing resources, and non-conformities. The aim is to develop new scheduling tools that are capable to flexibly respond to disturbances by continual adaptation of schedules to achieve the best possible utilization of resources. The target production line is organized as a sequence of several work stations, in each of which there is a single instance of the product (fuselage of Airbus A350 aircraft) at given time. The production in each station takes several days (the time span is called cycle time), after which all the products are moved synchronously to the next station. The work to be
3667
S2 ...
In the second scenario, a service can send a message to an agent hosted within another service. For this case the ARUMMessage has one more attribute (agentName) to store the name of the receiving agent, which is used by the Gateway agent in the receiving service to route the message.
Station sequence
Fig. 3. Flow of messages in agent-to-service communication
IV.
C2
Sn
Fig. 4. Organization of agents taking care of scheduling operations of specific work station in specific cycle times.
A scheduling problem solved by each agent is represented as a constraint satisfaction problem where a set of variables (for example start and end times of jobs) must satisfy a number of constraints stated usually as a set of inequalities and equalities (such as operation’s start time must be less than the end time). Each agent uses a constraint solver that searches for such values of variables so that the constraints are satisfied and a given objective function (the length of the cycle time) is optimized. As Fig. 4 shows the agents communicate with each other when handling a “traveling work” problem. It often happens that a particular operation cannot be executed in given station, typically because of a missing or non-conformant part. In certain cases it is allowed that the operation execution can be shifted to a next station in the following work cycle. However, it has to be checked if the next station’s schedule will be able to incorporate an extra operation. This is done by negotiation between the corresponding agents – for instance the agent at position (S1,C1) in matrix shown in Fig. 4 asks the agent at position (S2,C2) if he can put an extra task into its schedule. This agent can contact other agent, like (S1,C2) to check if he can “borrow” workers from the original station. If the
operation cannot be placed in the schedule, it can be propagated further on to following stations.
[5]
There is a dedicated Controller agent in the scheduler whose task is to obtain input data needed for scheduling and coordinate the work of scheduling agents. The data includes set of work orders, jobs, their precedencies, available resources, and other parameters for each cell in the matrix. The data is provided by another service – the Ontology service – that is responsible for retrieving data from legacy systems (like SAP) and convert them to a semantic form using OWL ontology. Hence, the Controller agent sends multiple (MxN) query-ref messages to the Ontology service using the JADE-JBossESB gateway to obtain the data. When the data is returned back, the Controller agent distributes them to particular scheduling agents and triggers the scheduling process. A unique conversation ID in each request is used to distinguish the corresponding cell in the matrix. When the scheduling process is finished, the Controller agent aggregates the results and sends them to User interface service, where it is presented to the user.
[6]
V.
[7]
[8]
[9]
[10]
[11]
CONLUSIONS AND FUTURE WORK
The paper presents a framework for integration of the JADE agent platform and the JBoss Enterprise Service Bus. It provides a Gateway that translates JADE agent messages from FIPA-ACL format to ESB-aware messages delivered by JBossESB. To enable 100% mapping the ESB messaging was extended with the FIPA-ACL attributes. The gateway is used in several ESB services that implement specific business logic by help of multi-agent system. It is mainly the Scheduler service, which is responsible for day-to-day operative scheduling and the Planning service aiming at the long-term capacity planning. Future work will be focused on closer integration of these two services to allow for propagation of long-term plans into the short-term operations scheduling. Additionally, the integration of JADE’s DF and JBossESB registry is planned. ACKNOWLEDGMENT
[12]
[13] [14]
[15]
[16]
[17]
[18]
This research was supported by the European Union FP7 Programme under the ARUM project No.314056, and by the Grant Agency of the Czech Technical University in Prague, grant No. SGS12/188/OHK3/3T/13.
[19]
[20]
REFERENCES [1]
[2]
[3]
[4]
[21]
P. Leitão, V. Maík, and P. Vrba, “Past, present, and Future of industrial agent applications,” IEEE Transactions on Industrial Informatics, vol. 9, No. 4, pp. 2360-2372, 2013. M. Pchouek, and V. Maík, “Industrial deployment of multi-agent technologies: review and selected case studies,” Auton. Agent Multi Agent Syst., vol. 17, no. 3, pp. 397-431, 2008. F. Jammes, and H. Smit, “Service-oriented paradigms in industrial automation,” IEEE Transactions on Industrial Informatics, vol. 1, no. 1, pp. 62-70, 2005. Oasis. (2007). Web Services Business Process Execution Language Version 2.0 [Online]. Available: http://docs.oasisopen.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html
[22]
[23]
[24]
[25]
3668
R. G. Smith, “The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver,” IEEE Transactions On Computers, vol. C-29, no. 12, pp. 1104-1113, 1980. P. Vrba, M. Radakovi, M. Obitko, and V. Maík, “Semantic Technologies: Latest Advances in Agent-based Manufacturing Control Systems,” International Journal of Production Research, vol. 49, issue 5, pp. 1483-1496, 2011. P. Vrba, P. Tichý, V. Maík, K. H. Hall, R. J. Staron, F. P. Maturana, and P. Kadera, “Rockwell Automation's Holonic and Multi-agent Control Systems Compendium, “ IEEE Transactions on System, Man, and Cybernetics, Part C: Applications and Reviews, vol. 41, no. 1, pp. 14-30, 2011. J. Puttonen, A. Lobov, and M. A. Cavia Soto, J. L. Martinez Lastra, “A Semantic Web Services-based Approach for Production Systems Control,” Advanced Engineering Informatics, vol. 24, pp. 285-299, 2010. J. L. M. Lastra, and I. M. Delamer, “Semantic Web Services in Factory Automation: Fundamental Insights and Research Roadmap,” IEEE Transactions on Industrial Informatics, vol. 2, no. 1, pp. 1-11, 2006. A. Cannata, S., S. Karnouskos, and M. Taisch, “Evaluating The Potential Of A Service Oriented Infrastructure For The Factory Of The Future,” in 8th IEEE International Conference on Industrial Informatics, pp. 592-597, 2010. W3C. (2006). OWL-S: Semantic Markup for Web Services. [Online]. Available: http://www.w3.org/Submission/2004/SUBM-OWL-S20041122/ J. M. Mendes, P. Leitão, F. Restivo, and A. W. Colombo, “Serviceoriented agents for collaborative industrial utomation and production systems,” in V. Maík, V. Strasser, T., and Zoitl, A. (eds.), HoloMAS 2009, LNAI 5696, Springer-Verlag, Berlin Heidelberg, pp. 13-24, 2009. F. Bellifemine, G. Caire, and D. Greenwood, Developing Multi-Agent Systems with JADE. New York: Wiley, 2007. M. Winikoff, “Jack™ Intelligent Agents: An Industrial Strength Platform,” Multiagent Systems, Artificial Societies, and Simulated Organizations, vol. 15, pp. 175-193, 2005. W. Shen, H. Ghenniwa, and Y. Li, “Agent-based service-oriented computing and applications,” in 1st International Symposium on Pervasive Computing and Applications, pp. 8-9, 2006. X. T. Nguyen, and R. Kowalczyk, “Enabling agent-based management of Web services with WS2JADE,” in Fifth International Conference on Quality Software, pp. 407-412, 2005. M. O. Shafiq, A. Ali, H. Farooq Ahmad, and H. Suguri, “AgentWeb Gateway - a middleware for dynamic integration of multi agent system and Web services framework,” in 14th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprise, pp. 267-268, 2005. Oasis. (2004). Web Services Description Language [Online]. Available: http://xml.coverpages.org/wsdl.html D. Greenwood, M. Lyell, A. Mallya, and H. Suguri, “The IEEE FIPA approach to integrating software agents and web services,” in 6th international joint conference on autonomous agents and multi-agent systems, pp. 276:1-276:7, 2007. The Foundation for Intelligent Physical Agents (2014). [Online]. Available: http://www.fipa.org. M. S. Hemayati, M. Mohsenzadeh, M. A. Seyyedi, and A. Yousefipour, “A framework for integrating web services and multi-agent systems,” in 2nd International Conference on Software Technology and Engineering (ICSTE), vol. 2, pp. 314-319, 2010. H. J. Zhou, J. Z. Cao, C. X. Guo, and J. Qin, “The architecture of intelligent distribution network based on MAS-SOA,” in IEEE Power and Energy Society General Meeting, pp. 1-6, 2010. Foundation for Intelligent Physical Agents. (2002). Agent Communication Language Specifications. [Online]. Available: http://www.fipa.org/repository/aclspecs.html V. S. Kimlaychuk, “Integrating Oracle enterprise service bus with JADE agents,” IEEE International Conference on Computational Cybernetics, pp. 59-61, 2008. redhat. (2014). JBossESB. [Online]. Available: http://jbossesb.jboss.org
