Method of Using BDI Agents to Implement Service-oriented Workflow Mapping in AGWMS1

Lei Cao, Minglu Li, Jian Cao, Feilong Tang Department of Computer Science and Engineering, Shanghai Jiao Tong University, Shanghai

200240, China clcao@sjtu.edu.cn, {li-ml, cao-jian, tang-fl}@cs.sjtu.edu.cn

1 This paper has been supported by the grand project of the Science and Technology Commission of Shanghai Municipality (No.05dz15005), Chinese High Technology Development Plan (No.2004AA104340), Chinese NSF Project (No.60473092, No. 60503041) and Natural Science Foundation of Shanghai Municipality of China (Grant No. 05ZR14081).

Abstract

Grid computing is becoming a mainstream technology for large-scale distributed resource sharing and system integration. Workflow management is also emerging as one of the most important grid services. Web service composition has been one of the hottest research topics. Grid environment is very dynamic, and the services are shared among many users, it is impossible to optimize the workflow from the point of view of execution ahead of time. In fact, one may want to make decisions about the execution locations and the access to a particular data set as late as possible. In this paper, we propose a method of using BDI agents to implement service-oriented workflow mapping in our agent-based grid workflow management system (AGWMS), which helps grid users streamline, manage and monitor their routinely problem solving processes without having to know any details of the underlying complex structure and dynamic state of VOs. BDI agent technology helps the system meet challenges from the grid context. Three types of workflow in AGWMS are denoted as abstract workflow (AW), concrete workflow (CW) and executable workflow (EW). We also propose AW2CW mapping algorithm and CW2EW mapping algorithm to implement service-oriented workflow mapping. Utilization of three workflow types further liberates model designers from sophisticated system details. It also increases the reusability of domain-specific models and improves the fault tolerance of the system. 1. Introduction

Grid computing [1] facilitates the sharing and

aggregation of heterogeneous and distributed

resources, such as computing resources, data sources, instruments and application services in science, engineering and commerce. Web services are self-describing software applications that can be advertised, located and used across the Internet using a set of standards such as SOAP, WSDL and UDDI [2]. The Web Services Resource Framework (WSRF) defines a generic and open framework for modeling and accessing stateful resources using Web Services [3]. The broad support for WSRF has been gotten from both the Web services and Grid communities. With the advent of grid technologies, scientists, engineers and businessmen are building more and more complex applications to manage and process large data sets, and to execute respective tasks on distributed grid resources. Means of composing and executing distributed applications and services to form complex workflow are needed. Some efforts in the research of business workflow and web services composition [4] can be reused in grid workflow systems. Grid workflow is a workflow intended to solve sophisticated problems that occur in highly heterogeneous, distributed, complex and dynamic grid environments that comprise of one or more virtual organizations (VOs). Given the dynamic nature of the Grid environment, it is more suitable for users to define workflow applications in the abstract model, in which the workflow is specified without referring to specific Grid resources for task execution. In this paper, we propose a method of using BDI agents to implement service-oriented workflow mapping in our agent-based grid workflow management system (AGWMS), which helps grid users streamline, manage and monitor their routinely problem solving processes without having to know any details of the underlying complex structure and dynamic state of VOs. BDI agent technology is used to meet challenges from the grid context. Three

