Workflow Expansion & DBMS Loggingcsce.uark.edu/~cwt/COURSES/2009-08--CSCE-4613--AI/TERM... · Web...

Term Project – Final Report CSCE 4613 Artificial Intelligence – Fall 2009

University of Arkansas – CSCE DepartmentCSCE 4613 Artificial Intelligence – Preliminary Report – Fall 2009

Workflow Expansion & DBMS Logging

Michael Laflamme, Daniel Starling, & Nam Truong

Abstract

The current workflow implementation consists of a monolithic logic architecture. This project contains a few distinct subprojects, namely: rewriting the Prolog decision-making and C++ pathfinding components, design and integration of database logging, and streamlining of the C# code which allows the individual components to communicate. Regarding the Prolog in particular, the goal is to split agent logic into independent agents, all of which concurrently attempt to resolve a problem leading to the conclusion of the workflow.

1. Introduction

1.1 Problem

There is little research regarding the integration of computing with medical workflows and the analytic aid that software can provide in proceeding through a workflow and recording the results. In addition, there is no widely-used method of representing medical workflows, of automating the collection of a record of workflow steps, or of querying and mining past workflow outcomes for events of interest (after action reports).

A medical workflow can be characterized in such a way that it is possible to represent it with a rule-based decision engine (e.g. Prolog) and log the outcome of the operation using a Database Management System (DBMS). By representing and modeling a workflow with Prolog, we can carry out simulated procedures that mimic real life's random circumstances (e.g. varying dose levels for a patient, or patient death) and allow the decision engine to formulate a new path of action based on rules. By logging the activities that take place during the workflow, we can monitor for events as they occur, such as “What percentage of operations required 3 stents?” or “What are some predictors of a bad patient outcome in operation X?”

1.2 Objective

By expanding on past research at the University of Arkansas (UofA), we hope to build a foundation for creating arbitrary medical workflows with exceptional conditions, taking into account different roles, and the ability to query for information from workflows that were carried out in the past.

In more detail, this project is exploring:


- How to break big workflows into much smaller, more modular subtasks

- How to add variation to workflows (randomization)

- How to represent exception and exception handling in workflows

- How to represent different roles and coordinate problem-solving processes to result in a workflow

- How to monitor a workflow for interesting events in progress

- How to log the results of the workflow in an external database

- How to optimize the database to more readily yield useful statistics

- How to add additional workflows

- How to replay workflows logged in the database

1.3 Context

Our project is carried out in the context of Second Life (SL), a 3D virtual world where human participants (known as “avatars”) can create 3D objects and attach logic to them that makes them “smart” and interactive. The workflow project takes place in UofA's area of SL that is dedicated to designing the hospital of the future—one largely reliant on RFID tags to spatially track inventory/items and give them identity.

This environment suggests the notion that “Everything is Alive” (EiA), which is an ongoing UofA project [1]. This is an umbrella idea under which the workflow project falls. In it, we presume that objects have identity, and that many of them can even tell us information about themselves (thanks to a built-in computing capacity). By supposing that pervasive computing already exists, we can assume that many aspects of medical workflows can be carried out under automation, underlining the importance of characterizing these workflows in a way that a computer can understand and remember.

1.4 Potential Impact

At its current stage of development, workflows could be analyzed to optimize equipment, staff, and timing for any implemented operation. If the agents move beyond simply enacting a scene to actively solving problems, then the workflow itself is a tool used in generating optimal solutions where an agent has complete knowledge of past workflows, and can act according in the current workflow based on the interaction of logic and known desirable outcomes. Moving to the realm of science fiction, workflows could be used to control smart entities in the real world. For example, a robot doctor could be continually updated by a workflow that runs many generations of agents susceptible to natural selection, with spider entities bridging the gap between the real and the virtual. In this way, problems in the real world can be solved with precision and speed greater than that of any one person.

