An Agent-based Grid Workflow Management System using AI Planning

An Agent-based Grid Workflow Management System using AI Planning1 Lei Cao, Minglu Li, Jian Cao Department of Computer Science and Engineering, Shanghai Jiao Tong University, Shanghai 20030, China {lcao, li-ml, cao-jian}@cs.sjtu.edu.cn

Abstract Grid computing is becoming a mainstream technology for large-scale distributed resource sharing and system integration. Workflow management is emerging as one of the most important grid services. In this paper, we present an agent-based grid workflow management system (AGWMS) using Artificial intelligence (AI) planning technology. AGWMS has a four-layer architecture. The agent layer makes the system more robust, flexible and intelligent. AI planning technology is utilized in the system. The adapter layer makes it easily that AGWMS invokes external applications.

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. With the advent of grid technologies, scientists and engineers are building more and more complex applications to manage and process large data sets, and execute scientific experiments on distributed grid resources. Means of composing and executing distributed applications to form complex workflow are needed. Some efforts in the research of business workflow and web services orchestration can be reused in grid workflow systems. Grid workflow is “a workflow intended to solve sophisticated scientific problems that occur in highly heterogeneous, distributed, complex, and dynamic Grid environments that comprise of one or more virtual organizations (VOs)”[2]. We develop an adequate grid workflow management system for VOs to help scientists streamline, manage, and monitor their routinely scientific problem solving processes without having to know any details of the underlying

complex structure and dynamic state of VOs. However, there are new challenges needing to be addressed in a typical grid environment: (a) Computational and networking capabilities can vary significantly over time; (b) There is no central ownership and control in grids; (c) The execution of a grid workflow faces many uncertain factors such as unavailability, incomplete information and local policy changes, so a full-ahead plan is not always suitable; (d) The processing of resource discovery and selection could be quite complicated in grids. Workflow and agent technologies are complementary to each other, so we use multiagent technology to meet those challenges. Our AGWMS has a four-layer architecture to make itself more adaptive. The system is distributed improving its execution efficiency. The workflow engines of AGWMS may scatter in many hosts to balance the system’s workload using JINI[3] technology. Our AGWMS also applies AI planning technology to generate the agent plan automatically enhancing its intelligence and robustness. The paper is organized as follows. We discuss related work in Section 2. Section 3 presents the architecture of AGWMS. Section 4 gives some planning definitions and algorithms. Section 5 presents AGWMS’s multi-agent platform. A case study and the implementation of system are given in Section 6. Section 7 gives lessons learned and future work.

2. Related work DAGMan[4] was developed to schedule jobs to Condor system in an order represented by a DAG and to process them. With the integration of Chimera[5], Pegasus[6] maps and executes complex workflow based on full-ahead planning. In Pegasus, a workflow can be generated from metadata description of the desired data product using AI-based planning technologies. The Taverna project[7] has developed a

1 This paper has been supported by the 973 project (No.2002CB312002) of China, grand project of the Science and Technology Commission of Shanghai Municipality (No.03dz15027)

Proceedings of the International Conference on Next Generation Web Services Practices (NWeSP’05)

0-7695-2452-4/05 $20.00 © 2005 IEEE

tool for the composition and enactment of bioinformatics workflow for the life science community. The tool provides a graphical user interface for the composition of workflows. The workflow management system for grid computing, called GridFlow[8], is presented, including services of both global grid workflow management and local grid sub-workflow scheduling. Simulation, execution and monitoring functionalities are provided at the global grid level. McRunjob[9] is a grid workflow manager used to manage the generation of large numbers of production processing jobs in High Energy Physics. It converts core metadata into jobs submitted in a variety of environments. GALE[10] is an HPC workflow vocabulary that uses key grid services to provide a “run code X anywhere, then post process results, then ...” grid-level scripting language for users and problem solving environments. In addition, many efforts on the composition of Web services[11] can also be complementary to the development of grid workflow management systems. Our AGWMS is based on Event-Condition-Action (ECA) rules, which are used to deal with the flexibility of business processed and combine the workflow definition stage and workflow enactment stage. It has two modeling types: full-ahead predefining one, online planning one.

3. The architecture of AGWMS AGWMS Wo r k f l o w Co n s o l e