Proceedings of the Fifth International Conference on Grid and Cooperative Computing (GCC'06)0-7695-2694-2/06 $20.00 © 2006

types of workflow in AGWMS are denoted as abstract workflow (AW), concrete workflow (CW) [5, 6] and executable workflow (EW). We also propose AW2CW mapping algorithm and CW2EW mapping algorithm to implement service-oriented workflow mapping. Plan generating algorithm and Plan merging algorithm are also given to aid the process. Utilization of three workflow types further liberates model designers from sophisticated system details. It also increases the reusability of domain-specific models and improves the fault tolerance of the system.

The remainder of the paper is organized as follows. We discuss related work in Section 2. Section 3 presents the BDI agent model of AGWMS in detail. Section 4 gives more details about algorithms in the service-oriented workflow mapping process. Section 5 presents a case study and the implementation of system. We conclude in Section 6 with lessons learned and future research consideration. 2. Related work

The abstract workflow model provides a flexible way for users to define workflows without being concerned about low-level implementation details. A full or partial concrete model can be generated just before or during workflow execution according to the current status of resources. Additionally, in some systems [7], every task in the workflow is concretized only at the time of task execution. The concrete model binds workflow tasks to specific resources.

The mapping of Grid workflows onto Grid resources based on existing planning technology is presented in [8]. This work focuses on coding the problem to be compatible with the input format of specific planning systems and thus transferring the mapping problem to a planning problem. Although this is a flexible way to gain different destinations, significant disadvantages regarding the time-intensive computation, long response times and the missing consideration of Grid-specific constraints appeared. The latter is the main cause that the suggested solutions often do not express the expected quality.

Cao et al. presented an algorithm that maps each sub-job separately on individual Grid resources [9]. The algorithm processes one sub job at a time, schedules it to a suitable RMS with start time slot not conflicting the dependency of the flow. The selection of the destination resources is optimized with respect to a minimal completion time. When applying this strategy to the specified problem, each sub job will be assigned separately to the cheapest feasible RMS. This strategy allows fast computation of a feasible schedule,

but it does not consider the entire workflow and the dependencies between the sub jobs.

3. BDI agent model of AGWMS 3.1. Architecture of AGWMS

Workflow Console

Workflow Engine (Distributed)

DatabaseAdapter

Web ServiceAdapter

Java ClassAdapter

Grid ServiceAdapter

Resource Resource Resource Resource

Resource Pool

Adapter Middleware

Workflow Modeling ToolDatabase

Multi-Agent Platform

Command LineAdapter

GridFTPAdapter

GlobusJobAdapter

DCOM Adapter

User Layer

Engine Layer

Agent Layer

Adapter Layer

Grid Middleware(Globus)

AGWMS

Figure 1. Four-layer architecture of AGWMS

From the Figure 1, you can see that there are four

layers in AGWMS. The user layer is the interface between user and system. There are mainly two modules in this layer: Workflow modeling tool and Workflow console. The engine layer is the core layer to manage workflow execution. Our workflow engine is distributed using JINI technology [10]. It’s based on ECA rules. The agent layer makes it possible that the workflow could be divided into three types: abstract, concrete and executable. The adapter layer makes it easy that AGWMS invokes external applications. Adapter is the proxy for the invokable application. It encapsulates the complex invoking details. Different types of adapter are designed in AGWMS. 3.2. BDI agents in AGWMS

All agents in the agent layer are constructed according to Belief-Desire-Intention (BDI) model [11]. There are six kinds of agents in the layer depicted in Figure 2. Our model is based on Jadex [12]. The term “plan” in Jadex is modified to “project” in this paper to be distinguished from our own “plan” notation.

Proceedings of the Fifth International Conference on Grid and Cooperative Computing (GCC'06)0-7695-2694-2/06 $20.00 © 2006

PA-1

UA

IA-1 MA-1

ACL Channel

IA: Information Agent MA: Merging Agent PA: Planning Agent UA: User AgentAdA: Administrator Agent SAg: Service Agent

SAg-1 SAg-2

PA-2

AdA-1

Figure 2. BDI agent model in AGWMS

Definition 1. The term “capability” is used for different purposes in the agent community. In the context of AGWMS, the term is used to denote an encapsulated agent module composed of beliefs, goals and projects. A capability is basically the same as an agent, but without its own reasoning process. Definition 2. Plan is a special kind of workflow, which is used in planning agent (PA) of AGWMS. Plan is the internal expression of an external capability of PA. Each plan has many common components compared with the generic workflow, such as logical nodes, internal actions (start, finish, delay, evaluate, convert). But external actions, such as invocations of Web or Grid Services, operations on database or execution of other kinds of application, will be replaced with application agents (AAs) in the plan. In service-oriented context, AA refers to service agent (SAg). Definition 3. Beliefs represent the agent's knowledge about its environment and itself. In AGWMS the beliefs can be any Java objects. They are stored in a belief base and can be referenced in expressions, as well as accessed and modified from projects using the belief base interface. Definition 4. Goals make up the agent's motivational stance and are the driving forces for its actions. Therefore, the representation and handling of goals is one of the main features of AGWMS. The goal notation is equal to the desire notation. Definition 5. Projects represent the agent's means to act in its environment. Therefore, the projects predefined by the developer compose the library of (more or less complex) actions the agent can perform. Depending on the current situation, projects are selected in response to occurring events or goals. The project notation is equal to the intention notation.

Table 1 presents the concrete definitions about the BDI model of our AGWMS.

Table 1. BDI definitions of agents in AGWMS

Agent Beliefs Desires Intentions UA 1.AdA address

2.MA address 1.Goal to perform mapping of AW 2.Goal to perform CW execution

1.Project of mapping AW 2.Project of executing CW

AdA 1. IA address 1.Goal to perform mapping of CW

1.Project of mapping CW

2.Goal to perform EW execution 3.Goal to query CW information

2.Project of executing EW 3.Project of query

MA 1.IA address 1.Goal to perform bids invitation to PAs 2.Goal to achieve CW composition 3.Goal to query PAs information

1.Project of bids invitation 2.Project of CW composition 3.Project of query

IA 1.Important data of all agents 2.Database access point

1.Goal to maintain all agents information 2.Goal to return query result

1.Project of maintaining all agents information 2.Project of returning query result

PA Capability

1.Preconditions of plan 2.Effects of plan 3.Functionality name of plan

1.Goal to execute plan 1.Project of executing plan with the agent engine

PA 1.IA address 1.Goal to perform bids submission 2.Goal to perform capability searching 3.Goal to perform new capability generation 4. Goal to perform capability updating in IA

1.Project of bids submission 2.Project of searching demanded capability 3.Project of generating new capability 4.Project of updating capability in IA

SAg Capability

1.Preconditions of service adapter 2.Effects of service adapter 3.Functionality name of service adapter

1.Goal to execute service adapter

1.Project of executing service adapter

SAg 1.IA address 1.Goal to perform capability updating in IA

1.Project of updating capability in IA

1) Planning agent (PA)

PA is the main component of AW. It is domain specific, and its capabilities are always stable and predefined. In some sense, PA takes the role of host of sub-workflow denoted in business workflow domain. In this paper, each capability of PA represents a plan. Each PA has multiple plans in its plan library, so it has multiple capabilities in its capability library. PA is also responsible for the scheduling of plan execution. It contains the agent engine to carry out the scheduling.

{ }{ }

{ }

( )( )

Beliefs(Capability( )) ( ), ( ), ( )

, ,...,1 2( ), ( ),..., ( )1 2

i i i i

Plans PACapability PA

plan Preconditions plan Effects plan FunctionalityName plan

plan plan plannCapability plan Capability plan Capability plann

==

= 2) Service agent (SAg)

