Jadex Software Projects
This is the main page of the Jadex software projects, which are open source and Java-based and especially target the development of concurrent and distributed software systems. Below you can find a list of links to the subprojects, which are currently hosted under the Jadex software umbrella.
The
Jadex Active Components projects provides a general purpose runtime infrastructure for all kinds of active components. Similar to traditional (passive) component runtime environments such as Java EE, the active components infrastructure provides a container that manages the components. Active components differ from traditional (passive) components in having some autonomy with regard to their execution. This means that they may actively decide for themselves to execute some actions (e.g. in response to events). This allows highly concurrent systems being realized and efficiently executed. The specification of active components requires only a few properties so that very different active components can be devised and implemented. Currently, implementations for agents and processes exist (cf. the Jadex Agents and Jadex Processes subprojects below).
The
Jadex Agents project aims at providing a software framework for building multi-agent applications. The project builds on the
Jadex Active Components middleware and adds agent architecture support. Currently, with BDI and micro agents a cognitive and a reactive agent architecture is available. BDI agents are capable of acting in a goal-directed manner using their beliefs, desires an intentions. Besides these cognitive agents, which are especially suited for complex tasks, Jadex also directly supports simple and reactive micro agents, which are similar to active objects and are very efficient in terms of low resource consumption. In applications also heterogeneous systems, consisting of agents based on different agent architectures, can be built.
The
Jadex Processes project aims at providing execution facilities for workflows. Currently, with BPMN and GPMN two workflow types are supported. Both workflow types are designed as active components and can thus be executed on the
Jadex Active Components middleware. The BPMN engine is realized as an interpreter for (extended) BPMN diagrams that are produced by the eclipse STP BPMN editor. In order to be executable the diagrams need to be annotated with Java expressions describing the semantics of the main elements like activities or branching conditions. GPMN workflows are goal-oriented and allow the definition of processes at a higher abstraction level.
Jadex Rules is a forward chaining rule engine similar to Drools and Jess. In contrast to these and other rule engines it has been developed as a reusable software module that can be easily integrated as part of other software. The rule engine currently supports three different rule specification languages: an adapted Java language, a CLIPS/JESS derivate and an internal representation. The adapted Java language allows writing conditions in a very intuitive way for users that are already familiar with the underlying base language and is an outstanding feature of Jadex Rules. The engine further encapsulates an enhanced state representation, which allows OAV (object attribute value) and Java beans, as well as mixed forms for describing facts. The state also handles automatic garbage collection. Another nice feature of the rule engine is a visual debugger supporting breakpoints, stepwise execution and Rete-network browsing.
Jadex XML is an XML data binding framework for Java and also for other representations. The main idea of Jadex XML is that neither the XML-Schema on the one side nor the Java classes on the other side should define the binding. Instead, a separate mapping between both is used as a mediation. This allows designing the XML representation independent of the Java side but still being able to connect both as desired. This idea was first put forward by the JiBX data binding framework. Jadex XML pushes it further by combining it with the
configuration by exception principle. The framework can detect obvious correspondence between both sides automatically and only needs configuration information when translations are necessary. The configuration information is currently specified directly in form of Java configuration classes.