Workflows can also be used for educational and entertainment purposes, neither of which are necessarily distinct. Instead of describing an operation to a patient, a doctor can just show the patient the procedure, without the gory details. One or more users can replace digital agents and have specific roles in the workflow, with possible errors and unforeseen situations arising not unlike that of the real world. Finally, workflows can be used just for entertainment's sake. Did you ever want to perform an open heart bypass?


2. Related Work

2.1 Key Technologies

Our project (and the all-encompassing EiA project) is developed within the virtual world known as Second Life. SL differs from other similar games in that it fully supports scripting and object creation/manipulation by players, which gives us the freedom to model currently developing technologies as they might exist within a decade or two (or perhaps even longer). This allows us to focus on researching real-world applications for such technologies before they even come into prevalence.

A primary focus of the EiA project is varying applications for RFID systems, especially in the area of inventory management. This aspect in particular is of interest to our project, as inventory control is inherently connected to workflow efficiency.

By creating virtual workflows such that AI agents can solve them, we are essentially designing the very same thing for real-world applications. If a logic-based program can successfully complete the workflow by following a set of rules (or steps, as one might view them in an actual workflow), then humans should be able to utilize the same process to solve the same problem.

On the broader subject of workflows in general, the Workflow Management Coalition (WfMC) is an organization which oversees the development and standardization of workflows, mainly through a language of their own creation—XPDL—which (according to WfMC) is “the leading process…design format for storing the visual diagram and process syntax of business process models.” [4]

We make extensive use of custom HTTP web services, a byproduct of our integration into other UofA SL hospital projects (e.g. tracking virtual items through RFID) and need to speak with programming-enabled objects inside of Second Life. To carry out workflows in Second Life, we also require a customized pathfinding system to navigate the 3D environment. In fact, expanding on a previous pathfinding project is a peripheral goal of the workflow project for this semester.

Prolog threading capability is crucial to this project as it allows the main Prolog engine to evaluate agent communication concurrently. Similarly, sockets allow for inter-process communication. The SWI C# library (see [5]) allows for the main Prolog process to call C# subroutines directly.

2.2 Related Work

Clark discussed the implementation of multi-agent systems in Qu-Prolog. The Prolog component of this project implements a multi-agent system through the use of multiple threads and multiple processes-- the difference being multiple processes do not share the global database. Clark states that in situations where an agent wishes to send a message without knowing the destination identity, "it is better to use a communications server that routes messages based on content rather than destination identification". That is, the sole form of agent to agent communication in this project is broadcast communication via changes to the global database. To enable the various processes to interact with the threads in the main system, sockets, a form of inter-process communication is used. Lastly, to enable Prolog to C# interaction, a message queue associated with a thread is used.


Because agents in a multi-agent system cannot have knowledge of everything in the system, the system itself or a mechanism in the system must narrow or hide knowledge appropriately. Clark uses a bid arbitration thread to regulate the actions of agents in their auction scenario. In this project, the system regulates the modification of the world state.

There are different approaches to exception handling of workflows, but at the core, exceptions must be triggered, identified, and passed around until a resolution is found. Han and Klein suggest a Java/C++ approach to handling exceptions. First, an individual agent must recognize that something out of the ordinary has occurred during the course of the workflow- “Something is wrong”. This general triggering of an exception must be made more specific for optimal resolution-- that is, the agent must narrow down the exception to a single case - “Something is wrong. The patient has died”. Klein suggests an inheritable approach by traversing an exception tree, where at each node certain characteristics must be met for more specificity of exceptions. The mechanism for dealing with the exception must first suspend the current workflow, and allow for communication between agents. Again, a Java/C++ approach is suggested by passing an exception up the caller-callee tree until some agent has the tools to deal

with the exception. At the top (in this case, the global Prolog database), methods independent of the caller-callee relationship can be implemented.

2.3 Related EiA Projects

Our workflow project relates to several other EiA projects, e.g.;

Mirror Worlds project – Our project could allow us to monitor real-life medical workflows as they are carried out by observing a reflection of them in a virtual environment. We could also replay past workflows in this same manner.