SAg is the main component of PA plan. It corresponds with a list of service adapters that have the specific function. A service adapter might bind some services having same functionality, whereas services from different service adapters of the same SAg are only similar in functionality. Each capability in SAg represents one service adapter. SAg has multiple service adapters in its adapter library, so it has multiple

Proceedings of the Fifth International Conference on Grid and Cooperative Computing (GCC'06)0-7695-2694-2/06 $20.00 © 2006

capabilities in its capability library. In the mapping process of CW to EW, SAg is responsible for binding the most suitable service and uniting others to make the whole workflow have the maximum QoS value.

{ }{ }2

Adapters(SAg) =

Capability(SAg)= 1Beliefs(Capability( )) ( ), ( ),

...

n

i i i

adapter ,adapter , ,adapter1 2 nCapability( adapter ), Capability( adapter ), ..., Capability( adapter )

adapter Preconditions adapter Effects adapter F= { }( )iunctionalityName adapter 3) Information agent (IA)

IA is the registry of all agents in the multi-agent platform. We adopt multi-layer distributed framework for IA in Grid environment. Each VO has its local IA. The local IA keeps the information about capabilities of all PAs and SAgs in the VO. SAgs are chosen preferentially from the same VO when building a plan in order to get better efficiency at the execution time. The general IA has the registration information about all local IAs. 4) Merging agent (MA)