Wo r k f l o w Mo d e l i n g To o l

Da t a b a s e

Wo r k f l o w En g i n e ( Di s t r i b u t e d )

Mu l t i - Ag e n t

Ad a p t e r Mi d d l e wa r e We b Se r v i c e Gr i d Se r v i c e Ad a p t e r Ad a p t e r Gr i d FTP DCOM Ad a p t e r Ad a p t e r

Pl a t f o r m

Da t a b a s e Ad a p t e r Co mma n d L i n e Ad a p t e r

Us e r

La y e r

Eng i n e La y e r

Age nt

J a v a Cl a s s Ad a p t e r Gl o b u s J o b Ad a p t e r

Ada pt e r

Lay er

Lay er

Gr i d Mi d d l e wa r e ( Gl o b u s )

Re s o u r c e Po o l Re s o u r c e

Re s o u r c e

Re s o u r c e

Re s o u r c e

Figure 1. AGWMS four-layer architecture There are four layers in AGWMS(See Figure 1). 1) User Layer The user layer is the interface between user and system. There are mainly two modules in this layer. Workflow Modeling Tool is used to model the complex grid application, which can be seen as a collection of activities (mostly computational tasks) that are processed in some order. In the system, we have two kinds of modeling tool. The macro-workflow modeling tool is used to model abstract workflow of some application domains. The micro-workflow modeling

tool is used to model the plan of domain-specific agent. Users can submit the preferred workflow model to the system for execution using Workflow Console. It’s also used as the monitoring tool about execution states of the submitted workflow. 2) Engine Layer The engine layer is the core layer to manage workflow execution. Our workflow engine is distributed using JINI technology. The engine is responsible for the instantiating and scheduling of the workflow, and it needs to monitor all activities’ execution. If needed, the engine will interface with other external applications or operators when executing the workflow. We can balance the workload of the engine using JINI technology. It’s adaptive and efficient when there are many coinstantaneous execution requests coming. 3) Agent Layer The agent layer makes it possible that the grid workflow could be divided into two types: abstract one and concrete one. The abstract workflow in specific domain may be stable and unchangeable, and also be called macro-workflow. It may not bind to actual grid resources. All activities in the abstract workflow are encapsulated into agents. There are many domainspecific agents in the multi-agent platform. The agent has its own micro-workflow, which is also called “agent plan”. We can predefine it using microworkflow modeling tool. AI planning technology has been used to create the plan automatically at run time. Section 5 will give the details. 4) Adapter Layer The adapter layer makes it easily that AGWMS invokes external applications. As the proxy for the invokable application, the adapter encapsulates the complex invoking details. Upper functional modules only need to know the interface parameters of the adapter. Doing so makes our system more scalable. An adapter may have multiple input and output ports, through which streams of data tokens flow. Our adapter library allows one to plug different execution models into workflows as reusable adapters, such as Web Service, Grid service, Database operation, DCOM, Java class, Command line, GridFTP, GlobusJob[12] and so on. More application types only need more adapters plugged in.

4. Planning definitions and algorithms We adopt partial-order planning (POP) algorithm in plan agent (PA). Some useful definitions are given[13]: Definition 1: A planning problem can be described as a three-tuple: < S S >, where Gdenotes the initial state of the planner, G denotes the goal state the planning system


0-7695-2452-4/05 $20.00 © 2005 IEEE

should attempt to reach, G is the set of ground actions the planner can perform in attempting to reach a goal state. Definition 2: A state can be represented as a conjunction of positive literals. Definition 3: A goal is a partially specified state, represented as a conjunction of positive ground literals. Definition 4: 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 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: z 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. z 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. z A set of causal links. A causal link between two actions A and B in the plan is written as A ⎯⎯ →B which asserts that p is an effect of the A and a precondition of B. z A set of open preconditions. A precondition is open if it is not achieved by some actions in the plan. Algorithm 1 is used to generate the agent plan. We have modified POP successor function to permit the decomposition method used in the existing abstract workflow, and we can get the final concrete workflow by Algorithm 2. Algorithm 1:

3)

they result in consistent plan. 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.

Algorithm 2: 1)