Ontology project – Parts of our project assume that certain supplies are needed to complete the medical operation workflow. This might require associating items with a particular set of workflows, and viewing a workflow as a recipe with a list of ingredients and a set of steps. The information gathered is also crucial to the logic of the agents in the workflow, in that agents can deal with exceptions based not on logic alone, but also on past outcomes.

Smart Devices – In order to avoid burdening medical professionals with error-prone data entries to record the status of a medical workflow (which would preferably happen in real-time), we need devices (wheelchairs, pill bottles, etc.) to recognize when they're being used and report it.

Pathfinding project – Our workflow project will be renovating and expanding on a previous project that allows us to represent a hospital as a model (this model is independent of Second Life, as if we were modeling it after something in real life) and then determine how to get from point A to point B within it. A hospital “hypervisor” program might use this technology to move items around a hospital.


3. Architecture

3.1 Requirements or Use Cases

A pathfinding system that can determine an optimal route for avatarbots to take when acting out a particular medical workflow

◦ Need to use the existing pathfinding system that already accounts for the complexities of avatarbots interacting with Second Life

◦ Must automate the task of importing the Second Life hospital model into our internal representation, and then optimize the algorithm used for pathfinding so that avatarbots can better avoid items.

Avatars (agents) play roles (surgeon, patient, nurse, etc.) in a workflow. Each agent has a set of responsibilities and their own internal model of a workflow. As the workflow proceeds, it must coordinate the agents to “solve the problem” and execute the procedure. Agents must exhibit:

1. Autonomy – The agent has, and resolves its individual tasks. Actions of one agent do not directly affect other agents, but instead through some intermediary--in this case, the Prolog database.

2. Locality – An individual cannot know everything in the system. The system hide information from some agents while giving it to others.

3. Decentralization – The system is not the controlling agent but merely a reflection of actions by agents.

4. Exception handling – Each agent must be able to communicate exceptions and if appropriate deal with the exception specific to his domain.

5. Random behavior – Each agent must have failure probabilities for a chosen number of actions.

6. The C# interface must not have any logic related to agents nor the system, but merely act as a translation unit from the Prolog database to language, SL, DBMS, C++, etc, can understand.

3.2 Architecture or Design Space

Our project consists of primary 3 components and one extra project (a pathfinding component). These components are:

1. At its base, the Prolog component was responsible for housing all agent logic, and the current world state. The primary goal this semester was to split the workflow logic, that is each agent possessing his own logic that was separate and cannot be entirely known by other agents. Two primary sub-components were necessary to achieve a multi-agent system. The first obvious component- agents that can independently interact with other entities, and the second- a system that housed the current world state, dictated communication rules, and interacted with the C# interface.

A first attempt of this goal was thought to be achievable by utilizing the meta-programming capabilities of Prolog-- that is, allowing a system to uniquely process some


request by compiling the relevant logic. For example, given two agents A, B, and a system, communication between the two agents would proceed by first having the system consult the agent that was expected to begin the exchange. In Prolog, this can be achieved by merely using consult/1, or use_module/1,2, the advantages of adding modules instead of full files being the hidden nature of goal execution in modules-- the system can execute the module without having access or knowledge of its logic. Once added to the database, A would process his unique logic and attempt to communicate with B by passing a name and message to the system. The system would recognize the name of B, retract the logic of A, assert the logic of B, and so on.

This approach has problems. First, one could recognize that multiple retractions and assertions are not necessary-- that is, A and B could have separately named methods, ie a_resolve, b_resolve, and the system can call that unique method appropriately without having to worry about functors clashing, however this would necessitate the system breaking atoms apart and concatenating the appropriate prefix or postfix so as to allow the correct functor to be evaluated. At the time, this author thought this action to be undesirable, as the sheer number of functors meant for every agent communication, the system would have to keep track of the source, the destination, and the method, and break apart/ append atoms appropriately. Perhaps in a future project, one could look into achieving this same idea by using the module system. Each agent would only have one globally visible functor, and all communication would have to be routed to this functor, thus lessening the the system's role of atom manipulation.