MA is responsible for merging all related plans of PAs to get a concrete workflow according to the predefined abstract workflow. Based on all functionality modules defined in AW, MA will send out bid invitations to related PAs. Both Plan generating algorithm and Plan merging algorithm are utilized by MA. 5) User agent (UA)

As the representative of users, UA interacts with Workflow console and Macro-workflow modeling tool. UA receives CW execution command from Workflow console and returns real-time execution states latterly. UA also gets AW model from Macro-workflow modeling tool and returns corresponding CW latterly. UA would interact with other agents in the system to complete these tasks. 6) Admin agent (AdA)

Admin agent is responsible for the mapping from CW to EW using Genetic algorithm. Furthermore, it is responsible for the scheduling of EW execution. It contains the global engine to carry out the scheduling. 4. Algorithms in the mapping process 4.1. Mapping algorithms Definition 6. The PA matching the functionality module implies that at least one of the PA capabilities could satisfy the following situations: Pr ( ) Pr ( )

( ) ( )( ) ( ( ))

i

i

i

econditions Cap econditions ModuleEffects Cap Effects ModuleFunctionalityName Cap SubClassOf FunctionalityName Module

⊆⊇

∈

Definition 7. Functionality decomposition means the functionality name could be decomposed with its sub-functionality names according to the domain ontology.

1 2( ) ( , ,..., )mFunctionalityName Module Composite FN FN FN= Definition 8. Joint bid inviting means that the MA

sends out the composite functionality, which includes all sub-functionalities, to related PAs to accomplish it together. Definition 9. Qualified bidding consortium, which satisfies the joint bid invitation as a single bidder, should have two or more PAs. Each PA must have at least one capability which satisfies the following situations:

1 2

( ) ( )Pr ( ) Pr ( )( ( ) ( ) ... ( )) ( )

i i

i

m

FunctionalityName Cap SubClassOf FNecondtions Cap econditions Module

Effects Cap Effects Cap Effects Cap Effects Module

∈⊆

∪ ∪ ∪ ⊇

User agent Admin agentMerging agent

Planning agent Information agent(Order by Domain)

Service agent

Workflow ConsoleMacro-workflow modeling tool

1. Sends macro model

2. Query PA information

3. All related PA information

4. Sends bidding request

5. Bidding response

0a. Updates registration information

5a. Planning

6. Merging

5a1. Query SAg information

5a2. Related SAgs

Planning agent

0b. Updates registration information

1'. Sends running command

7. CW 5'. EW

4'. GA optimization

2'. Query related QoS values

3'. All related QoS values

Figure 3. Activity diagram of workflow mapping

There are two mapping algorithms in our system.

Figure 3 gives the activity diagram depicting AW2CW mapping and CW2EW mapping. AW2CW mapping algorithm is used by MA to implement the mapping from AW to CW. CW2EW mapping algorithm is used by AdA to implement the mapping from CW to EW just before the selected CW to be executed. 1. AW2CW mapping algorithm: 1) After received the mapping request from Macro-

workflow modeling tool, the UA sends the AW model to the MA. As we know, the AW is composed of many functionality modules, which are described as preconditions, effects and functionality names.

2) The MA sends the query about information of PAs in specific domain to the IA.

3) The IA returns information of all related PAs to the MA.

4) The MA sends out all module bid invitations to related PAs gotten at Step 2).