Select one PA c’ in Aw (the abstract workflow generated by user) and for the most suitable Decomposition (c, d) method from the plan library such that p and c’ unify with substitution ș, we replace c’ with d’=SUBST (ș, d). z 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. z Hook up the ordering constraints for d in the original workflow to the steps in d’. Hook up causal links. If B ⎯⎯ → 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. Continue step 1 until all PAs in the original abstract workflow have been dealt with. Thus we get the last concrete workflow. p

z

2)

p

1)

2)

The initial plan contains Start and Finish, the ordering constraint Start Finish, no casual links, and all the preconditions in Finish are open preconditions. 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: p z The causal link A ⎯⎯ → 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. z 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 links. A p conflict between A ⎯⎯ →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

5. Multi-agent platform used in AGWMS MA- 1

PA- 1

AA- 1

PA- 2

AA- 2

AA- 3

AA- 4

ACL Channel

IA: Information Agent

MA: Merging Agent

PA: Plan Agent

AA: Application Agent

Figure 2. Multi-agent platform structure Currently, there is not much consensus on what an "agent" is, and many definitions abound. We define an agent as a software component that acts autonomously on behalf of a person or organization, and is also able to interact with its environment and with other agents. Agents here should be complex including features: autonomous, communication, self-consistent, goaloriented, and reacting to environment. Other high-level features such as learning, negotiation are also of benefit. All agents in the agent layer are constructed according to Belief-Desire-Intention (BDI) model. There are four kinds of agents in the layer depicted in Figure 2. 1) Plan agent (PA) PA is the main component of abstract workflow, and its capability is always stable and predefined. In some sense, PA takes the role of host of sub-workflow denoted in business workflow domain. PA plan behaves externally as three parts:(1)Goal(Postconditions of the plan);(2)Context(Pre-conditions of the plan);(3)Content(Actions’ sequence of the plan).


0-7695-2452-4/05 $20.00 © 2005 IEEE

I A- 1

To find a suitable plan only means to search in the plan library to get the plan whose context can be meet by the given conditions and goal can contain the required intention. The plans in PA can be built either manually by agent designer or automatically by the planner. The plan in PA has many common components comparing with the generic workflow, such as logical nodes, internal actions (start, finish, delay, evaluate, convert). But external actions, such as invocation 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. We prefer no other plans embedded in PA’s plan. Nested plans will be complicated. So the actions in the plan of PA are all atomic type, and they can be executed directly. The capability of a PA may be represented with the intersection of preconditions and the conjunction of effects of its all plans. {

}

Plans(PA) = plan1 ,plan2 ,...,plann

{

}

Capability(PA)= Preconditions(PA), Effects(PA)

Preconditions(PA) = Preconditions ( plan1 ) ∩ Preconditions ( plan2 ) ∩ ... ∩ Preconditions ( plann ) Effects(PA) = Effects ( plan1 ) ∪ Effects ( plan2 ) ∪ ... ∪ Effects ( plann )

To check whether a PA has the demanded capability means to compare their preconditions and effects. If the two qualifications given below could be fulfilled, the PA will have the demanded capability. (1) P reconditions(P A ) ⊆ P reconditions(given) (2) Effects(P A ) ⊇ E ffects(needed)

Due to above definitions, such decision is loose. The satisfied PA might have no eligible plan to achieve the demanded goal. In the situation, a new plan should be generated automatically and the PA’s capability will be updated and enhanced. 2) Application agent (AA) Each AA corresponds some application adapters from the same domain. Both preconditions and effects of its capability are the conjunctive ones of its all application adapter instances. Some definitions are given below: {

}

{

}

Adapters(AA) = adapter1 ,adapter2 ,... ,adaptern

Capability(AA)= Preconditions(AA), Effects(AA)

Preconditions(AA) = Preconditions ( adapter1 ) ∪ Preconditions ( adapter2 ) ∪ ... ∪ Preconditions ( adaptern )

the definition of Service agent (SAg). SAg is the broker of some grid services or web services. Those services belong to the same type. That means their action effects and preconditions have intersection. When planning, SAg is responsible for binding to the best service, which meets the action requirements of precondition and effect and has the maximum QoS value. 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 AAs in the VO. AAs are chosen preferentially from the same VO when building a plan in order to get better efficiency in time of processing. 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 in a user-defined abstract workflow to get a concrete workflow. Both POP and HTN are utilized by MA. Details are given in Algorithm 2.

