Programming of Multiagent Applications with JIAC
Marco Lützenberger; Thomas Konnerth; Tobias Küster Technische Universität Berlin, DAI-Labor, Berlin, Germany
Abstract
Given the complexity of software development, it is only natural that industrial players are doubtful about new development paradigms and technologies and would rather stick to well-established mechanisms. This phenomenon may explain why there are very few serious applications of agent technology in industrial software development processes. Furthermore, most available agent frameworks were developed to answer research questions and were not designed for industrial appliances. Thus, it is difficult for industrial stakeholders to see the benefit of using agent technology. In this chapter, we show how essential agent-concepts can be implemented in compliance with industrial requirements. For this purpose, we present the latest version of the Java-based Intelligent Agent Componentware.
Acknowledgments
JIAC, and JIAC V in particular, is the work of the Competence Centre Agent Core Technologies of the DAI-Labor, namely Michael Burkhardt, Tuguldur Erdene-Ochir, Dr. Axel Heßler, Christopher-Eyk Hrabia, Dr. Jan Keiser, Dr. Thomas Konnerth, Tobias Küster, Marco Lützenberger, Nils Masuch, Denis Pozo, Jakob Tonn, as well as Dr. Yuan Xu. The DAI-Labor is chaired by Prof. Dr. Dr. h.c. Sahin Albayrak.
21.1 Introduction/Motivation
The development of high-quality software is considered to be extremely difficult. In fact, it has been argued that such endeavors are one of the most difficult construction tasks that humans undertake (Jennings and Wooldridge, 2000). Given the complexity of software development, it is only natural that industrial players are doubtful about new development paradigms and technologies and would rather stick to well-established mechanisms. This phenomenon may explain why there is still no serious application of agent technology in industrial software development processes. Of course, it is also possible that the agent paradigm cannot be applied to reality, though, given that when looking at contemporary software it becomes obvious that the central concept of a software agent is ubiquitous. As an example, consider software that has been developed for the large amount of mobile devices—commonly known as apps. Apps are usually executed as background processes in order to respond quickly to user inputs. Running in the background, an app constantly retrieves and sends information and maintains itself. Most apps therefore comply with the fundamental characteristic of software agents, namely autonomy (Wooldridge, 1997). Depending on the app, there are also other features that qualify for agency—e.g., reactivity, proactiveness, and even social competence. However, the bottom line is that although there is clearly an area of application for agent-oriented software, development is mostly done through traditional approaches—e.g., object-oriented software engineering (Jacobson et al., 2003), process-oriented software development (Fernandes and Duarte, 2003), and service-oriented software engineering (Karhunen et al., 2005).
One reason for the lack of success of agent technology is the academic nature of most available agent frameworks. Academic frameworks were developed to answer research questions, not to solve industrial appliance problems, thus it is difficult for industrial stakeholders to see the benefit of using agent technology. In fact, there were some promising approaches to furthering industrial adoption by developing frameworks with a particular emphasis on industrial and professional requirements. The most popular frameworks, without a doubt, were JACK Intelligent Agents® (hereafter referred to as JACK; Winikoff, 2009) and the Java Agent Development Framework (JADE; Bellifemine et al., 2003, 2007). Up until today, both frameworks were applied to a wide range of projects.
Now, given the fact that there are already agent frameworks with a strong focus on professional requirements, one might ask if there is a need for further platforms. Indeed there is! Over the last several years, software development has drastically changed. The wide variety of available service providers has narrowed the market’s tolerance for developmental delays or problems. As a consequence, current software development processes are significantly coined by the implementation of established standards or the reuse of components whose functionality has been established. In fact, JACK and JADE use standardized mechanisms as well. JADE, for instance, uses the Hypertext Transfer Protocol (HTTP) as a communication channel. JACK implements a mechanism that complies with the User Datagram Protocol (UDP), yet other mechanisms—e.g., logging or monitoring—are in-house solutions and do not comply with established standards.
The philosophy of the Java-based Intelligent Agent Componentware (JIAC; Lützenberger et al., 2013), is a different one. The fifth incarnation of JIAC, namely JIAC V (for matters of simplicity hereafter referred to as JIAC), was geared toward the requirements of professional and industrial-quality software development. Industrial requirements were comprehensively discussed by Mařík and McFarlane (2005), McKean et al. (2008), Pěchouček and Mařík (2008), Burmeister (2009), and Weyns et al. (2008, 2009). The analysis of these works shows that there are certain factors that facilitate the industrial adoption of new technologies. These factors include:
• An awareness of the general need (McKean et al., 2008).
• Support of well-established and commonly accepted standards (Mařík and McFarlane, 2005; Weyns et al., 2008, 2009; Pěchouček and Mařík, 2008).
• The costs that are necessary to implement new technologies (McKean et al., 2008; Burmeister, 2009; Mařík and McFarlane, 2005; Pěchouček and Mařík, 2008; Weyns et al., 2008).
• The scalability and performance characteristics of these new technologies (Mařík and McFarlane, 2005; Weyns et al., 2008)
• Guarantees on operational performance (Mařík and McFarlane, 2005; Pěchouček and Mařík, 2008).
• Mature development methodologies and tool support (Mařík and McFarlane, 2005; McKean et al., 2008).
• Comprehensive documentation (Mařík and McFarlane, 2005; Pěchouček and Mařík, 2008; Weyns et al., 2009).
Admittedly, it is difficult to focus on all these aspects because this was never intended. Rather, JIAC aims to further the industrial adoption of agent technology by supporting selected factors, namely the consequent application and implementation of standards, development support by a sophisticated set of easy-to-use and state-of-the-art tools, and a comprehensive documentation.
The philosophy of JIAC is to facilitate industrial adoption by implementing all relevant and critical features by means of standard, or quasi-standard, libraries. In doing so, JIAC aims to overcome the industry’s natural skepticism by using familiar and established implementation concepts and by increasing the capabilities of these concepts with the freedom and flexibility of the multiagent system (MAS) paradigm.
This chapter aims to present JIAC in more detail. In doing so, fundamental concepts of JIAC—e.g., distribution, communication, cooperation, monitoring, and service invocation, to name but a few—are introduced (see Section 21.2). Subsequently, it is shown how these concepts can be implemented by means of state-of-the-art libraries (see Section 21.3) and tools (see Section 21.4) and thus meet the requirements of industrial stakeholders. Practical applications of JIAC are presented in Section 21.5 and discussed in Section 21.6. The chapter concludes with a summary and conclusions in Section 21.7.
21.2 Application Overview
The central concept of the JIAC architecture revolves around agents serving as intelligent service execution containers. Thus, a MAS can work as a flexible and dynamic service execution platform that corresponds to the principles of service-oriented architectures. In order to achieve this, JIAC features dedicated concepts that cover the whole range, from single service components to a whole application. These concepts are depicted in Figure 21.1 and are as follows:
• The AgentBean is the atomic building block of JIAC agents and applications. All other concepts and elements are built from this. An AgentBean is basically a Java class that can be plugged into an agent.
• An agent in JIAC is an autonomous entity dedicated to a role. The capabilities of the agent are implemented with AgentBeans and can be made accessible to other agents as services.
• An AgentNode is a runtime container that holds and manages all agents that reside on a single computer. The AgentNode mainly provides management and infrastructure functions and is responsible for managing access to physical resources.
• A JIAC application is the sum of all AgentNodes that can communicate with each other. Thus, it is a physically distributed environment that encompasses all agents that are able to interact with each other.
Thus, the AgentNode and the JIAC application are constructs that are only required for configuration and deployment of applications. Actual implementation is done by implementing agents and AgentBeans that provide functionality. In order to facilitate this, each agent consists of a number of standard components that guide its control flow and operation. These components, which are AgentBeans themselves, provide the basic structure of an agent.
The execution cycle controls all actions and behaviors of the agent. It holds the thread of control of the agent and determines which actions the agent takes next. Furthermore, it is implemented to be as fault-tolerant as possible. If any function or behavior of another AgentBean produces a failure, the execution cycle makes sure this failure does not propagate through the agent and does not bring the whole agent to a halt. Thus, the worst thing that can happen is that an AgentBean is stopped and deactivated due to a failure. Even then, the rest of the agent will continue to work.
The memory of an agent is an implementation of a tuple space that allows the AgentBean to store and access knowledge about the world and the agent’s environments. This memory provides a central knowledge repository for each agent, which can be accessed and shared by all AgentBeans. As an added benefit, due to the features of the tuple space metaphor, it can also be used for synchronization and coordination within an agent.
The third mandatory component within an agent is the communication bean. This AgentBean handles the communication of an agent with other agents. Because JIAC communication relies heavily on the ActiveMQ message bus on the implementation level, the actual realization consists of a component within the AgentNode that contains the action message broker, which is a unique component on each machine. The communication bean in an agent, however, is responsible for accessing the message bus, and handling all messages that concern the agent. It can of course be exchanged with a different implementation that uses a different networking back-end.
The communication bean can promote all actions of an agent via the white pages and yellow pages services and handles service sessions with other agents. The service sessions themselves are mapped onto a simple request-response protocol, and the communication bean creates and processes the appropriate messages in order to map that protocol onto the message-based communication infrastructure.
All other functionalities of an agent are provided by AgentBeans and can be created and configured by a programmer. Therefore, JIAC provides interfaces and Java classes that allow the AgentBeans to easily declare new actions, promote these actions as services for other agents, and access and call services from other agents. The function of an AgentBean is to connect an agent to a certain environment. Thus, an AgentBean typically offers multiple actions and services that are required for the domain.
The set of AgentBeans that make up an agent and their configuration are represented by an AgentRole. An AgentRole contains all information that is required to instantiate an agent. Runtime-specific information (e.g., addresses and/or unique identifiers) is not included in an AgentRole. If an agent is to be deployed on an AgentNode, the AgentRole is instantiated on the AgentNode by an actual running agent. This happens via the Spring framework—a Java component framework that allows the flexible configuration and deployment of Java-based applications. As the name AgentRole suggests, multiple agents with the same role can be instantiated on an AgentNode, which are then functionally equivalent, but have all individual knowledge, threads of control, and addresses.
21.2.1 Functional Components and Standards
Because JIAC should support the development of distributed, dynamic, and loosely coupled systems, interoperability was one of the key requirements considered in the concept stage. Implementations designed with JIAC should build upon well-established technologies and should explicitly be able to communicate with external components. Therefore, the intention for the framework was to utilize and provide standards and quasi-standards in all areas of MAS development.
As certain basic functionalities are commonly needed in many applications, and therefore in the implementation of many agents, JIAC comes with a number of components that are already implemented, that do rely on well-established technologies, and that can be reused in any project.
The first of such components are the three components that make up the basic framework of an agent, namely the memory, the execution cycle, and the communication bean. While these can technically be replaced by alternative implementations, they are usually sufficient and so far have been adequate in all known appliances of JIAC.
Furthermore, the AgentNode usually does not just have the communication infrastructure, but also directory services such as white pages and yellow pages similar to agent management systems (AMSs) and directory facilitator (DF) services defined by the standards organization Foundation for Intelligent Physical Agents (FIPA) (Bellifemine et al., 1999). Note that these directories are automatically synchronized between all AgentNodes that can reach each other (thus forming the JIAC application).
Additionally, the service discovery can be enhanced with the help of the dedicated service matcher SeMa2 (Küster et al., 2012). To achieve this, JIAC services are additionally described by the semantic service ontology Web Ontology Language for Web Services (OWL-S) which itself relies on the standardized ontology language Web Ontology Language (OWL) and the Semantic Web Rule Language (SWRL).
In order to enable communication paradigms other than simple messages or service calls, JIAC agents can also be equipped with a protocol handler that is able to facilitate complex protocols based on the FIPA speech-act and protocol specifications (Foundation for Intelligent Physical Agents, 2004) between two or more agents.
Because authorization and authentication play a vital role in modern software applications, the JIAC service mechanism also offers a generic authorization model in which each AgentBean can be wrapped with an authorization interface that allows the generic implementation of the authentication and authorization model. This is typically used with an implementation of the authorization wrapper that accesses the domain LDAP (Lightweight Directory Access Protocol) server.
For the creation and provisioning of web-based user interfaces and web services, a JIAC AgentNode can also be equipped with an embedded web server that allows the agents to deploy arbitrary Java servlets. These servlets are standard Java servlets that can either provide web sites for users or web services based on the de facto standard Web Service Description Language (WSDL) and RESTful Application Programming Interfaces (APIs).
Finally, an AgentNode, as well as all agents residing on that AgentNode, can be remotely accessed and managed via a Java Management Extensions (JMX)-based management interface, which allows both full control of existing components and the deployment of new components at runtime.
21.2.2 Communication and Messaging
One of the most important capabilities of MASs is communication between autonomous agents. In JIAC, the communication occurs by sending serialized messages to other agents or groups of agents belonging to the same (virtual) platform, which can be distributed over several hosts connected via different network interfaces. Messages are not restricted to FIPA messages and can have any data as their payload. An example of group communication is the exchange of agent and service descriptions (also called white and yellow pages) between the DFs of each agent node within a platform to realize a distributed directory service.
Each agent node contains a message broker, which is responsible for the exchange of messages. A multicast-based discovery mechanism enables the automatic and decentralized connection of all brokers of the same platform. Additionally, a central gateway broker forwarding the messages to the other brokers can be specified for communication across organizational boundaries and firewalls. The technical realization of the communication is described in Section 21.3.2.
21.2.3 Monitoring
Runtime monitoring features are a requirement in implementing and maintaining long-running, highly available services. The ability to monitor states and behavior at runtime is very helpful during the development of an application, especially for debugging purposes. In JIAC, this is supported by an integrated monitoring and management interface based on the JMX API.
The JIAC monitoring interface exposes properties of JIAC entities (agents, agent nodes, etc.) via JMX. Furthermore, it provides a notification handler for events such as message sending or receiving, or action invocations, where clients can register to be notified when such an event occurs. The monitoring interface also exposes several management functionalities, which can be used for maintenance in running application installations, or to test the system’s behavior during debugging.
Through the use of JMX technology, monitoring is possible both locally and remotely. The adoption of a standard technology for monitoring allows the use of generic tools that connect to JMX interfaces, such as the jConsole tool provided with Java SE installations. A tool more specialized to the task of monitoring distributed MAS applications is available in the form of the ASGARD monitoring application, which is described in detail in Section 21.4.4. The JIAC API also provides basic client implementations to connect to its monitoring, which can be used to implement domain-specific monitoring and management tools for JIAC application projects.
21.2.4 (Commercial) Distribution
Finally, it is necessary to find a way to distribute implemented agents and make them available for other developers or users. Because the “app store” metaphor has become popular over the last few years, we decided to implement a similar concept, namely the Agent Store. The Agent Store is a web-based platform where users can browse, download, upload, and deploy available agents or AgentBeans. The Agent Store uses the JMX API to download and deploy agents on currently running agent nodes.
21.3 Application Details
The JIAC architecture and agent model, as described in Section 21.2, has been implemented on the basis of Java and the Spring framework. Java was chosen as a programming language because of its flexibility and platform independence.
Instead of implementing the whole architecture from scratch, several well-established technologies and standards were integrated—most of these technologies meet industrial requirements as well. The role of these technologies and standards is described next.
21.3.1 Component Framework: Spring
The Spring framework1 provides a solid state-of-the-art component framework, which is used for bootstrapping and as a runtime container for agents, agent nodes, and all associated components. Furthermore, Spring provides ready-to-use components, which can be added to an application. Examples of these components include web servers, database access, and transaction management, as well as aspect-oriented programming frameworks. Through this, Spring covers some important aspects of industry-ready agent applications. It provides a solid environment for configuring and deploying applications.
21.3.2 Communication: ActiveMQ and JMS
The implementation of JIAC communication (see Section 21.2.2) is based on Apache ActiveMQ,2 one of the most popular open-source messaging servers. It fully supports the Java Message Service 1.1 (JMS) (Sun Microsystems Inc., 2002) specification for a loosely coupled, reliable, and asynchronous communication between components of a distributed application.
Using ActiveMQ, agents can communicate transparently with other agents, both on the same node as well as on other nodes, or even on other computers in the network. Communication through firewalls and across network boundaries is also possible, provided that the transport uniform resource identifier (URI) and port are specified, or a dedicated broker service is set up. ActiveMQ also supports the buffering of messages for agents that are currently not available, as well as automatic reconnection after network problems.
The communication bean of each JIAC agent registers a message box address for point-to-point communication at the local broker service consisting of the unique identifier of the agent node and the agent during its initialization. If the agent is part of specified agent groups, it additionally registers group addresses for publish-subscribe communication. The directory service of each agent node also registers a group address for each directory group to exchange descriptions of the local agent node, agents, and services.
21.3.3 Logging: Log4J
For debugging and monitoring of distributed JIAC applications, we use the logging framework Log4J,3 which is also used by most commercial software products. Each JIAC component creates a logger with a unique category composed of the identifiers along the component hierarchy, greatly facilitating both debugging and post-mortem analysis. The log level of each component can be set individually, either in the respective Spring configuration file, or at runtime using JIAC runtime monitoring (see Section 21.3.4). Different log appenders allow users to write the messages not only on the console, or into a file or database, but also allow for monitoring tools to connect to the JIAC logging (see, e.g., ASGARD in Section 21.4.4).
21.3.4 Monitoring: Java Management Extensions
The JMX (Sun Microsystems Inc., 2006) technology standard is used to provide the management and monitoring interface, as described in Section 21.2.3. JMX controls which properties and functions of an object are accessible through the use of so-called MBean interfaces, which are provided for each of JIAC’s basic components, and can also be provided for any application-specific components.
JIAC advertises the JMXUrls used for connecting to the monitoring interface in several ways, namely by announcing them via multicast packets in the local network, publishing them via RMI (Remote Method Invocation) registries, and by having each agent node announce the JMXUrls of other nodes known to it.
JMX is also used to implement runtime deployment of JIAC agents—in other words, new agents can be deployed on a remote agent node by transferring an agent configuration and the packed bytecode of its implementation. The agent is created on the target node using a separate class loader, avoiding problems that result from duplicate classes in the class path.
21.3.5 Third-Party Interaction: Web Services
As described in Section 21.2.1, JIAC provides three different standards for the description and interaction of services.
To start with, JIAC actions can be transformed and deployed as a WSDL service description on an embedded web server and invoked via the Simple Object Access Protocol (SOAP). The transformation procedure is done using a web service Gateway component and runs automatically. External web services described in WSDL can be easily integrated with the help of a WebserviceAccessBean, which hides the web service overhead, proposing the functionality as a typical JIAC action.
Second, a RESTful gateway exposes JIAC actions as RESTful services (Fielding, 2000). JIAC defines a bijective mapping between domain-specific models and the JavaScript Object Notation (JSON; ECMA International, 2011). The JIAC actions are automatically transformed and deployed on an embedded web server.
Finally, JIAC actions can be enhanced with the World Wide Web Consortium (W3C) Standard Submission OWL-S, enabling a semantic description of JIAC actions for the automatic search, interpretation, composition, and invocation of them. OWL-S describes input and output parameters in the W3C standard ontology language OWL. Further, preconditions for the invocation of the service and effects can be defined using SWRL.
21.4 Tools
Being a JIAC, JIAC can be developed with any of your preferred Java development tools. However, a combination of Eclipse and Apache Maven is recommended, because the main distribution channel for the JIAC libraries is via a Maven repository. Also, there are a number of editors and tools specifically for the development of JIAC applications, most of which are Eclipse plug-ins.
First, there are a number of tools to be used at design time, helping the developer set up and implement new JIAC applications. Then, there are tools for the deployment and monitoring of existing JIAC applications, and for reusing them in new projects. In the following, these tools are presented in more detail.
21.4.1 JIAC and Eclipse
Because JIAC is a Java-based agent framework, all of the JIAC development work can be done using any Java development tools. However, a combination of Eclipse as an IDE and Apache Maven for dependency management and building is recommended. This way, setting up a new JIAC project can be done quickly and easily following a few steps described in the JIAC manual (JIAC Development Team, 2012).
Further, a specific Eclipse plug-in, the JIAC Project Plugin, provides a special kind of Eclipse Project Nature for JIAC projects and a respective wizard for creating those projects. This will automatically create a Project Object Model (POM), allowing Maven to download and install the JIAC libraries and all its dependencies and thus create an Eclipse project.
This plug-in is complemented by a number of additional Eclipse views, each providing a particular functionality to make developing JIAC agents and applications easier. Among those is a view showing the different components of the current JIAC project, such as AgentBeans, actions provided by those beans, and defined domain ontologies/fact classes. Further, another plug-in uses JMX to show all the JIAC nodes running in the same network, listing the respective agents and their actions and allowing reuse of those actions in the current project. Similarly, there is a view for searching the AgentStore (see the following) for certain functionalities and importing those into the current project, and for packaging the current project and deploying it to the store itself (Petzold, 2013).
21.4.2 The Agent World Editor
As described in the previous section, the several agents, roles, and their capabilities found in a JIAC MAS are described via Spring configuration files—i.e., in XML (eXtensible Markup Language). While this provides a flexible way of combining JIAC agent beans to agents, and agents to nodes, as well as for configuring individual beans (e.g., setting communication addresses), configurations for large MASs can be hard to overview, in particular if they are split up into several files.
The AWE (Agent World Editor) was developed to alleviate this problem by providing a graphical overview and editor for those Spring configuration files (Küster et al., 2012). After modeling the MAS using intuitive graphical symbols for agents, nodes, and beans, the AWE can then be used to generate both, the configuration files and stub for the individual agent beans (if they do not exist yet). In its current version, the AWE can also be used for managing agent configuration laid out across several files, and for importing and editing existing files. The AWE is illustrated in Figure 21.2.
21.4.3 The Visual Service Design Tool
The VSDT (Visual Service Design Tool) is an Eclipse-based editor for the Business Process Model and Notation (BPMN). It allows users to design and implement services and entire MASs in terms of process diagrams (Küster et al., 2012). Besides the basic BPMN editor, it also features some modeling assistance, structural validation, and a simple interpreter/simulator for stepping through the processes and interpreting the diagrams, which has proven very useful for debugging.
Processes modeled in the VSDT can be transformed and exported to a number of JIAC AgentBeans, creating one agent bean for each Pool in the business process diagrams. Those beans consist of one method for each individual Activity in the process, one method for the workflow of the process as a whole, orchestrating those methods, and mechanisms for triggering this workflow, according to the Start Events in the original process diagram. For example, the process can be triggered at a certain time, on receiving a particular JIAC message, or it can be exposed as a JIAC service.
While process diagrams created with the VSDT are easy to understand even when containing complex workflows, event handling, and communication, creating them can be more laborious for a skilled programmer than writing code in a text editor. Also, while the VSDT has basic support for data types and complex classes, it does not offer the coding assistance known from regular Java editors. Thus, the VSDT’s main area of application is the modeling of high-level processes and interactions between the several roles of a MAS, while low-level algorithms and, e.g., GUI interactions should either be handled in external services, or implemented in the activity method stubs after the code generation (Küster et al., 2012). Using the Java Emitter Templates (JET) code generation framework, the VSDT makes sure that modified methods will not be overwritten.
Currently, the VSDT’s debugging interpreter is being extended to a JIAC-based process interpreter agent bean, allowing VSDT diagrams to be sent to a JIAC agent for interpretation. This is intended not as a successor, but as a complement to the export to JIAC agent beans, being particularly useful for quickly creating and deploying service orchestrations, while the export will still be the better choice for creating the basic structures for more complex MASs. It is also planned to establish a link between the interpreter, running inside a JIAC agent, and the VSDT, such that the current state of the execution can be shown in the process diagram. The VSDT is illustrated in Figure 21.3.
21.4.4 ASGARD
ASGARD (Tonn and Kaiser, 2010) is a visual monitoring application with some management capabilities for the JIAC platform. It provides a three-dimensional graphical overview (see Figure 21.4) of currently running JIAC entities within a local network, and uses the visualization to indicate properties, states, and interaction of the JIAC entities. ASGARD’s main use is to support developers during implementation and testing of distributed JIAC applications, as well as to check the current state of deployed applications at runtime for maintenance purposes.
ASGARD uses JIAC’s integrated monitoring interface (see Section 21.2.3) to connect to local and remote entities via JMX (see Section 21.3.4). Automatic discovery of running JIAC entities is provided via multicast technology, RMI registries, and peer-to-peer forwarding of known entity addresses. A visual representation is then created for each discovered entity, with its properties either influencing the visual appearance or being shown in textual form, depending on the nature of the property. Interaction between JIAC agents is visualized through animations, such as messages in the form of letter envelopes being transferred between agent objects.
The application is better suited for the problem of monitoring a distributed MAS application compared to generic solutions such as log outputs or the JMX-based JConsole tool. Those tools provide a very detailed view of the events in one component, but do not allow users to easily spot how other entities might be affected. Because interaction between agents is one of the central concepts in MAS applications, having a tool dedicated to the visualization of these processes is an advantage for the development of applications with industrial requirements.
21.4.5 The Semantic Service Manager
In order to provide a high degree of flexibility in changing environments, agents must be able to dynamically interpret and invoke the functionality of other agents. The enhancement of services by semantic information allows for such an approach. The SSM (Semantic Service Manager) directly addresses this problem by offering an editor for the description of JIAC actions as OWL-S at design time. It consists of an OWL ontology manager which provides automated integration of new OWL ontologies and a transformation procedure from EMF (Eclipse Modeling Framework) Ecore models to OWL. In general, the manager supports the developer by automatically annotating JIAC actions with OWL-S descriptions, which can be refined manually afterward.
21.4.6 The Agent Store
After the agent systems have been developed and tested, they can be deployed to the JIAC Agent Store. Inspired by the popular “app store” metaphor, as known from, say, Apple and Google, this Agent Store can be used for deploying, sharing, and reusing MASs or individual agents that serve some specific task (Küster et al., 2012).
21.5 Benefits and Assessment
The problem with many available agent frameworks is that their scientific nature frequently does not match the requirements of professional, industry-grade applications. JIAC was developed to bridge that gap and bring industry and research together. In order to substantiate this thesis, JIAC was applied to several projects where both academic and industrial requirements were needed. This section provides an overview of the most important practical applications of JIAC.
21.5.1 Applications
The goal of the Service Centric Home (SerCHo) project was the development of an open service platform that increases life quality at home. The platform was intended to support the quick and easy delivery of new context-sensitive services into the home environment and the provisioning of a consistent user interface for these services. In this project, it was required to integrate agent technology with the service metaphor (Hirsch et al., 2006). This project set the foundation for, and greatly profited from, JIAC’s service metaphors.
The focus of the Multi-Access—Modular Services (MAMS) project and its successor, MAMS +, was to allow nontechnical persons to quickly and easily create, deploy, and manage services, according to the users’ needs. In this project, JIAC’s service delivery platform was developed, integrating modern technologies such as Information Management System (IMS)/Session Initiation Protocol (SIP) and allowing for service composition, and features service matching, load-balancing, and self-healing mechanisms, to name but a few (Thiele et al., 2009).
Within the project Gesteuertes Laden V2.0(2011), the goal was to develop a decentralized intelligent energy management system that uses electric vehicles’ (EVs) batteries as mobile energy storage units. The purpose of the developed planning algorithms was to stabilize the energy grid and maximize the amount of renewable energy within the EVs depending on forecasts regarding available wind energy. Here, JIAC was used as an agent-based middleware, transparently connecting the different machines contributing to the distributed system.
To maintain a good standard of living for senior citizens, new technologies have been developed within the SmartSenior project. The development included sensor-based situation detection, reaction, notification, and remote management (Raddatz et al., 2012). During a field study, the solutions were successfully installed and tested in the home environments of more than 30 elderly participants. In this project, JIAC was extended with capabilities for integration into Open System Gateway Initiative (OSGI)-based infrastructures (i.e., JIAC actions could now be used as OSGI services and vice versa).
The project Energy Efficiency Controlling in the Automotive Industry (EnEffCo) aimed at implementing a modular software system (Küster et al., 2013) to simulate operational modes of plant sections with relevant energy consumption. The software serves as a tool for decision makers in manufacturing, to whom it offers the identification and evaluation of strategies and tactics for establishing cost- and energy-efficient production schedules. In this project, JIAC agents were used for distributing and parallelizing the distributed process optimization and for negotiating optimization orders.
Intelligent Solutions for Protecting Interdependent Critical Infrastructures (ILIas) is a project aimed at developing intelligent solutions for protecting critical infrastructures that provide electricity and telecommunication services to the general public (Konnerth et al., 2012). These solutions need to be scalable and reconcile the need for fast and automated reactions with manual supervision for highly critical decisions, making use of JIAC’s decentralized communication infrastructure. Software solutions and protection mechanism efficiencies in large-scale networks are evaluated using simulated disaster scenarios. The simulation models are supplemented by a hardware test laboratory where exemplary interdependent energy and telecommunication infrastructures are set up.
The BeMobility 2.0 project investigated the integration of EVs into urban transport and energy networks. In addition to the development of concepts that combine different mobility services (e.g., vehicles, public transportation, etc.), an energy management system (Freund et al., 2012) for a Micro Smart Grid was developed, in which a variety of system components, such as EVs, charging infrastructures, and energy sources, are taken into account. Here, JIAC contributed the same distributed, agent-based optimization framework that was previously used in EnEffCo.
The aim of the Connected Living project is to provide a system for integrating and managing “smart devices” in future home environments: Connected Living Operating System (CL-OS). Besides providing a layer of abstraction for controlling devices by diverse vendors, another goal is to supply an infrastructure for developing, publishing, and deploying agents or coalitions of agents to users’ home environments to help future home users achieve its goals. For this project, each “assistant” is modeled as a JIAC agent and is deployed to the running system from the Agent Store by means of JMX, and its services are advertised by means of JIAC actions.
The objective of the project Extensible Architecture and Service Infrastructure for Cloud-aware Software, or EASI Clouds, is to provide a comprehensive and easy-to-use cloud computing infrastructure with support for cloud interoperability and federation. The infrastructure includes advanced SLA (service-level agreement) management for all service layers, facilities for capacity planning, heterogeneous provisioning, and accounting and billing. Here, JIAC nodes were used as a “platform as a service” (PaaS).
21.6 Discussion
In most of the projects presented here, JIAC applications had to be tested during field trials or user rollouts. Applications had to be highly reliable, running for months without problems. Practical applications showed that this requirement can be fulfilled by the consequent application of well-established programming libraries. The application of ActiveMQ and JMS, for instance, particularly facilitated a reliable communication mechanism, enabling highly distributed applications with software agents running on heterogeneous hardware and communicating throughout different computer networks. The application of the Spring framework eased the maintenance and increased the flexibility of JIAC applications because it was possible to shut down and restart selected beans, agents, and/or agent nodes without affecting the entire system. This mechanism helped to revise malfunctioning components at runtime. The application of JMX facilitated a comprehensive and complete monitoring of JIAC applications. Finally, the implementation of the service metaphor significantly eased the integration of third-party applications and cooperation with partners. These partners simply had to align their implementation to comply with the service metaphor and official standards, not with the particularities of the agent paradigm.
The application of standards and standard libraries is not the only contribution to the requirements of professional software development. Most applied programming libraries are extremely well documented and thus directly address another requirement for professional software development, namely a comprehensive documentation. Furthermore, available component documentation makes it easier to provide documentation for the agent framework because one can focus on agent aspects and use references to the documentation of third-party libraries. Given that these libraries feature a certain standard—and in the case of JIAC, they do—it is also granted that there is always up-to-date documentation available. The many successful JIAC appliances showed that such forms of documentation are helpful, especially for partners that are not familiar with the agent paradigm but want to use JIAC for their own purposes, or have to connect their applications to JIAC MASs. With most of the projects presented here, it was possible to develop joint applications with industry partners without any significant problems.
Furthermore, joint developments were actively supported by the comprehensive set of JIAC tools. The visual representation of agent systems helped non-experts become familiar with the nature of MASs. Embedded in an approved methodology and equipped with comprehensive description, the tools facilitated a quick configuration of the MAS architecture, allowing domain experts to focus on their particular implementation focus, or their particular implementation problem. This problem is not necessarily related to the agent-oriented perspective, yet in order to solve this problem the entire flexibility of the agent paradigm can be used.
Finally, it has to be mentioned that JIAC actively supports the integration process—especially in projects where many partners are involved. Development in JIAC usually starts by setting up the MAS architecture, including all agents and agent nodes. This initial system has no functionality, yet the AgentBean mechanism allows partners to extend the capability of agents gradually. The approach has the advantage that—from the beginning—communication between all relevant (and possibly highly distributed) entities is ensured. This mechanism promotes rapid testing and helps to identify problems early in the development process. Admittedly, during projects, particular messages that are exchanged between all relevant entities changes, yet using JIAC it is rather easy to modify this parameter. Project experience also showed that the initial MAS architecture almost never changes, and even if it does, the modular assembly of JIAC applications promotes these changes as well.
To wrap up, the JIAC framework features a high degree of stability and robustness and facilitates a good developer experience. The high level of robustness was important, especially in dynamic environments. The aim was to design the framework such that deploying and undeploying new services or agents should not affect other parts of the application. The same holds true in a distributed context—e.g., when new agents join or leave a system or migrate between them.
The JIAC framework is able to handle a potentially large number of agents without a decrease in performance, a requirement especially affecting communication infrastructure and the distributed service directory. Several projects dealt with service delivery and management of services, resulting in various requirements such as support for service life cycles, management interfaces, runtime deployment, and third-party service integration. Additional features of JIAC are related to management and adaptive behavior, namely monitoring and introspection, such that it is possible to retrieve status information from all framework components in a standardized way. Certain functionalities were required in multiple projects. The component reuse mechanism of JIAC supports this requirement comprehensively. Finally, JIAC is highly extensible. This feature facilitates maintainability inasmuch as future application requirements can easily be integrated.
Admittedly, there are many requirements for professional software development. It is commonly accepted (McKean et al., 2008; Mařík and McFarlane, 2005; Pěchouček and Mařík, 2008; Weyns et al., 2008, 2009) that there are seven main drivers that may further industrial technology adoption, namely: the general need, compliance with standards, reasonable costs, scalability and performance, guarantees about operational performance, mature methodologies and tools, and comprehensive documentation. To be clear about this, JIAC was never intended to cover all requirements, rather the framework aims at selected drivers:
• First, JIAC comprehensively implements standards and demonstrates that agent technology can be built on top of an established foundation.
• Second, by using high-performance libraries, JIAC aims to cover scalability and performance issues—well-known problems in the agent domain. For the same reason, namely the utilization of established libraries, JIAC fosters a guarantee on the operational performance of JIAC agent systems. This guarantee was both needed and established within the many successful appliances of the framework.
• Finally, JIAC provides a mature methodology, a comprehensive set of visual tools, and a detailed documentation, and thus directly addresses the last-mentioned factor for a successful industrial adoption.
The remaining factors are actually not a matter of the framework itself, and depend instead on the market. Yet, given the ever-increasing amount of mobile devices, the “general need” for distributed software applications can do nothing but increase. Costs, on the other hand, are difficult to assess, but like with all new technologies, costs significantly drop with increased usage. To facilitate this usage, successful applications of agent technology, as well as more frameworks with a focus on industrial requirements, are needed.
21.7 Conclusion
Industrial software development differs from academic software development inasmuch as there is a strong focus on reliability and robustness. Quality issues are major regarding the expense of sophisticated AI features. JIAC aims to bridge that gap. JIAC was developed with a focus on state-of-the-art software libraries and thus copes with industrial requirements. But being an academic product, JIAC also provides sophisticated AI features and facilitates the development of custom concepts as well. The aim of this chapter was to present the JIAC framework as a tool for the development of professional MASs.
At the beginning of the chapter, fundamental agent concepts of JIAC, namely the assembly of JIAC MASs, functional components, communication and messaging, and monitoring were introduced. Subsequently, it was explained how these fundamental concepts can be implemented by means of state-of-the-art software libraries. Spring is an example of a state-of-the-art library that was used for the development of JIAC. The entire MAS architecture is reflected in the Spring framework, which is a sophisticated component framework. Agent communication and messaging is implemented by means of ActiveMQ, while the Log4J library is used for logging purposes. Monitoring capabilities are implemented by means of JMX and a support for web services that comply with WSDL, SOAP, and REST. JIAC also provides a comprehensive set of well-documented tools that were also presented in this chapter. The AWE, the VSDT, and SSM are integrated into the Eclipse platform and can be used for the development of JIAC MASs. ASGARD is a 3D runtime monitor tool that can be used for monitoring and bug-tracking. Finally, the Agent Store brings the popular “app store concept” to the agent domain and facilitates a flexible distribution of implemented agents and agent components.
To sum up, there are only few agent frameworks that aim to bridge the gap between industry and research. The main problem is that industrial stakeholders mainly rely on well-established concepts and standards. In order to tackle this problem, JIAC was exclusively developed with a focus on state-of-the-art libraries and well-established standards. Positive effects of this philosophy are stability, robustness, flexibility, monitoring capability, reuse, and extensibility—all of which are features that foster industrial adoption.
JIAC is not a silver bullet, but rather a stepping stone toward industrial adoption, and an example of a successful application of agent technology in selected industrial processes.