5) The PA searches in its capability library for qualified one. If matchmaking is successful, the PA will return the bid submission. If else, no response will be sent back.

6) When the defined threshold time is due, the MA checks the bid submissions from PAs. If all modules have their corresponding PAs, go to Step

Proceedings of the Fifth International Conference on Grid and Cooperative Computing (GCC'06)0-7695-2694-2/06 $20.00 © 2006

10). 7) If the module has the combined functionality, the

MA will do the functionality decomposition and send out new joint bid invitations to related PAs gotten at Step 2). If else, go to Step 9).

8) When the defined threshold time is due, the MA checks whether a qualified bidding consortium has been generated to satisfy the joint bid invitation. If successfully, go to Step 7) until there are no unsatisfied modules.

9) The MA uses Plan generating algorithm depicted in Section4.2 to create a new PA and its new plan to match the demanded module. Go to Step 7) until there are no unsatisfied modules.

10) The MA uses Plan merging algorithm depicted in Section4.2 to merge all plans in the same sequence with all functionality modules in the AW. Now the final CW can be gotten.

11) The MA sends back the final CW to the UA. The UA displays it in Macro-workflow modeling tool.

2. CW2EW mapping algorithm 1) After received the execution command of selected

CW from Workflow console, the UA transmits it to the AdA.

2) The AdA gets the detailed information about the selected CW from the IA. The information includes all QoS values of the related services referred in the CW. As we know, those services may have some kinds of relationship with each other. Some alteration to their QoS value should be made when those correlative services co-exit in the same workflow.

3) The AdA uses Genetic algorithm (GA) to select the most suitable services from the candidate services set in all SAgs. Thus we can get the final EW. The global QoS value of the workflow can be maximized using GA. GA used in service selection is depicted in our former work [13].

4.2. Planning algorithms Definition 10. A planning problem can be described as a three-tuple: , ,δ< Γ ∆ > , where Γ denotes the initial state of the planner, ∆ denotes the set of goal states the planning system should attempt to reach, δ is the set of (ground) actions the planner can perform in attempting to reach a goal state. Definition 11. A state can be represented as a conjunction of positive literals. For example, At(Nanjing,Frank) Destination(Sanya)∧ might represent a state in the travel planning problem. Definition 12. A goal is a partially specified state, represented as a conjunction of positive ground literals such as:

At(Sanya, Frank) Hotel(PearlHotel)∧ . Definition 13. An action is specified in terms of the preconditions that must hold before it can be executed, and the effects that ensue when it executes. In the paper, An action is represented as a SAg capability.

In our system, each plan has following four components, where the first two define the steps of the plan and the last two serve to determine how plans can be extended:

A set of actions, which make up the steps of the plan. The empty plan contains just the Start and Finish actions. Start has no preconditions and has all the literals in the initial state of the planning problem. Finish has no effects and has the goal literals of the planning problem as its precondition.

A set of ordering constraints. Each ordering constraint is of the form A B≺ , which means that action A must be executed before action B.

A set of causal links. A causal link between two actions A and B in the plan is written as pA B→ which asserts that p is an effect of the A and a precondition of B. The plan may not be extended by adding a new action C that conflicts with the causal link.

A set of open preconditions. A precondition is open if it is not achieved by some action in the plan.

We design Plan generating algorithm, which is based on Partial-order planning (POP) algorithm [14, 15], to generate the agent plan. We have modified POP successor function to permit the decomposition method used in the existing AW, and we can get the final CW by Plan merging algorithm. 1．Plan generating algorithm: 1) The initial plan contains Start and Finish, the

ordering constraint Start Finish≺ , no casual links, and all the preconditions in Finish are open preconditions.

2) The successor function arbitrarily picks one open precondition p on an action B, and generates a successor plan for ever possible consistent way of choosing an action A that achieve p. Consistency is enforced as follows:

The causal link pA B→ and the ordering constrain A B≺ are added to the plan. Action A may be an existing action in the plan or a new one. If it is new, add it to the plan and also add Start A≺ and A Finish≺ .

