The agents that participate the interaction on the BPEL4WS model based MAS plat- form are proxy agents, which means the agents themselves don’t need to make complex decision making processes but simply follow what the LCC protocol asks them to do and perform some of the computational functions. Therefore, the design issues of such agents are mainly about how to enable the agent conform to the protocol received and to perform proper actions. The contents of the package passed between agents have to be discussed before we get into the agent’s design since the rationale of agent design
relies on this. Figure 5.6 shows the inside structure of the message package that is used between agents based on our approach. For simplicity, the diagram only shows the essential components of the message package. The components located at the com-
Figure 5.6: The essential components of our message package
munication layer have been discussed earlier. The transition layer contains two forms of agent verification information. ”Physical agent address” defines the real location of the agents in the system, which might be a URL etc. ”Agent capability description” describes the intend message receiver’s capability. Thus when an agent receives a mes- sage package, it is able to decide if it can process this package before further expanding it.
According to the message package contents, the internal structure of the agents based on our approach is shown in Figure 5.7:
Figure 5.7: The internal structure of an agent
• Transition layer: is responsible for the underlying message passing between
different agents. It controls the message passing at the lowest level of our sys- tem. It receives the processed outgoing messages from communication layer and forwards the received messages from other agents to communication layer. The basic components of transition layer is shown in Figure 5.8 The ”incoming mes-
Figure 5.8: The components of agent’s Transition layer
sage queue” and ”outgoing message queue” are used to store the the message re- ceived and the messages that are going to be sent out. These two message queues are operated by ”message receiver” and ”message sender” in a first in first out manner and are used as a channel for the communication between the transition layer and communication layer. Once a ”message receiver” receives a message package from others, it puts it in in the end of ”incoming message queue” while ”message sender” fetches the first message in the ”outgoing message queue” and sends it out. The main task that ”message receiver” needs to perform is filtering transition level information of the received package such as the if this message is intended for it or if the agent it represents for matches the agent’s capability de- scription attached in the message package. In contrast, ”message sender” adds transition layer to the outgoing message package according to the information derived from communication layer.
• Communication layer: is responsible for unpacking the received messages
from the transition layer and producing the outgoing messages according to the protocol attached with the received messages. Figure 5.9 gives the inside look of the communication layer. ”Incoming message processor” is used to judge
Figure 5.9: The components of agent’s communication layer
that is required by the ”protocol expander”. If so, it passes it to ”protocol ex- pander”. Otherwise, ”incoming message processor” put this message and every- thing that is attached with it at the end of ”incoming message queue” for later processing. ”Outgoing message processor ” receives information from ” pro- tocol expander” and puts them at the end of ”outgoing message queue”. Proto- col expander” communicates with ”incoming message processor” and ”outgoing message processor” in following ways:
– If it doesn’t hold a LCC protocol at the moment, it asks the ”incoming mes- sage processor” for a message package. Once it receives it, it unpacks the message package, performs the required tasks, re-generates a new message package and sends it to ”outgoing message processor” using the following protocol expanding and re-write rules[Rob04]:
A :: B−−−−−−→ A :: EMi,Mo,P,O i f B−−−−−−→ EMi,Mo,P,O (rule 1) A1or A2 Mi,Mo,P,O −−−−−−→ E i f ¬closed(A2) ∧ A1 Mi,Mo,P,O −−−−−−→ E (rule2) A1or A2 Mi,Mo,P,O −−−−−−→ E i f ¬closed(A1) ∧ A2 Mi,Mo,P,O −−−−−−→ E (rule3) A1then A2 Mi,Mo,P,O −−−−−−→ E then A2 i f A1 Mi,Mo,P,O −−−−−−→ E (rule4) A1then A2 Mi,Mo,P,O −−−−−−→ A1then A2 i f closed(A1) ∧ A2 Mi,Mo,P,O −−−−−−→ E (rule5) A1par A2 Mi,Mo,P,O1 S O2 −−−−−−−−−−→ E1par E2 i f A1 Mi,Mo,P,O1 −−−−−−−→ E1∧ A2−−−−−−−→ E2Mi,Mo,P,O2 (rule 6)
C ← A ⇐ M−−−−−−−−−−→ c(M ⇐ A)Mi,Mi−M⇐A,P,φ i f (M ⇐ A) ∈ Mi∧ satis f y(C) (rule7)
M ⇒ A ← C−−−−−−−−→ c(M ⇒ A)Mi,Mo,P,M⇒A i f satis f ied(C) (rule8)
a(R, I) ← C−−−−−−→ a(R, I) :: BMi,Mo,P,φ
i f clause(P, a(R, I) :: B) ∧ satis f ied(C) (rule9) Rule1means the definition for a given agent may be re-written by re-writing
the components of that definition. Rule2and rule3means that if any branch
of a00or00operator is properly expanded, processed and closed, the process- ing of 00or00 operator is then accomplished. In order to expand a 00then00
operator according to its sequential semantic, rule4 and rule5 together in-
dicate that the clauses defined before a00then00 operator must be expanded before the expansion of the clauses defined after the00then00operator. Paral- lel execution in LCC in controlled by operator ”par” for which the re-write rule is defined by rule6. Rule7and rule8are used to tell agent how to be-
have when it receives a message and sends out a message. When dealing with message passing, each agent has to process the constraints associated with the messages according to rule7 (checks if the received message is
the message that it waits for and then processes the constraints) and rule8
(checks if the constraints are satisfied before it sends out the message and close the clause). Rule9 defines the re-write procedure for agent role’s
changing. According to it, if the constraints defined for agent role’s chang- ing is satisfied, agent then fetches the clauses defined for new role and starts executing them according to the other re-write rules. A protocol term is decided to be closed as follows:
closed(c(X ))
closed(A or B) ← closed(A) ∨ closed(B) closed(Athen B) ← closed(A) ∧ closed(B) closed(A par B) ← closed(A) ∧ closed(B) closed(X :: D) ← closed(B)
satis f ied(C) is true if C can be solved from the agent’s current state of
knowledge. satis f y(C) is true if the agent’s state of knowledge can be made such that C is satisfied. clause(
P
, X) is true if clause X is the dialogue framework of protocolP
, as defined earlier.– If it holds a protocol and is waiting for a message, it asks ”incoming mes- sage processor” for the message and blocks itself until it receives the re- quired message.
During the process of protocol expansion, all the constraints involved are sent to ”constraints solver” in the application layer for further processing.
”Outgoing message processor” simply forwards the message package that it re- ceives from ”protocol expander” to ”outgoing message queue” currently. It is a place holder for outgoing message processing. For example, the message pack- age may have priorities. In such case, the ”Outgoing message processor” is responsible for sorting the messages in ”outgoing message queue” accordingly.
• Application layer: is the place where the constraints defined in LCC protocol
are solved. It contains at least two components, web services invoker and con- straints solver, as shown in Figure 5.10 ”Web services invoker” takes care of all
Figure 5.10: The components of agent’s application layer
the issues of web services invocation including: invoking a web service accord- ing to the received messages; handling the returned message from invoked web
service and converting them into agent’s messages. ”Constraint solver” provides a container for executing the constraints that are requested by the ”protocol ex- pander”. The way for solving the constraints might be attached to the LCC protocol or purely solved by the local methods.