We propose a lightweight approach that provides mechanisms for dynamic agent behavior at run-time. Agent collaborations are modeled in UML diagrams and agent behaviors are encoded in XML-based business rules. The combination of these captures the behavioral requirements and governs interagent and intra-agent behaviors. A CASE tool has been developed to enable the dynamic specification of agent behaviors and the generation of the agent systems. Agents get the appropriate rules in XML format and then translate and execute them at run-time. These rules are externalized and so maintenance effort is reduced, since there is no need to recode and regenerate the agent system. Rather, the system model is easily configured by users and agents will always get up-to-date rules to execute at run-time. The approach is illustrated with the aid of an e-business example and its efficacy discussed.
Agent-oriented systems differ from object-oriented systems in that agents are active,
while objects are passive. Thus, agents have the goal of having dynamic behaviors.
Therefore, agent systems should be easily adaptable, being easily changed by
engineers. Better still, would be that they were adaptive, where systems change their
behavior according to their context [
Although many tools and techniques are available for agent-oriented systems
development, there is no unified and mature way to do it. What is more, existing agent
platforms, like JADE [
Various agent platforms are available, the JADE [
A business rule is a compact statement about some aspect of a business. It is a
constraint in the sense that a business rule lays down what must or must not be the
case [
return iv&u.name;; } </Rule> If the name of one of the public attributes for an Order class was “discount”, and its type “Double”, then this template would generate: public Double getDiscount() {
return ivDiscount; }
Because agent behaviors represent actual system requirements and are subject to change, the application of business rules to the agent world should offer similar advantages as in the object world.
Agent-Object-Relationship (AOR) [
Current approaches to agent-oriented system design and implementation are
fundamentally based on the identification of agent interaction protocols, message
routing, and the precise specification of the ontology. This need for complete upfront
design makes it difficult to manage agent conversations flexibly and to reuse agent
behavior subclasses [
State machines have also been suggested for agent behavior modeling [
Agent behaviors are modeled as workflow processes in [
In answer to the weaknesses of the existing approaches, we propose the use of UML diagrams to model agent interactions and XML-based business rules to encode agent behaviors. Stable business classes are available for these rules to act upon. Rules govern agent behaviors, make decisions for agents in various contexts, have controls over the invocation of business classes and are adaptive. Agents and their rules are specified using an AAM-CASE tool. Rule definitions in terms of inter-agent behaviors are generated from the given UML diagrams, while rule definitions in terms of intraagent behaviors are specified in the tool, so that different business classes can be used in different message processing or agent actions. Agent systems can be generated from the tool. Each agent reacts to events according to the XML-based rules document at run-time. Rules can be changed in the tool very easily and it makes use of extensible ontologies.
We emphasize the integration of UML diagrams which model inter-agent relationships and XML rule definitions each of which describes an individual agent behavior. UML model information will become part of the XML definitions and enable agents to understand their communication with the outside world.
To illustrate our approach and to use in our discussion later, we introduce an ecommerce case study. Suppose a retailer runs an online shop. The retailer has an association with customers and also with various supplier companies, who may or may not serve the retailer, depending on different conditions. Overall, the relationship between customers, retailers and supplier companies can change at any time. The business vocabulary is also changeable and the decision making process for each company, retailer and customer is unpredictable.
Structural models are built through Agent Diagrams, and show agents, business rules, business classes and their relationship. Agents manage rules and rules manage the invocation of business classes. Such models are used for agent identification, agent relationship identification, and eventually building an Agent/Rule/Class hierarchy. They are later the basis for the behavioral models.
Agents are identified to represent distinct conceptual domains. Agent Diagram has
Class Diagram, the backbone of UML [
Agent systems always require interactions among many agents. Such interactions are modeled as message passing between agents. The message sender requests a service from the message receiver. The message receiver uses its internal business objects for the computation required to fulfill the request and then, possibly, takes a further action. Different situations will arise and these are modeled as rules that agents should obey. Thus, a rule is responsible for the behavior of an agent in dealing with a particular situation. Multiple rules can be defined to let the agent collaborate with other agents to achieve different goals.
association …… orderProcessing () ……
Order + Order (b: BusinessInfo) + isOrderAttractive (): boolean + createProposal (): Proposal
order:Order …… Call for proposal saleProcessing (order) ……
constraint { RetailerAgent. orderProcessing.actionMessage() equals to CompanyAgent.
saleProcessing.eventMessage() }
In Figure 2, “RetailerAgent” and “CompanyAgent” are the two identified agents for our case study. “RetailerAgent” has a rule “orderProcessing” that will construct an object with type “BusinessInfo”, package it into a “Call for proposal” message and send the message to “CompanyAgent”. To respond to such requests, “CompanyAgent” will offer a deal, if the order is attractive, using the rule “saleProcessing”. Thus, we have an association relationship between the two agents involved and a constraint for them. They resemble an association between two classes and a constraint for classes in the OO world. During the processing of rule “saleProcessing”, an “Order” object will be constructed from the received “BusinessInfo” structure and the constructed object should pass an “isOrderAttractive” check before “CompanyAgent” proceeds to offer a deal, “Proposal” for the order. Thus, such a business class of “Order” is managed by “CompanyAgent” and it has at least three methods that will be invoked by the agent rule.
Agent Diagrams capture the static relationship between different entities and depict the whole system. Agent Communication Diagrams are used to model the interaction of agents. Such behavioral models organize agents, rules and messages around business processes. For every business process, all participating agents will appear in the diagram, with message passing between them to accomplish certain business goals.
Software Architecture refers to the communication structures for system entities. In
traditional object-oriented systems, objects are aware of which other objects they will
pass messages to, but are unaware of which objects will pass messages to them. Full
architecture independence requires that the detail of where objects will send messages
should also be hidden [
In our approach, UML is used to model agent collaborations, describing how message passing among coordination agents can accomplish business tasks. UML diagrams provide a blueprint for involved business rules, the composition elements of our diagrams. Each rule governs an individual agent behavior in participating collaborations. Rules are connected to form a flow of decision making, process by process, one decision being made at each connection point. As such, the model visualizes the actual system function in a sequence of agent actions dictated by rules. User specified agent collaborations in UML diagrams are used to generate the interagent part of the rules definition, in XML format. It is through these rules that agent systems are adapted both in collaborations and internally without re-code or regeneration, since we let agents get appropriate rules to execute only at run-time, and rules get configured continuously through supporting tools we provide.
Accurately, the UML diagram used for the design of multi-agent behaviors is the Agent Communication Diagram. It has been developed based on Agent Diagram and used for the generation of agent systems. Figure 3 describes the process from the case study, where a customer orders products from a business company through a retailer. Business classes are not shown on the diagram but the invocations of their methods are, such as, the one for condition check. R2 has been shown previously as “saleProcessing” in the bottom compartment of “CompanyAgent” in Figure 2.
CAogmenptany
R2
Call for proposal
Propose
RAegteanilter
R1 R3
Place an order
CAugsetnotmer
R4 isOrderAttractive ()
Accept proposal
isProposalSatisfactory () Acknowledge
Acknowledge
Fig. 3. An Agent Communication Diagram describing a business process - - -
# " ! " "
Fig. 4. The XML definition for rule “saleProcessing” owned by “CompanyAgent” We encode diagrammatic rules in the models with a main structure of {event, processing, condition, action, priority} in XML. On receipt of an event (normally modeled as a message), an agent would act on it if the condition of the rule which is defined to deal with this event for the agent is satisfied. Rules are considered according to their priorities set by users. The XML representation for rule R2 is given in Figure 4.
UML diagrams are good at showing collaborations among agents, while XML rules
as such are good at precise definition of agent behaviors: this is what the UML
Diagrams lack [
A tool has been developed to enable the specification of the agent collaborations, rule definitions and message flow control. Figure 5 captures a window from this tool showing the construction of an Agent Communication Diagram in its main panel. Rules can be defined either in XML text or using a more user-friendly tree structure as shown in the left panel. By using this tool, part of the <event> and <action> sections of rules can be generated when incoming/outgoing messages are specified and, <processing>, <condition> and <priority> sections are given afterwards by users. XML code is eventually generated from the completed tree structure and saved in a rules document.
The AAM-CASE tool uses a business rules document as the database. Once business processes are specified graphically in the tool, agent interaction models, rule reaction patterns and message flows are established accordingly. Agent systems are automatically generated such that each rule maps to an agent behavior. Program code is not generated at this moment. Instead, XML-based rules are plugged in and are subsequently translated by agents at run-time. While the system is running, rules can be updated through the tool, so that agent behaviors are continuously updated. The system runs on the JADE platform and can be in a distributed network. All agents access the central XML-based rules document via a parsing package. This allows dynamic adjustment of agent communication structure and therefore the architecture of the system. Sample pseudo code for agent behaviors is shown in Figure 6.
A shared module called “Rule” is used by all behaviors with its ability to access the XML definition of rules and assemble corresponding objects. The methods getPriority(), getEvent(), and getAction() are provided by “Rule”. " " '( " 1 1 ! " '( '( $ * " ) + ) ) " ),
# * " / ) " # * "
% " (' * " " (' (' + + .
0"
0 & ),
This approach achieves two-way encapsulation. Agent behaviors are guided by rules so that they do not need to know who they will contact in advance. To reflect business process change, the agent behavioral models can be changed easily with the tool. These changes are automatically reflected in the XML definitions for corresponding agent rules, for example, in their <event>/<message>/<from> and <action>/<message>/<to> sections. This enables agents in the running system have their partners changed in order to accomplish the updated business processes. On receipt of any message, an agent reads the most recent rules, analyzes them and finds out the appropriate agents to send messages to. In the case study, we may wish to reconfigure the rule “saleProcessing”, and let the “CompanyAgent” take a new action in a condition previously not predicted.
Suppose now we wish to introduce a new occasion where if the current “CompanyAgent” does not evaluate the received order request to be “attractive” or can not fulfill the order request, it forwards the order to another “CompanyAgent”. This new requirement can be specified, implemented and deployed by agents automatically, via configuring the Agent Communication Diagrams through the tool. The achievement of this dynamic collaboration is through painless model adjustment rather than expensive code change. Further, we achieve a model-driven communication architecture.
The behavior of agents in processing the event, checking the condition, and taking the action is externalized in business rules. This means that they can be configured dynamically. In fact, by changing the <event>, <processing>, <condition>, and <action> fields in appropriate rules, alternative methods of the managed business objects can be selected for invocation. In the case study, we can re-configure the rule “saleProcessing” to invoke a new evaluation method of the “Order” class or event a method of a new “Order” class to check the attractiveness of the order. In addition, we can configure two couplets of <condition> and <action>, so that for ordinary customers and company customers, different ways to generate sale proposals can be used. All this can be carried out at run-time.
Only business concepts registered through the tool and saved in the rules document may appear in agent messages. When a new business concept is required, it can be registered with its properties, and a new business class with attributes will be generated by the tool. New vocabularies thus can become available for the specification of agent rules through the tree structure on the left panel of the tool (Figure 5). Also at run-time new classes with new methods thus can become available for invocation by the running agent system. Eventually, all agents will be able to understand the new vocabularies the other agents in the system are using even those registered after the system has been running for a while. Hence, ontologies are always updatable. For the case study, suppose that an additional attribute of the “BusinessInfo” business object is required and added while the system is running, the updated class becomes available to all agents immediately.
Agent behaviors are modeled and externalized as rules, and represented in UML diagrams. They are centrally managed and easy to be changed through the models or the XML-based definitions. Agent behaviors reflect functional requirements. Because rules are easy to edit, deploying new requirements requires minimal effort. The rules are, in effect, executable requirements.
One weakness of the Adaptive Agent Model is that the framework’s externalization of agent behaviors in XML-based rules will degrade the performance of such systems. Every time an agent acts and reacts to events, it will read the rules document, test rules’ applicability, find the one with the highest priority, and execute it. Therefore, there is a trade-off between ease of adaptation and performance. However, adding/upgrading hardware or using parallel computation will compensate the cost.
In the future, we expect to achieve self-adaptivity in the AAM where, as agents interact with end users they perceive their behaviors and preferences. As shown in Figure 7, this allows agents to update their beliefs, and so deduce rules that can be added to the central rules document. These inferred rules can be shared and executed by all agents and are subject to amendment. After some time, a mature and reliable rule set, independent of those acquired through the tool can be established.
Business people (business infrastructure/architecture designer)
AAM
Adaptive Information (requirements) Business people (business decision maker) Business Rules Document (including UML models & rules) Generation Adaptive Information (behaviors) Agent beliefs End users
F e e d b a c k
AAM would be useful for those domains that have frequently changing requirements where re-development would otherwise be costly. Particularly, AAM should work well when there is collaboration between many different entities and where this collaboration may be subject to adjustment, as a result of changing business processes. AAM is also suitable where the business environment is frequently changing with emerging concepts and behaviors.
Other future work will include the development of richer business rules. The Adaptive Agent Model will be made more powerful and more flexible, but work so far indicates that it will contribute in a novel and substantive way to the business need for adaptivity in systems.