6. A case study and the implementation In order to show how the planning technology presented in the paper works, this section introduces a service-based system model for online conference arrangement planning, which needs to integrate services provided by different organizations such as conference organizers, ticket agents and hotels.

6.1. Abstract workflow model We assume several international conferences will be held in Shanghai Jiao Tong University in this year. So the conference organizers want to build an online conference arrangement service for the future attendee. At first step, they build an abstract workflow using the macro-workflow modeling tool: Start

Register_Conference

Book_Ticket

Reserve_Hotel

Fi ni sh

Effects(AA) = Effects ( adapter1 ) ∪ Effects ( adapter2 ) ∪ ... ∪ Effects ( adaptern )

During the generation of a new plan, PA will search for suitable AAs in action library that includes all relevant AAs according to the demanded initial states and goals. The two qualifications are given below: (1) Preconditions(AA) ⊆ Preconditions(given) (2) Effects(AA) ⊇ Effects(needed)

IO parameters of those adapter instances are also stored in AA. According to different application types, AAs have different names: Service agent (SAg), Java Class agent (JCAg), Database agent (DBAg), Command Line agent (CLAg), etc. Here we only give

Figure 3. Abstract workflow model With their experiences, they believe some parameters should be given before invoking the workflow. We call these parameters “Preconditions” (See Table 1). Table 1. Preconditions of Workflow Name

Description

Conf_name Attendee_name Attendee_city Vehicle_type Hotel_level

Conference name Attendee name City attendee lives Vehicle type (Plane, Train, Bus, Ship) Level of hotel


0-7695-2452-4/05 $20.00 © 2005 IEEE

ORDERINGS:{Startٜ S1ٜ S2ٜ Finish }

The organizers also define the requirements of each functional module in the model (See Table 2). Table 2. Requirements of functional modules Module

Precondition

Register_ Conferen ce

Conf_name Attendee_name

Book_Tic ket

Reserve_ Hotel

Source_city Destination_city Start_date Passenger_name Vehicle_type Conf_city Attendee_name Hotel_level Enter_date Leave_date

Effect Conf_starttime Conf_endtime Conf_city Registration_id Vehicle_no Ticket_cost Start_time Arrival_time Booking_id Hotel_name Hotel_address Reservation_id Duration Total_cost

Description Provide conference registration service Book the return ticket from the conference city Reserve the required hotel for attendee

6.2. Present plan agents Three plan agents are assumed in the system. Conference_Registration PA: The conference_Registration PA has only one plan in its plan library. It is CR1.

→S1, LINKS: {Start ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Source_city,Destination_city,Start_date,Time_of_period

Vehicle_no S1 ⎯⎯⎯⎯ → S2, S2 ⎯⎯⎯⎯→ Finish})

Booking_id

Its capability may be represented as below: Capability(Ticket_Booking,PRECOND: Source_cityഊDestination_cityഊ Start_date ഊ Passenger_name,EFFECT: Vehicle_no ഊ Ticket_costഊStart_timeഊArrival_timeഊBooking_id)G

z

Hotel_Reservation PA: We assume that every attendee will reserve a standard room. The Hotel_Reservation PA has one plan HR1. Action(HotelSearch, PRECOND:Conf_cityഊHotel_level, EFFECT:Hotel_nameഊHotel_address) Action(GuestReservation, PRECOND: Hotel_name ഊ Attendee_name ഊ EnterDate ഊ LeaveDate, EFFECT:Reservation_id ഊ Duration ഊ Total_cost) Decompose(Hotel_Reservation, Plan(STEPS:{S1: HotelSearch, S2: GuestReservation } ORDERINGS:{Startٜ S1ٜ S2ٜ Finish } Conf_city,Hotel_level ⎯⎯ ⎯ ⎯ ⎯ ⎯→ S1, Hotel_name S1 ⎯⎯⎯⎯→ S2, Reservation_id,Duration,Total_cost S2 ⎯⎯⎯⎯⎯⎯⎯⎯⎯→ Finish})

