In this chapter, we discussed how to develop protocol based multi-agent systems us- ing executable business process models. Language mapping is performed between a business process modelling language (BPEL4WS) and a IP (LCC) to generate the pro- tocol used in a MAS from a business process model. Since the gap between them is large, we use a another modelling language (SPPC) as an intermediary. Thus a SPPC model derived from a BPEL4WS specification can be translated into LCC protocol automatically using the existing algorithm.
During the language mapping process, we found that although most of the main concepts from business process modelling language (BPEL4WS) and SPPC match, some particular notations from the business process modelling language cannot be seamlessly represented by a another modelling language which is based on different paradigm. For example, the computing activities nested at the end of a < sequence > activity in BPEL4WS can not be easily translated in to SPPC clauses as addressed earlier and also, the translation for the synchronisation links defined in < f low > re- quires the revision of LCC protocol generation algorithm from SPPC. Such restrictions mean only some BPEL4WS specifications (those conforming to the language mapping rules) can be used for interaction protocol guided MAS development, which makes the approach discussed in this chapter incomplete. In fact, such language mapping based completeness is very hard to achieve (even for particular business process mod- elling languages) since different business process modelling languages and protocol modelling languages may be based on different computing paradigms.
A Novel Approach of Using Executable
Formal BPMs For MAS Development
In chapter 4, we discussed the automatic generation of LCC protocol from BPEL4WS specification using syntax based language mapping technique and concluded that such an approach can only provide partial solution for the problem (using executable busi- ness process model for MAS development) because of missing of a implicit role work- flow server in MAS and also the gap between the computing paradigms of two different languages is too great.Therefore, in this chapter we propose another approach for our work: producing a LCC protocol, which acts as BPEL4WS interpreter. The BPEL4WS specification and the LCC protocol (BPEL4WS interpreter) are passed together between the agents to enable their coordination. BPEL4WS specification defines the tasks that agents need to perform and the LCC protocol tells agents how to interpret BPEL4WS specifications received. Based on this idea, a BPEL4WS specification that is defined in any fashion can be interpreted neatly by LCC protocol when they are passed together in the multi- agent system.
5.1
Agent Coordination Using LCC Protocol and
BPEL4WS Specification
From the purely technical point of view, a BPEL4WS model is nothing but a XML document that is composed by certain syntaxes which can be understood by comput- ing software. The BEPL4WS workflow engine is software that is designed and imple-
mented to understand the syntax used in a BPEL4WS specification and is used process them to perform tasks described. In a MAS, if each agent is given the knowledge of how to process the BPEL4WS document and if the states of running process instance are provided, the centralised workflow server is not needed any more at least for exe- cuting the business process model. There are two ways to give an agent capability to perform task:
1. embedding the business process model processing capability inside the agent which means the agent knows how to do things when it is initially created. This is the way of how the conventional workflow is implemented and we are not in- terested in this approach since making each agent additive to particular business process modelling language loses generality.
2. assigning the capability to the agent dynamically, which means the agent can only has the ability of performing certain tasks, for instance, processing BPEL4WS models, when it is given such knowledge at run time. This approach, compared with the first one, is more generic because MAS is simply used as a platform to provide pure distributed architecture and is separated from particular application (workflow management) deployed on it. Therefore, for our work, we concentrate on this approach.
The crucial issue that we need to consider for the second approach then is how we can dynamically assign capability to agent. It is noticed that one of the design principles of LCC is to specify and to tell agents what to do and how to do the tasks speci- fied. Therefore, if we can use LCC protocol to tell agents in MAS how to process BPEL4WS, BPEL4WS specifications can be used directly in MAS. In this way, LCC protocol acts as a language interpreter, which understands all the BPEL4WS syntaxes and their semantics, and this interpreter is given to each agent dynamically during their interaction. In agents’ interactions, BPEL4WS is used to tell agents what are the cur- rently requested tasks and LCC protocol tells how to perform the tasks specified by BPEL4WS. In addition, the states of the BPEL4WS model attached in a LCC protocol are also recorded. Figure 5.1 shows the new correspondences between the components of a conventional workflow server and a LCC protocol, from which we can clearly see that all the components that compose a workflow server can be assumed by a LCC protocol. In the other words, with these correspondences, the LCC protocol passed between agents gives agents the ability of acting as a ”conventional workflow server” at the moment when they hold the received message packages.
Figure 5.1: The correspondence between the components of the conventional workflow server and LCC
The infrastructure of the system based on the new idea is given in Figure 5.2. Based on this infrastructure, the multi-agent interaction protocol, BPEL4WS specification and interacting messages are packed and passed together between the agents. Once an agent receives the package, it processes: the incoming message (initiating appropriate behaviours), interaction protocol and BPEL4WS (resolving the next action it needs to take), then it sends out a new package to the next agent to continue the coordination. Besides LCC protocol, BPEL4WS model and messages, the package that is passed between agents in MAS also contains all the values of the variables that are used for the attached BPEL4WS model, which means the storage of data is also decentralised.