Because the author choose to keep all agent methods identical-- that is, agents A and B both have the same "resolve" method, then multiple assertions and retractions are necessary. There is a major problem with this approach. Consider communication between A and B. At any time, only the logic of a single agent is allowed to be in the database, thus the system adds A to the database, A processes his logic accordingly and tells the system he needs to talk to B. The system retracts all of A's functor and asserts all of B's functor. The problem then lies in the fact that A is not yet done processing. By calling the system, A is still waiting to evaluate whether the call was true. The system retracts the very functor that A is still in, and replacing that with B's exact named functor, thus producing situations in which A begins execution of his own logic, but ends by mistakenly executing B's logic. One could explore allowing agents not to call the system directly but just assert facts into the database, thus allowing the functor to end, and avoiding the problem outlined above, however, this author decided to go in a different direction once this problem was encountered.

One could avoid the problem of database consistency all together by allowing each agent to maintain his own database-- that is, for every agent, there is a separate Prolog process running. This is achieved by allowing the C# interface to start a process for each individual agent, and a core process for the system. Inter-process communication was achieved through sockets. The system, acting as a server, would accept incoming requests from the agents, where the agent spoke first, identifying himself. Each agent is connected to this server, but not between each other. Every agent is placed into a polling cycle. At the top of the cycle, the agent asks the server for the current state of the world. A very simple world state was implemented for this project, where a state is the last action performed by some agent-- the beginning state is null. The agent takes this state, processes it, and sends appropriate data back to the system.


The system retracts it's current world state and asserts this new state. The new world state then is then polled by some other agent or in some cases the same agent and becomes the catalyst for that agent action.

Because of the concurrent nature of the above mechanism, the system must have multiple threads, each responsible for communication with whichever agent it happened to be assigned. Extensive inter-thread communication was avoided because agent communication was achieved by just modifying the world state. The use of mutual exclusive predicates was also avoided since all Prolog terms can be utilized by multiple threads with no danger of corruption. However, it is probably a good idea to implement mutexes in future project as more complex logic necessitates agents receiving reliable states. For the current project, agent A could query the system while agent B is in the process of modifying the world state, thus receiving either the correct state, the outdated state, or the empty state. Since agents recognize unique states, none of which involve the empty state, a "miss" then in this situation means the agent will just have wasted one cycle-- that is, the agent is a bit too late to realize the new world state. This method will fail when two or more agents respond to the same world state. That is, in situations where A and B can both potentially perform the same action, mutexes must be implemented to ensure that in any race condition, only one agent is successful in achieving the goal.

While race conditions between agents might be sought after and controlled, as it indicates that agents are indeed working concurrently, a race condition between Prolog and the C# interface cannot be allowed to happen. The main form of communication between SWI Prolog and the C# interface is provided through an add-on library. At the start of the workflow, the C# code registers delegates with the main Prolog engine. This allows for the main Prolog system to call unique C# functions without having C# parse a string to determine intent. Because, on the Prolog side, we have multiple threads processing, at any one time two or more threads could attempt to communicate some information with C#. Or, at any one time Prolog could attempt to communicate with the same delegate before it has finished processing . This problem then requires that the Prolog system start up one final "interface" thread, solely responsible for communication with C#. All threads not the "interface" thread must attempt communication with C# by inserting whatever information into a queue that is monitored by the interface thread. Further, C# must open a socket, acting as a server as to allow the main Prolog engine to connect. The sole purpose of this connection is to allow for C# to communicate that delegate operations have finished executing, and that is is safe for Prolog to remove an element from the queue and attempt delegate communication again. This is simply accomplished by having the "interface" thread wait for input from the incoming C# stream.

2. Coordination program (combined effort) – Written in C#. This program integrates the workflow (Prolog) and database components. In particular, this program allows the Prolog program to carry out “actions” in Second Life, and then updates the state of the Prolog program to indicate when these actions have finished. These actions can be recorded in a database for later review. We inherited this program from past work on the workflow project, but will be modifying it to allow for easier creation of new workflows.