LINKS:{Start

z

Action( ConfInquiry, PRECOND:Conf_name, EFFECT:Conf_starttimeഊConf_endtimeഊConf_city) Action( AttendeeRegistration, PRECOND:Conf_nameഊAttendee_name, EFFECT:Registration_idഊConf_schedule) Decompose(Conference_Registration, Plan(STEPS:{S1:ConfInquiry, S2:AttendeeRegistration} ORDERINGS: {Startٜ S1ٜ Finish, Startٜ S2ٜ Finish} LINKS:{ Start

Conf_name ⎯⎯⎯⎯ → S1,

Conf_starttime,Conf_endtime,Conf_city Finish, ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯→ Conf_name,Attendee_name Start ⎯⎯⎯⎯⎯⎯⎯⎯ → S2, Registration_id,Conf_schedule S2 ⎯⎯⎯⎯⎯⎯⎯⎯→ Finish})

S1

Its capability may be represented as below: Capability(Conference_Registration,PRECOND: Conf_name ഊ Attendee_name,EFFECT: Conf_starttime ഊ Conf_endtime ഊ Conf_cityഊRegistration_idഊConf_schedule)

z

Ticket_Booking PA: The Ticket_Booking PA has two plans: TB1, TB2. Definition of TB1 is: Action(TicketQuery1, PRECOND: Source_city ഊ Destination_city ഊ Start_dateഊTime_of_period, EFFECT: Vehicle_noഊTicket_cost ഊStart_timeഊArrival_time) Action(PassengerBooking, PRECOND:Start_date ഊ Vehicle_no ഊ Passenger_name, EFFECT:Booking_id) Decompose(Ticket_Booking, Plan(STEPS:{S1: TicketQuery1, S2: PassengerBooking } ORDERINGS: {Startٜ S1ٜ S2ٜ Finish} LINKS: {Start ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ →S1, Source_city, Destination_city, Start_date, Time_of_period

Vehicle_no S1 ⎯⎯⎯⎯ → S2, S2 ⎯⎯⎯⎯→ Finish})

Booking_id

Definition of TB2 is: Action(TicketQuery2,PRECOND: Source_city ഊ Destination_city ഊ Start_date ഊ Vehicle_type, EFFECT:Vehicle_no ഊ Ticket_cost ഊ Start_time) Action(PassengerBooking, PRECOND:Start_date ഊ Vehicle_no ഊ Passenger_name,EFFECT:Booking_id) Decompose(Ticket_Booking, Plan(STEPS:{S1: TicketQuery2, S2: PassengerBooking }

Its capability may be represented as below: Capability(Hotel_Reservation,PRECOND: Conf_cityഊAttendee_nameഊ Hotel_level ഊ Enter_date ഊ Leave_date,EFFECT: Hotel_name ഊ Hotel_addressഊReservation_idഊDurationഊTotal_cost)G

6.3. Analysis and planning We assume 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 three functional modules, appropriate PAs are selected and matched. z Conference_Registration PA can satisfy the requirements of Register_Conference module, and CR1 plan is selected. z Ticket_Booking PA can satisfy the requirements of Book_Ticket module, but TB1 and TB2 in its plan library are all not befitting. With the new preconditions and effects, a suitable plan TB3 is generated using Algorithm 1: Action(TicketQuery3,PRECOND:Source_city ഊ Destination_city ഊ Start_dateഊVehicle_type, EFFECT:Vehicle_noഊTicket_costഊStart_timeഊArrival_time) Action(PassengerBooking,PRECOND:Start_date ഊ Vehicle_no ഊ Passenger_name,EFFECT:Booking_id) Decompose(Ticket_Booking, Plan(STEPS:{S1: TicketQuery3, S2: PassengerBooking } ORDERINGS:{Startٜ S1ٜ S2ٜ Finish } LINKS:{Start ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ →S1, Source_city,Destination_city,Start_date,Time_of_period

S1

Its capability also holds the line.


0-7695-2452-4/05 $20.00 © 2005 IEEE

Booking_id ⎯⎯⎯⎯→ S2, S2 ⎯⎯⎯⎯ → Finish})

Vehicle_no

z

Hotel_Reservation PA can satisfy the requirements of Reserve_Hotel module, and HR1 plan is selected.

6.4. Final concrete workflow Preconditions: Conf_name Attendee_name Attendee_city Vehicle_type Hotel_level

Conf_Registration PA Ticket_Booking PA

Conf I nqui r y

St ar t

AA

AA

Ti cket Quer y3

Passenger Boo ki ng

AA

At t endeeRegi st r at i on

Hotel_Reservation PA AA

Hot el Sear ch

AA

Guest Reser va t i on

Dat a&Cont r ol Fl ow

A A

Fi ni sh

Logi c node A: And

Effects: Conf_starttime Conf_endtime Conf_city Registration_id Conf_schedule Vehicle_no Ticket_cost Start_time Arrival_time Booking_id Hotel_name Hotel_address Reservation_id Duration Total_cost

Figure 4. Final concrete workflow At last, the final concrete workflow is generated by MA using Algorithm 2. It is depicted in Figure 4. Six AAs in the final workflow: ConfInquiry,AttendeeRegistration,TicketQuery3,Pass engerBooking,HotelSearch,GuestReservation, will all choose the best adapter instance having the maximum QoS value from the candidates, and bind it to run.

6.5. System prototype implementation

(a) Workflow-modeling Tool

(c) Agent-hosting Environment

(b) Web Service Adapter

Figure 5. System prototype A prototype has been developed according to the framework. Figure 5(a) gives a screenshot of the macro-workflow modeling tool. Figure 5(b) shows web service adapter interface. Our multi-agent platform is developed using JADE[14] technology. Figure 5(c) shows the agent-hosting environment. The prototype runs on Windows platform.

middleware increases the scalability of AGWMS. Usage of agent technology makes AGWMS more intelligent. AI planning technology is adopted. Our multi-agent platform makes the system meet challenges from the grid context. In the near future, we plan to go further using AI planning technology in AGWMS and to do a practical performance evaluation to show that our agent-based workflow management system can be efficiently used in the Grid environment. We will also utilize global optimization algorithm in the mapping from abstract workflow to concrete workflow.

8. References [1] I. Foster and C. Kesselman (editors), The Grid Blueprint for a Future Computing Infrastructure, Morgan Kaufmann Publishers, USA, 1999. [2] Soonwook Hwang, Grid workflow-A flexible framework for fault tolerance in the grid, Phd Thesis [3] Jini Community. http://www.jini.org/ [4] Condor Team, The directed acyclic graph manager, http://www.cs.wisc.edu/condor/dagman, 2004 [5] I. Foster, J. Voeckler, M. Wilde, and Y. Zhao,Chimera: A Virtual Data System for Representing, Querying, and Automating Data Derivation, presented at Scientific and Statistical Database Management, 2002 [6] Ewa Deelman, et al., Pegasus : Mapping Scientific Workflows onto the Grid, Across Grids Conference 2004, Nicosia, Cyprus [7] MyGrid Project. http://www.mygrid.org.uk/ [8] J. Cao, S. A. Jarvis, S. Saini, G. R. Nudd. GridFlow: Workflow Management for Grid Computing. In Proceedings of the 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGRID'03), 2003, 198-205 [9] G.E. Graham,D. Evans and I. Bertram: McRunjob :A High Energy Physics Workflow Planner for Grid. Computing in High Energy and Nuclear Physics. California 3(2003) [10] Hugh P. Bivens and Judy I. Beiriger: GALE: Grid Access Language for HPC Environments, Available at ass3186.sandia.gov/ hpbiven. [11] BPEL4WS Specification, http://www106.ibm.com/developerworks/library/ws-bpel/ [12] S. Tuecke, e.a.: Open grid services infrastructure (OGSI) version 1.0. In: Specification of GGF by OGSI-WG. (2003) [13] Stuart Russell, Peter Norvig, Artificial Intelligence: A Modern Approach (Second Edition), Prentice Hall, 2002 [14] JADE project, http://jade.tilab.com/

7. Conclusion and future work This paper has described an agent-based Grid Workflow Management System (AGWMS) using AI planning technology. We give its four-layer architecture and describe its components. The adapter


0-7695-2452-4/05 $20.00 © 2005 IEEE