We resolve conflicts between the new causal link and all existing actions, and between the action A (if it is new) and all existing causal

Proceedings of the Fifth International Conference on Grid and Cooperative Computing (GCC'06)0-7695-2694-2/06 $20.00 © 2006

links. A conflict between pA B→ and C is resolved by making C occur at some time outside the protection interval, either by adding B C≺ or C A≺ We add successor states for either or both if they result in consistent plan.

3) The goal test checks that a plan is a solution to the original planning problem. Because only consistent plans are generated, the goal test just needs to check that there are no open preconditions.

2．Plan merging algorithm: 1) Select one PA c’ in AW and for the most suitable

Decomposition (c, d) method from the plan library such that c and c’ unify with substitution θ, we replace c’ with d’=SUBST (θ, d).

First, the PA c’ is removed from AW. Then, for each step s in the decomposition d’, we need to choose an action to fill the role of s and add it to the workflow.

Hook up the ordering constraints for c’ in the original workflow to the steps in d’.

Hook up causal links. If 'pB c→ was a causal link in the original workflow, replace it by a set of causal links from B to all the steps in d’ with precondition p that were supplied by the Start step in the decomposition d.

2) Continue step 1) until all PAs in the original AW have been dealt with. Thus we get the last CW.

5. A case study and the implementation

In order to show how BDI agents are used to implement service-oriented workflow mapping, this section introduces a service-based system model for Online conference arrangement, which needs to integrate services provided by different organizations such as Conference organizers, Ticket agents, Car rental companies, Hotels, Restaurants, Travel agencies and Retailers. We need build domain-specific ontologies for workflow mapping in advance. Plan generation and selection, PA selection, SAg selection and Service adapter selection are all based on those term ontologies. 5.1. Abstract workflow model

Rent_CarStart

Finish

Register_Conference Book_Ticket

Reserve_Accommodation(Hotel&Restaurant) Buy_SouvenirArrange_Tour

Figure 4. The abstract workflow model

We assume several international conferences will be