3. Pathfinding web service (Daniel Starling) – We already have a powerful C++ web service that is used for pathfinding in Second Life (e.g. moving an avatarbot from a starting position to an operating position at a table), but it does not know about newly added


items to the hospital (e.g. the operating table) and cannot recognize some items that are not of a particular height – so, it will just have the avatarbot walk through them. There is also little documentation for using this service or the associated hospital model viewer that accompanies it. By the end of our project, it will be possible to precisely describe the area and search parameters needed for retrieving a set of waypoints when getting from point A to B in Second Life. It will also be possible to visually review this search space for debugging purposes. Finally, it will be possible to update the model for the hospital (or other area of Second Life) by interacting with an SL object or web service that performs this task (the degree to which this is possible may vary; the format chosen for storing the SL model is not ideal for doing this, as it assumes every SL object can be described as a cube, which is only true of walls – this behavior must be preserved in order to keep the search complex algorithm intact).

4. Database logging (Michael Laflamme) – The significance of these workflows to the model of a hospital environment can be extended by storing the relevant data from each run of a given workflow in a database, such that intelligently-phrased queries can extrapolate useful information (patterns, percentage of error, cost of supplies per operation, etc.). This subproject uses the existing PHP/mySQL framework of the EiA project to store a relational database for the workflow logs. The coordination program (the C# portion) will be modified to insert records as the workflow progresses, with a final commit at workflow end. No rollbacks should ever be necessary or used (because a rollback would wreak havoc on inventory control…and a failed workflow is as statistically significant as a successful one). MySQL Connector/Net (see [6]) provides the required C# to SQL interface. The database is designed to be self-contained, and will reference external databases as necessary (following a format inspired by the schema described in [7]). More specifically, this database currently references the dummy tables patients, staff, and items, which represent entities outside the scope of the workflows themselves. They are designed to demonstrate how the workflow database has been designed to integrate with a future unified database for the entire EiA project, and are included in the schema for completeness. The database will initially contain only records of the catheterization lab workflow, but will be designed in such a way that it can be extended to support new workflows, if desired. Note that all references to SL entities use the CHAR(36) datatype, which is used to store the UUID of the entity in question. The database is stored using InnoDB (for foreign key support), and the schema is as follows:

Table workflowsThis is the main table, containing an index of the workflows, some relevant information, and a reference to the patient on whom the workflow is being performed.

Field Description

idworkflows INT NOT NULL PK auto-inc. ID for workflow records

patient_id CHAR(36) NOT NULL FK ref. eia_patients.uuid

type ENUM(‘cath’,’other’) NOT NULLworkflow type (currently only includes the cath workflow and a generic placeholder, but can easily be expanded)

start DATETIME NOT NULL beginning of workflow


end DATETIME NOT NULL end of workflow

room INT NOT NULLroom of the workflow (this is more for a future version of the hospital…coordinates could be used in the meantime)

outcome ENUM(‘S’,’F’) NOT NULLsuccess if the workflow completed as expected; default is ‘S’ (should only be ‘F’ if there are unhandled exceptions)

Table workersThis table relates hospital staff to any workflows in which they are involved.

Field Description

idworkers INT NOT NULL PK auto-inc. ID for staff/workflow relation

staff_id CHAR(36) NOT NULL FK ref. staff.uuid

workflow_id INT NOT NULL FK ref. workflows.idworkflows

role VARCHAR(45) NOT NULL

role assignment for the given staff in the referenced workflow (could also be an ENUM)…however, if staff always have fixed assignments, regardless of workflow, this field should (eventually) be moved to table staff

desc VARCHAR(45) contains any miscellaneous information

Table equipmentThis table records any equipment (IVs, stent packs, crash cart, wheelchairs, etc.) requested by a worker for a workflow. There is one unimplemented field relating to exception handling.

Field Description

idequipment INT NOT NULL PK auto-inc. ID for item/workflow relation

item_id CHAR(36) NOT NULL FK ref. eia_items.uuid


requested_by INT NOT NULL FK ref. workers.idworkers

desc VARCHAR(45) contains any miscellaneous information

Additional fields (NYI)

exception_id INT FK ref. exceptions.idexceptions; all equipment requests caused by exceptions


should reference the exception in question

Table exceptionsThis table is designed to be as generic as possible, since exceptions and exception handling have not yet been implemented in the workflows. It is modeled to be analogous to exception handling in computing. Additional fields which I considered including, but decided against (for now, since this table is quite speculative) are included at the bottom of the table description.

To illustrate how I see this working in the future, imagine a cath workflow in which a stent is damaged, and a new one is needed. The cardiologist would raise the exception of type ‘equipment_failure’, referencing the equipment.idequipment field corresponding to the damaged stent. The cardiologist would then make a new equipment request for another stent, referencing the idexceptions field of his exception. Once handled (and assuming the workflow can then continue as usual), handled_by is updated to reference the cardiologist, and outcome is set to ‘S’. The record is then inserted into the database.

Field Description

idexceptions INT NOT NULL PK auto-inc. ID for exception/workflow relation


type VARCHAR(45) NOT NULLtype of the exception raised (ENUM is another viable choice—could be ENUM(‘code’,’equipment_failure’, etc.)

desc VARCHAR(45) miscellaneous information

Additional fields (NYI)

raised_by INT FK ref. workers.idworkers

handled_by INTFK ref. workers.idworkers; if multiple workers are involved, use the most senior one

outcome ENUM(‘S’,’F’) NOT NULL success if the workflow can continue; failure if the workflow must halt

equipment_failed INT FK ref. equipment.idequipment

Table prescriptionsThis table relates prescriptions (prescribed during, for, or as a result of the workflow) to the workflow and prescribing worker.

Field Description

idprescriptions INT NOT NULL PK auto-inc. ID for prescription/workflow


relation


prescribed_by INT NOT NULL

FK ref. workers.idworkers (this may need to reference table staff if workflow-related prescriptions are not limited to workers assigned to the workflow)

item_id CHAR(36) NOT NULL FK ref. eia_items.uuid (or a global prescriptions table, if one were to exist)

desc VARCHAR(45) miscellaneous information

Dummy tablesThe following tables are simple skeletons, used to show how the workflow database is designed to integrate with a future overarching EiA database via foreign keys. The tables are prefixed with “eia” to distinguish them from the workflow tables (I couldn’t create a separate database for them, due to the permissions on my account).

Table eia_patientsField Description

uuid CHAR(36) NOT NULL PK UUID of the patient

… ….

Table eia_staffField Description

uuid CHAR(36) NOT NULL PK UUID of the staff member

… …

Table eia_itemsField Description

uuid CHAR(36) NOT NULL PK UUID of the item

… …

3.3 Tasks

Our particular tasks include

Creating new Prolog program(s) for existing/new workflows with the addition of nondeterministic circumstances. Nam Truong handles all aspects of Prolog.


Creating a relational database and modifying the workerbot code to access it as needed. This is Michael Laflamme’s task.

Renovating the pathfinding web service as described earlier. This project is assigned to Daniel Starling. More details can be found in the separate pathfinding final report that was submitted.

3.4 Testing

The pathfinding system can be tested through trial-and-error for the most part. Visualization tools make it easy to locate a pathfinding error (or potential area of error), since we can already use the Second Life client to review that area of the model to see if it was copied over accurately.

Agent logic can be judged based on a successful workflow outcome. Testing is accomplished by querying the system at each stage of the workflow to ensure the agent has come to the right conclusion based on the current system, and updated the system appropriately. The interaction between the C# interface and the Prolog database can simply be tested by checking that the C# variables correspond to the Prolog variables.

The current SWI-Prolog library, which is crucial for multiple-processes to communicate, does not currently work with windows Vista. Therefore, the Prolog component was not integrated with the pathfinding system nor the database, and will not work with any currently implemented workflows. This problem was not understood by Nam and not solved before the end of the semester. Testing then was done solely on the working version with Windows XP, and as mentioned above, correctness was judged based on the messages the C# interface received.

The screen shot below shows multiple processes being instantiated, each representing an agent. The window in the middle shows what the C# interface has received from the main Prolog engine.


The instantiation of the process and the first two steps proceeds as follows:

1. C# acts as a server, opening a socket

2. C# instantiates the main Prolog engine and registers all delegates with this engine.

3. The main Prolog engine connects to the open socket in C#.


4. The main Prolog engine opens up sockets, the minimum being the number of agents in the workflow.

5. The "orderly" agent, running in a separate engine, connects to the main Prolog engine. 6. The "orderly" agent polls the main Prolog engine, and recognizing the current "null"

world state, attempts to modify the state.

7. The agent "nurse1" instantiates (not necessarily in this particular order), connects to the main Prolog engine, polls the system, recognizes the modified state by "orderly", and

attempts to modify the state again.


4. Results and Analysis

A working version of multiple concurrent agents in a workflow environment was not successfully implemented due to unresolved problems with Windows Vista and the SWI sockets library. A "working" solution exists for Windows XP-- that is, a solution that sends the C# interface the correct actions at the appropriate time. Due to lack of a working version for Vista, the Prolog component was not integrated with the pathfinding nor the database component.

Assuming that a future workflow group resolves the library conflict, other questions of the current Prolog implementation must also be raised. First, the polling mechanism is extremely inefficient. For every action performed by an agent, three input/output operations must be performed. A "miss" by an agent, that is the agent does not recognize a world state, means that the agent will not evaluate the state again until he has polled and received the polled data. For every cycle, an agent must waste a single output operation (sends useless data over the stream) to ensure deadlock does not occur between the system and the specific agent. Second, more efficient solutions exists, for example reversing the server-client relationship whereas the agents become the server and the system a client, and using the meta-programming idea, however these solutions appear to lack in one important aspect of the component- concurrency. That is, only one agent can be evaluated the world state at any given instance.

Concerning the DBMS integration, it is difficult to implement a good interaction between the Workerbot code, as it currently exists, and the database, since the workflow still operates procedurally. The chat strings outputted throughout the workflow could be parsed to generate INSERT and UPDATE queries easily enough, but it seems more beneficial to design the framework now, and then modify it as needed to suit the updated (and hopefully randomized) Prolog code (next semester, perhaps). As is, every single run of the workflow would insert the same records to the database (save for the auto-incrementing indices and DATETIME fields). Integrating the DBMS connection with the old Workerbot code (the currently-running version in the lab) was also considered, but that seemed rather counter-productive to the project (especially since most of the integrated code would need to be rewritten to support the randomization). If implemented now, the DBMS code would be in pure C#; however, after the Prolog randomization is completed, I would greatly prefer generating the queries within the Prolog itself, then sending the queries to the C# code with callbacks (via the SWI-Prolog to C# interface). C# functions for interfacing with the database are included in the Deliverables section, below.

5. Conclusions

5.1 Summary

The mechanism for implementing multi-agent concurrent logic was demonstrated but only executes under Windows XP. A solution has not yet been found regarding the dynamic library difficulties of SWI-Prolog and Windows Vista. A more efficient mechanism for achieving a multiple-agent-system might better be achieved through different methods, but consideration must be paid to keeping concurrency.


5.2 Future Work

The author of the Prolog component will continue to explore the question of multiple-agents using Prolog, but without the constraints of Second Life.

Bios

Michael Laflamme – Laflamme is a senior Computer Science major in the Computer Science and Computer Engineering Department at the University of Arkansas. He is experienced with C++, PHP, and mySQL, and will be responsible for creating the workflow database and integrating it with the existing C#/LSL code.

Daniel Starling – Starling is a Computer Science major in the Computer Science and Computer Engineering Department at the University of Arkansas. Experienced in C/C++ programming for the Quake 3D game engine, has held an internship at J.B. Hunt in Business Intelligence (analyzed mainframe job workflows, worked with DBMS software). Daniel is responsible for increasing the flexibility of the current hospital pathfinding system through the introduction of visual tools, more parameters for use with web service queries, and better documentation. Also, he is responsible for help with Second Life interaction.

Nam Truong – Truong is a Computer Science major in the Computer Science and Computer Engineering Department at the University of Arkansas. He has not taken any courses or held any positions relevant to the workflow project. His responsibilities include the design of Prolog agents and the communication between Prolog and the C# interface.

Dr. Fran Hagstrom, Mentor – Hagstrom is Interim Head, Department of Rehabilitation, Human Resources and Communication Disorders; Associate Professor of Communication Disorders. She is the project’s domain expert, responsible for providing detailed medical workflows for our project.

Keith Perkins, Advisor – Perkins is a graduate student in the Computer Science and Computer Engineering Department. He is working as a graduate assistant, doing research in Dr. Craig Thompson's Everything is Alive research project. He joined the project in Spring 2008, and has been focusing on workflow simulation in 3D Virtual Worlds.

Dr. Craig Thompson, Mentor – Thompson is a professor in the Computer Science and Computer Engineering Department. He leads the Everything is Alive research project that is currently focusing on how to simulate pervasive computing using 3D virtual worlds. See http://vw.ddns.uark.edu.

References

[1] Thompson, “Everything is Alive”, January 2004. http://www.csce.uark.edu/~cwt/DOCS/2004-01--PAPER--IEEE-Internet-Computing--Everything-is-Alive.pdf

[2] K.L. Clark, et al, "Multi-threaded communicating agents in Qu-Prolog", www.doc.ic.ac.uk/~klc/auctionsInQuP.pdf. Accessed 12/2009.


[3] Klein, Dellarocas, “A Knowledge-Based Approach to Handling Exceptions in Workflow Systems”, 1999. http://cci.mit.edu/klein/papers/cscw-99.pdf

[4] “Workflow Management Coalition – About Us”, http://www.wfmc.org/about-us.html Accessed 12/2009.

[5] http://www.swi-prolog.org/contrib/CSharp.html

[6] http://dev.mysql.com/downloads/connector/net/6.1.html

[7] http://vw.ddns.uark.edu/sldbaccess/DB_Doc.pdf


Appendix A – Deliverables Manifest

Prolog Component

universe.pl - The main Prolog system holding world states.

anesth.pl - Logic for anesthesiologist agent.

md.pl - Logic for doctor agent.

nurse1.pl - Logic for nurse1 agent.

nurse2.pl - Logic for nurse2 agent.

orderly.pl - Logic for orderly agent

pa.pl - Logic for physician assistant agent.

patient.pl - Logic for patient agent.

Program.cs - The C# interface to Prolog.

In addition, these files are neccessary for Windows XP

SWI-Prolog (http://www.swi-prolog.org/) must be installed

The DLLs for the Prolog-C# interface (http://www.lesta.de/prolog/swiplcs/Generated/Index.aspx) must be placed in the executable directory

The following DLLs from ../pl/bin and /pl/library must be placed in the executable directory

libpl.dll

pthreadVC.dll

socket.dll

socket.pl and dependencies from this

No known working configuration works for Windows Vista

DBMS Component

SQL database at vw.ddns.uark.edu (accessible via phpMyAdmin)

uworkflow///pwf09F&P

DbFramework.cs – basic framework of the database access class, which will be adapted to a future re-write of the main C# and Prolog code (for randomization)

the Mysql.Data.dll file (from Connector/Net) must be installed to enable SQL functionality within C#

Pathfinding deliverables

See pathfinding final report that was submitted separately.

Workflow Expansion & DBMS Loggingcsce.uark.edu/~cwt/COURSES/2009-08--CSCE-4613--AI/TERM... · Web...

Documents

Transcript of Workflow Expansion & DBMS Loggingcsce.uark.edu/~cwt/COURSES/2009-08--CSCE-4613--AI/TERM... · Web...