held at Shanghai Jiao Tong University this year, so the conference organizers want to build an online conference arrangement service for the future attendee. Our AGWMS provides them the platform to build such composite service, which is actually a service-oriented workflow. At first step, they build an abstract workflow using Macro-workflow modeling tool (See Figure 4. With their experiences, the conference organizers define the requirements of each functionality module in the model. They believe that some parameters should be given before invoking the module. We may denote these parameters “Preconditions”. They also define some parameters that will be gotten after the module successfully runs. We may denote them “Effects”. With the help of domain ontology, they also assign functionality name to these modules. 5.2. Present plan agents

For the reason of clearness, we give details only about present PAs in the case. Other types of agents, such as MA, IA, UA and SAgs are not referred here. Six PAs are assumed in the system. They all have more than one plan. Each plan is corresponding to one capability in PA. Table 2 tells their descriptions.

Table 2. Present PAs PA name Capabilities Plans Note

Registration

1. ConfRegistration 2. VisitRegistration

1.Conf_reg 2.Visit_reg

1.Registration of conference 2.Resistration of visit

Ticket_Booking

1.TranspBooking 2.EntertBooking 3.MatchBooking

1.TranspTicket_booking 2.EntertTicket_booking 3.MatchTicket_booking

1.Transportation ticket booking 2.Entertainment ticket booking 3.Match ticket booking

Rental_SP

1.CarRental 2.BicycleRental 3.CopterRental 4.YachtRental

1.Car_rental 2.Bicycle_rental 3.Copter_rental 4.Yacht_rental

1.Rental of car 2.Rental of bicycle 3.Rental of copter 4.Rental of yacht

Hotel_Reservation 1.HotelReservation 1.Hotel_reservati

on 1.Reservation of hotel

Restaurant_Reservation

1.RestaurantReservation

1.Restaurant_reservation

1.Reservation of restaurant

Tour_Arrangement

1. OverseasTour 2.DomesticTour 3.LocalTour

1. Overseas_tour 2.Domestic_tour 3.Local_tour

1.Overseas tour arrangement 2. Domestic tour arrangement 3.Local tour arrangement

Proceedings of the Fifth International Conference on Grid and Cooperative Computing (GCC'06)0-7695-2694-2/06 $20.00 © 2006

For example, Registration PA has two plans in its

plan library (See Figure 5). ConfRegistration capability is given in file ConfRegistration.capability.xml and VisitRegistration capability is depicted in file VisitRegistration.capability.xml. Registration PA itself is configured in file RegistrationPA.agent.xml. For the reason of paper length, we can not give the details here. Plans of other PAs are also not presented.

Conf_Inquiry Attendee_RegistrationA A A AStart D ocu men t s_

DistributionA A FinishA A

Visit_Inquiry Visiter_RegistrationA A A AStart A A Finish

1. Conf_reg Plan

2. Visit_reg Plan

Logic node A: AndData&Control Flow Figure 5. Plans of Registration PA

5.3. Mapping procedure

We assume that the attendee will arrive at the day before the conference open day and go back at the day after the conference end day. The assumption adds some exact relationships among those conditions and simplifies the problem solving. According to the user requirements about six functionality modules in AW model, appropriate PAs are selected and matched by MA at first. AW2CW mapping algorithm is used in the process. Finally we get the results as follows:

Registration PA can match Register_Conference module, and ConfRegistration capability is selected.

Ticket_Booking PA can match Book_Ticket module, and TranspBooking capability is selected.

Rental_SP PA can match Rent_Car module, and Carrental capability is selected.

Tour_Arrangement PA can match Arrange_Tour module, and Localtour capability is selected.

Reserve_Accommodation module has no proper PA to match. As we know, the functionality name of Reserve_Accommodation is “Reservation of accommodation”, which is composed of “Reservation of hotel” and “Reservation of restaurant” in the domain ontology. So MA will send out new joint bid invitation to all related PAs. In this time, Hotel_Reservation PA unites with Restaurant_Reservation PA to generate a qualified bidding consortium to satisfy the joint bid invitation. The eligible capability in Hotel_Reservation PA is HotelReservation, and RestaurantReservation in Restaurant_Reservation PA.

Buy_Souvenir module also has no proper PA to match. Because the module has no combined functionality, the MA uses Plan generating algorithm to create a new PA Souvenir_Buying

and its new plan Souvenir_buying (See Figure 6). The corresponding capability SouvenirBuying will satisfy the functional requests of the module.

Goods_Query Goods_PurchaseA A A AStart Goods_DeliverA A FinishA A

1. Buying_souvenir Plan

Logic node A: AndData&Control Flow Figure 6. Plans of Souvenir_Buying PA

Start

Finish

Conf_Inquiry Attendee_Registration

Do cument s_ Distr ibution TT_Inquiry TT_Select TT_Booking

CR_Inquiry CR_Select CR_Rent

Hotel_Search Hotel_Select Guest_Reserve

Restaurant_Search

Restaurant_Select

Guest_Reserve

LT_Search LT_Select Guest_Register Goods_Query Goo ds_Pu rch

aseG oods_Deliver

Figure 7. The final concrete workflow

At last, the concrete workflow is generated by MA. It is depicted in Figure 7. For the services bound in eighteen SAgs in the final CW, we could get their QoS values in advance. Before the generated CW in the above process is selected to run, CW2EW mapping algorithm will be utilized by AdA to get the final EW, which has the maximum QoS value. Details are omitted here. 5.4. System prototype implementation

AGWMS is developed with Java language. A prototype has been developed according to the framework. Figure 8(a) gives a screenshot of Macro-workflow modeling tool. Figure 8(b) shows web service adapter interface. Our BDI multi-agent platform is developed using Jadex technology. Figure 8(c) shows the agent-hosting environment. The prototype runs on Windows platform.

(a) Macro-workflow modeling tool

(b) Web service adapter

(c) Agent-hosting environment

Figure 8. System prototype

Proceedings of the Fifth International Conference on Grid and Cooperative Computing (GCC'06)0-7695-2694-2/06 $20.00 © 2006

6. Conclusion and future work

This paper presents a method of using BDI agents to implement service-oriented workflow mapping in our agent-based grid workflow management system (AGWMS). BDI agent technology helps the system meet challenges from the grid context. Three types of workflow in AGWMS are denoted as abstract workflow (AW), concrete workflow (CW) and executable workflow (EW). We propose AW2CW mapping algorithm and CW2EW mapping algorithm to implement service-oriented workflow mapping. Plan generating algorithm and Plan merging algorithm are also given to aid the process. Combined with BDI agent technology, the workflow mapping process can be accomplished efficiently and accurately. Utilization of three workflow types further liberates the model designers from sophisticated system details. It also increases the reusability of domain-specific models and improves the fault tolerance of the system.

In the near future, we intend to go further using BDI agent technology in AGWMS and do a practical performance evaluation to show that our system can be efficiently used in the Grid environment. We will also consider plan mining from numerous existing domain-specific workflow models. 7. References [1] Foster I., & Kesselman C. The Grid Blueprint for a Future Computing Infrastructure. San Fransisco: Morgan Kaufmann. 1999 [2] Curbera F., et al. Unraveling the web services: An introduction to SOAP, WSDL, and UDDI. IEEE Internet Computing, 6(2), 86-93. IEEE Press. 2002 [3] WSRF Specifications. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf. 2005 [4] Benatallah B., & Dumas M., et al.. Declarative composition and peer-to-peer provisioning of dynamic web services. In Proc. of the Int. Conference on Data Engineering (ICDE), 297-308. IEEE Press. 2002 [5] E. Deelman, J. Blythe, et al. Workflow Management in GriPhyN. The Grid Resource Management, Kluwer, Netherlands, 2003. [6] E. Deelman, J. Blythe, et al. Pegasus: Mapping Scientific Workflow onto the Grid. Across Grids Conference 2004, Nicosia, Cyprus, 2004. [7] J. Yu and R. Buyya. A Novel Architecture for Realizing Grid Workflow using Tuple Spaces. In 5th IEEE/ACM International Workshop on Grid Computing (GRID 2004), Pittsburgh, USA, IEEE Computer Society Press, Los Alamitos, CA, USA, Nov. 8, 2004 [8] E. Deelman, J. Blythe, et al. Mapping Abstract Complex Workflows onto Grid Environments, Journal of Grid Computing, Vol 1, no. 1, pp. 25-39, 2003. [9] J. Cao, S. A. Jarvis, S. Saini, G. R. Nudd. GridFlow: Workflow Management for Grid Computing, Proc. 3rd

IEEE/ACM Int. Symp. on Cluster Computing and the Grid, Tokyo, Japan, pp. 198-205, 2003. [10] Jini Community. http://www.jini.org/ . 2005 [11] A. Pokahr, L. Braubach, and W. Lamersdorf. A Flexible BDI Architecture Supporting Extensibility, The 2005 IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT-2005). [12] Jadex project. http://vsis-www.informatik.uni-hamburg.de/projects/jadex/. 2005 [13] Lei Cao, Minglu Li, Jian Cao: Cost-Driven Web Service Selection using Genetic Algorithm. WINE2005, Hong Kong, China, December 15-17, 2005. LNCS3828: 906-915 [14] Stuart Russell, Peter Norvig, Artificial Intelligence: A Modern Approach (Second Edition), Prentice Hall, 2002 [15] Michael Wooldridge, Introduction to MultiAgent Systems, John Wiley and Sons, 2002

Proceedings of the Fifth International Conference on Grid and Cooperative Computing (GCC'06)0-7695-2694-2/06 $20.00 © 2006