MOBILE AGENTS FOR GLOBAL MOBILE DEVICE GRID ...

MOBILE AGENTS FOR GLOBAL MOBILE DEVICE GRID INFRASTRUCTURE ENTERPRISES

by

GERARD GOUWS

DISSERTATION

submitted in fulfilment of the requirements for the degree

MASTER OF SCIENCE

in

COMPUTER SCIENCE

in the

FACULTY OF SCIENCE

at the

UNIVERSITY OF JOHANNESBURG

SUPERVISOR: PROF. E.M. EHLERS

CO-SUPERVISOR: MR O.L. OOSTHUIZEN

OCTOBER 2008

Abstract

Keywords: Mobile computing, mobile agents, mobile software development, chess

Grid computing is a technology concerned with harvesting idle resources of geographically

distributed and interconnected computers. It solves problems regarded as too complex or

large to be solved by a single computer. Furthermore, economic grid computing is becoming

the most dominant form of grid computing. It enables some form of payment to occur

between resource producers and resource consumers in grid computing.

Mobile devices and mobile telecommunication services, a relatively new field of technology,

are rapidly increasing in popularity, size, strength and application. At the end of 2006, there

were approximately 2.7 billion global active mobile users utilising mobile devices and mobile

telecommunication services [Aho07]. At the end of 2007 this number had grown to 3.3

billion mobile users, more than half a billion additional mobile users in a period of one year

[McN07].

With such large numbers, grid computing can benefit from the clustering of mobile devices

forming a mobile grid computing model. However, there are many inherent disadvantages

concerning mobile devices, such as low processing capabilities, unpredictable network

connections and battery utilisation. Such hurdles must be addressed and solved if a mobile

computing infrastructure or architecture is ever to be considered.

This dissertation proposes the implementation of an economic mobile computing solution:

Mobile Agents for Global Mobile Device Grid Infrastructure Enterprises, or MAGGIE.

MAGGIE is concerned with harvesting idle mobile device resources by implementing the

supply and demand economic model, aiming to create a healthy competitive economic

market environment.

MAGGIE implements agent and mobile agent technology to compensate for the hurdles

introduced by mobile devices and mobile device software development platforms. It is

targeted at both Sun Microsystems’s J2ME MIDP 2.0 and Microsoft’s .NET Compact

Framework, enabling lower-end and higher-end mobile devices to contribute mobile

computing services and resources for utilisation by other mobile device users.

The primary goal of MAGGIE is to produce an architecture as generic as possible regarding

the development and implementation of MAGGIE services. MAGGIE allows third-party

application developers to seamlessly implement an array of MAGGIE services, without in-

depth prior knowledge of the architecture and technical aspects of MAGGIE.

Finally, MAGGIE’s capabilities are demonstrated by implementing a distributed mobile

chess service known as the MAGGIE Chess Service. The MAGGIE Chess Service enables a

iii

collection of distributed mobile devices in determining the best move originating from a

chessboard position.

iv

Contents

1. Introduction ......................................................................................................................... 1

1.1 Research Theory .......................................................................................................... 2

1.1.1 Grid Computing Architectures ................................................................................ 2

1.1.2 Grid Computing Utilising Mobile Devices ............................................................. 2

1.1.3 Agent and Grid Computing Security ...................................................................... 3

1.1.4 Chess Software Playing Techniques ....................................................................... 3

1.2 Issues Addressed by MAGGIE ................................................................................... 3

1.2.1 Agent-based Mobile Computing Architecture ....................................................... 4

1.2.2 Mobile Device Constraints .................................................................................... 4

1.2.3 Architecture as Generic as Possible ....................................................................... 4

1.2.4 Motivating Participation in MAGGIE ................................................................... 5

1.2.5 Security .................................................................................................................. 5

1.2.6 Distributed Alpha-Beta Pruning Algorithm ........................................................... 5

1.3 The Implementation of MAGGIE ................................................................................. 6

1.4 Published Articles .......................................................................................................... 7

2. Grid Computing Architectures .......................................................................................... 8

2.1 Introduction ................................................................................................................. 8

2.2 Grid Computing Classifications .................................................................................. 8

2.2.1 Computational Grids .............................................................................................. 9

2.2.2 Data Grids .............................................................................................................. 9

2.2.3 Network Grids ........................................................................................................ 9

2.2.4 Multi-purpose Grids ............................................................................................. 10

2.3 Grid Computing Components.................................................................................... 10

2.3.1 Grid Services Requirements ................................................................................ 10

2.3.1.1 Multiple Domains and Autonomy ................................................................. 10

2.3.1.2 Heterogeneity ................................................................................................ 10

2.3.1.3 Scalability ...................................................................................................... 11

2.3.1.4 Adaptability ................................................................................................... 11

2.3.1.5 Quality of Services ........................................................................................ 11

2.3.1.6 Security.......................................................................................................... 11

v

2.3.2 Layered Grid Architecture ................................................................................... 12

2.3.2.1 Fabric Layer .................................................................................................. 12

2.3.2.2 Communication Layer ................................................................................... 13

2.3.2.3 Core Middleware ........................................................................................... 14

2.3.2.4 User Middleware ........................................................................................... 14

2.3.2.5 Applications Layer ........................................................................................ 14

2.3.2.6 Grid Portals ................................................................................................... 14

2.4 Resource Management Architectural Models ........................................................... 14

2.4.1 Hierarchical Model .............................................................................................. 15

2.4.1.1 Hierarchical Model Structure ........................................................................ 15

2.4.1.2 Active Components……………………………………………………….

2.4.2 Economy/Market Model ...................................................................................... 16

2.4.2.1 The Need for Economy/Market Models........................................................ 16

2.4.2.2 Requirements for Economy/Market Model................................................... 17

2.4.2.3 Economy/Market Model Structure ................................................................ 18

2.4.2.4 The Grid Resource Broker ............................................................................ 18

2.4.2.5 The Grid Middleware .................................................................................... 20

2.4.2.6 The Domain Resource Manager .................................................................... 21

2.5 Existing Grid Computing Projects............................................................................... 21

2.5.1 ChinaGrid ............................................................................................................. 21

2.5.2 International Data Grid Project ............................................................................ 22

2.5.3 Globus: A Metacomputing Infrastructure Toolkit ............................................... 23

2.5.4 The Legion Project ............................................................................................... 24

2.6 Conclusion ................................................................................................................... 24

3. Utilising Agent Technology in Grid Computing............................................................. 26

3.1 Introduction ................................................................................................................. 26

3.2 Agent Technologies ..................................................................................................... 26

3.2.1 Agent Definition .................................................................................................. 26

3.2.2 Agent Orientated Software Engineering (AOSE) ................................................ 28

3.2.3 AOSE and Grid Computing ................................................................................. 30

3.2.3.1 Service/Resource Advertisement and Discovery .......................................... 31

3.2.3.2 Negotiations .................................................................................................. 32

vi

3.2.3.3 Performance Management............................................................................. 32

3.2.3.4 Virtual Organisations .................................................................................... 32

3.2.3.5 Security.......................................................................................................... 33

3.2.4 AOSE and Grid Computing Conclusion .............................................................. 33

3.3 Mobile Agent Technologies ........................................................................................ 33

3.3.1 Mobile Agent Definition ...................................................................................... 34

3.3.1.1 Mobile Agent Performance Benefits ............................................................. 34

3.3.1.2 Mobile Agent Software Engineering Benefits .............................................. 35

3.3.2 Mobile Agent Utilisation ..................................................................................... 35

3.3.2.1 Information Retrieval Applications ............................................................... 35

3.3.2.2 Telecommunications ..................................................................................... 36

3.3.2.3 Mobile Devices ............................................................................................. 37

3.3.3 Mobile Agent Technology and Grid Computing ................................................. 37

3.3.3.1 Enhanced Negotiations .................................................................................. 38

3.3.3.2 Grid Monitoring ............................................................................................ 38

3.3.3.3 Service/Resource Discovery .......................................................................... 38

3.4 Conclusion ...................................................................................................................... 38

4. Mobile Grid Computing ................................................................................................... 40

4.1 Introduction ................................................................................................................. 40

4.2 Mobile Devices in Grid Computing ............................................................................ 40

4.2.1 Mobile Device Constraints .................................................................................. 41

4.2.1.1 Resource Poor ............................................................................................... 41

4.2.1.2 Inherently Hazardous .................................................................................... 41

4.2.1.3 Network Connectivity ................................................................................... 42

4.2.1.4 Battery Power ................................................................................................ 42

4.2.1.5 Operating System Constraints ....................................................................... 43

4.2.2 Motivation for Mobile Devices in Grid Computing ............................................ 43

4.3 Mobile Agents in Mobile Devices ............................................................................... 44

4.3.1 Network Load ...................................................................................................... 44

4.3.2 Flexibility ............................................................................................................. 44

4.3.3 Fault-tolerance mechanism .................................................................................. 45

4.4 Mobile Device Software Development Technologies ................................................. 45

vii

4.4.1 Java Micro-Edition Platform 2 (J2ME) ............................................................... 45

4.4.1.1 Configurations ............................................................................................... 46

4.4.1.2 Profiles .......................................................................................................... 48

4.4.1.3 Mobile Information Device Profile (MIDP) ................................................. 49

4.4.2 .NET CF – The .NET Compact Framework ........................................................ 50

4.5 Code Mobility in Mobile Devices ............................................................................... 51

4.5.1 Executing Local Mobile Agents .......................................................................... 51

4.5.1.1 Introducing Code Mobility into J2ME .......................................................... 51

4.5.1.2 Introducing Code Mobility into the .NET Compact Framework .................. 52

4.5.1.3 XML and Web Services ................................................................................ 52

4.5.2 Executing Remote Mobile Agents ....................................................................... 53

4.5.2.1 The JADE Architecture ................................................................................. 53

4.5.2.2 The Jini Architecture ..................................................................................... 54

4.6 Conclusion ................................................................................................................... 55

5. Mobile Agent and Mobile Device Security ...................................................................... 56

5.1 Introduction .................................................................................................................. 56

5.2 Mobile Agent Security ................................................................................................ 56

5.2.1 Mobile Agent Security Issues .............................................................................. 57

5.2.1.1 Mobile Agent Threats.................................................................................... 57

a) External Threats................................................................................................. 57

b) Malicious Mobile Agent Threats....................................................................... 57

c) Malicious Host Threats...................................................................................... 58

5.2.1.2 Mobile Agent Host Threats ........................................................................... 59

a) Malicious Mobile Agent Threats ....................................................................... 59

b) Malicious Mobile Agent Hosts

5.2.2 Mobile Agent Technology Security Techniques ................................................. 60

5.2.2.1 Mobile Agent Security Techniques ............................................................... 60

a) Code Obfuscation .............................................................................................. 60

b) Sliding Encryption ............................................................................................ 61

c) Environmental Key Generation ......................................................................... 61

d) Encrypted Function ........................................................................................... 62

e) State Appraisal Functions .................................................................................. 62

viii

f) Mobile Agent Integrity ...................................................................................... 62

5.2.2.2 Mobile Agent Host Platform Security Techniques ....................................... 62

a) Authentication Credentials ................................................................................ 62

b) Sandboxing ........................................................................................................ 63

c) Proof-carrying Code .......................................................................................... 63

d) Path Histories ..................................................................................................... 64

e) State Appraisal................................................................................................... 65

5.3 Mobile Technology Security Issues ............................................................................ 65

5.3.1 J2ME MIDP 2.0 Security ..................................................................................... 65

5.3.1.1 Protection Domains ....................................................................................... 66

5.3.1.2 Permissions and Security Policies ................................................................. 66

5.3.1.3 Secure Communications ................................................................................ 67

5.3.1.4 Secondary Storage ......................................................................................... 68

5.3.1.5 Security and Trust Services API ................................................................... 68

5.3.1.6 Signed Applications ...................................................................................... 69

5.3.2 Microsoft .NET CF Security ................................................................................ 70

5.4 Conclusion ................................................................................................................... 71

6. Computer Chess-playing Techniques .............................................................................. 72

6.1 Introduction ................................................................................................................. 72

6.2 Game Tree Search Algorithms ..................................................................................... 72

6.2.1 Minimax Algorithm ............................................................................................. 73

6.2.2 SSS* Algorithm ................................................................................................... 75

6.2.3 Alpha-Beta Pruning Algorithm ............................................................................ 76

6.3 Alpha-Beta Enhancements .......................................................................................... 78

6.3.1 Aspiration Windows ............................................................................................ 78

6.3.2 Minimal Search Windows.................................................................................... 79

6.3.3 Move Ordering ..................................................................................................... 81

6.3.3.1 Killer Heuristics ............................................................................................ 81

6.3.3.2 Transposition Tables ..................................................................................... 81

6.3.4 Selective Searching .............................................................................................. 83

6.3.5 Combinations ....................................................................................................... 85

6.4 Chess Evaluation Functions ........................................................................................ 85

ix

6.4.1 General Chess Fundamentals ............................................................................... 86

6.4.2 The Evaluation Function ...................................................................................... 87

6.4.2.1 Material Balance ........................................................................................... 88

6.4.2.2 Positional and Strategic Aspects ................................................................... 88

6.5 Conclusion ................................................................................................................... 90

7. Mobile Agents for the Global Mobile Device Grid Infrastructure Enterprises

(MAGGIE) Architecture ...................................................................................................... 91

7.1 Introduction .................................................................................................................. 91

7.2 MAGGIE Goals ............................................................................................................ 92

7.3 MAGGIE Architecture Breakdown ............................................................................. 92

7.3.1 Installation Subsystem ......................................................................................... 93

7.3.1.1 The User Agent ............................................................................................. 93

7.3.1.2 The Installation Web Server .......................................................................... 93

7.3.2 The MAGGIE Storage Point ................................................................................ 94

7.3.3 Single Client/Virtual Organisation Representation components ....................... 95

7.3.3.1 The Client Agent ........................................................................................... 95

7.3.3.2 Single Client Representation ......................................................................... 96

7.3.3.3 Virtual Organisation Representation ............................................................. 97

7.3.4 Service Registration and Discovery Subsystem .................................................. 98

7.3.4.1 The Broker Agent .......................................................................................... 98

7.3.4.2 The Sub-Broker Agent .................................................................................. 99

7.3.5 Service Negotiation Subsystem ........................................................................... 99

7.3.5.1 The Trade Negotiator Agent ....................................................................... 100

7.3.5.2 The Trade Server ......................................................................................... 101

7.3.5.3 Economic Models ........................................................................................ 101

7.3.6 Work Deployment Subsystem ........................................................................... 101

7.3.6.1 The Job Handler Agent ............................................................................... 102

7.3.6.2 The Worker Agent ....................................................................................... 102

7.4 Conclusion ................................................................................................................. 103

8. Service Implementation and 2egotiation Mechanisms................................................ 104

8.1 Introduction ............................................................................................................... 104

8.2 MAGGIE Service Implementation ............................................................................ 104

x

8.2.1 Service Logic Implementation ........................................................................... 105

8.2.1.1 Interface class

8.2.1.2 The ServiceUnit Interface............................................................................. 106

8.2.2 Service Initialisation .......................................................................................... 107

8.2.3 Service Publication ............................................................................................ 107

8.2.4 The Sum Service Problem Example .................................................................. 108

8.2.4.1 Generating and Submitting Tasks ............................................................... 108

8.2.4.2 Processing a Task ........................................................................................ 109

8.2.4.3 Retrieving and Processing Results .............................................................. 110

8.3 MAGGIE Negotiations Implementation ................................................................... 112

8.3.1 The Supply and Demand Economic Model ....................................................... 112

8.3.2 The Supply and Demand Negotiation Variables ............................................... 113

8.3.3 Consumer Negotiation Variables ....................................................................... 114

8.3.3.1 Consumer Negotiation Variables ................................................................ 115

8.3.3.2 Developer Negotiation Variables ................................................................ 116

8.3.4 MAGGIE Supply and Demand Algorithm ........................................................ 117

8.4 Conclusion ................................................................................................................. 119

9. Agent Execution Plans .................................................................................................... 121

9.1 Introduction ............................................................................................................... 121

9.2 Agent-aiding Components ......................................................................................... 121

9.2.1 Client Agent Reservation Entries....................................................................... 121

9.2.2 Worker Agent Storage ....................................................................................... 122

9.3 Trade Negotiator Agent ............................................................................................. 123

9.3.1 Trade Negotiator Agent Initialisation ................................................................ 124

9.3.2 Trade Negotiator Agent Execution Plan ............................................................ 124

9.3.3 Negotiation Approval......................................................................................... 125

9.4 Job Handler Agent ..................................................................................................... 126

9.4.1 Job Handler Agent Initialisation ........................................................................ 127

9.4.2 Job Handler Agent Execution Plan .................................................................... 127

9.4.3 Collecting Processed Results ............................................................................. 129

9.5 Worker Agent ............................................................................................................ 129

9.5.1 Worker Agent Initialisation ............................................................................... 130

xi

9.5.2 Worker Agent Execution Plan .......................................................................... 130

9.5.3 Worker Agent Migration to Mobile Devices .................................................... 132

9.6 User Agent ................................................................................................................ 133

9.7 MAGGIE Security .................................................................................................... 136

9.7.1 Rijndael Encryption Algorithm ......................................................................... 136

9.7.2 MAGGIE Mobile Host Protection .................................................................... 137

9.7.3 MAGGIE Mobile Agent Protection .................................................................. 137

9.7.4 Rogue Mobile Devices ...................................................................................... 138

9.7.5 Single Sign-on Mechanism ............................................................................... 138

9.8 Conclusion ................................................................................................................ 139

10. MAGGIE Chess Service Implementation ................................................................... 141

10.1 Introduction ............................................................................................................. 141

10.2 Algorithm Selection................................................................................................. 141

10.3 Distributed Alpha-Beta Pruning Algorithms in MAGGIE ...................................... 142

10.3.1 Normal Pruning Algorithm .............................................................................. 143

10.3.2 Enhanced Pruning Algorithm .......................................................................... 144

10.3.3 EPA Advantages and Disadvantages ............................................................... 145

10.4 Determining Developer Negotiation Variables ....................................................... 146

10.4.1 Size Prediction of a Chess Alpha-Beta Tree .................................................... 146

10.4.1.1 Chess Alpha-Beta Prediction Problems .................................................... 147

10.4.1.2 The Prediction Formula ............................................................................. 147

10.4.1.3 The Adaptive Prediction Formula ............................................................. 148

10.4.1.4 Single Side Expansion Factor ................................................................... 149

10.4.1.5 Double Side Expansion Factor .................................................................. 149

10.4.2 The Superior Approach

10.4.2.1 Calculating the Developer Negotiations ................................................... 153

10.4.2.2 Fault-tolerance Mechanisms ..................................................................... 154

10.5 Conclusion ............................................................................................................... 154

11. MAGGIE Prototype and Implementation .................................................................. 156

11.1 Introduction ............................................................................................................. 156

11.2 Technology Utilisation ............................................................................................ 156

xii

11.2.1 Implementation of MAGGIE Broker Domains ............................................... 156

11.2.2 Implementation of MAGGIE Mobile Device Software................................... 157

11.3 MAGGIE Device Implementations ......................................................................... 158

11.3.1 Economic Model Implementation.................................................................... 158

11.3.2 Negotiations ..................................................................................................... 158

11.3.3 Running Maggie Services ................................................................................ 160

11.3.4 Submitting Jobs ................................................................................................ 160

11.4 Notable MAGGIE characteristics............................................................................ 160

11.4.1 Simple Service Implementation ........................................................................ 160

11.4.2 Ease of Use ...................................................................................................... 162

11.4.3 Optimised for Mobile Devices ......................................................................... 162

11.4.4 Semi-heterogeneous Grid Computing Solution ............................................... 163

11.5 MAGGIE Usage Example ...................................................................................... 164

11.5.1 MAGGIE Chess Service Initialisation ............................................................. 164

11.5.2 MAGGIE Task Data Submission..................................................................... 165

11.5.3 Tracking Submitted Consumer Tasks .............................................................. 167

11.5.4 Processing the Submitted Task Fragments ...................................................... 167

11.6 Conclusion ............................................................................................................... 170

12. Conclusion and Future Research ................................................................................. 171

12.1 Introduction ............................................................................................................. 171

12.2 MAGGIE Objectives Reached ................................................................................ 171

12.2.1 Optimised Mobile Device Support ................................................................. 172

12.2.2 Generic Mobile Grid Computing Environment .............................................. 174

12.2.3 Efficient Negotiation Mechanisms ................................................................. 174

12.2.4 Well-defined architecture ................................................................................ 175

12.2.5 Implementation of the MAGGIE Chess Service. ........................................... 175

12.2.6 Implementation of Security Mechanisms ....................................................... 176

12.2.7 Semi-heterogeneous Grid Computing Behaviour ........................................... 176

12.2.8 Ease of Use ..................................................................................................... 177

12.3 Benchmarking......................................................................................................... 177

12.3.1 Mobile OGSI .NET .......................................................................................... 177

12.3.2 Globus Infrastructure Toolkit ......................................................................... 178

xiii

12.3.3 The ChessBrain II Project ............................................................................... 179

12.4 Future Research Work ............................................................................................. 180

12.4.1 Heterogeneous Grid Computing ...................................................................... 180

12.4.2 Integration with Existing Grid Computing Projects ........................................ 180

12.4.3 Custom Scheduling and Negotiation Components .......................................... 181

12.4.4 Support for True Mobile Code ......................................................................... 182

12.4.5 Implementing Semantic Meaning .................................................................... 182

12.4.6 Additional Economic Models .......................................................................... 182

12.5 Final Conclusion ...................................................................................................... 182

References ............................................................................................................................ 184

Appendix A .......................................................................................................................... 198

A.1 Introduction ............................................................................................................. 198

A.2 Analysis Data ........................................................................................................... 198

A.3 Generation of Analysis Data .................................................................................... 199

A.4 Depth 4 Analysis Data ............................................................................................. 200



Appendix B .......................................................................................................................... 232

B.1 Introduction ............................................................................................................. 232

B.2 Published Article ..................................................................................................... 232

xiv

List of Figures

Figure 2.1: Layered grid computing architecture ................................................................. 13

Figure 2.2: Generic economy/market model structure ......................................................... 19

Figure 3.1: Classification of autonomous agents ................................................................. 27

Figure 3.2: Canonical view of a complex multi-agent system. ............................................. 30

Figure 3.3: A4 model hierarchy. ........................................................................................... 31

Figure 3.4: Mobile agent implementation on mobile devices .............................................. 37

Figure 4.1: Subset functionality libraries of CDC and CLDC ............................................. 47

Figure 4.2: J2ME architecture .............................................................................................. 48

Figure 4.3: .NET Compact Framework architecture

Figure 4.4: Remote agent implementation over mobile devices .......................................... 53

Figure 5.1: Multiple security threats targeted at mobile agents ........................................... 58

Figure 5.2: Steps of proof-carrying code ............................................................................. 64

Figure 5.3: MIDP 2.0 application deployment cycle ........................................................... 69

Figure 6.1: Possible tic-tac-toe positions originating from one position .............................. 73

Figure 6.2: Minimax representation of Figure 6.1 ................................................................ 73

Figure 6.3: Minimax search algorithm ................................................................................. 74

Figure 6.4: Alpha-Beta algorithm ........................................................................................ 76

Figure 6.5: Alpha-Beta algorithm pruning capabilities ........................................................ 77

Figure 6.6: Aspiration search algorithm ............................................................................... 79

Figure 6.7: Minimal window search algorithm .................................................................... 79

Figure 6.8: Transposition table implementation algorithm .................................................. 81

Figure 6.9: Horizon effect .................................................................................................... 82

Figure 6.10: Nuchess vs. Cray Blitz, white to move ............................................................... 84

Figure 6.11: Nuchess vs. Cray Blitz, black to move ............................................................... 84

Figure 6.12: Cray Blitz’s victory at the 15th

ACM NACCC ................................................... 84

Figure 7.1: Unified Modelling Language (UML) deployment diagram of the IWS............. 92

Figure 7.2: UML class diagram of entity representations in MAGGIE ................................ 93

Figure 7.3: UML deployment diagram of MAGGIE’s hierarchical structure ...................... 96

Figure 7.4: UML class diagram of MAGGIE service negotiation subsystem ...................... 98

Figure 7.5: UML class diagram of work deployment subsystem ......................................... 99

Figure 8.1: Layered architecture of MAGGIE grid services .............................................. 103

Figure 8.2: Sum Service task generation algorithm ............................................................ 107

Figure 8.3: Sum Service processing task fragments algorithm .......................................... 108

Figure 8.4: Algorithm for processing retrieved results, regarding Sum Service

Figure 8.5: Sum Service .NET CF and J2ME MIDP 2.0 GUI implementations

Figure 8.6: Price equilibrium graph of MAGGIE ............................................................... 111

xv

Figure 8.7: Implementation of developer negotiation variables ........................................ 116

Figure 8.8: Supply and demand economic model negotiation algorithm .......................... 116

Figure 9.1: UML class diagram of Trade Negotiator Agent .............................................. 121

Figure 9.2: UML class diagram of Job Handler Agent ..................................................... 127

Figure 9.3: UML class diagram of Worker Agent ............................................................. 127

Figure 9.4: UML activity diagram of Worker Agent execution plan ................................. 130

Figure 9.5: UML class diagram of User Agent .................................................................. 132

Figure 9.6: UML activity diagram of Worker Agent dispatching onto a User Agent ....... 133

Figure 9.7: MAGGIE symmetric key distribution ............................................................. 137

Figure 10.1: Normal pruning algorithm graph .................................................................... 141

Figure 10.2: Effects of EPA on a game tree ........................................................................ 144

Figure 10.3: SSP vs. SSAP vs. DSP vs. DSAP at depth 4 .................................................. 150



Figure 11.1: Technologies applied in MAGGIE prototype ................................................. 156

Figure 11.2: GUI implementation of supply and demand model negotiation variables ..... 157

Figure 11.3: Detailed negotiation form depicting negotiation details of submitted jobs .... 158

Figure 11.4: Form depicting MAGGIE-specific grid service information ......................... 159

Figure 11.5: Form depicting negotiation values of a job to be submitted ........................... 159

Figure 11.6: Functionality distribution over main components of MAGGIE ..................... 161

Figure 11.7: Identical source code executing in .NET Framework (left) and.NET CF (right)

........................................................................................................................................... 162

Figure 11.8: MAGGIE Chess Service initialisation ............................................................ 164

Figure 11.9: Submission of MAGGIE Chess Service data ................................................. 165

Figure 11.10: Keeping track of MAGGIE submitted negotiations ....................................... 166

Figure 11.11: Final data assessment of submitted task fragments ........................................ 168

Figure A.1: Custom chess tool application utilised for data generation. ........................... 198

xvi

List of Tables

Table 10.1: Accuracy analysis of SSP, SSAP, DSP and DSAP ........................................... 149

Table A.1 ............................................................................................................................... 199

Table A.2 ............................................................................................................................... 200

Table A.3 ............................................................................................................................... 202

Table A.4 ............................................................................................................................... 204

Table A.5 ............................................................................................................................... 205

Table A.6 ............................................................................................................................... 207

Table A.7 ............................................................................................................................... 209

Table A.8 ............................................................................................................................... 211

Table A.9 ............................................................................................................................... 213

Table A.10 ............................................................................................................................. 215

Table A.11 ............................................................................................................................. 216

Table A.12 ............................................................................................................................. 219

Table A.13 ............................................................................................................................. 220

Table A.14 ............................................................................................................................. 221

Table A.15 ............................................................................................................................. 222

Table A.16 ............................................................................................................................. 224

Table A.17 ............................................................................................................................. 225

Table A.18 ............................................................................................................................. 229

List of Acronyms and Abbreviations

.NET CF: .Net Compact Framework

A4 Model: Agile Architecture and Autonomous Agents Model

ACL: Agent Communication Language

ACM: Association of Computing Machinery

ADSL: Asymmetric Digital Subscriber Line

AES: Asymmetric Encryption Standard

AOSE: Agent Orientated Software Engineering

APF: Adaptive Prediction Formulae

API: Application Programming Interfaces

CA: Certificate Author

CAD: Computer-aided Design

CDC: Connected Device Configuration

CERN: European Organisation for Nuclear Research

CERNET: China Education and Research Network

CFD: Computational Fluid Dynamics

CLDC: Connected Limited Device Configuration

CMIP: Common Management Information Protocol

CPU: Central Processing Unit

DES: Digital Encryption Standard

DNS: Domain Name Server

DoS: Denial of Service

DSAP: Double Side Adaptive Prediction

DSE: Double Side Expansion Factor

DSP: Double Side Prediction

EPA: Enhanced Pruning Algorithm

FIFO: First-In, First-Out

FIPA: Foundation for Intelligent Physical Agents

FP: Foundation Profile

GAP: Maggie Storage Point

GB: Gigabyte

GPRS: General Packet Radio Services

GSI: Grid Services Information

GSM: Global System for Mobile Communications

GUI: Graphical User Interface

HEP: High Energy Physics

HTTP: Hyper Text Transfer Protocol

HTTPS: Hyper Text Transfer Protocol over Secure Socket Layer

IBM: International Business Machines

IDE: Integrated Development Environment

IMP: Information Module Profile

ISDN: Integrated Services Digital Network

ISO: International Standards Organisation

IWS: Installation Web Server

J2EE: Java 2 Platform, Enterprise Edition

J2ME: Java Micro-Edition Platform 2

J2SE: Java 2 Platform, Standard Edition

JADE: Java Agent Development Environment

xviii

JAXP: Java API for XML Processing and Parsing

JAX-RPC: Java API for XML-based Remote Procedure Calling

JSR: Java Specification Request

JVM: Java Virtual Machine

KB: Kilobyte

LAN: Local Area Network

LDAP: Lightweight Directory Access Protocol

LEAP: Lightweight Extensible Agent Platform

LGPL: Less General Public License

MAGGIE: Mobile Agents for Global Mobile Device Grid Infrastructure Enterprises

MB: Megabyte

MDP: Massive Data Processing

MDS: Metacomputing Directory Services

MIDP: Mobile Information Device Profile

MHz: Megahertz

MSIL: Microsoft Intermediate Language

NACCC: North America Computer Chess Championship

NIST: US National Institute of Standards and Technology

NPA: Normal Pruning Algorithm

OGSA: Open Grid Services Architecture

OGSI: Open Grid Services Infrastructure

OOP: Object Orientated Programming

OTA: Over-The-Air

Palm OS: Palm Operating System

PBP: Personal Basis Profile

PDA: Personal Digital Assistant

PF: Prediction Formulae

PIN: Personal Identification Number

PKI: Public Key Infrastructure

PP: Personal Profile

QoS: Quality of Service

RAM: Random Access Memory

RC: Real Count

RMS: Record Management Store

ROM: Read Only Memory

SATSA: Security and Trust Services API

SATSA-APDU: SATSA-Application Protocol Data Unit

SATSA-JCRMI: SATSA-Java Card Remote Method Invocation

SATSA-PKI: SATSA-Public Key Infrastructure

SETI: Search for Extra Terrestrial Intelligence

SHA1: Secure Hash Algorithm 1

SNMP: Simple Network Management Protocol

SOAP: Simple Object Access Protocol

SOMA: Secure and Open Mobile Agent

SQL: Structured Query Language

SSAP: Single Side Adaptive Prediction

SSE: Single Side Expansion Factor

SSL: Secure Socket Layer

SSP: Single Side Prediction

SSS*: State Space Search

xix

TCP: Transmission Control Protocol

TCP/IP: Transmission Control Protocol with Internet Protocol

TLS: Transport Layer Security

TMCE: Tools and Methods for Competitive Engineering

UML: Unified Modelling Language

URL: Uniform Resource Locator

VO: Virtual Organisation

VOIP: Voice Over IP

WAN: Wide Area Network

WAP: Wireless Application Protocol

WAP TLS: Wireless Application Protocol TLS

Windows CE: Windows Embedded Component

WTLS: Wireless Transport Layer Security

WWW: World Wide Web

XML: Extensible Mark-up Language

Chapter 1

Introduction

“A journey of a thousand miles begins with a single step.”

- Confucius

Grid computing is a technology that harvests the idle resources of geographically distributed,

interconnected computers to solve a problem that is regarded as too complex or large for a

single computer [Buy00]. With the ever-increasing popularity of computers and the Internet,

grid computing is becoming a feasible, easy and cost-effective solution and implementation

platform for exactly such problems. Furthermore, economic grid computing enables some

form of payment to occur between resource producers and resource consumers in grid

computing [Buy00].

Mobile devices and mobile telecommunication services, a relatively new field of technology,

are rapidly increasing in popularity, size, strength and application. At the end of 2006, there

were approximately 2.7 billion global active mobile users utilising mobile devices and mobile

telecommunication services. During 2006, approximately 1 billion new mobile devices were

sold [Aho07]. During 2007, these numbers had grown to 3.3 billion global active mobile

users and 1.1 billion new mobile devices sold, indicating a healthy and prosperous future for

the mobile device market [Cit08, McN07].

Grid computing can benefit from the clustering of mobile devices to form a mobile grid

computing model, either as a stand-alone system or as an integration of personal computers,

micro-computers, supercomputers and mainframes. With such a large number of grid

computing nodes, software applications regarded as too complex and large for a single

mobile device may be executed with the aid of a group of mobile devices, contributing

resources to solve complex problems.

However, there are many inherent disadvantages associated with mobile devices, such as low

processing capabilities, unpredictable network connections and battery utilisation [Pha02].

These inherent disadvantages are indeed hurdles that must be addressed and solved if a

mobile grid computing infrastructure or architecture is ever to be considered.

Furthermore, an architecture that adheres to the goals described above must allow for the

support of various grid computing services. Such services may include:

2

• Protein folding in biology.

• Particle physics.

• Games.

• Image processing.

• Financial data processing.

To allow for the realisation of such a model, a number of concepts must be taken into

consideration. The key concepts defined above are described briefly in the following section

and are considered as part of the research theory of this dissertation.

1.1 Research Theory

The research theory background in this dissertation is described below.

1.1.1 Grid Computing Architectures

The core of such a model described above can be defined as a grid computing model or some

form of this model. Thus a clear understanding must be obtained of exactly what grid

computing entails and the different grid computing paradigms that exist. Chapter 2 defines

grid computing and discusses the general architectures of grid computing that currently exist.

Chapter 3 provides an abstract overview of agent technology and how agents can solve many

of the obstacles presented in both grid computing and mobile grid computing environments.

1.1.2 Grid Computing Utilising Mobile Devices

As discussed previously, mobile devices have many inherent disadvantages that introduce

obstacles in the context of creating a mobile device grid computing architecture. Chapter 4

provides a collection of arguments that support the use of mobile devices in future grid

computing implementations. It also provides an in-depth overview of the two most popular

mobile device software development platforms, namely Sun Microsystems’s Java Micro-

Edition Platform 2 (J2ME) and Microsoft’s .NET Compact Framework (.NET CF).

3

1.1.3 Agent and Grid Computing Security

For any system to be considered as a practical solution, security mechanisms must be

implemented in the proposed mobile grid computing architecture. To identify security threats,

a clear understanding must be obtained of what security threats exist with regard to:

• Agents.

• Mobile agents.

• Mobile agent execution platforms.

• Mobile device software development platforms.

Chapter 5 discusses the existing security risks and provides solutions or partial solutions to

such security threats.

1.1.4 Chess Software Playing Techniques

In order to demonstrate that a mobile grid computing architecture can yield satisfactory

results, an application is required to show that a computationally expensive software

application can be successfully divided into smaller fragments and distributed over mobile

devices for processing. For this reason, chess was chosen. Chess software that produces a

fairly strong level of play is regarded as extremely computationally expensive. Chapter 6

discusses popular algorithms utilised for playing chess, as well as their advantages and

disadvantages. It continues to explain mechanisms that aid search algorithms, and finally

discusses typical knowledge embedded in chess software.

The previous subsections dealt with the relevant research theory and background of this

dissertation. The following section covers the issues and problems addressed by the

dissertation.

1.2 Issues Addressed by MAGGIE

Mobile Agents for Global Mobile Device Grid Infrastructure Enterprises, or MAGGIE, can

be described as an economic mobile grid computing platform, enabling mobile device owners

to sell and purchase the utilisation of mobile device resources.

4

The proposed MAGGIE architecture addresses several issues in order to be viewed as an

efficient, powerful and realistic economic mobile computing solution.

1.2.1 Agent-based Mobile Computing Architecture

The majority of conventional grid computing issues can be solved or enhanced by the

implementation of agent mechanisms [Leo06]. MAGGIE addresses the issues commonly

found in grid computing and mobile computing architectures by implementing agent and

mobile agent technologies. Furthermore, MAGGIE addresses the issue of constructing a

mobile computing architecture that is defined primarily as communities of interacting agents

and mobile agents.

1.2.2 Mobile Device Constraints

Many inherent disadvantages are associated with mobile devices, such as low processing

capabilities, unpredictable network connections and battery utilisation [Pha02]. These

disadvantages introduce many hurdles not only in the sense of conventional software

engineering, but also in grid computing.

MAGGIE addresses the constraints introduced by mobile devices primarily in the context of

mobile computing. It places great emphasis on the following mobile device constraints:

• Battery power utilisation: MAGGIE addresses the issue of not overutilising the

battery power of a mobile device.

• Unpredictable network connections: MAGGIE deals with the issue of slow,

intermittent and unpredictable network connections commonly exhibited by mobile

devices.

• Limited resource budgets: MAGGIE covers the issue of the limited computational

and storage capabilities exhibited by mobile devices. More importantly, it addresses

the limited resource budgets of mobile devices from a mobile computing context and

environment.

1.2.3 Architecture as Generic as Possible

One of the constraints introduced by mobile devices is the lack of support for true code

mobility [Pet05, Wil07]. Without the support of code mobility, the code of mobile agents

5

cannot be executed via mobile devices dynamically. Furthermore, the absence of mobile

agents in a proposed architecture such as MAGGIE may render the MAGGIE architecture as

more of an application-specific or domain-specific architecture rather than a generic one.

MAGGIE addresses the issue of mobile agents and code mobility by providing a mobile

computing architecture that is as generic as possible. It also covers constructing a mobile

computing architecture, where third-party application developers can implement domain-

specific or application-specific grid services.

Lastly, MAGGIE also deals with the fact that third-party application developers do not need

in-depth prior knowledge of the MAGGIE architecture or processes embedded within

MAGGIE. The MAGGIE architecture provides an easy and efficient means of implementing

grid services.

1.2.4 Motivating Participation in MAGGIE

The owners of mobile devices may question why they should contribute their mobile devices

to a mobile computing solution such as MAGGIE. Without the support or contribution of

mobile device resources, the functionality of MAGGIE will be rendered useless. MAGGIE

addresses the issue of motivating potential MAGGIE users to contribute their mobile devices

to be utilised by other mobile device owners.

1.2.5 Security

Efficient security mechanisms in the context of grid computing, mobile computing, agent and

mobile agent technologies are essential. If any component or mechanism is compromised in a

grid computing or multi-agent solution, such a solution may exhibit unwanted behaviour.

Components that are compromised can also lead to the theft of sensitive information

embedded within grid computing or multi-agent components.

MAGGIE addresses the issues of implementing security mechanisms that ensure a safe, fair

and confidential mobile computing environment. It also deals with security matters stemming

from a mobile computing, mobile device, agent and mobile agent context.

1.2.6 Distributed Alpha-Beta Pruning Algorithm

As discussed in Section 1.1.4, chess was chosen to demonstrate the distributed processing

capabilities of the proposed MAGGIE architecture. MAGGIE deals with implementing a

distributed and asynchronous Alpha-Beta pruning algorithm well-suited to mobile devices.

6

MAGGIE covers the issue of enabling both low-end and high-end mobile devices to

participate efficiently in the evaluation of a chessboard position. Finally, the matter of

implementing a distributed chess grid service targeted exclusively at mobile computing and

mobile devices is also addressed.

The previous subsections identified and discussed the issues that are addressed by MAGGIE

in this dissertation. The issues that were identified range from grid computing, mobile

computing and agent to chess software technologies. The layout of chapters discussing the

implementation of MAGGIE in this dissertation is given below.

1.3 The Implementation of MAGGIE

As discussed in Section 1.2, MAGGIE can be described as an economic mobile grid

computing platform, enabling mobile device owners to sell and purchase the utilisation of

mobile device resources. The following key concepts have been summarised from Chapters 2

to 6:

• Grid computing and economic grid computing (Chapter 2).

• Agent and mobile agent-based grid computing (Chapter 3).

• Mobile grid computing and the mobile device environment (Chapter 4).

• Agent and mobile device related security threats (Chapter 5).

• Chess searching algorithms (Chapter 6).

The fields of research listed above can be combined to construct a possible economic mobile

grid computing architecture that is as generic as possible. Chapter 7 gives an abstract

overview of the architecture of MAGGIE and explains the various interacting components

and agents present in MAGGIE. Chapter 8 discusses the easy and efficient implementation

strategy of a MAGGIE mobile computing service in MAGGIE. Chapter 8 also motivates the

utilisation of the supply and demand economic model as a means for negotiations between

resource producers and resource consumers. Chapter 9 provides the execution algorithm of

each agent and mobile agent in MAGGIE and the security mechanisms implemented to

achieve a safe and reliable economic mobile grid computing solution.

Based on the in-depth discussion of the architecture of MAGGIE and how MAGGIE mobile

computing services are implemented, Chapter 10 puts forward the best implementation of a

distributed chess service in MAGGIE. Chapter 11 provides the results of the first successful

7

prototype implementation of MAGGIE. Finally, the conclusion and future research work of

MAGGIE are given in Chapter 12.

An article has been published based on the work presented in this dissertation.

1.4 Published Articles

An article based on the generic architecture of MAGGIE has been published in the

Proceedings of the Tools and Methods for Competitive Engineering (TMCE) on pages 1101

to1112 ( ISBN 978-90-5155-044-3). The 2008 symposium of the TMCE was held in Izmir,

Turkey, from 21 to 25 April 2008. The article published in the TMCE 2008 Symposium is

presented in Appendix B.

8

Chapter 2

Grid Computing Architectures

“Where there is unity there is always victory.”

- Publilius Syrus

2.1 Introduction

Grid computing is a technology that has been evolving over the last decade, allowing for the

harnessing of interconnected and geographically distributed resources, providing a medium to

satisfy various software application needs [Buy00, Buy02]. Such idle resources range from

idle CPU cycles, memory, secondary storage, bandwidth, specialised devices and scientific

instruments [Buy00, Buy02]. The popularity of grid computing has been fuelled even further

by the Internet, and the affordability and availability of high-speed network connectivity are

enjoying an increasing level of attention [Buy00A].

In this chapter, the various classifications and utilisation of grid computing are given. The

essential and general building blocks and components that form grid computing architectures

are discussed. Finally, a collection of popular and successful grid computing projects are

discussed regarding their architecture, functionality and objectives.

2.2 Grid Computing Classifications

Grid computing is generally defined as the interconnection of distributed resources and the

efficient harvesting of such idle resources [Buy00, Fer05]. There are different grid computing

models based on the types of resources that are donated for utilisation. Generally, there are

four primary grid computing models [Fer05]:

• Computational grids.

• Data grids.

• Network grids.

9

• Multi-purpose grids.

The objectives of each grid listed above are discussed in the following paragraphs.

2.2.1 Computational Grids

A computational grid provides an infrastructure that donates computing and processing

power to virtual organisations and users on a grid. Applications typically use these

computational grids when additional processing power is required and where a single

computer cannot provide sufficient processing power [Fer05, Jac05].

A popular example of a computational grid computing project is SETI (Search for Extra

Terrestrial Intelligence). The SETI computational grid is used to analyse radio transmissions

received from outer space in the search for extraterrestrial life [Jac05].

2.2.2 Data Grids

A data grid provides an infrastructure that allows information visualisation of distributed data

over a collection of heterogeneous data repositories [Fer05]. This information visualisation

provides a cohesive and unified view of all distributed data to users on a grid.

Many businesses implement data grid solutions to support and expand data-mining abilities in

conjunction with an existing storage infrastructure investment, thereby reducing the

complexity of data management [Jac05]. An example of a data grid is the International Data

Grid Project, as discussed in Section 2.5.2.

2.2.3 2etwork Grids

A network grid typically utilises permanently connected machines that use only a small

fragment of the network bandwidth. The unused network bandwidth is regarded as an idle

resource and can be harnessed by users to prevent network bottlenecks [Fer05].

An example of a network grid computing solution is the International Business Machines

(IBM) downloadGrid. The IBM downloadGrid reduces the transatlantic network traffic found

within IBM’s internal network [Fer05].

10

2.2.4 Multi-purpose Grids

Multi-purpose grids form a combination of computational, data and network grids and can

prove to satisfy the requirements of various users by routing the requests to the appropriate

grid computing model [Fer05]. Owing to their adaptive behaviour, multi-purpose grids will

most likely prevail as the most common and powerful implementations of grid computing in

the future [Fer05].

2.3 Grid Computing Components

The requirements, essential and general building blocks and terminology found in grid

computing environments, irrespective of their donated services, are discussed below.

2.3.1 Grid Services Requirements

To fully comprehend what key components are needed to construct a practical grid

computing model, a full definition is needed of what exactly is expected from a grid

computing implementation. The broad characteristics of general grid computing architectures

are as follows:

2.3.1.1 Multiple Domains and Autonomy

Grid computing resources are geographically distributed across a vast range of multiple

domains and are consequently owned by different organisations (virtual organisations). It is

essential to respect and abide by the different administrative settings of each virtual

organisation, such as local resource management mechanisms, payments and security issues

[Buy02, Fos02]. If such administrative settings are not addressed correctly, the grid

computing solution is defined as a local management system.

2.3.1.2 Heterogeneity

A grid computing infrastructure will have to deal with a gigantic collection of resources that

are heterogeneous in nature and will have to compensate for a wide range of technologies

[Buy00]. It is therefore essential to implement protocols and interfaces that are defined as

standard and open. If such grid computing protocols and interfaces are not standard or open,

the grid computing solution is defined as an application-specific grid computing solution

11

[Fos02]. The standard and open protocols and interfaces address critical issues such as

authentication and resource discovery.

2.3.1.3 Scalability

As a grid computing project grows more popular, it can potentially contain millions of

contributed services or resources. This growth can have a severe impact on the performance

of the grid to complete and handle the requests of all users. To address scalability, the grid

must be designed to be both latency and bandwidth tolerant [Buy02]. It must also be designed

to abide strictly by distributed systems principles, allowing the load on a component not to

increase as the number of components increase in a grid [Gri05].

2.3.1.4 Adaptability

In any grid computing solution, it is safer to assume that resource failures will occur at any

given time and should not be considered as an exception [Buy00, Gri05]. Consequently, it is

critical that components responsible for resource management and scheduling adjust their

behaviour accordingly to available resources and services [Buy00]. This is also defined as

fault tolerance and is a critical requirement for any practical grid computing solution [Gri05].

2.3.1.5 Quality of Services

It is critical that every user that contributes services and resources to the grid can deliver non-

trivial quality of services to clients producing the requests [Fos02]. Quality of services (QoS)

should include the average response time expected, availability of resources and security

[Buy00A, Fos02]. Implementing QoS can enhance the utilisation of resources distributed

throughout a grid computing solution [Bar03].

Because virtual organisations may contain a collection of resources, it is also important to

supply the ability to co-allocate these multiple resources to meet complex user and

application demands [Fos02]. QoS should reflect the quality of services of an entire system

rather than the sum of its parts [Fos02].

2.3.1.6 Security

Security covers a range of critical factors such as authentication, data integrity and

authorisation, and should be implemented into any grid computing architecture from the early

12

requirements and development phases. Security implementations should be able to support

multiple policies that fit the specific needs and requirements of users [Gri05].

It is therefore important to understand which components of a grid computing solution must

be secured so as not to allow any viruses, Trojan horse programs or software malicious in

nature to execute [Fer03].

The architecture of grid computing solutions that enable the realisation of the previously

discussed requirements is explained below.

2.3.2 Layered Grid Architecture

As discussed in the previous subsections, a grid must address all essential requirements in

order to serve as a practical solution. Consequently, the essential requirements must be

reflected in the architecture of a grid. To provide such an architecture that is both dynamic

and flexible, a layered structure is proposed where each layer invokes the services provided

by lower layers [Buy02, Fos02, Ven06].

Layered grid architectures follow the principles of an hourglass model [Fos01]. An hourglass

model is justified by the fact that the narrow neck of the hourglass defines a collection of core

abstractions and communication protocols, (TCP, HTTP, SOAP, XML, Internet, etc.) 1

onto

which many applications and tools can be built upon (the top of the hourglass) [Ven06]. The

applications can in turn be mapped to many different underlying resources and technologies

(the base of the hourglass) [Ven06]. The layers follow from bottom to top and are illustrated

in Figure 2.1.

2.3.2.1 Fabric Layer

The fabric layer reflects all geographically distributed resources that are connected via the

Internet or high bandwidth networks. Each such resource runs its own operating system, job

scheduling and management software. Idle resources include computers, storage devices,

databases and specialised equipment such as telescopes or cameras [Buy00, Fos02, Ven06].

The fabric layer also includes all physical communications mediums such as electric wires,

radio, optical or electromagnetic communication mediums [Vol06]. This also includes all

satellite, fixed and mobile (wireless) networks [Vol06].

1 TCP – Transmission Control Protocol, HTTP – Hyper Text Transfer Protocol, SOAP – Simple Object Access

Protocol, XML – Extensible Mark-up Language

13

Figure 2.1: Layered grid computing architecture [Buy00, Ven06]

2.3.2.2 Communication Layer

The communication layer is concerned with the secure communication between resources

embedded in the fabric layer and also supports the secure execution of grid computing

network transactions. It evolves around key protocols such as the Transmission Control

Protocol with Internet Protocol (TCP/IP) for communication, and key security protocols such

as Public Key Infrastructure (PKI), Secure Sockets Layer (SSL) and passwords for

authentication [Ven06].

14

The authentication protocols allow for the validation of the authenticity of virtual

organisation users and the integrity and protection of data transferred between different points

in a grid computing environment.

2.3.2.3 Core Middleware

The core grid middleware provides core grid orientated services such as discovery, trading

and reservation of resources defined in the fabric layer [Buy02]. Core middleware is

commonly seen as the management protocols that effectively handle all requests, policy

relationship monitoring between requests and resources, billing and accounting [Fos02,

Vol06].

2.3.2.4 User Middleware

The grid user middleware provides libraries and tools for the development of grid

applications, management of resources and the scheduling of application requests [Buy02].

2.3.2.5 Applications Layer

The grid applications layer reflects all applications that utilise the distributed grid resources

defined in the fabric layer [Buy02, Vol06]. The grid applications are developed using grid-

enabled languages or technologies [Buy02, Vol06].

2.3.2.6 Grid Portals

According to Volanis and Dumortier, an additional layer where users can submit and collect

jobs on remote resources via the Internet can be added [Vol06]. Grid portals can provide

access via web services where tasks are submitted by virtual organisation users and results

are collected when completed [Buy02].

2.4 Resource Management Architectural Models

The resource management system in any grid computing environment is responsible for the

management, discovery and representation of distributed resources found in the grid fabric

layer (see Section 2.3.2.1) [Buy00, Buy00A, Buy02]. Resource management models can

15

result in quite a complex task as resources are heterogeneous in nature and are owned by

different organisations and users (virtual organisations). Each user may implement user-

specific policies reflecting the management and access of the distributed grid resources

[Fos02]. To address the issues introduced by complex resource management models, there

are three different commonly implemented resource management architectural models

[Buy00]:

• Hierarchical model.

• Abstract owner model.

• Economy/market model.

Only the hierarchical model and economy/market model will be discussed in the remainder of

Chapter 2, as these two models are most applicable to the goals and objectives of the

dissertation.

2.4.1 Hierarchical Model

The hierarchical model is an outcome of the Grid Forum (http://www.gridforum.org) and is

implemented by most contemporary grid computing projects, such as Globus and Legion

[Buy00].

2.4.1.1 Hierarchical Model Structure

The hierarchical resource management model is composed of active and passive components.

The passive components are:

• Resources: Resources represent all geographically distributed resources present in the

grid computing environment [Buy00, Fos02].

• Tasks: Tasks are known as the consumers of resources [Buy00].

• Schedules: Schedules represent mappings of tasks to resources over a period of time

[Buy00].

16

2.4.1.2 Active Components

The following components are considered the active components of the hierarchical resource

management model:

• Schedulers: Schedulers generate the correct schedules that map tasks to the correct

resources [Buy00, Buy00A]. When a task or collection of tasks is submitted to the

scheduler, all tasks contained in such a job are scheduled at once. The scheduler

components can be embedded either as grid computing services or as a higher-level

service implemented by application developers [Fos97].

• Information services: These act as a repository point for collected and summarised

information on the grid computing environment [Buy00].

• Agent components: Many grid computing architectures implement agent technology

to solve certain grid computing issues such as negotiations between consumers and

producers of resources, the monitoring, management and execution of submitted tasks

[Buy00].

2.4.2 Economy/Market Model

In the economy/market model, each set of geographically distributed resources contains its

own resource management mechanism and policy that determines the pricing of idle

geographically distributed resources, to different users [Buy00, Buy02].

2.4.2.1 The 2eed for Economy/Market Models

Typical grid environments contain producers (users contributing services and resources) and

consumers (users utilising services and resources) [Buy02]. Resource producers and

consumers exhibit different strategies, supply-and-demand patterns and objectives [Buy02].

The economic approach provides a fair foundation on which the geographically distributed

and heterogeneous resources of organisations can be managed. The economy/market model is

a new emerging model and is predicted to be the most dominant approach to grid computing

in the near future [Alt07]. Economic grid computing is even considered to become the next

generation Internet or Web 3.0 where services and resources are traded electronically [Alt07].

There are many benefits associated with using the economy/market model. The benefits and

motivations are as follows:

17

• Both the consumer and producer may customise their pricing policies, algorithms and

economic attributes to maximise profits and to reflect their true requirements [Buy00,

Buy02, Bar03].

• The economy/market model supports the regulation of the supply of and demand for

resources and treats all resources as uniform (computational power, memory, storage,

etc.) [Buy00B].

• The model provides a foundation for the fair processing of time critical problems

above lower priority requests, as such requests are more expensive [Bar03].

• It provides a more scalable environment in which all resources are allocated and

managed more efficiently. It supports the development of user-centric policies instead

of system-centric policies [Bar03, Boy00A].

• The economy/market model provides owners of resources with the capability to offer

different services and resources to different applications at different times [Buy00A,

Buy01].

• Lastly, the most significant benefit that the model presents is the motivation to

contribute resources, where both producer and consumer can maximise profits

[Buy00B, Buy01, Buy02].

It is evident from the benefits above why the implementation of an economic-based model

would be desirable. This model motivates consumers and producers of services and resources

to participate actively in a grid computing environment [Buy00A]. There are many

economic-based grid computing projects and many commercial companies that utilise such

grid computing solutions. Examples of these solutions are Mariposa, Nimrod/G, JaWS and

GridBank [Bar03, Buy00, Buy01, Buy02]. Commercial companies such as Entropia,

ProcessTree, Popular Power and United Devices contribute idle CPU cycles from desktop

machines to a commercial computational grid infrastructure [Buy02].

An economic-based model introduces additional requirements to enable both consumer and

producer to express their requirements and to negotiate with one another.

2.4.2.2 Requirements for Economy/Market Model

The requirements for an economy/market model are divided into three categories:

18

• Value expression: Value expressions enable producers and consumers to express their

requirements by utilising a utility model. The utility model expresses requirements

such as constraints, deadlines and budgets [Buy00A, Buy00B, Buy02].

• Value translations: Value translations provide mechanisms to translate value

expressions into resource allocations [Buy02]. This is realised by implementing a grid

resource broker as discussed in Section 2.4.2.4 [Buy02].

• Value enforcement: Value enforcement provides mechanisms to enforce and adapt to

any changes that occur in the user’s environment [Buy02]. This is realised by

implementing highly efficient grid resource brokers and schedulers [Buy02].

It is essential that all three of the above requirements be implemented efficiently to allow

economic grid computing to reach a price equilibrium [Buy02]. A price equilibrium is the

process at which the quantity that is demanded of goods or services is equal to the quantity

supplied [Buy02]. It is only then that an economic market can reach its fullest potential and

be regarded as healthy and competitive [Buy02].

2.4.2.3 Economy/Market Model Structure

A generic economy/market model has been proposed in the literature of Rajkumar Buyya and

is illustrated in Figure 2.2. The following components are used to form the economy/market

model [Buy02]:

• Grid resource broker.

• Grid middleware.

• Domain resource manager.

• User applications.

Each component listed above is now discussed in more detail.

2.4.2.4 The Grid Resource Broker

The resource broker acts as a communicator between consumers and distributed resources

(producers) by utilising the core grid services [Buy01A]. The primary function of the

resource broker is the discovery, selection and reservation of resources, value enforcement

19

and a unified view of distributed resources to the consumer. The resource broker is divided

into the following logical components [Buy01]:

Figure 2.2: Generic economy/market model structure [Buy02]

20

• Job Control Agent: This agent is responsible for the creation, maintenance,

scheduling and monitoring of submitted tasks [Buy00B, Buy01A].

• Schedule Advisor (Scheduler): The primary function of the Schedule Advisor is to

select resources that match the value expressions of users (value translation), and it

assigns tasks to appropriate resources [Buy02A].

• Grid Explorer: The Grid Explorer is responsible for all resource discovery techniques

and identifies all registered machines and resources embedded within them [Buy00B,

Buy01A, Buy02A].

• Trade Manager: The Trade Manager negotiates with trade servers (see Section

2.4.2.5) of producers and determines if an agreement can be made between consumer

and producer [Buy00B, Buy01A, Buy02A].

• Deployment Agent: This agent is responsible for the deployment of submitted tasks to

the designated resources provided by the Schedule Advisor. The Deployment Agent

interacts with the Job Control Agent to post the progress of the task execution.

2.4.2.5 The Grid Middleware

The grid middleware offers core services that bind a consumer to resources or a grid-enabled

application via the grid resource broker [Buy02]. The components of the economic

market/model grid middleware are as follows:

• Trade server: The trade server component acts as a proxy or salesperson for resource

producers. The trade server always aims to deliver maximum profits to the resource

provider by utilising pricing algorithms or economic models as defined by the user

[Buy01A, Buy02A]. It acts as a rich lookup mechanism enabling resources best fitting

a grid application to be selected [Gok03].

• Pricing algorithms/models: Pricing algorithms and models define the prices that a

producer wishes to charge consumers. The prices can vary depending on the time of

day, the user concerned or according to supply and demand. The fluctuating prices

mimic a real economic market environment [Buy02, Buy02A].

• Accounting system: The accounting system is responsible for the billing and recording

of resource usage originating from resource consumers in a grid environment

[Buy01A, Buy02A].

21

2.4.2.6 The Domain Resource Manager

The Domain Resource Manager is responsible for the management and scheduling of local

resources. The local resources may include storage devices, CPU cycles, primary memory

(random access memory), network peripherals, scientific instruments and databases [Buy02].

There are several successful grid computing projects in existence and their implementation

will now be discussed.

2.5 Existing Grid Computing Projects

Thus far the classification of grid computing, different forms of grid computing and the

general different structures of grid computing resource management models have been

discussed. The following sections cover a collection of successfully implemented grid

computing solutions. Each has objectives, architecture and implemented strategies in solving

challenges commonly found in grid computing.

2.5.1 ChinaGrid

The ChinaGrid project is a grid computing project funded by the Ministry of Education of

China. ChinaGrid aims to develop a grid computing project enabling large-scale sharing of

computer resources across multiple administrative domains [Jin05]. It is deployed at 20 key

universities throughout China and aims to develop and extend ChinaGrid via three different

stages [Jin05]:

• Stage one: Ranging from 2002 to 2005, ChinaGrid aims to be implemented into the

top 12 universities throughout China, providing a computational grid computing

platform.

• Second stage: Ranging from 2006 to 2010, ChinaGrid aims to be implemented into 50

key universities and extended to an information service grid.

• Third stage: Ranging from 2011 to 2015, ChinaGrid aims to extend the use of

ChinaGrid to 100 universities and primary and secondary schools.

ChinaGrid is driven primarily by five disciplines [Jin05]:

• Bioinformatics.

22

• Computational fluid dynamics (CFD).

• Image processing.

• Remote education.

• Massive data processing (MDP).

The underlying structure of ChinaGrid uses the China Education and Research Network

(CERNET), which is implemented by more than 1 000 universities and institutes throughout

China. ChinaGrid is based on the Open Grid Services Architecture (OGSA) and follows a

layered architecture similar to the one discussed in Section 2.3.2 [Jin05]. ChinaGrid applies

the Globus toolkits as discussed in Section 2.5.3. It implements a job manager, information

centre and data management mechanism for job scheduling, maintenance of resources and

service information [Jin05]. The ChinaGrid architecture reflects a hierarchical structure

[Jin05].

2.5.2 International Data Grid Project

The European Organisation for Nuclear Research (CERN) has established a project known as

the International Data Grid Project. The goal of this project is to supply data resulting from

experiments to researchers and institutes situated in all of Europe and beyond [Has00].

Discussed in a paper by Haschek, Jaen-Martinez, Samar, Stockinger and Stockinger, three

different real-world applications have been found for the International Data Grid Project

[Has00]:

• High energy physics (HEP).

• Earth observations.

• Bioinformatics.

It is the ultimate goal of the International Data Grid Project to enable up to 2 000 researchers

around the globe to analyse and research the data produced by various experiments and

events [Has00]. The data generated by the CERN experiments is estimated to produce several

petabytes2 of data in one year [Has00]. This data is then stored in a hierarchical fashion

around different sites distributed around the globe [Buy02, Kra02]. The experiment data is

not only stored locally at CERN, but is distributed to other sites called regional centres.

2 One petabyte equals 1 000 terabytes. One terabyte equals 1 000 gigabytes.

23

Regional centres are located in Italy, France, Great Britain, Japan and the USA [Has00,

Kra02].

The service provided by the International Data Grid Project is engineered based upon a

hierarchical model and implements a uniform protocol utilising Lightweight Directory

Access Protocol (LDAP) [Kra02]. The International Data Grid Project implements the

Replica Manager, which observes the access patterns of files. The Replica Manager pushes

such accessed data or files to other regional centres, increasing the response time for access.

Resource discovery is based on queries, and schedulers make use of a hierarchical

organisation with extensible and flexible policies.

2.5.3 Globus: A Metacomputing Infrastructure Toolkit

The Globus system is designed with the intention of achieving a vertically integrated

structure of applications, middleware and networks that utilise a large collection of free

resources [Fos97]. The Globus system is possible through the Globus toolkit. This is a low-

level toolkit providing very basic mechanisms and services to application developers for the

development of user- or service-specific applications [Fos05]. Such low-level services

include authentication, networking, resource location and resource management. The Globus

toolkit provides a layered architecture where application-specific and higher-level services

are implemented on top of lower-level Globus services [Fos97]. The latest Globus toolkit

introduces the development of web services using Java, C and Python [Fos05].

The -exus communication library provides the communications library for application-

specific and higher-level services [Fos97]. The interfaces and methods provided support

various protocols, compression algorithms and QoS in order to perform communications

[Fos97]. The selection of the attributes is determined by selection rules determining which

attributes should be used for communications [Buy02, Fos97]. Resource and status

information is stored in a single unified access mechanism known as the Meta-computing

Directory Services (MDS) [Buy02]. The MDS is implemented on top of the LDAP where

information is structured as a set of entries. Each entry contains zero or more attribute-value

pairs, containing both mandatory and optional attributes [Buy02, Fos97].

The Globus system is engineered based on a hierarchical structure and provides scheduling

components provided by the Globus toolkit [Buy02]. The Globus toolkit, however, does not

provide standard scheduling policies [Buy02]. Instead, the scheduling policies are provided

by higher-level schedulers and have been applied in many global grid computing schedulers,

such as Nimrod-G and AppLes [Buy02].

24

2.5.4 The Legion Project

The Legion Project was developed at the University of Virginia to provide a foundation for

the design and implementation of system services. Legion gives the illusion of a single

system to its users composed of high-performance, heterogeneous and geographically

distributed resources [Lew96].

The Legion class objects are organised in a hierarchical structure, where LegionObject is

positioned at the top of the class hierarchy and all other Legion objects inherit from it

[Buy02]. Legion provides the capability for resource reservations and decentralised policies

via a hierarchical architecture. It provides default system orientated scheduling policies, but

can be extended by implementing resource brokers such as Nimrod-G and AppLes [Buy02].

2.6 Conclusion

In this chapter, grid computing technology and the various resources donated to consumers

were defined formally. It is evident that any idle resource that can be harvested by some

application can serve as a contribution to a grid computing environment.

Requirements that characterise a grid were listed, supporting the development and definition

of the architecture of practical grid computing solutions. Conclusively, the following primary

requirements must be met to satisfy the implementation of a successful grid computing

architecture:

• The full integration of different resources that are inherently heterogeneous in nature.

• Mechanisms enabling users to fully express their goals, objectives, security concerns

and strategies.

• Lastly, the appropriate mechanisms to enforce such policies defined by each grid

node, resource consumer and resource producer.

Two resource management model architectures were discussed: the hierarchical structure and

the economy/market model. The goals and general architecture of each model were

highlighted. It is evident that the economy/market model may prevail as the most dominant

form of grid computing, as it provides motivation to different parties to consume and produce

resources [Alt07, Buy02].

Lastly, an overview was given of a number of successfully implemented grid computing

projects regarding their goals and general architecture. Grid computing solutions such as the

25

International Data Grid Project and ChinaGrid prove that grid computing technology can play

significant roles in the fields of research, education and complex data processing [Has00,

Jin05]. Even more importantly, such services can be provided to literally thousands of

institutes across the world.

Chapter 2 provided in-depth discussions of the requirements, building blocks and general

architecture of grid computing solutions. The content of this chapter provides a clear

foundation for what is expected from MAGGIE in terms of requirements, functionality,

components and architecture.

Chapter 3 discusses the integration of conventional agent and mobile agent technologies into

grid computing architectures, as this is an emerging trend in grid computing development

communities.

26

Chapter 3

Utilising Agent Technology in Grid Computing

“The test of a first-rate intelligence is the ability to hold two opposed ideas in

mind at the same time, and still retain the ability to function.”

- F. Scott Fitzgerald

3.1 Introduction

Chapter 2 discussed the classification of grid computing technologies and how these

technologies contribute significantly to various types of applications. The general structures

and components implemented to construct a practical grid computing solution were also

explained.

Chapter 3 provides the definition and characteristics of both agent and mobile agent

technologies. Once a more in-depth understanding is obtained of agent technologies, the

focus shifts to how these technologies are implemented to further enhance grid computing

technologies. The implementation of mobile agents into mobile devices, supporting the

concept of mobile grid computing, will also be explained.

3.2 Agent Technologies

To fully comprehend how agent technology can extend or aid grid computing paradigms, the

concept of agent technology must first be formally defined.

3.2.1 Agent Definition

The word agent translates into actor, meaning that one person acts on behalf of another

person [Leo06]. However, in the context of computer science and software engineering, the

word agent has many definitions given by various researchers [Fra96]. It can be safely

assumed that an agent is an encapsulated computer system that is situated in some

environment, and is capable of autonomous actions within that environment. The autonomous

nature of an agent enables it to meet its design goals and objectives that affect its senses in

27

the future [Fra96]. Figure 3.1 illustrates the classification of autonomous agents and software

agents as defined by Franklin and Graesser [Fra96].

Figure 3.1: Classification of autonomous agents [Fra96]

The concept of agents was first introduced in the mid-1950s by John McCarthy and then

firmly established several years later by Oliver G. Selfridge [Kim99]. Since the 1980s, there

has been enormous interest in the research, development and deployment of agent-based

technologies and solutions to solve real-world problems [Fos04, Kim99]. It is widely

assumed that agents have the following important properties:

• Autonomy: An agent can formulate its own decisions regarding which action to

execute, based on a collection or representation of internal states [Kim99]. An agent

consequently requires no third-party intervention or human interaction in order to

function.

• Problem solving: Agents are problem-solving entities that are equipped with well-

defined boundaries and interfaces, and contain clearly constructed goals and

objectives [Fos04]. Agents thus do not only interact with their environments [Fra96].

28

• Adaptation: An agent monitors its environment through a collection of sensors, which

are also known as effectors and, if deemed necessary, can adapt to environmental

changes in an orderly and timely fashion [Fos04, Kim99]. Agents also exhibit the

capability to adapt their goals and objectives based on environmental changes

[Fos04].

• Co-operation: Agents may co-exist with other existing agents and communicate via

an agent communication language (ACL). An ACL enables agents to engage in social

activities to achieve a similar goal [Kim99].

• Role specific: Each agent is labelled with a specific role or collection of services it

may present, aiding in the process of solving problems [Fos04].

• Life cycles: An agent is initialised on behalf of some authority and that agent can be

destroyed only by the same authority [Hor99].

With the clear and formal definition of agent technology above, the question may come to

mind as to why agent technology should be implemented to solve real-world applications.

Consequently, the following question must be answered clearly: Why use agent-based

technology above conventional software solutions? The following subsections explain why

agent-based technologies are being integrated into conventional software engineering

paradigms.

3.2.2 Agent Orientated Software Engineering (AOSE)

Industrial-strength software systems are compiled of hundreds of interacting components,

resulting in large and complex systems. This is by far not an accidental trait but rather an

inherent property of large systems [Jen01]. It can be argued that software development and

engineering improvements are a direct result stemming from the introduction of powerful

abstractions. Such abstractions continue to aid in the management of software’s inherent

complexity [Woo99]. The following three abstractions have introduced significant advances

in software engineering [Woo99]:

• Procedural abstractions.

• Abstract data types.

• Object-Orientated Programming (OOP).

One of the strongest arguments supporting AOSE is that agents provide an extremely

powerful level of abstraction. It is this abstraction that allows systems to be modelled as an

29

organisation or community of interacting agents [Cia00, Jen01, Woo99]. The community of

interacting agents can pursue a collection of objectives either collaboratively or individually

[Cia00, Jen01, Woo99]. As software engineers gain a better understanding of the

characteristics of complex software systems, it is understood that interaction is a dominant

characteristic introduced by complex software systems [Cia00]. It is the autonomous and

interacting nature of agents that attracts many software developers to solve real-world

problems using AOSE [Gri01, Woo99].

The majority of software engineers are likely to develop agent-based solutions utilising

traditional object-orientated paradigms. This means that there will be fewer agents than

objects [Woo99]. Thus AOSE must complement and not replace OOP [Woo99].

Owing to corresponding properties of complex software and multi-agent solutions, an

increasing number of real-world applications are implemented using agent technology

[Fos04]. Therefore, AOSE is seen as the next-generation software development paradigm

[Gri01]. In the past few years, an increase in the implementation of agent technologies in the

corporate environment has been noticed [Fos04]. Examples of real-world problems where

agent-based solutions have been used are as follows [Fos04]:

• Manufacturing.

• Electronic commerce.

• Process control.

• Traffic and transportation management.

• Information filtering.

The motivation behind AOSE is clear: organisations of interacting and autonomous agents

are created to complete a collection of objectives collaboratively or individually [Gri01].

Figure 3.2 illustrates how a problem consists of a collection of interacting and autonomous

agents that form a collection of virtual organisations (VOs) [Fos04]. Software engineers

utilising AOSE either implement artificial intelligence or conventional programming

technology to construct agents [Gri01].

However, the question now may be: How can AOSE be mapped to grid computing paradigms

and applications? This question is answered below.

30

Figure 3.2: Canonical view of a complex multi-agent system [Fos04]

3.2.3 AOSE and Grid Computing

In the previous subsections, the question raised was why AOSE should be utilised in solving

complex and real-world problems. The conclusion was that AOSE motivates the abstract

modelling of a community of interacting agents, collaboratively working towards achieving

similar goals. Parallel lines exist between grid computing and agent-based technologies, and

both have commonalities and complement one another.

31

3.2.3.1 Service/Resource Advertisement and Discovery

The A4 model (Agile Architecture and Autonomous Agents) is a methodology that arranges a

large number of agents into a hierarchical structure. It supports the discovery of other agents

and their corresponding services (see Figure 3.3) [Leo06]. This model does not introduce the

constraint that agents must be utilised as a multi-agent system, but rather that each agent may

still contain its own motivation and collection of goals [Jun02].

Service advertisement is achieved by allowing agents to advertise their available services

either upwards or downwards in the hierarchical structure of agents [Leo06]. Service

discovery is achieved by allowing an agent to first query its own knowledge base regarding

the existence of a service. If the desired service is not found, the agent searches for the

desired service via other agents in the hierarchy [Leo06]. Consequently, the A4 model or an

adaptation of it can be implemented to represent grid resource discovery and management

mechanisms [Jun02].

A reliable, dynamic and rich grid computing service model is essential because various

services are created and destroyed over the lifetime of any grid computing environment

[Fos04].

Figure 3.3: A4 model hierarchy [Le06]

32

3.2.3.2 2egotiations

Chapter 2 defined grid computing negotiations as the negotiation process between a resource

producer and resource consumer, binding both parties via some form of a contract. In agent

technology, agent negotiation mechanisms can support or replace grid computing service

negotiations [Leo06, Sim05A]. The implementation of agent negotiation mechanisms serves

to bind producers and consumers via service contracts [Fos04].

Sim [Sim05A] proposes that grid resource allocation negotiation protocols can be replaced

efficiently by agent negotiation protocols and market-driven agents. Each agent is embedded

with three negotiation criteria:

• Opportunity: The opportunity criteria determine the probability of an agent reaching

successful negotiations based on negotiation proposals and available trading partners.

• Competition: The competition criteria determine the amount of competition the agent

represents to other market-driven agents. The competition criteria are calculated by

determining the probability that the agent will not be preferred as the most adequate

trading partner.

• Time: The time criteria define embedded time constraints such as trading deadlines in

the agent. They can cause negotiations within the agent to be relaxed or can cause

negotiations to be placed under pressure.

3.2.3.3 Performance Management

Grid performance management mechanisms can benefit hugely from AOSE if agents are

implemented to gather and process information collected via sensors from the grid computing

environment [Leo06]. Consequently, no raw data needs to be sent to performance processing

points which may potentially create network bottlenecks. The decentralised processing of raw

data into information can later be summarised at higher levels or services in the grid

computing solution [Leo06].

3.2.3.4 Virtual Organisations

In the context of grid computing environments, VOs are viewed as a community of distinct

entities based on similar services or capabilities [Fos04]. The architecture enabling the

dynamic creation and configuration of VOs is not generally considered part of grid

infrastructures. However, agent technology research has made considerable advances in the

33

dynamic creation and configuration of VOs. Thus grid computing technologies can greatly

benefit from agent technologies used in VOs [Fos04].

3.2.3.5 Security

Fundamental to the creation of VOs is not only the notion of authentication, but trust [Fos04].

It is fundamental to VOs and all encapsulated entities to be embedded with autonomous

mechanisms to represent, enforce and negotiate policy terms between one another [Fos04].

Agents provide authentication and trust mechanisms as part of their basic operations and can

aid grid computing technologies in authentication and trust [Fos04].

3.2.4 AOSE and Grid Computing Conclusion

Many of the research efforts presented by agent technologies address many of the issues

commonly found in grid computing. Grid computing issues such as negotiations, security,

service registration and discovery can be addressed by agent technology. It is clearly evident

that AOSE can significantly enhance grid computing architectures.

Additionally, grid computing technology can benefit enormously from another form of agent

technology, known as mobile agent technology. The following section provides the formal

definition of mobile agents, their corresponding properties and contribution towards grid

computing.

3.3 Mobile Agent Technologies

Section 3.2.1 presented the formal definition, properties, use and implementation of agent-

based technologies. Agents are situated in an environment and interact with other

components or agents via conventional means, and are more commonly referred to as

stationary agents [Lan99].

Another important property of agents is that some agents exhibit mobile behaviour, and are

referred to as mobile agents [Lan99]. It has been suggested that mobile agent technologies

will be used in next-generation enterprises [Jai00]. To fully understand what mobile agent

technology entails, a clear definition must be provided.

34

3.3.1 Mobile Agent Definition

Agent mobility is an orthogonal property, meaning that not all agents need to exhibit mobile

behaviour [Lan99]. Mobile agents are viewed as self-contained software systems that migrate

from one network node to the next [Pha98]. Some authors and researchers of mobile agents

view mobile agents as a special case of agents, while others differentiate between the agency

and the mobility of an agent [Pha98]. Regardless of the difference in definition, all

researchers agree on the justification of mobile agents, which is divided into two broad

categories [Jai00, Jai00A]:

• Performance benefits.

• Software engineering benefits.

3.3.1.1 Mobile Agent Performance Benefits

Distributed and telecommunication systems rely on communication protocols to accomplish

specific tasks, which results in large amounts of generated network traffic [Lan99]. Such

systems usually follow the traditional client/server paradigm to accomplish tasks. It is

specifically in this context where mobile agents deliver more efficient services and

approaches, as opposed to client/server approaches [Gli02].

Mobile agents provide a more efficient approach as they reduce network traffic significantly

[Lan99, Pha98]. The reduced network traffic stems from the fact that if large volumes of data

are stored at a remote host, it is more efficient to process such data in its locality rather than

transfer large volumes of data over the network [Gli02, Lan99]. Additionally, mobile agents’

code or state can be transferred over a network, resulting in reduced network traffic [Gli02,

Lan99].

Mobile agents are extremely well adapted for mobile devices utilising intermittent and fragile

network connections [Lan99, Jai00]. These agents compensate for weak network connections

owing to their asynchronous and autonomous execution [Lan99]. When a mobile agent is

dispatched, it operates completely asynchronously and autonomously. Mobile agents are also

well suited for mobile devices that utilise a wireless connection to some fixed wired network,

where the quality of the connection link decreases [Jai00].

35

3.3.1.2 Mobile Agent Software Engineering Benefits

As discussed in the previous subsection, mobile agents are well adapted for intermittent

network connectivity, lightweight devices (mobile devices) and slow networks [Lan99, Jai00,

Sam04]. Thus, they introduce many benefits to the Internet and World Wide Web [Sam04].

Mobile agents provide seamless system integrations through their inherent heterogeneous

nature. They are computer and transport layer independent as they only depend on an

execution environment for correct functionality [Lan99].

Mobile agents are fault-tolerant and allow for the development of systems that easily and

logically react to unfavourable situations [Lan99]. They significantly ease the task of

programming as they exhibit more natural representations of applications [Gli02]. For

example, it is more natural to model electronic commerce applications as mobile agents,

migrating from one site to another [Gli02]. Mobile agents are easier to customise to adapt to

rapid changes in an environment as opposed to the traditional client/server approaches

[Gli02].

It is clearly evident that mobile agents introduce benefits such as performance and simplified

software engineering and are extremely well adapted for certain environments. Such

environments include particularly mobile devices utilising intermittent, fragile and slow

network connections. Mobile agents have been implemented successfully in various areas to

solve real-world problems.

3.3.2 Mobile Agent Utilisation

The specific fields and applications in which mobile agents have been implemented are

discussed below.

3.3.2.1 Information Retrieval Applications

Many applications have been implemented specifically for information retrieval purposes

[Gli02, Fuk03]. Mobile agent solutions provide satisfactory results as information retrieval

systems, by accessing distributed databases over the Internet or World Wide Web (WWW)

[Mil99, Sam04]. The following applications are good examples of mobile agents that have

been implemented in data-intensive applications:

• Search engines: The paper by Glitho, Olougouna, Pierre and Polytechnique [Gli02]

provides an example of where mobile agents locate servers holding the queried

36

information. The mobile agents first consult with network-sensing agents to determine

if the traditional client/server paradigm must be utilised. If this is not the case, then a

mobile agent approach is taken advantage of. When the requested information is

retrieved, the mobile agents analyse and format the results accordingly. As proposed

in the paper by Lange and Oshima [Lan99], such mobile agents can permanently

reside on a remote server that is completely autonomous and personalised.

• Telemedicine: In a study by Smith, mobile agents are implemented in the field of

medicine to conduct a diagnosis [Gli02]. The mobile agents migrate to medical

libraries containing collections of mammograms for consultation. They identify and

return a collection of mammograms that best fit the case being studied.

• Weather forecasting: A study by Glitho, Olougouna, Pierre and Polytechnique [Gli02]

shows a personalised mobile agent migrating to a data server containing weather

prediction data. The mobile agent retrieves the data and processes it according to the

user’s profile. It notifies the end-user once one or more of the embedded conditions

are satisfied in the mobile agent’s preferences.

3.3.2.2 Telecommunications

Mobile agents have already found a firm footing in next-generation network architectures

[Pha98, Mak06]. Traditional network or telecommunication architectures based on the

Simple Network Management Protocol (SNMP) and Common Management Information

Protocol (CMIP) utilise more bandwidth and generate significant volumes of network traffic

[Mak06]. Mobile agents can address the following issues that are unique to

telecommunication networks [Mak06]:

• They can supervise SNMP variables and network elements where the configuration

changes often.

• They can react efficiently towards network failures such as the breakdown of a link.

• Mobile agents can configure the underlying network management policies as deemed

necessary.

• They provide a higher level of communication between network applications.

Mobile agents are ideal for telecommunication systems as they provide a more flexible

management solution for these systems. Mobile agents overcome many of the shortcomings

of SNMP and CMIP by introducing decentralised network monitoring and management

[Mak06].

37

3.3.2.3 Mobile Devices

As discussed in Section 3.3.1.1, mobile agents are well adapted for mobile device

applications owing to the weak, unreliable and intermittent network connectivity of mobile

devices [Mil99]. They are also well adapted for mobile devices that exhibit small memory

footprints, which is common in the mobile device environment. Consequently, mobile agents

can be dispatched from a connected mobile device and execute instructions and algorithms on

a range of servers as illustrated Figure 3.4 [Jai00, Mil99]. Figure 3.4 illustrates how a mobile

agent can asynchronously execute from the mobile device it was dispatched from.

Figure 3.4: Mobile agent implementation on mobile devices [Jai00]

3.3.3 Mobile Agent Technology and Grid Computing

Mobile agents have been implemented successfully into various domains, providing

satisfactory solutions. The following subsections deal with how mobile agent technologies

enhance or support grid computing technologies.

38

3.3.3.1 Enhanced 2egotiations

As mentioned in Section 3.2.3.2, agent technologies can aid the negotiation process between

a resource producer and resource consumer in grid computing environments. The

implementation of mobile agents can even further enhance negotiation mechanisms in grid

computing environments because the negotiations may be bilateral or multilateral [Leo06].

The bilateral and multilateral nature of negotiations reduces the amount of data sent between

producer and consumer during negotiations [Leo06]. The reduced amount of data is due to

the fact that each mobile agent is executed at the resource producer’s locality [Leo06].

3.3.3.2 Grid Monitoring

Mobile agents can be implemented as grid computing monitoring mechanisms because they

migrate from one grid node to the next. During such migrations, mobile agents collect,

analyse and format information [Leo06]. The migrating mobile agent removes the need to

make frequent request-response communications between grid nodes, resulting in decreased

network traffic [Leo06].

3.3.3.3 Service/Resource Discovery

Mobile agents can migrate effectively throughout grid computing environments, enabling the

process of interaction, discovery and invocation of other mobile agent resources and services

[Guo04, Yan05]. In the paper by Yanxiang, Weidong, Huin and Haowen [Yan05], a

hierarchical model adapted from the A4 model represents a collection of mobile agents. The

adapted A4 model enables mobile agents to traverse through the hierarchical structure,

discovering and interacting with other mobile agents.

It is evident that both stationary agent and mobile agent technologies can solve or support

many grid computing issues. Agent and mobile agent technologies can also enhance current

grid computing infrastructures and architectures.

3.4 Conclusion

Chapter 3 introduced a formal definition for agents and mobile agents, which in short can be

defined as encapsulated software that is situated in an environment and is autonomous in

nature. The autonomous nature of agents and mobile agents enables them to meet a collection

of objectives [Fra96, Fos04, Leo06].

39

Valid arguments motivated the implementation of both agent and mobile agent technology

into grid computing architectures. Agent technology has enhanced the negotiations, service

discovery/registration, security, performance management and grid monitoring of grid

computing. Also, mobile agents can be implemented to migrate grid computing to mobile

devices (mobile computing).

Many still believe that mobile agents are yet to be implemented in a killer application,

justifying mobile agents [Fuk03]. However, it is via grid computing that many believe mobile

agents will reach their full potential [Fuk03].

Chapter 3 provided in-depth discussions on how agents and mobile agents can enhance or aid

grid computing solutions. The content of this chapter motivates and supports the

implementation and utilisation of agent technologies in MAGGIE. Chapter 3 also provides

the foundation for MAGGIE in how to implement agent and mobile agent technologies

specifically aimed at grid computing solutions.

In Chapter 4 the migration of grid computing to mobile devices is discussed in detail. The

mobile device technologies most commonly utilised to implement mobile device solutions

are also described.

40

Chapter 4

Mobile Grid Computing

“It showed that our country was capable of making a scientific

discovery of global importance. We forget that we use the results of

space exploration every day. Cellular telephones, television

programming, satellite navigation – all this is a result of what we did,

which became a way of life.”

- Alexei Leonov

4.1 Introduction

Chapter 3 discussed how agent and mobile agent technologies are implemented to support or

enhance grid computing architectures. Agent and mobile agent technologies can increase the

flexibility and efficiency of grid computing technologies.

Chapter 4 discusses how grid computing, agent and mobile agent technologies are merged

with mobile devices and resource-constrained devices. The standards and technologies

associated with mobile devices and mobile device software development platforms are

discussed. In order to fully understand how to realise mobile computing, the constraints

introduced by mobile devices must be understood. The constraints mobile devices introduce

not only in general, but more specifically in the grid computing environment, are explained

below.

4.2 Mobile Devices in Grid Computing

Throughout the remainder of this dissertation, the term mobile devices will include both high-

end mobile devices such as personal digital assistants (PDA), laptops, notebooks, etc. and

low-end mobile devices such as cell phones.

In recent years, both academic institutions and industry organisations have been successful in

implementing commercially successful mobile device products [Pha02]. According to

Informa’s Mobile Market Status 2007 report, the number of mobile phones accounted for at

the end of 2006 were 2 704 661 000 (just over 2.7 billion) [Aho07]. Informa also verified that

41

during 2006, 942 700 000 new mobile devices were sold, just short of a billion [Aho07]. At

the end of 2007, an approximated 3.3 billion mobile devices were in service with 1.1 billion

new mobile devices sold [Cit08, McN07]. This clearly shows a healthy growth and future for

the mobile device market.

Though mobile devices introduce many constraints in terms of resource and computational

capabilities, their vast number potentially presents a huge benefit to grid computing

environments [Pha02]. However, to integrate mobile devices into the grid computing

environment successfully, the fundamental differences between mobile devices and

conventional computers (desktops, servers, etc.) must be fully understood. Any grid

computing infrastructure that utilises mobile devices must abide by the critical and

fundamental constraints introduced by mobile devices [Pha02, Sat93].

4.2.1 Mobile Device Constraints

Mobile devices introduce a number of constraints that are unique not only to grid computing,

but also to the general development of mobile device applications. Each of these constraints

is discussed below.

4.2.1.1 Resource Poor

The weight, power and size of mobile devices results directly in the decrease of resource and

computational capabilities such as CPU speed, primary memory, secondary storage and

networking capabilities [Pha02, Sat93, Sat96, Tao05]. Even with the increase of mobile

devices’ resource and computational capabilities, mobile devices will always remain resource

poor and constrained compared to static machines such as desktops and servers [Sat96].

Resource constraints and limitations introduced by mobile devices are problematic when

viewed in the context of grid computing. Grid computing applications need to temporarily

store large volumes of data to be analysed or processed, which is not supported by mobile

devices [Pha02].

4.2.1.2 Inherently Hazardous

Mobile devices are more likely to be stolen or damaged than desktop computers or any other

conventional grid computing hardware components [Sat93, Sat96]. The inherently hazardous

nature of mobile devices means that extra effort must be taken for any mobile device

application, reinforcing security.

42

The motivation for efficient security mechanisms is fuelled even further when viewing

national crime statistics in the Republic of South Africa. One in every 30 people’s cell phones

are stolen or lost, resulting in 600 000 to 700 000 cell phones stolen or damaged annually

[Ple05].

4.2.1.3 2etwork Connectivity

Grid computing fabric resources commonly rely on network connections such as a local area

network (LAN), wide area network (WAN), integrated services digital network (ISDN),

asymmetric digital subscriber line (ADSL). Each of these network connections provides high,

reliable and secure network connectivity [Sat93]. However, mobile devices are likely to

experience unreliable and intermittent network connectivity [Meg06].

The characteristics of mobile networks can change significantly over a period of time, when

compared to fixed networks [Meg06, Wei98]. The inherent network connectivity issues of

mobile devices are summarised as follows:

• Bandwidth limitations [Pha02, Wei98].

• Prolonged, frequent and unpredictable disconnections [Meg06, Pha02, Wei98].

• Fast-changing mobile network topologies [Meg06, Wei98].

• Many applications may need one-to-many routing, which is inadequately supported in

mobile devices’ point-to-point routing [Wei98].

The above network issues are problematic when viewed in the context of grid computing

environments. Grid computing nodes are expected to receive large volumes of data for

analysis and processing, and should be able to deliver results within a specific time frame

[Pha02].

4.2.1.4 Battery Power

Battery technology will continue to improve over time, but will always play an important and

critical role in mobile devices [Sat96]. Applications must be sensitive to battery power

consumption at all times, both at software and hardware levels [Sat96]. Battery power and

the battery life of mobile devices may limit the capabilities of mobile device computational

and resource components. For example, IBM’s Microdrive, which is a micro hard disk of 1

GB capacity, can increase the battery power requirements of mobile devices [Pha02].

43

4.2.1.5 Operating System Constraints

The operating systems implemented on mobile devices, such as Palm OS, Windows CE and

J2ME, do not offer developers the same array of services compared to their desktop/server

counterparts (Windows, J2EE, J2SE, etc.) [Hu06, Rot01]. Services such as networking

functionality, security and graphical user interfaces are limited on mobile devices [Hu06].

It is evident from the above that mobile devices do present a number of significant issues.

These issues are problematic not only to software development in general, but also to grid

computing. The following subsection discusses the motivation to integrate mobile devices

with grid computing technologies.

4.2.2 Motivation for Mobile Devices in Grid Computing

Owing to mobile devices’ inherent disadvantages and limitations, it may almost not seem

viable or logical to implement mobile devices as grid computing nodes [Pha02].

However, there are various reasons supporting the notion of implementing mobile devices

into a grid computing environment. The arguments are summarised as follows [Pha02]:

• Gigantic numbers: A great many mobile devices are available and can therefore

contribute significantly to grid computing technologies [Pha02]. Approximately 1.1

billion new mobile devices were sold globally during 2007, and could provide huge

potential harvesting capabilities [McN07].

• Moore’s Law: Mobile devices (excluding battery power) will increase in resource and

computational capabilities over time, thus abiding by Moore’s Law [Pha02, Sat96,

Wan06].

• User control: By providing mobile device users with policy settings and mechanisms,

each user can reflect what they perceive as overusage. The implementation of policy

settings and mechanisms place the mobile device user in complete control [Pha02].

• Economy/market models: Incorporating an economic/market-based model (see

Chapter 2) utilising mobile devices will most likely motivate users to contribute

mobile device services and resources for consumption [Pha02].

It is evident that the single, strongest justification of integrating mobile devices into grid

computing environments is the current size and growth of the mobile device market.

Regardless of the constraints associated with mobile devices, mobile grid computing has been

used in the following fields and applications [Zou06]:

44

• The monitoring and management of the tracking, usage and wastage of construction

materials.

• Interaction with database services to retrieve e-mails, letters, information, etc.

• Mobile applications such as word processors, spreadsheets, computer-aided design

(CAD) software, etc. that would otherwise not be able to execute on a single mobile

device.

Next, the introduction of mobile agent technology into the mobile computing platform

environment is covered.

4.3 Mobile Agents in Mobile Devices

Agent and mobile agent technologies have been implemented to aid or enhance many grid

computing architectures (see Chapter 3). However, they can specifically enhance or aid

elements commonly found in mobile computing.

4.3.1 2etwork Load

Mobile agents reduce the network traffic in wireless networks as they migrate from one grid

node to the next [Pou06]. When compared to traditional client/server architectures, mobile

agents do not need to send many messages to other agents or components [Kim03]. The

network traffic-reducing capabilities of mobile agents are ideal for mobile devices, as they

usually consist of low bandwidth capabilities.

Another critical issue that arises from the utilisation of mobile computing applications is that

mobile device owners pay for the amount of data that is sent and received. Mobile agents

consequently minimise the amount of data that is sent and received, in turn minimising the

amount paid for utilising the mobile device application.

4.3.2 Flexibility

Mobile agents increase the flexibility of mobile computing environments, because wireless

networks exhibit extremely dynamic behaviour and conditions [Meg06, Pou06]. The

increased flexibility is due to the autonomous and mobile nature of mobile agents as they

travel from one node to the next [Pou06]. The added flexibility enables mobile agents to

migrate dynamically through wireless networks and mobile devices [Ven06].

45

4.3.3 Fault-tolerance Mechanism

The inherent disadvantages introduced by mobile devices may cause unexpected failures to

occur. Mobile agents greatly improve the resilience, robustness and reliability of mobile

computing technologies [Kim03, Pou06, Vas04, Wan06] by resolving the following issues

effectively:

• -etwork disconnection: Wireless network connections can suddenly and unexpectedly

disconnect for long periods of time (see Section 4.2.1.3). However, mobile agents

continue to execute asynchronously after being dispatched, even if they do lose

connectivity with the components they are meant to communicate with [Kim03,

Vas04].

• Failed environments: The mobile device that a mobile agent executes upon may fail

for a number of reasons such as operating system failures, hardware failures, process

failures and battery failures [Lop06, Kim03]. Mobile agents are autonomous in nature

and can report execution errors, or migrate to another grid computing node to resume

job execution and processing [Lop06, Wan06]. Thus mobile agents can divert from

the failed parts identified in a grid computing environment [Pou06].

It is clearly evident that mobile agents enhance the adaptability, flexibility, resilience,

efficiency and performance of mobile computing architectures. However, they are

autonomous in nature and may migrate with executable, embedded code or data (see Chapter

3). In order to implement mobile agents for mobile devices, popular mobile device software

development platforms need to be understood. Two such popular mobile device software

development platforms are described below.

4.4 Mobile Device Software Development Technologies

Section 4.4 discusses the current popular mobile device software development platforms.

The goals, objectives and technical information of each mobile device software development

platform are explained.

4.4.1 Java Micro-Edition Platform 2 (J2ME)

The J2ME is a mobile device software development platform created by Sun Microsystems.

J2ME specifically targets various consumer electronics and embedded devices such as mobile

phones, pagers, TV set-top boxes and PDAs [Li05, Pet06, Ort04]. Each of the targeted

devices does not contain sufficient resources or computing power to fully implement the

following Java editions:

46

• Java 2 Platform, Standard Edition (J2SE): J2SE provides application programming

interfaces (APIs), tools and runtime environments to implement desktop solutions.

The J2SE defines core collections and definitions of functionality for other Java

editions [Ort04].

• Java 2 Platform, Enterprise Edition (J2EE): J2EE provides libraries supporting the

implementation of scalable database-orientated enterprise applications and solutions

[Ort04].

Two important concepts are introduced by J2ME: configurations and profiles.

4.4.1.1 Configurations

The configuration layer found in J2ME defines the lowest-common-denominator J2ME

libraries, Java virtual machine (JVM) features and programming languages (see Figure 4.1)

[Li05, Ort04, Rig03]. Configuration layers support a specific category of devices containing

similarities regarding hardware capabilities. To date, only two J2ME configuration layers

have been implemented and released [Li05, Ort04]:

• Connected Limited Device Configuration (CLDC): The CLDC is designed for

embedded devices that contain large restrictions on memory, network bandwidth,

battery life and computational power [Li05]. The following hardware characteristics

are found in CLDC targeted devices [Sun03]:

o Minimum memory budget of 192 kilobytes (KB).

o 16-bit or 32-bit processor.

o Network connectivity (usually exhibiting wireless, intermittent, low

bandwidth connectivity).

o Very low power consumption and operating with battery power.

• Connected Device Configuration (CDC): The CDC is designed for embedded devices

that contain much larger memory budgets, processing power and higher network

connectivity [Li05, Ort04, Rig03, Sun05]. The CDC contains full J2SE capabilities

[Ort04, Sun05] and can be implemented on the following embedded devices [Sun05]:

o High-end PDAs.

o Voice Over IP (VOIP) phones.

47

o Set-top boxes.

o Network printers.

o Routers and residential gateways.

The following hardware characteristics are found in CDC targeted devices [Li05]:

• 32-bit processors.

• At least 2 megabytes (MB) of random access memory (RAM).

• At least 2.5 MB of read only memory (ROM).

• Higher bandwidth connectivity.

Both the CDC and CLDC are subsets of the J2SE in terms of libraries, programming

languages and JVM features, and are illustrated in Figure 4.1 below.

Figure 4.1: Subset functionality libraries of CDC and CLDC [Ort04, Rig03]

48

4.4.1.2 Profiles

A configuration layer contains only the lowest-common-denominator libraries, virtual

machine features and programming language features. However, a configuration layer

contains no classes capable of displaying user interfaces, manipulation of persistent data, or

accessing information using communication protocols [Ort04]. This level of functionality is

supplied by profiles. Profiles in J2ME contain more domain-specific functionality for specific

embedded devices [Li05, Ort04]. Each profile is implemented on top of an existing

configuration. The profile uses only the functionality provided by the underlying

configuration layer, as illustrated in Figure 4.2 [Ort04]. To date, the following profiles have

been implemented on top of the CLDC layer:

• Mobile Information Device Profile (MIDP) 1.0 & 2.0[Li05, Ort04].

• Information Module Profile (IMP) [Ort04].

Figure 4.2: J2ME architecture [Ort04, Rig03]

To date, the following profiles have been implemented on top of the CDC layer:

• Foundation Profile (FP).

• Personal Basis Profile (PBP).

• Personal Profile (PP).

49

For the remainder of this dissertation, the CLDC and MIDP 2.0 will be taken as the default

development configuration and profile regarding low-end mobile devices. The MIDP was the

first CLDC profile implemented and consequently is the most mature and complete profile

[Ort04].

4.4.1.3 Mobile Information Device Profile (MIDP)

MIDP was the first profile developed and implemented for the CLDC and is deployed over

millions of mobile devices [Ort04]. MIDP 2.0 gained additional APIs and libraries

differentiating it from MIDP 1.0 [Ort04, Sun02]. It contains the following APIs that were

considered essential requirements to achieve broad spectrum portability and deployment

[Sun02]:

• Application delivery and billing [Sun02].

• Application life cycle management [Sun02].

• End-to-end transactional security (https) [Ort04, Sun02].

• Networking, adding new TCP socket stream classes [Sun02].

• Persistent storage [Sun02].

• User interface components [Ort04, Sun02].

• Timers [Sun02].

The following device capabilities are expected of any device that wishes to implement MIDP

2.0 [Rig03, Sun04]:

• Screen-size of 96 x 54 with a display depth of 1-bit.

• Aspect ratio of approximately 1:1.

• One or more of the following input mechanisms: One-handed keyboard, two-handed

keyboard or touch screen.

• 256 kilobytes of non-volatile memory.

• 8 kilobytes of non-volatile memory for application-created data.

• 128 kilobytes of volatile memory used for the Java heap.

• Two-way, wireless networking.

50

• Ability to play tones made possible via dedicated hardware or software algorithms.

The previous subsections discussed Sun Microsystems’s J2ME technology targeted at low-

end mobile devices. The Microsoft .NET Compact Framework technology targets the

development of high-end mobile device software, and this technology is discussed below.

4.4.2 .2ET CF – The .2ET Compact Framework

The Microsoft .NET Compact Framework3 is a subset of the Microsoft .NET Framework and

contains additional libraries targeted at mobile devices [Bar03A, Mot07, Pin03]. The .NET

Compact Framework is viewed as a collection of reusable classes to develop applications,

targeted at mobile devices supporting the .NET Compact Framework [Roo02, Mot07]. Figure

4.3 illustrates the abstract layered architecture of the .NET Compact Framework.

Host Operating System

PAL

Execution engine

Compact Framework Class Libraries

OEM extensions Application

OEM Applications

Native code

Managed Code

Figure 4.3: .2ET Compact Framework architecture [Bar03A]

The .NET Compact Framework is supported by the following mobile device operating

systems:

• Pocket PC: The .NET CF is supported by the Pocket PC 2003 Phone Editions

[Mic08]. Pocket PC is supported and implemented by more than 20 companies

including Casio, Dell, HP, Packard Bell, Siemens and Toshiba [Roo02].

3 At the time of the completion of this dissertation, the .NET Compact Framework 3.5 was the latest .NET CF

release [Mic08].

51

• Windows CE .NET: Embedded solutions that execute on Windows CE. NET 5.0 or

later for smart mobile devices support the .NET CF [Mic08].

• Windows Mobile: The .NET CF is supported by the Windows Mobile 5.0 or later

operating systems [Mic08]. Devices that support Windows Mobile 6.0 or later have

the .NET Compact Framework and Microsoft SQL Server 2005 Compact Edition pre-

installed [Wil07].

.NET Compact Framework applications can be developed by utilising the Visual Studio .NET

2005 or 2008 Integrated Development Environment (IDE) [Mic08]. .NET CF solutions can

be programmed in either the C# or Visual Basic .NET programming languages [Roo02,

Wil07].

4.5 Code Mobility in Mobile Devices

The most widely used platforms for the development of mobile device software applications

were discussed above. Because of the inherent disadvantages introduced by mobile devices,

the traditional migration mechanisms used by mobile agents to migrate state and mobile code

no longer apply. There are potential solutions for implementing mobile agents utilising

mobile device software development platforms. Two general approaches enabling mobile

agents to execute on mobile devices are now dealt with in more detail.

4.5.1 Executing Local Mobile Agents

It is possible to develop a mobile agent platform for mobile devices that accept and execute

migrating mobile agents. The inherent disadvantage of the approach is that prior compulsory

software components should be installed and configured onto the mobile device, enabling

agent mobility [Vas04]. However, because of the resource constraints introduced by mobile

devices, enabling true code mobility for mobile devices poses a true and real problem. The

following subsections cover the challenges of enabling true code mobility to both the J2ME

MIDP 2.0 and the .NET Compact Framework environment.

4.5.1.1 Introducing Code Mobility into J2ME

To achieve code mobility in J2ME, two requirements must be satisfied: Dynamic class

loading and object serialisation [Pet05]. Not one of these two requirements is currently

satisfied in the context of J2ME MIDP 2.0 [Pet05].

52

The dynamic loading of user-defined classes in the CLDC was disregarded because of

security concerns [Pet06]. This means that the CLDC platform does not allow for the

dynamic loading of classes retrieved from remote locations [Pet06].

As proposed by Petrea and Grigoras, it is possible to design and implement the security

mechanisms enabling dynamic class loading in J2ME. However, this involves the redesigning

and reimplementation of the JVM that the CLDC utilises [Pet05A, Pet06]. This provides a

solution to enabling code mobility in J2ME, but also means the implementation of a new

CLDC JVM and might prove incompatible with previous CLDC JVMs [Vas04]. This

therefore cannot be seen as a complete and viable solution to enable agent mobility.

4.5.1.2 Introducing Code Mobility into the .2ET Compact Framework

Even though the .NET Compact Framework is targeted towards high-end consumer devices

such as PDAs, it still contains significant constraints. One of the constraints is the binary

serialisation of objects and object code [Bar03A, Wil07]. The serialisation of object data is,

however, permitted [Bar03A, Wil07].

The Compact Formatter is a generic .NET Compact Framework formatter that enables the

serialisation of .NET Compact Framework objects. It was developed by Angelo Scotto

utilising .NET Compact Framework libraries. It is developed under the Less General Public

License (LGPL) licence and can be found at http://www.freewebs.com/compactFormatter.

According to the website where Compact Formatter is available, support for Compact

Formatter was abandoned in 2005 and the formatter was left in its beta stage. It still requires

more testing for full industry usage and therefore cannot be viewed as a viable solution.

4.5.1.3 XML and Web Services

As discussed in the paper by Chu and Humphrey [Chu04], the Mobile Open Grid Services

Infrastructure (OGSI).NET implementation relies on the invocation of web service instances

implemented on mobile devices. The .NET Compact Framework specifically supports the

implementation of web services onto mobile devices [Bar03A, Roo02]. The Mobile

OGSI.NET implementation discovers available web services situated on mobile devices and

invokes the appropriate web service. When the web service has been invoked, the appropriate

results are returned to the requesting application [Chu04].

The above approach can also be implemented by the J2ME CLDC environment, as a J2ME

web service specification was developed for CLDC targeted devices. This extension was

developed within the Java Community Process as the Java Specification Request (JSR) 172

[Ren05]. The JSR 172 provides the following additional APIs:

53

• JAXP: The Java API for XML processing and parsing [Ren05, Sun04]

• JAX-RPC: The Java API for XML-based Remote Procedure Calling [Ren05, Sun04].

The migration of mobile agents is possible via web services and the transfer of XML data

between mobile devices [Vas04]. However, as mentioned previously in Section 4.5.1, this

bears the disadvantage that prior software components must be installed and configured to

enable agent mobility [Vas04].

4.5.2 Executing Remote Mobile Agents

Agent mobility on mobile devices can be implemented by allowing access to remote mobile

agents executing on a wired network [Vas04]. There are various implementations that follow

this approach and these solutions are discussed in the subsections below.

4.5.2.1 The JADE Architecture

The Java Agent Development Environment (JADE) platform provides a development

environment for the rapid development of multi-agent systems [Cai04]. JADE includes life

cycle services, security, intraplatform mobility and system management for multi-agent

systems [Cai04, Pog04]. The JADE environment has evolved to cover all Java editions,

namely J2ME, J2SE and the J2EE [Cai04].

The JADE architecture supports the constraints of the J2ME MIDP environment by using a

split container execution mode [Cai04]. This mode executes a very small portion of the

mobile agent on the mobile device, known as the front-end [Cai04]. The remaining part of the

mobile agent executes on a fixed remote server, known as the back-end [Cai04].

Both front-end and back-end containers implement a set of APIs, enabling the split container

execution mode to be transparent to application agents and the rest of the JADE platform

[Cai04]. The front-end and back-end instances communicate via a permanent connection

where each front-end communicates only with its own corresponding back-end [Cai04].

The JADE architecture conforms to the Foundation for Intelligent Physical Agents (FIPA)

standards [Cai04, Pog04]. These standards define a set of rules on how a number of

autonomous agents can discover and communicate with one another [Cai04, Pog04]. The

FIPA standards aim to promote the development of generic multi-agent technologies,

realising seamless communication and interoperability between various agent-based

technologies [Cha00].

54

4.5.2.2 The Jini Architecture

The Jini architecture provides network infrastructures and mechanisms, such as the

registration and discovery of Jini services. Jini services can be invoked by Jini clients

distributed throughout a network infrastructure [Ber05].

CLDC MIDP solutions cannot act as regular Jini clients as a result of the dynamic class

loading constraint introduced by the CLDC MIDP [Ber05]. To overcome the constraint, the

Jini solution creates a Java servlet acting as a Java proxy. The Java servlet executes on a

remote server connected to a wired network. The Java servlet acts as a proxy communicator

for the MIDP client and all other Jini services [Ber05]. The communication between the Java

servlet and the MIDP client utilises HTTP [Ber05].

Other implementations such as MobiNet and the Lightweight Extensible Agent Platform

(LEAP) present mobile agent solutions that implement similar approaches to JADE and Jini.

The approach is where a fragment of a mobile agent executes remotely on a server connected

to a wired network, and the remaining fragments execute locally on the mobile device

[Ber05, Cai04, Vas04]. The fragment executing on the remote server acts on behalf of the

mobile device and permanent communication is established between them [Ber05, Cai04,

Vas04]. The advantage of this approach is that no prior configuration or installation is

required to enable agent mobility [Vas04]. This approach also reduces the amount of

generated network traffic over wireless networks [Vas04]. An overall implementation of this

approach is illustrated in Figure 4.4.

Figure 4.4: Remote agent implementation over mobile devices [Vas04]

55

4.6 Conclusion

Chapter 4 discussed the constraints introduced by mobile devices with specific regard to grid

computing. The arguments against the integration of mobile devices into grid computing

were also given. However, an overwhelming number of arguments were provided defending

the integration of mobile devices into grid computing environments [Aho07, Pha02, Sat93,

Sat96, Zou06].

The Sun Microsystems’s J2ME CLDC, CDC and MIDP and Microsoft’s .NET Compact

Framework libraries are the most widely used and implemented mobile device technologies.

J2ME and .NET CF provide rich, powerful and flexible libraries for the development of

mobile device applications. However, J2ME and .NET CF still introduce constraints that are

unique and problematic [Bar03A, Pet05, Pet05A, Pet06].

The fusion of agent and grid computing technologies can produce more efficient, smarter and

more flexible grid computing architectures. The implementation of agent and mobile agent

technologies in mobile devices poses a major challenge owing to constraints introduced by

mobile devices [Vas04]. In response to the constraints introduced by mobile devices, two

mobile agent approaches were discussed [Vas04]:

• The development and installation of a mobile agent platform on the actual mobile

device. Data exchanges are executed via web services and XML [Chu04, Vas04].

• The development of agents executing on a remote server connected to a wired

network, and acting on behalf of the mobile agent residing on the mobile device

[Ber05, Cai04, Vas04].

It is evident that the popularity of mobile devices is on the increase, yet these devices present

many hurdles and constraints regarding grid computing [Aho07, McN07]. However, it is

possible to develop a mobile grid computing architecture utilising grid computing paradigms,

agent and mobile agent technologies, mobile devices and mobile device software

development platforms.

Chapter 4 highlighted the constraints of mobile devices that MAGGIE should address in

order to realise a mobile computing solution. The content of this chapter provided in-depth

guidelines towards developing the software components of MAGGIE that should reside on

mobile devices. More importantly, a sound foundation has been established for how

MAGGIE can implement mobile agents to fully realise a mobile computing solution.

Chapter 5 identifies security threats associated with mobile agent technology, grid computing

and mobile devices. The implementation of security mechanisms solving or partially solving

the identified security threats will continue to be discussed.

56

Chapter 5

Mobile Agent and Mobile Device Security

“Invincibility lies in the defence; The possibility of victory in the

attack.”

- Sun Tzu

5.1 Introduction

In Chapter 4, how the implementation of mobile agent technology enables the successful

migration of grid computing to mobile devices was explained. The most popular mobile

device software development platforms were also described.

For any system to be widely distributed and accepted by its users, it must withstand existing

security threats. Chapter 5 deals with the various security threats targeted at mobile agents,

mobile agent execution environments, mobile devices and mobile device software. Multiple

solutions addressing the identified security threats are discussed.

5.2 Mobile Agent Security

It is necessary to have an understanding of existing mobile agent security threats as the

proposed architecture of MAGGIE (discussed in Chapters 7, 8 and 9) is based primarily on

agent and mobile agent technology.

The security requirements of grid computing require a secure relationship amongst hundreds

of processes. The processes may stretch over multiple, administrative domains that

complicate the security requirements of grid computing solutions [Fos98]. Trusted

relationships are to be formed between different sites in a grid computing environment prior

to application execution, owing to the inherent dynamic nature of grid computing solutions

[Fos98].

Various security threats are targeted at mobile agents.

57

5.2.1 Mobile Agent Security Issues

Mobile agent implementations enable more flexible and powerful software systems (see

Chapters 3 and 4). For any system or technology to be accepted as reliable, it must withstand

security threats. Mobile agents are no exception.

5.2.1.1 Mobile Agent Threats

Security threats targeted at mobile agents originate from the following sources [Aou05,

Gre98, Wan04]:

• External threats.

• Malicious mobile agents.

• Malicious mobile agent platforms.

Each of the above sources is illustrated in Figure 5.1.

a) External Threats

Many external threats are targeted at mobile agents as mobile agents migrate from one

execution environment to the next [Aou05]. Roaming mobile agents can be copied, modified,

tampered with or captured by an attacker or hacker. The attacker can exist outside the

execution environment of a migrating mobile agent [Aou05] (see Figure 5.1).

b) Malicious Mobile Agent Threats

A mobile agent may attack another mobile agent. Two broad categories of malicious mobile

agent threats are identified [Aou05]:

• Active attacks: The state or data of the targeted mobile agent is modified.

• Passive attacks: The mobile agent’s secrets are retrieved via unauthorised queries.

58

Figure 5.1: Multiple security threats targeted at mobile agents [Auo05]

The above attacks are possible when mobile agents share the same stack layer, agent

execution environment, memory space or underlying hardware configurations [Gre98].

c) Malicious Host Threats

Malicious host threats occur when a mobile execution environment modifies the state or data

of a mobile agent, or steals sensitive embedded data. Malicious host threats can easily occur

as mobile agent hosts have complete control and access to all incoming mobile agents (see

Figure 5.1) [Auo05].

59

The host alters the state of the mobile agent, rendering it useless or in an unstable state. The

host can even modify the mobile agent’s functionality by altering embedded objectives

[Gre98]. Hosts may also fail to provide adequate resources and services for mobile agents to

execute, which is also known as a denial of service attack (DoS) [Cor99, Gre98]. If this is the

case, it renders the mobile agent useless and does not enable the mobile agent to travel to its

successor execution site [Cor99].

Whilst a mobile agent executes on a mobile agent host, it creates a window of vulnerability.

The window of vulnerability is created since encrypted keys, encrypted data and certificates

must be decrypted before being used [Gre98]. Such sensitive data is then copied and abused

by malicious mobile agent hosts [Gre98, Noo04]. During the execution of a mobile agent, a

malicious host can spy on a mobile agent attempting to understand its code, state and network

communication protocols [Gua00].

Hosts can also track or monitor the activities of mobile agents, determining the corresponding

sources and destination addresses of a mobile agent. This can lead to the theft of mobile agent

embedded data [Gre98]. The security of mobile agents is essential, because mobile agents do

not only act on behalf of a user, but may be embedded with sensitive information concerning

a user [Wan04].

5.2.1.2 Mobile Agent Host Threats

Security threats targeted at mobile agent hosts originate from the following sources [Gre98]:

• Malicious mobile agents.

• Malicious mobile agent hosts.

The most critical security threat targeted at mobile agent hosts stem from malicious mobile

agents (see Figure 5.1).

a) Malicious Mobile Agent Threats

Whilst malicious mobile agents execute on a mobile agent host, any residing data, services or

resources can be attacked or modified on the host [Auo05, Gre98]. Such attacks render the

entire host and all other executing mobile agents useless [Gre98]. It is during such a scenario

that a mobile agent may consume the resources of a host, resulting in a DoS attack [Gre98].

60

b) Malicious Mobile Agent Hosts

The same applies to malicious agents stealing sensitive data embedded within hosts. This is

of great concern as mobile agent hosts may embed sensitive data such as authentication

credentials, encryption keys and digital certificates [Gre98].

5.2.2 Mobile Agent Technology Security Techniques

As discussed in the previous subsections, both mobile agents and mobile agent hosts have to

be secured against malicious threats. The malicious threats may be external threats, malicious

mobile agents or malicious hosts. There are multiple implementations of security techniques,

enabling more secured mobile agent environments.

5.2.2.1 Mobile Agent Security Techniques

Security threats can modify a mobile agent, rendering it useless. The primary security threat

targeted at mobile agents stems from malicious hosts and is a field for which not many

solutions and proposals have been suggested [Cor99, Cor99A, Gua00]. The following are

security implementations protecting mobile agents from malicious mobile agent hosts:

a) Code Obfuscation

Code obfuscation is a technique that obscures the mobile code of mobile agents. The

obscured code of the mobile agent makes it more difficult to reverse engineer the agent on a

mobile agent host [Gre98].

One approach is to let agent Z be derived from an ordinary agent X, leaving it difficult to

analyse owing to code obfuscation techniques [Auo05]. Code obfuscation may include the

following techniques [Auo05]:

• Utilising the GOTO statement commonly found in many programming languages.

• The use of insignificant variable names.

• Replacing procedure calls with actual procedure code.

• Insertion of useless snippets of code.

61

Another approach discussed in Greenberg, Byington, Holding and Harper [Gre98] is black

box security. An encrypted mobile agent contains an embedded execution layer that it

executes upon. The embedded execution layer enables a mobile agent to execute in an

encrypted state, hiding sensitive data and code from malicious hosts.

b) Sliding Encryption

Sliding encryption entails the encryption of small amounts of data embedded within a mobile

agent by using a public key [Bor02, Gre98]. The inherent nature of asymmetric cryptography

allows encrypted data to only be decrypted with a corresponding private key. The private key

is embedded only within trusted mobile agent hosts [Bor02].

The consequent disadvantage is that a mobile agent cannot access its own encrypted data

until it arrives at a trusted host [Bor02]. However, as only small amounts of data are

encrypted, the sliding encryption technique results in efficient and practical sizes [Bor02,

Gre98].

c) Environmental Key Generation

The environmental key generation technique is very similar to the sliding encryption

technique, where portions of a mobile agent are encrypted. To decrypt encrypted parts of the

mobile agent, the encryption key is derived from a collection of classes or environmental data

stemming from the host platform [Bor02, Rio98]. The encrypted data can be decrypted if and

only if some environmental conditions are true [Bor02, Rio98]. Basic examples of the

derivation of the encryption key can be constructed in the following fashion [Rio98]:

• Web pages: The encryption key is steganographically embedded within a web page or

an image, residing on the web site.

• Mail messages: A specific message or e-mail contains a string that would serve as an

encryption key, or the key might be a hash of the mail message.

• File systems: The encryption key is stored at a specific location within a file or is the

hash of a file’s content or filename.

• Local network resources: The encryption key is retrieved from the local domain name

server (DNS) or could be the result of a broadcast ping packet.

62

d) Encrypted Function

Encrypted functions are when some agent X implements function f and is encrypted using

encryption algorithm E and results in �(�). The encrypted data of agent X then is

implemented by some program P, and results in �(�(�)). This new program �(�(�))

reflects the new agent Y. Agent Y migrates to the designated host and is executed on some

value z, and results in ��(�)�(�)) . The derived result then migrates back to the original

source site, where decryption occurs and results in � �� (�)�(�)). This results in �(�) and

yields the correct results of function f [Auo05, Bor02]. The encrypted function technique

enables the execution of an agent to be kept secret, including any embedded data within the

mobile agent [Bor02].

e) State Appraisal Functions

State appraisal functions ensure that unencrypted dynamic data of a mobile agent is not

tampered with by malicious hosts [Gre98, Auo05]. An example provided in Corradi,

Montanari and Stefanelli [Cor99, Cor99A] is the development of the Secure and Open

Mobile Agent (SOMA) platform. In SOMA each agent is authenticated based on tamperproof

credentials, such as X.509 certificates. Each agent is embedded with a collection of roles,

defining how other mobile agents and hosts are allowed to interact with the mobile agent

concerned.

f) Mobile Agent Integrity

Qi and Yu state that the integrity of a mobile agent is enforced by calculating a hash value

[Qi01]. The hash value is calculated based on the mobile agent’s code, state, variables, etc.

The calculated hash value enables one to determine if tampering occurred with the mobile

agent during the migration from one mobile host to the next.

5.2.2.2 Mobile Agent Host Platform Security Techniques

As discussed previously, a malicious mobile agent attacks a mobile agent host or steals

sensitive information residing on the host. Secure implementations protecting mobile agent

hosts from malicious mobile agents (see Figure 5.1) are discussed below.

a) Authentication Credentials

A mobile agent is digitally signed by one or more parties using encryption algorithms, such

as the public key signature algorithm [Gre98]. The digitally signed mobile agent enables

63

hosts to authenticate the author and sender of the mobile agent [Cor99, Cor99A, Gre98]. This

technique is also referred to as signed code [Bor02, Jan02].

Authentication credentials do not assure hosts that mobile agents are not malicious in nature.

They do, however, provide assurance to the host that some other entity vouches for the

mobile agent [Gre98].

b) Sandboxing

Sandboxing isolates applications which, in the context of Chapter 5, are mobile agents into

distinct domains enforced by software [Bor02]. This has the effect that malicious mobile

agents execute only within their own allocated virtual address space. This space prevents

applications from interfering with one another [Bor02]. Each domain also monitors sensitive

system resources accessed by applications. Java utilises sandboxing, and is consequently a

popular choice for development and implementation of mobile agents [Bor02, Jan02].

c) Proof-carrying Code

Proof-carrying code is a technique where mobile agent hosts require the code author of the

mobile agent to formally prove that the mobile agent is embedded with a collection of safety

features, as stipulated by the code consumer [Jan02]. This disallows unsafe code to execute

on the host.

The proof-carrying code technique implements a two-stage interaction process [Nec98]. In

the first stage, the code consumer (party receiving the incoming mobile agent) receives

unsafe code and extracts a corresponding safety predicate. The safety predicate can prove

successful only if the execution of the code does not violate the safety policy defined by the

code consumer [Nec98]. In the second stage, this safety predicate is validated through a proof

checker [Nec98]. If the proof is valid, the unsafe code is deemed as safe. The code is then

installed and executed. The two stages of the proof-carrying code technique are illustrated in

Figure 5.2.

The primary advantage of proof-carrying code is that the safety predicate can be attached to

the mobile agent without encryption [Jan02]. If the safety predicate was tampered with, it will

result in a verification error. However, if the verification of the code succeeds, the attacker

only succeeded in having created a safe code transformation [Jan02].

64

Figure 5.2: Steps of proof-carrying code [2ec98]

The disadvantages of proof-carrying code are as follows:

• Difficulty: Generating such formal proofs in an automated manner can prove to be

difficult [Bar02].

• Slow: The proof-carrying code works only as well as its implementation. A very poor

implementation can result in an extremely slow process [Gre98].

• Size: In theory, the safety predicate can reach very large sizes. Consequently,

techniques will need to be implemented that limit the size of the safety predicates

[Nec98].

d) Path Histories

Path histories enable a mobile agent host to determine what the exact history of the arriving

mobile agent entails [Bor02, Jan02, Ord96]. The host can then examine the history of the

agent and determine the level of privileges, trust and risk to be bestowed upon the mobile

agent [Ord96].

65

To implement the path histories technique, every host that the migrating mobile agent visits

digitally signs the path histories list. The digital signature of the host serves as a successful

and safe identification for other mobile agent hosts [Bor02]. To prevent tampering with the

path histories list, each newly added signature takes into account each previous entry in

calculating the message digest [Jan02]. The newly visited host trusts the mobile agent by

either reviewing or authenticating each visited host [Jan02].

The primary disadvantage is the size that the path histories list may reach as mobile agents

migrate from one host to the next [Jan02]. Another problem that arises is how a current host

can trust a previously visited host that is unknown [Jan02].

e) State Appraisal

State appraisal functions ensure that unencrypted data embedded within mobile agents is not

tampered with by a malicious host. However, this function too can be applied by mobile hosts

[Bor02, Jan02]. Hosts detect if any tampering occurred within a mobile agent’s state or data.

The state appraisal technique ensures that mobile agents do not execute any illegal actions

[Bor02]. Consequently, based on the state of the mobile agent, the host determines the level

of risk associated with the mobile agent and assigns the correct privileges to the mobile agent

[Bor02].

It is not yet clear how practical state appraisals are, as the size of the mobile agent state can

reach unpractical sizes. State appraisal functions allow obvious attacks to be detected with

relative ease, but more subtle attacks may prove significantly more difficult to detect and

prevent [Jan02].

5.3 Mobile Technology Security Issues

The previous section dealt with the existing security threats targeted at mobile agents and

mobile agent hosts and partial or complete solutions for the identified security threats. In the

following section, existing security threats targeted at mobile device software development

platforms are reported on, as discussed in Chapter 4.

5.3.1 J2ME MIDP 2.0 Security

Sun Microsystems’s J2ME MIDP 2.0 is targeted at lower-end mobile devices such as cell

phones and pagers (see Chapter 4). The following are the existing security threats, limitations

and security features of J2ME MIDP 2.0.

66

5.3.1.1 Protection Domains

The integral component protecting mobile devices executing MIDP 2.0 applications is known

as a protection domain [Kol04]. Protection domains contain a collection of permissions

granting privileges to a MIDP 2.0 application [Kol04, Sun02]. The collection of permissions

authorise a MIDP 2.0 application to access APIs that are deemed sensitive. The sensitive

APIs cannot be accessed by untrusted MIDP 2.0 applications [Kol04].

In the case of an untrusted MIDP 2.0 application attempting to access sensitive APIs, the user

must first grant explicit permission to the MIDP 2.0 application [Kol04, Sun02]. The

following APIs are deemed protected [Sun02]:

• HttpConnection: The javax.microedition.io.HttpConnection provides a MIDP 2.0

application with HTTP functionality.

• HttpsConnection: The javax.microedition.io.HttpsConnection provides a MIDP 2.0

application with Hyper Text Transfer Protocol over Secure Socket Layer (HTTPS)

functionality.

5.3.1.2 Permissions and Security Policies

The collection of permissions contained within a protection domain can be marked either as

critical or non-critical [Kol04]. If a permission is marked as critical but access is denied or

the requested API does not exist on the mobile device, the application is not installed

[Kol04]. Permissions found within a protection domain are divided into two categories,

namely [Kol04, Sun02]:

• Allowed permissions: A collection of permissions that must be allowed.

• User permissions: A collection of permissions where the user must first authorise the

permission. Each user permission is paired with an interaction mode, which is

discussed below.

In the case of a user permission, the mobile device user either grants or denies the right of the

MIDP 2.0 application to access protected APIs [Sun02]. The following are interaction modes

in MIDP 2.0 [Kol04, Sun02]:

• Blanket: The blanket interaction mode enables MIDP 2.0 applications to invoke

protected APIs until the application is uninstalled or permissions settings are

configured by the mobile device user.

67

• Session: The session interaction mode enables MIDP 2.0 applications to invoke

protected APIs until the application terminates. Consequently, the user is prompted to

grant access on the first invocation of protected APIs. When the MIDP 2.0 application

restarts, the process is repeated.

• Oneshot: In the oneshot interaction mode, the user is prompted on each invocation of

a protected API.

5.3.1.3 Secure Communications

MIDP 2.0’s networking functionality supports the implementation of secured end-to-end

network communication. Secured network communication can be implemented on mobile

devices by implementing one or more of the following methods [Kli07, Sun02]:

• HTTP utilising Transport Layer Security (TLS) (RFC 2818) with TLS v1.0 (RFC

2246).

• SSL v3.0.

• Wireless Transport Layer Security (WTLS).

• Wireless Application Protocol TLS and tunnelling specification (WAP TLS).

A developer needs no prior knowledge of how secured networking functionality is

implemented on a mobile device supporting MIDP 2.0. In the case of WTLS, there is a

secured connection between the Wireless Application Protocol (WAP) gateway and the

phone, and again from the WAP gateway to the final destination [Kli07]. The WAP gateway

must be fully trusted as it has full access to the unencrypted data. The trusted WAP gateways

are commonly governed by the network provider of the mobile device [Kli07].

To enable secured communications, the requested server must contain a valid certificate for

authentication [Kli07]. However, MIDP 2.0 does not support client-based authentication by

providing a client certificate. Thus MIDP 2.0 applications or mobile devices must be

authenticated by other means [Kli07].

SSL is arguably the most implemented encryption algorithm for the safekeeping of data

transported over the Internet and WWW. A security threat can be exploited when utilising

Sun Microsystems’s SSL implementation in MIDP 2.0 [Sim05]. The effectiveness of MIDP

2.0’s SSL relies on the generation of secret key material. The randomness used in the process

of generating key materials determines the strength of the keys [Sim05]. Simonsen, Moen

and Hole [Sim05] exploit a flaw identified in the generation of the key material in MIDP

68

2.0’s SSL implementation. An attack can be initiated on an SSL connection between a server

and mobile device by successfully recovering the authentication and encryption keys used

during the SSL connection [Sim05].

5.3.1.4 Secondary Storage

The javax.microedition.rms API allows MIDP 2.0 applications to access the Record

Management Store (RMS). The RMS is a component where persistent data is stored on a

mobile device [Sun02]. MIDP 2.0 does not enable the encryption of persistent data in the

RMS [Kli07]. Some mobile devices support the installation of a file system explorer, which

allows users to display files and data utilised by J2ME [Kli07]. Cryptographic algorithms

can be implemented, such as the Bouncy Castle’s lightweight cryptography API [Kli07].

However, cryptographic algorithms remain a computationally intensive task for mobile

devices and may be time consuming [Kli07].

5.3.1.5 Security and Trust Services API

The Security and Trust Services API (SATSA) defines a collection of optional packages

targeted at the J2ME environment. The SATSA provides security and trust mechanisms to

enforce security in J2ME-enabled applications [Sun04A]. The following APIs are embedded

within the SATSA and can be implemented independently [Sun04A]:

• SATSA-Application Protocol Data Unit (SATSA-APDU): The SATSA-APDU

supports communication between an application and the smart card found in the

mobile device. The SATSA-APDU is defined in the International Standards

Organisation (ISO) 7816-4 specification [Sun04A, Kli07].

• SATSA-Java Card Remote Method Invocation (SATSA-JCRMI): The SATSA-JCRMI

enables a J2ME application to invoke a method residing on a remote Java Card Object

[Sun04A]. The SATSA-JCRMI allows higher-level communication with smart cards

[Kli07].

• SATSA-Public Key Infrastructure (SATSA-PKI): The SATSA-PKI enables J2ME

applications to utilise digital signature signing, but not the verification of digital

signatures [Sun04A].

• SATSA-CRYPTO: The SATSA-CRYPTO enables J2ME applications to support basic

cryptographic operations such as message digest, signature verification, encryption

and decryption. SATSA specifications recommend that implementers of SATSA

implement Digital Encryption Standard (DES), 3DES and Asymmetric Encryption

69

Standard (AES) as symmetric ciphers [Kli07]. SATSA specifications recommend the

RSA4 as an asymmetric cipher, Secure Hash Algorithm 1 (SHA1) as a digest

algorithm, and finally SHA1 with RSA as a means of digital signatures [Kli07].

For SATSA to operate fully, it must trust the operating system (OS) that the mobile device

executes upon [Kli07]. Consequently, if there are any exploited vulnerabilities in the OS,

these can lead to the compromising of SATSA services. Such threats may take the form of

key loggers or Trojan horses when, for example, the personal identification number (PIN) of

the mobile device is stolen, as it is first stored in the OS memory [Kli07].

5.3.1.6 Signed Applications

The MIDP 2.0 specification enables MIDP 2.0 applications to be digitally signed, utilising

the X.509 PKI signatures [Kli07, Kol04, Sun02]. Digitally signed MIDP 2.0 applications are

considered trusted, and are extremely important in mobile commerce and mobile government

applications [Kli07] (see Figure 5.3). However, problems may arise when using the PKI

system, as found by Ellison and Schneider [Ell00]:

• Trusting the certificate author (CA) can be difficult and dangerous, as customers may

not know the intentions or background of the CA.

• The protection of private keys may prove problematic, or the private keys may be

stolen.

• An attacker may be able to duplicate or match an authentic certificate. The falsified

certificate is then presented during authentication.

• How much is really known of the person or entity that owns the digital certificate?

• Is the CA truly an authority in the context of digital certificates?

• How secure, standard and strong are the processes implemented by the CA for the

creation of digital certificates?

It is evident that even widely utilised and implemented PKI systems contain many flaws.

Therefore, J2ME applications that are labelled as trusted may prove to be insecure and

malicious. The deployment cycle of a trusted MIDP 2.0 application and how it is accepted as

trusted by a mobile device is illustrated in Figure 5.3.

4 The letters RSA represents the initials of the surnames of the inventors of the RSA encryption algorithm: Ron

Rivest, Adir Shamir and Leonard Adleman.

70

Figure 5.3: MIDP 2.0 application deployment cycle [Kol04]

5.3.2 Microsoft .2ET CF Security

Many security standards, methods, etc. are embedded in Microsoft’s .NET CF. The .NET CF

contains the complete subset of the standard .NET Framework security protocols and

methods [Roo02]. This reduces many security threats associated with the development of

.NET CF applications.

There is one remaining security issue targeted at the .NET CF.

Code Obfuscation

When generating mobile applications with Microsoft .NET CF, all application code is

transformed to Microsoft Intermediate Language (MSIL). MSIL is vulnerable to reverse

engineering, allowing attackers to view source code [Mic03].

To address the issue of reverse engineering, the DotFuscator embedded within the Microsoft

.NET Visual Studio can be used to protect mobile applications. The DotFuscator implements

several code obfuscation techniques and algorithms [Mic03]. The default edition of the

DotFuscator is a community edition, and is not as optimised or secure as its professional

71

counterpart. The DotFuscator community edition still provides reasonable protection against

the reverse engineering of Microsoft .NET CF mobile applications.

5.4 Conclusion

Chapter 5 discussed the existence of security threats targeted at mobile agents, mobile agent

hosts, mobile devices and mobile device software development platforms. Effective

implementation to protect mobile agent hosts against malicious mobile agents and vice versa

was expanded upon in this chapter.

From the discussions in Chapter 5 of the protection of mobile devices and software, it is clear

that considerable diligence must be taken when enforcing security onto mobile device

applications. This is especially true in the J2ME MIDP 2.0 environment. However, by

implementing carefully and well-designed software, such shortcomings and security concerns

can be solved.

Chapter 5 provides guidelines of what is expected from MAGGIE from a security point of

view. It emphasises the important factor that MAGGIE must implement agent, mobile agent

host and mobile device software security mechanisms. More importantly, the content

provided in this chapter provides significant insight into how to secure MAGGIE from

malicious threats.

The architecture described in the dissertation utilises chess to demonstrate the distributed

computational capabilities of MAGGIE (discussed in Chapters 7, 8 and 9). Therefore,

Chapter 6 discusses computer chess-playing techniques enabling a computer to play efficient

chess against humans.

72

Chapter 6

Computer Chess-playing Techniques

“Whoever sees no other aim in the game than that of giving checkmate

to one’s opponent will never become a good chess player.”

- Max Euwe

6.1 Introduction

In Chapters 2 to 5, the concepts of grid computing, agent and mobile agent technology,

mobile devices, mobile grid computing and the security threats targeting each concept were

explained. These concepts can be applied to develop a flexible, dynamic and secure mobile

computing architecture.

In order to demonstrate the capabilities of MAGGIE, MAGGIE implements a distributed

chess grid service. In this chapter algorithms and concepts regarding the generation of best-

moves in games such as chess are given. Enhancements specifically associated with the

Alpha-Beta pruning algorithm are also provided.

To implement a successful chess-playing application, rich chess knowledge, tactics,

principles and strategies need to be embedded [Mar92]. The importance and implementation

of chess related knowledge are emphasised in this chapter.

6.2 Game Tree Search Algorithms

The game tree search algorithms and related concepts discussed throughout Chapter 6 are

concerned with zero-sum games. Examples of zero-sum games are backgammon, checkers,

chess, Othello and tic-tac-toe [Pla96]. Zero-sum games are defined as two-player games

where the loss of one player is the gain of the other player [Pla96]. Typical game trees

produced by zero-sum search algorithms are the results of both sides playing during a game

[Bjo00]. Each game tree search algorithm contains its own set of advantages and

disadvantages and to judge game tree search algorithms effectively, appropriate judging

criteria must be identified [Bha95]:

73

• Pruning power: The ability of algorithms to discard positions that are not of critical

concern.

• Storage requirement: The amount of memory required by algorithms.

• Execution time: The amount of time taken by algorithms to generate the best move.

Game tree search algorithms are divided into two categories based on their search strategy

[Pla96]:

• Depth-first: Depth-first algorithms traverse from left to right in an expansion

sequence.

• Best-first: Best-first algorithms attempt to locate the best move first, increasing the

probability of reaching the best move faster. Best-first algorithms typically implement

heuristic mechanisms to aid them in generating the best move.

The different game tree search algorithms commonly implemented for zero-sum games and

the advantages and disadvantages of each algorithm are dealt with below.

6.2.1 Minimax Algorithm

In the context of zero-sum games, a player always attempts to play a move that maximises

their possibility of victory [Bjo00, Pla96]. The opposite player, in turn, always attempts to

minimise the possibility of victory for the first player [Pla96]. The alternating pattern of

maximiser and minimiser has produced the term “minimax” [Pla96]. By evaluating terminal

nodes (leaf nodes) propagated by the Minimax algorithm, the value is negated back up the

tree. The negated evaluation value depicts the best move [Bjo00]. The Minimax algorithm

implements a depth-first approach to traverse the state-space.

Demonstrating the Minimax algorithm, a tic-tac-toe diagram is provided in Figure 6.1. This

figure illustrates every possible move originating from one tic-tac-toe position. Figure 6.2

provides the Minimax representation of Figure 6.1.

In Figure 6.2, the root of the tree is level 0. At each even level, the MAX player attempts to

execute a move maximising the probability of victory. At each odd level, the MI- player

attempts to execute a move minimising the likelihood of a victory for the MAX player

[Pla96]. Figure 6.3 depicts pseudocode illustrating the implementation of the Minimax

algorithm [Boj00, Pla96].

74

The Minimax search algorithm is ideal for games such as tic-tac-toe, where the propagated

game tree is small. However, in games such as chess, Othello and checkers, the propagated

game tree grows exponentially and is too large to traverse through [Bjo00]. To implement an

acceptable Minimax algorithm with regard to time and memory requirements, the propagated

Minimax tree game only expands to a depth d [Bjo00].

Figure 6.1: Possible tic-tac-toe positions originating from one position

Figure 6.2: Minimax representation of Figure 6.1

75

void minimaxSearch(Node n)

{

if (n == LEAF_NODE)

return evaluate(n);

else if (n == MAX_NODE)

{

result = -∞;

c = getFirstChild(n);

while (c != null)

{

result = max(result, minimax(c));

c = getSibling(c);

}

else //This is a MIN_NODE

{

result = +∞;

c = getFirstChild(n);

while (c != null)

{

result = min(result, minimax(c));

c = getSibling(c));

}

}

return result;

}

Figure 6.3: Minimax search algorithm [Pla96]

The Minimax algorithm is easy to understand, but is not suitable for more complex games

such as chess and checkers. The State Space Search (SSS*) algorithm is an alternative search

algorithm to the popular Minimax search algorithm.

6.2.2 SSS* Algorithm

In 1979, Stockman introduced a Minimax algorithm known as SSS* [Bha95, Pla96, Rei93].

SSS* is a best-first algorithm that investigates the most promising tree nodes first [Pla96]. It

utilises AND/OR tree views and searches trees in a best-first fashion [Kai91]. SSS* expands

multiple paths in different regions of the tree and retains all information of the expanded

search space [Rei93]. When SSS* traverses a game tree composed of collections of subsets of

AND/OR trees, it examines fewer tree nodes than most other tree-searching algorithms

[Rei93]. This is because all node and search space information is stored in a large data

structure known as the OPEN list [Rei93, Pla96].

SSS* outperforms most other game tree search algorithms when comparing pruning

capabilities [Kai91, Pla96, Rei93]. However, SSS* exhibits many disadvantages that label it

as a non-practical game tree search algorithm and the problems are listed below [Bha95,

Kai91, Pla96, Rei93]:

76

• Memory: The OPEN list in SSS* consumes large amounts of storage memory and

overheads to correctly execute [Bha95, Kai91, Pla96, Rei93].

• Complexity: The SSS* algorithm tends to be complex and difficult to understand. It

also tends to be difficult to implement [Pla96].

It is evident that SSS* may outperform many search algorithms including the Minimax

algorithm when comparing pruning capabilities. However, many inherent disadvantages are

introduced by SSS*.

The Alpha-Beta pruning algorithm is an extremely popular alternative to both Minimax and

SSS*.

6.2.3 Alpha-Beta Pruning Algorithm

The SSS* algorithm is not regarded as a very practical solution to finding the best move.

SSS*, more importantly, has proved that not all tree nodes need to be examined in order to

produce the best move [Bjo00]. Consequently, only the minimal tree needs to be expanded to

produce the best possible solution [Bjo00]. All game tree search algorithms can use the

minimal tree as a performance benchmark.

Game trees might contain more than one minimal tree, and the Alpha-Beta algorithm can

efficiently determine the minimax value from minimal trees [Bjo00]. In short, the Alpha-

Beta pruning algorithm calculates the same minimax values as the Minimax algorithm, only

at a much reduced cost [Mar82].

The Alpha-Beta pruning algorithm implements pruning mechanisms greatly reducing the

complexity of the game tree to reach the minimax result [Bjo00, Mar82, Pla96]. The Alpha-

Beta function typically receives three arguments: alpha, beta and depth. Alpha and beta form

the search window and dictate the search range that must be searched against [Mar82, Pla96].

Depth represents the current depth in which the Alpha-Beta algorithm is executing [Mar82].

The value returned by Alpha-Beta is the minimax value of a node n within the game tree

[Bjo00, Mar82, Pla96]. The returned value of node n is the lower-bound value of the current

player and the upper-bound value of the opponent [Bjo00].

The upper-bound value is used to prune sub-trees of remaining children nodes of node n

[Bjo00, Pla96]. Whenever a sub-tree is examined and is viewed as inferior according to the

lower-bound value (calculated at node n), the search is abandoned with regard to the sub-tree

region and the current node becomes the cut-off node [Bjo00]. Consequently, if a returned

value does not lie within the search window defined by alpha and beta, the search is

abandoned [Pla96].

77

Figure 6.4: Alpha-Beta algorithm [Pla96]

The pre-condition for each invocation of Alpha-Beta is that alpha < beta [Pla96]. To ensure

the correct execution of Alpha-Beta, the initial values of alpha and beta are -∞ and ∞,

respectively [Boj00, Mar92, Pla96]. Figure 6.4 depicts pseudocode for the implementation of

the Alpha-Beta pruning algorithm [Mar82].

The Alpha-Beta algorithm pruning capabilities are displayed in Figure 6.5. The dashed lines

reflect the nodes or sub-trees that are pruned and the search is discontinued in the specific

region of tree nodes. This style of representing Alpha-Beta pruning graphically has been

adapted from the method used by Plaat [Pla96].

In the worst-case scenario, Alpha-Beta examines the same number of nodes that Minimax

examines. The maximum number of nodes that can be examined is � , with d being the

depth of the game tree and w being the branching factor of the game tree. In the best-case

scenario, Alpha-Beta examines the minimal tree present in the game tree and is formulated as

� /� + � /�- 1 [Bjo00, Pla96]. Though Alpha-Beta proves less efficient than SSS*, it is still

considered the most popular game tree search algorithm owing to two attributes it exhibits

[Pla96]:

• Cut-offs: Alpha-Beta’s pruning capabilities potentially allow it to visit two times the

square root of the number of nodes compared to the Minimax algorithm [Mar82].

78

• Memory: The Alpha-Beta pruning algorithm exhibits excellent storage efficiency and

is noted as O(d).

As a result of Alpha-Beta’s relative simplicity, efficiency and easy implementation, it is still

widely implemented [Bjo00].

Figure 6.5: Alpha-Beta algorithm pruning capabilities [Pla96]

6.3 Alpha-Beta Enhancements

The Alpha-Beta pruning algorithm is one of the most well-known and well-utilised game tree

search algorithms to date. Many enhancements can be implemented, enabling even faster,

deeper and more efficient searches using the Alpha-Beta pruning algorithm.

6.3.1 Aspiration Windows

The Alpha-Beta algorithm is invoked with the values of alpha being -∞ and beta being ∞,

defining the search window. To retrieve the correct Alpha-Beta value, referred to as m, m

must lie between alpha and beta (alpha ≤ m ≤ beta) [Mar81, Pla96]. The aim of aspiration

windows is to tighten the search window, improving the efficiency and performance of the

Alpha-Beta pruning algorithm [Mar81, Sch89]. If, however, alpha and beta are given

incorrect values, value m lies outside the defined search window and a re-search needs to be

executed [Mar81, Pla96, Sch98].

79

To create the aspiration window, an expected evaluation score (estimate) and expected error

value (e) are determined [Mar81, Sch98]. By implementing and utilising the aspiration

window, three possible outcomes may occur [Mar81]:

• Failing low: Occurs when m ≤ estimate – e and the aspiration window is adjusted to

-∞ and m [Mar81, Pla96].

• Failing high: Occurs when m ≥ estimate + e and the aspiration window is adjusted to

m and ∞ [Mar81, Pla96].

• Success: The minimax value m is the true minimax value and no re-search is needed

[Mar82].

The phenomenon that parent and child nodes are closely related in chess game trees allows

the estimate value to be determined by evaluating the current chessboard position [Pla96].

The e (expected error) value usually reflects the material value of one pawn [Pla96]. Figure

6.6 illustrates the pseudocode for the implementation of the aspiration window [Pla96].

An advantage of aspiration window searches is that search times are reduced by

approximately 23% [Mar81]. The implementation of aspiration windows places the Alpha-

Beta pruning algorithm on a competitive level [Kai91].

6.3.2 Minimal Search Windows

The minimal search window technique (also known as Null Window Search and Scout) is

similar to aspiration windows. The minimal search window technique attempts to minimise

the search window and the number of re-searches [Mar87, Pla96]. The minimal search

window technique follows an approach that a sub-tree is inferior and does not need to be

searched [Mar87]. The approach is achieved by considering the first move as the best move,

until proven otherwise [Sch89]. If an interior node is searched and evaluated between a full

search window (alpha and beta) and the returned value (m) lies between alpha and beta, the

rest of the game tree can be searched using a minimal window. The minimal window is

defined as (m, m + 1) and is a probabilistic game to prove that a sub-tree is inferior [Sch89].

If the returned value fails, a re-search is done with the window (m + 1, beta) [Sch89]. Most

successful chess-playing software implements both aspiration windows and minimal search

window techniques [Pla96].

It has been shown that minimal search windows produce more cut-offs than a wider search

window [Pla96]. Figure 6.7 illustrates pseudocode for the implementation of the minimal

search window technique [Mar81, Pla96].

80

Figure 6.6: Aspiration search algorithm [Pla96]

Figure 6.7: Minimal window search algorithm [Pla96]

81

6.3.3 Move Ordering

To enhance the Alpha-Beta pruning algorithm, move ordering mechanisms are utilised where

a score or merit is assigned to moves, resulting in potentially best moves being examined first

[Mar92]. A common technique in move ordering is to examine captures first, i.e. where one

piece captures another [Mar92]. A move where a lower piece (for example a pawn) captures a

higher piece (for example a queen) is considered a good capture and is evaluated first. Move

ordering potentially leads to more efficient searches [Mar92]. More efficient move-ordering

techniques are available.

6.3.3.1 Killer Heuristics

Killer heuristics follow the approach that if a move x refutes move y, it is likely that move x

will prove effective in other positions [Mar81]. Consequently, killer moves are recorded at

each line of play and if an identical move appears in another line of play, the stored killer

move is considered first [Mar92]. Typical implementations only store two killer moves at any

given time [Mar92]. The exact performance statistics of killer heuristics are not quite clear,

but killer heuristics are still implemented by most chess programs [Mar81].

6.3.3.2 Transposition Tables

During the search of a game tree, identical chessboard positions appear in different locations

scattered throughout the game tree [Mar81]. Rather than reconstructing sub-trees, a

mechanism is implemented to retrieve stored results of identical positions [Mar81]. The

mechanism is better known as transposition tables [Mar81, Pla96, Sch89].

Transposition tables are hash tables, where each value of an entry reflects a chessboard

position. For nearly perfect hashing functionality, the Zobrist hash method is implemented

[Ara07, Mar81]. To implement Zobrist hashing, a table of random 64-bit integers is created

and each integer represents a position of a piece [Ara07]. To create the Zobrist hash key, the

hash key is initialised to 0 and all applicable 64-bit integers are XORed with one another,

creating the final Zobrist hash key [Ara07]. The primary advantage of Zobrist hashing is that

the hash key can be updated incrementally. If one position changes, only two XOR operations

need to be executed to calculate a new hash key [Ara07].

There are six distinct chess pieces: the king, queen, rook, knight, bishop and pawn, and there

are 64 squares on a chessboard. To represent each possible position on a chessboard, 12 x 64

Zobrist hashing keys (six for white pieces and six for black pieces) need to be created. An

additional 16 are needed to represent en-passant positions, and an additional 4 are needed to

represent castling [Mar81, Mar92]. This totals 788 randomly generated 64-bit integers.

82

Figure 6.8: Transposition table implementation algorithm [Mar92, Pla96]

Typical transposition table entry structures contain the following fields [Mar81, Mar92]:

• Lock: The lock reflects the corresponding Zobrist hash key and ensures that the table

entry reflects the appropriate tree position.

• Move: The best move that was found in a previous search of the stored position.

• Merit: The merit or score of the tree position calculated in a previous search.

• Flag: The flag indicates if the merit value is an upper bound (beta), lower bound

(alpha) or an exact match value.

83

• Height: The height value reflects the depth at which the transposition table entry was

stored.

Figure 6.8 depicts the pseudocode of the implementation of a transposition table [Mar92,

Pla96].

The implementation of a transposition table aids a chess program to effectively order moves,

by suggesting potential best moves based on previous searches [Sch89]. Transposition tables

do not suggest how to order remaining moves or how to provide information on the ordering

of nodes [Sch89].

6.3.4 Selective Searching

One of the flaws that the Alpha-Beta pruning algorithm exhibits is that all positions are

expanded to the same depth [Bjo00, Pla96]. Selective searching addresses this flaw by

expanding some positions further than others [Pla96, Mar92, Sch89]. To demonstrate the

significance of selective searching, the problem defined as the horizon effect must first be

understood [Mar92, Pla96]. Figure 6.9 illustrates an example of horizon effects and why a

computer may fail in such a scenario [Epp99].

In Figure 6.9 5, no matter what attempts black may try, the bishop on a2 will be lost because

the pawns on b3 and c2 trap the bishop [Epp99]. The best solution for black might prove to

be the sacrifice of the bishop, by capturing the pawn on b3. Afterwards black can focus on

the advancement of the three connected pawns on e4, f5 and g6, resulting in a win or draw for

black [Epp99].

However, programs searching to a depth of 8 will most likely check the white king, losing its

pawns [Epp99]. White responds by capturing the black pawns and delaying the capture of the

black bishop. The loss of black pawns eventually leads to the defeat of black [Epp99]. Many

grandmasters take advantage of this weakness. An example is the famous game between

Grandmaster Garry Kasparov and the computer chess program known as Fritz [Ros04].

Kasparov played the game in such a fashion where most moves formed part of a long-term

strategy goal [Ros04]. Kasparov eventually defeated Fritz by playing moves beyond the

search horizon of Fritz [Ros04].

The following techniques are implemented to solve the horizon effect [Jun98]:

5 All chess diagrams were created by ChessDiagrams, a freeware program created by Dr Amber Chatterjee

(http://www.geocities.com/diagramproject/index.html).

84

Figure 6.9: Horizon effect [Epp99]

• Forward pruning: The null-move heuristic proves to be very effective, especially in

chess [Bjo00A]. The null-move heuristic enhancement significantly decreases the

search depth, if two succeeding moves by the opposite player did not bring the value

back into the Alpha-Beta search window [Jun98]. The goal is to decrease the lower

bound value (alpha) in a cost-effective fashion [Pla96]. If the lower bound causes a

cut-off, then it was found with very little effort. If that is not the case, then very little

effort was wasted [Pla96].

• Quiescence search: Certain chess positions are considered as quiescent or quiet

[Mar92]. When no captures are made or no king is in check, the position is regarded

as quiet and no further expansion is needed [Mar92, Pla96].

• Singular extensions: Singular extension techniques are concerned with the discovery

of a best move via shallow searches, proving to be better than all other moves in a

specific position [Pla96].

One of the pitfalls associated with selective searching is that it may traverse too deeply in a

chess game tree. To ensure efficient utilisation of selective searching, extensive chess

knowledge must be embedded within a chess program, determining when a position must be

extended or not [Pla92, Mar92].

85

6.3.5 Combinations

As discussed, there are many Alpha-Beta pruning algorithm enhancements. Several

successful commercial chess-playing software programs incorporate some or all of these

enhancements [Mar92]. However, no matter how efficient or fast the search and pruning

algorithms may prove to be, the evaluation function remains the most important aspect of a

chess program [Mar92]. The following paragraphs discuss important theories associated with

chess evaluation functions.

6.4 Chess Evaluation Functions

It has been discovered that the deeper the search, the better the resulting tactical play [Ber90].

However, a program that does not understand the fundamental basics of chess strategies,

tactics and advantages needs to search to extreme deep depths to prove to be a formidable

opponent [Ber90]. Figure 6.10 displays a position between Nuchess and Cray Blitz during the

15th

Association of Computing Machinery North America Computer Chess Championship

(ACM NACCC). A lack of embedded chess knowledge in Nuchess led to its defeat [Mar92].

With Nuchess to move in Figure 6.10, Nuchess captures the pawn on g6. Cray Blitz responds

by capturing white’s rook, and in turn white captures black’s rook (see Figure 6.11). Nuchess

obtained one pawn during this exchange, but after the knight on c8 captures the bishop on d6,

this leaves a clear and unstoppable line for Cray Blitz’s pawn on a7 (see Figure 6.12). Many

reasons may be formulated as to why Nuchess lost, but all are a direct result of the lack of

knowledge regarding pawn structures [Mar92].

Figure 6.10: 2uchess vs. Cray Blitz, white to move

86

Figure 6.11: 2uchess vs. Cray Blitz, black to move

Figure 6.12: Cray Blitz’s victory at the 15th

ACM 2ACCC

6.4.1 General Chess Fundamentals

To fully understand the fundamental chess guidelines, a few key chess theory concepts are

explained [Sha50]. A chess position is defined as a [Sha50]:

• Statement of all positions of all pieces on the board.

• Statement where one side (white or black) must move.

• Statement of whether kings and rooks have moved (enabling castling).

87

• Statement containing the last executed move (enabling en-passant of pawns).

• Statement of the number of moves executed since the last pawn move or capture of a

piece (enabling the 50-move drawing rule).

• Statement of previous positions that occurred (including en-passant and castling),

enabling draw by repetition.

Any side can reside in different states at any given time during a chess game [Gom03]. The

different states are defined where player x is black or white, depending on which side is being

evaluated. Player y is the opposite of player x [Ber90, Gom03]:

• Player x is winning and player y is losing.

• Player x has a clear advantage and player y has a clear disadvantage.

• Player x has an edge and player y is trailing slightly behind.

• Player x and player y have an equal position.

Compared to other games such as backgammon and poker, chess does not incorporate any

element of chance (except for who should move first) [Sha50]. Each player has perfect

information over the board and any chess position will result in the following outcome

[Sha50]:

• Win for white: White can force a win and black defends.

• Draw: White can force a draw with black to play, or black can force a draw with

white to play. If both sides play perfectly, the game will end in a draw.

• Win for black: Black can force a win but white plays.

There is no definite method to determine in which category a general chess position can be

classified [Sha50].

6.4.2 The Evaluation Function

There is no perfect chess evaluation function owing to the complex nature of chess [Ber90,

Sha50]. Evaluation functions are based on the structure, mobility, material balance, etc. of

black and white [Sha50]. The following are key concepts enabling a program to distinguish

between good and bad chess positions.

88

6.4.2.1 Material Balance

Material balance is the difference between black and white material (pieces). To correctly

determine the material difference between black and white, each chess piece is assigned a

material value. The following values are commonly assigned to chess pieces [Kau99]:

• Pawn: 1 point.

• Bishop: 3 points.

• Knight: 3 points.

• Rook: 5 points.

• Queen: 9 points.

Results on the research of nearly 300 000 professional games conducted by International

Master Larry Kaufman have delivered more accurate values [Kau99]:

• Pawn: The pawn still remains unchanged with only a material score of 1.

• Bishop: A bishop has an initial score of 3�� , but a bishop pair adds an additional

��

point to the material score of a player.

• Knight: The knight is assigned an initial score of 3��. Increments of

��

are assigned for

each additional pawn above five of the side that is being evaluated. The opposite

adjustments are made for every additional pawn short of five.

• Queen: The queen is assigned a score of 9��.

• Rook: The rook is assigned an initial score of 5. Increments of �� are subtracted for

each additional pawn above five of the side that is being evaluated. The opposite

adjustments are made for every additional pawn short of five.

6.4.2.2 Positional and Strategic Aspects

The following are only a small subset of chess theory principles [Ber90, Kau05, Sha50]:

• Development

89

o Move pieces rapidly attempting to gain control of the board centre, during

opening and middle phases of the game.

o Move smaller pieces prior to larger pieces (bishops and knights before rooks).

• Mobility

o Pieces exhibiting greater mobility are considered stronger.

• King safety

o Castle early in games.

o Do not retain weak pawns in front of the king.

• Pawn structures

o Passed pawns are extremely valuable and should be protected at all costs.

o Isolated pawns are considered weak, because they need safeguarding from

other pieces.

o Doubled pawns are considered weak, because they hamper the development of

one pawn and might need more protection from other pieces [Kau05].

• Endings

o Elementary endings are essential and must be well understood by chess

programs. They may involve the following situations:

� Rook and pawn vs. rook.

� Rook vs. knight.

� Rook vs. bishop.

� Queen vs. bishop pair.

The concepts discussed thus far are known as static evaluation functions. These functions are

where a set of rules, guidelines and knowledge is embedded within the chess program. Chess

programs such as Deep Blue implemented knowledge discovery in databases (KDD) or data

mining to evaluate chess positions [Cam99, Fur97]. They consult a large database of

collected chess games and chess positions, determining the next move based on a large

collection of grandmaster games [Cam99, Fur97].

90

6.5 Conclusion

Chapter 6 explained the nature of two-player zero-sum games, also known as Minimax games

[Pla96, Mar92]. Even though there are many tree search algorithms such as M*, A*, SSS*,

conspiracy numbers, fuzzy numbers, etc., the Alpha-Beta pruning algorithm remains the most

popular and widely implemented algorithm [Jun98]. The Alpha-Beta pruning algorithm is

chosen for its pruning capabilities, small memory requirements and simplicity [Pla96]. The

Alpha-Beta pruning enhancements discussed in this chapter increase the efficiency and speed

of the Alpha-Beta pruning algorithm. The optimised implementation of Alpha-Beta pruning

algorithm enhancements transforms the Alpha-Beta pruning algorithm into a formidable yet

efficient algorithm [Bjo00, Sch89].

No matter how efficient the search algorithm may prove to be, the representation and

embodiment of chess knowledge plays an equal, if not larger, role [Mar92].Only a small

subset of fundamental chess principles, tactics and strategies were discussed in Chapter 6.

The discussion was only of a small subset because of the extreme complex and diverse nature

of chess [Ber90]. The advances made in computer chess tactics, hardware and software have

left a small gap between the elitist of chess grandmasters and their computer peers [McC06].

The capabilities of MAGGIE are demonstrated by implementing a distributed chess grid

service. The in-depth discussions of the Alpha-Beta algorithm and enhancements in this

chapter provide a foundation of how to implement a distributed chess search algorithm.

Chapter 7 discusses the general architecture and interacting component of MAGGIE.

91

Chapter 7

Mobile Agents for the Global Mobile Device

Grid Infrastructure Enterprises (MAGGIE)

Architecture

“The whole structure of science gradually grows, but only as it is built

upon a firm foundation of past research.”

- Owen Chamberlain

7.1 Introduction

Chapters 2 to 6 contain the essential theoretical concepts in order to design and implement

Mobile Agents for the Global Mobile Device Grid Infrastructure Enterprises (MAGGIE).

MAGGIE is an economic mobile grid computing architecture. It utilises mobile devices and

resource constraint devices to form virtual organisations where services and resources are

utilised via economic models.

This chapter explains the general architecture of MAGGIE. The abstract roles and attributes

of all components present in MAGGIE are discussed. Chapter 7 does not intend to provide an

in-depth discussion of algorithms, functionality and service implementations. These concepts

are discussed in more detail in Chapters 8, 9 and 10. The following subsystems of the

MAGGIE architecture are discussed in this chapter:

• The installation of MAGGIE software.

• The MAGGIE storage point.

• The representation of users in MAGGIE.

• The registration and discovery of MAGGIE services.

• The negotiation of MAGGIE services.

• The invocation of MAGGIE services.

92

7.2 MAGGIE Goals

The primary objective of MAGGIE is to provide safe, secure and easy-to-understand

platform that is as generic as possible to develop and implement distributed mobile

computing applications. MAGGIE aims to supply third-party application developers with a

platform to develop and implement domain-specific and application-specific services.

The secondary objective of MAGGIE is to incorporate a wide range of mobile devices to

form part of the mobile computing grid. It aims to incorporate both J2ME MIDP 2.0 and

Microsoft .NET CF enabled mobile devices. By accommodating both J2ME MIDP 2.0 and

.NET CF, MAGGIE covers a wide range of the mobile device market.

In order to motivate users to participate in MAGGIE, MAGGIE incorporates economic grid

computing models, where mobile device resources are traded electronically.

7.3 MAGGIE Architecture Breakdown

MAGGIE is divided into a collection of interacting components. The majority of the

components are based on agent and mobile agent concepts. The advantages of implementing

agent technology in grid computing and mobile computing are evident (see Chapters 3 and

4). The majority of MAGGIE components are defined as dynamic. The MAGGIE

architecture is broken down into the following subsystems:

• Installation subsystem.

• MAGGIE storage point subsystem.

• Single client/virtual organisation representation subsystem.

• Service registration and discovery subsystem.

• Service negotiation subsystem.

• Work deployment subsystem.

The roles, functionality and components of each MAGGIE subsystem are now discussed.

93

7.3.1 Installation Subsystem

Mobile devices range from mobile phones, cell phones, PDAs to even powerful laptops. This

results in mobile devices differing greatly in terms of resources, computational capabilities

and platform technologies [Pha02]. Consequently, each mobile device has to receive and

execute the correctly configured agent, known as the user agent in the MAGGIE architecture.

7.3.1.1 The User Agent

The User Agent’s objective is to reside on the targeted mobile device. This agent acts

primarily as the communicator between the owner of the mobile device and services provided

by MAGGIE. It encapsulates policies, preferences, economic model information, hardware

capabilities and availability. The embedded information is communicated to the Client Agent

(discussed in Section 7.3.3.1). The User Agent submits tasks on behalf of the mobile device

owner and accepts migrating Worker Agents (discussed in Section 7.3.6.2) embedded with

tasks for processing.

All communications made between the User Agent and Client Agent are executed via web

services. The implementation of web service technology allows XML-enabled platforms or

devices to invoke the services of MAGGIE. By implementing web services, MAGGIE

supports future technologies and mobile devices.

A mechanism that provides the correctly configured User Agent to a mobile device has to be

implemented.

7.3.1.2 The Installation Web Server

Each mobile device is required to install and execute the appropriately configured User

Agent, suitable for the mobile device. Mobile devices that wish to download User Agents

connect to an HTTP web server known as the installation web server (IWS). The IWS detects

the make, model and version of the mobile device by accessing the HTTP user-agent ID

[Nok06]. For example, a Nokia N90 is identified by extracting the HTTP user-agent ID

embedded with the following value: Mozilla/4.0 (compatible; MSIE 5.0; Series60 /2.8

-okia-90- 1/1.00.0 Profile/MIDP -2.0 Configuration/CLDC-1.1). The IWS detects that the

mobile device is a Nokia N90 and a User Agent configured for the Nokia N90 series is

downloaded and installed.

Detecting the make, model and version of the mobile device enables the IWS to determine

the underlying technology implemented by the mobile device (such as J2ME or .NET CF).

The IWS provides the correctly configured User Agent to the mobile device via over-the-air

94

(OTA) transfers. The IWS ensures that the mobile device owner downloads and installs the

best configured and capable User Agent. The IWS is illustrated in Figure 7.1.

The information of mobile device models, versions, User Agents, etc., is stored in a

subsystem known as the MAGGIE storage point.

Figure 7.1: Unified Modelling Language (UML) deployment diagram of the IWS

7.3.2 The MAGGIE Storage Point

The MAGGIE storage point (GAP) acts as a single, global repository point of data utilised by

various components in MAGGIE. The stored data at GAP is divided into five broad

categories:

• MAGGIE user accounts: Login credentials, user information and specifications are

stored in GAP. If any mobile device owner wishes to log in to MAGGIE, GAP is first

consulted to determine the authenticity of user login credentials.

• Mobile agent states: A number of MAGGIE components act as mobile agents

migrating from one host to the next. During the life cycle of mobile agents or when

95

the objectives of mobile agents are reached, the applicable information is stored at

GAP. The stored information enables authorised components to access and interpret

stored information in GAP, at any given point in time.

• Agent progress: The progress of agents during their life cycles is stored in GAP. The

stored information enables mobile device owners to view the progress of pending

requests and executing jobs. The GAP supports authorised components to view the

current progress of an agent, rather than having to locate and query the agent for its

current state or progress.

• User Agents: The User Agent executable programs (developed in J2ME and .NET CF

technologies) are stored in GAP.

• Registered services: The services provided by MAGGIE are stored in GAP and each

service contains a service identifier, version, name and description.

The following subsection discusses the representation of MAGGIE users and virtual

organisations in the MAGGIE architecture.

7.3.3 Single Client/Virtual Organisation Representation

Components

Mobile device owners wishing to utilise MAGGIE are represented either as a single client or

as part of one or more virtual organisations. A single client is defined as the single owner of a

mobile device donating services and resources to MAGGIE. A virtual organisation (VO) is a

collection of single clients that contribute similar resources or services to MAGGIE. The

three basic components enabling the dynamic representation of single clients and VOs in

MAGGIE are given below.

7.3.3.1 The Client Agent

MAGGIE implements an abstract base class known as the Client Agent, which is initialised

each time the User Agent logs onto MAGGIE. The Client Agent acts as the only authorised

proxy between MAGGIE and the User Agent residing on the mobile device. The Client

Agent is embedded with information provided by the User Agent such as economic model

information, pricing information and available MAGGIE services. In essence, it is a digital

replication of the User Agent. The Client Agent is illustrated in Figure 7.2.

The Client Agent provides basic functionality regardless of its inheriting children classes.

The basic functionality of the Client Agent includes:

96

Figure 7.2: UML class diagram of entity representations in MAGGIE

• Registration/discovery: The registration and discovery of services and requests.

• Result/progress download: The download of mobile agent progress statistics and

results.

• Administrative actions: The enforcement of administrative actions such as the

modification of MAGGIE user accounts and login credentials.

Children classes inheriting from the Client Agent need to override and implement the

following abstract methods as defined in the Client Agent:

• addService(Service s): When implemented by a class, adds a service to the Client

Agent’s collection of MAGGIE services.

• hasService(string serviceId): When implemented by a class, determines if the Client

Agent contains the requested service identified by the service’s identifier.

The security mechanisms preventing malicious User Agents from communicating with Client

Agents are discussed in Chapter 9. The following subsection reports on the representation of

a single client in the MAGGIE architecture.

7.3.3.2 Single Client Representation

As defined in Section 7.3.3, a single client is viewed as the single owner of a mobile device

donating services and resources to MAGGIE. A single client in the MAGGIE architecture is

represented by the Single Client class (see Figure 7.2). The Single Client class inherits from

the abstract Client Agent class, and overrides the abstract methods defined in the previous

section.

97

The Single Client class simply implements an array list to store all MAGGIE services it

presents to MAGGIE. When a MAGGIE service has to be stored or retrieved, the embedded

array list is utilised. The following subsection deals with the representation of a VO in the

MAGGIE architecture.

7.3.3.3 Virtual Organisation Representation

As defined in Section 7.3.3, a VO is a collection of single clients that contribute similar

resources or services to MAGGIE. A VO is thus a collection of two or more Single Client

instances and is represented by the Virtual Organisation class. VOs in MAGGIE are created

dynamically based on the following criteria:

• Similar services: A VO is formed once two or more Client Agents contain similar

donated MAGGIE services.

• Similar hardware specifications: A VO is formed once two or more Client Agents

contain similar hardware specifications. The hardware specifications include the

following criteria:

o CPU speed: The speed of the mobile device’s CPU measured in megahertz

(MHz).

o RAM size: The size of the mobile device’s RAM, measured in megabytes

(MB).

o Storage capacity: The storage capacity of the mobile device measured in MB.

• Similar economic models: A VO is formed once two or more Client Agents contain

similar economic models utilised for the exchange of payment and resources/services.

The Virtual Organisation class inherits from the abstract Client Agent class and overrides the

abstract methods defined in Section 7.3.3.1 (see Figure 7.2). Each instance of a Virtual

Organisation class embeds a collection of Client Agent instances. The Client Agent

abstraction enables VO instances to be composed of collections of Single Client or VO

instances.

The proposed approach supports the unified view of contributed services found in MAGGIE.

It also enables components not having to communicate with every client agent instance, but

rather only with VO instances. The MAGGIE subsystem responsible for the registration and

discovery of MAGGIE services is described below.

98

7.3.4 Service Registration and Discovery Subsystem

Client Agent instances need to be structured, enabling the registration and discovery of Client

Agent services and capabilities. The following hierarchal structure and components are

implemented by MAGGIE for service registration and discovery.

7.3.4.1 The Broker Agent

Only one Broker Agent exists and is viewed as the grid services information (GSI) point. The

GSI in grid computing architectures serves as a look-up mechanism for contributed services

and resources [Buy00]. The Broker Agent acts as a global look-up mechanism for MAGGIE

contributed services and resources. It always resides at the root of the hierarchical structure

found in MAGGIE as illustrated in Figure 7.3.

Figure 7.3: UML deployment diagram of MAGGIE’s hierarchical structure

99

7.3.4.2 The Sub-Broker Agent

A Sub-Broker Agent is the root of a subhierarchy of Client Agent objects and has a Sub-

Broker Agent or Broker Agent as a parent. Sub-Broker Agents act as a look-up mechanism of

contributed services and resources registered in the subhierarchy of Client Agent instances.

Client Agent instances register at Sub-Broker Agent leaf nodes. Each terminal Sub-Broker

Agent represents a mobile device communication mechanism such as general packet radio

services (GPRS) or global system for mobile communications (GSM) towers. Consequently,

Client Agents always attach themselves to the nearest Sub-Broker Agent, enabling faster and

more efficient communication between Client Agent and User Agent.

When Client Agent instances register at a Sub-Broker Agent, the Sub-Broker Agent registers

embedded Client Agent details with Sub-Broker Agents situated higher in the hierarchy. The

Client Agent details are propagated up the hierarchical structure until they are registered at

the Broker Agent.

Similarly, when a Sub-Broker Agent is required to act as a look-up mechanism, the requested

data is firstly matched against the Sub-Broker Agent’s locally registered services. If the

requested data is not found, the Sub-Broker Agent parent is consulted regarding the requested

information. In the worst-case scenario, the Broker Agent is consulted for the requested data.

In the context of MAGGIE, a Broker Domain is defined as the Sub-Broker Agent or Broker

Agent and all embedded MAGGIE services identified in the subhierarchy.

7.3.5 Service 2egotiation Subsystem

The previous sections discussed the hierarchical structure implemented by MAGGIE to

enable service registration and discovery. The following subsection explains the

implementation of the MAGGIE subsystem enabling the negotiation of services in MAGGIE.

When a MAGGIE mobile device owner wishes to submit a task to be processed by

distributed mobile devices, the User Agent provides the Client Agent with all necessary

information. The provided information is summarised as follows:

• Service identifier: The unique identifier of the MAGGIE service expected to be

invoked. The implementation of MAGGIE services is discussed in Chapter 8.

• Task data: The task fragments to be processed by distributed mobile devices.

100

• Pricing information: The pricing information contains all pricing and negotiation

conditions to be satisfied or taken into account when negotiating with Client Agent

instances. The negotiation conditions are discussed in Chapter 8.

The MAGGIE service negotiation subsystem is illustrated in Figure 7.4. The following are

the components enabling MAGGIE mobile device users to discover and negotiate with other

MAGGIE-enabled devices.

7.3.5.1 The Trade 2egotiator Agent

A Client Agent receives task fragments from a User Agent and initiates a Trade Negotiator

Agent embedded with the appropriate negotiation conditions (see Figure 7.4). The Trade

Negotiator Agent discovers services distributed in MAGGIE and negotiates on behalf of

MAGGIE mobile device users, migrating from one Broker Domain to the next. When a Trade

Negotiator Agent negotiates with Client Agents, this is done via the Client Agent’s Trade

Server component. The Trade Negotiator Agent continues migrating from one Broker

Domain to the next until all negotiation conditions are satisfied.

Whenever a negotiation is settled between the Trade Negotiator Agent and Client Agent, the

progress status of the Trade Negotiator Agent is updated at GAP. The frequent updates of the

Trade Negotiator Agent’s progress enable authorised MAGGIE users to keep track of all

negotiation processes. The negotiation algorithm implemented by MAGGIE is discussed in

Chapter 8 and the execution algorithm of the Trade Negotiator Agent is discussed in Chapter

9.

Figure 7.4: UML class diagram of MAGGIE service negotiation subsystem

101

7.3.5.2 The Trade Server

Negotiations are enabled between Trade Negotiator Agents and Trade Server components.

The Trade Server is embedded within every Client Agent instance and reflects the

requirements of MAGGIE mobile device owners. Each Trade Server component embeds an

economic model responsible for executing negotiations and reaching a negotiation price. The

current economic model implemented by MAGGIE is the supply and demand economic

model. The Trade Server component is illustrated in Figure 7.4.

The Trade Server component hides the implementation of the economic model utilised by the

Client Agent. The level of abstraction introduced by the Trade Server enables Trade

Negotiator Agents to interact with only the Trade Server and not the implemented economic

model. The Trade Server supports the configuration and implementation of future MAGGIE

economic models.

7.3.5.3 Economic Models

As discussed in the previous section, each Trade Server component embeds an economic

model. The economic models implement algorithms, rules, constraints and values configured

by MAGGIE mobile device users. These models determine if an agreement can be reached

between a Trade Negotiator Agent and a Client Agent. MAGGIE implements an interface

known as the economic model interface and defines one method to be implemented by all

inheriting children classes. The method defined in the economic model interface is as

follows:

• double negotiate(-egotiations n): When implemented by a class, the economic model

instance determines if the object n, containing all negotiation data, satisfies the

requirements embedded within the economic model. If a negotiation was reached, a

positive double value is returned. If the negotiations failed, a value of -1 is returned.

The abstraction layer provided by the economic model interface enables the provision of

future economic models, and does not constrain MAGGIE to only one economic model. The

implementation of the supply and demand economic model is discussed Chapter 8.

7.3.6 Work Deployment Subsystem

The components responsible for processing submitted task fragments over distributed mobile

devices are explained in the next paragraphs. The MAGGIE work deployment subsystem is

illustrated in Figure 7.5.

102

Figure 7.5: UML class diagram of work deployment subsystem

7.3.6.1 The Job Handler Agent

When all negotiation conditions have been satisfied by a Trade Negotiator Agent, a Job

Handler Agent is initiated by the Client Agent. The Job Handler Agent ensures the

submission of submitted task fragments to designated User Agents for processing. It collects

the processed results retrieved from Worker Agents and stores the processed results in GAP.

The stored processed results enable authorised User Agents to download and process results

at any given time.

7.3.6.2 The Worker Agent

Job Handler Agents utilise Worker Agents for the submission of task fragments to User

Agents. Worker Agents migrate to Broker Domains and dock with the designated User Agent

via the Client Agent.

As discussed in Section 7.3.1.1, the User Agent acts as an execution environment for Worker

Agents embedded with task fragments to be processed. Once the processing of a task

fragment is complete, the Worker Agent collects and delivers the processed result to its

corresponding Job Handler Agent. If the Worker Agent is scheduled for the docking of more

than one User Agent, it migrates to the designated Broker Domain. The Worker Agent

utilises the look-up mechanism of the Sub-Broker Agent in the Broker Domain it resides in.

103

Once docking with the User Agent is possible, the process is repeated as described above.

A scenario may exist where one or more task fragments are not processed within a specified

time frame. Reasons for this may be network failures, extended periods of absence or

unexpected mobile device errors. If this is the case, the Worker Agent also acts as a Trade

Negotiator Agent. It searches for a new Client Agent to process the task fragment. The

Worker Agent thus ensures that all task fragments are ultimately processed. The time period

is defined by each MAGGIE mobile device user and is discussed in more detail in Chapter 9.

In-depth discussions of the implementation, migration and execution algorithm of Worker

Agents are given in Chapter 9. Chapter 9 also explains the implementation of heart-beat

mechanisms. Heart-beat messages enable Job Handler Agents to monitor the status and

wellbeing of Worker Agents, should a Worker Agent halt execution owing to unforeseen

errors.

7.4 Conclusion

Chapter 7 discussed the general architecture, hierarchy and interacting components of

MAGGIE. It is evident that MAGGIE uses agent technology extensively. This creates a

dynamic, flexible, yet efficient environment. The services and functionality provided by

MAGGIE are dynamic and intelligent because of the autonomous behaviour of agents and

mobile agents.

MAGGIE implements several forms of abstraction, such as the representation of VOs and

economic models. The implementation of such abstractions allows for the efficient

maintenance and evolution of MAGGIE, as future research is conducted on MAGGIE.

The proposed architecture of MAGGIE enables .NET CF and J2ME MIDP 2.0 enabled

mobile devices to participate seamlessly and harmoniously in mobile computing. The

proposed architecture of MAGGIE is modelled to accommodate the constraints and hurdles

introduced by mobile devices. Lastly, MAGGIE aims to provide an architecture that is as

generic as possible for the development and implementation of mobile computing services.

Chapter 7 only covered the primary subsystems of MAGGIE. The roles and abstract

functionality of every component in the MAGGIE subsystems were discussed, providing the

layout and general architecture of the entire MAGGIE solution. With a better understanding

of the MAGGIE architecture, more attention can be given to the implementation details of

MAGGIE grid services. Chapter 8 provides the implementation of MAGGIE mobile

computing services and of the supply and demand economic model.

104

Chapter 8

Service Implementation and 2egotiation

Mechanisms

“The sole purpose of business is service. The sole purpose of

advertising is explaining the service which business renders.”

- Leo Burnett

8.1 Introduction

Chapter 7 discussed the general architecture and interacting components of MAGGIE. It is

evident from Chapter 7 that MAGGIE implements primarily agent and mobile agent

technologies.

Chapter 8 views the strategy that third-party developers should follow in order to implement

application-specific MAGGIE services. It also discusses the implementation of the supply

and demand economic model utilised for negotiations between consumers and producers.

Finally, the concepts underpinning the consumer and developers negotiation values are

explained.

8.2 MAGGIE Service Implementation

The primary goal of MAGGIE is to provide an architecture as generic as possible for the

development and implementation of mobile computing services. However, because of the

constraints introduced by Sun Microsystems’s J2ME MIDP 2.0, Microsoft’s .NET Compact

Framework and mobile devices, true code mobility cannot be realised (see Chapter 4). To

solve this problem, MAGGIE introduces an approach enabling third-party developers to

implement, distribute and utilise MAGGIE services. The following subsections discuss the

strategy implemented by MAGGIE to enable the implementation of MAGGIE mobile

computing services.

105

8.2.1 Service Logic Implementation

8.2.1.1 Interface class

To enable developers to implement domain-specific MAGGIE services efficiently, only one

interface class is required to be implemented by third-party developers. When the interface is

implemented, MAGGIE automatically initialises, registers and invokes the interface instances

by utilising the mobile device software development technologies. The approach proposed by

MAGGIE reflects a layered architecture when implementing application-specific services, as

illustrated in Figure 8.1 [Gou08].

Figure 8.1: Layered architecture of MAGGIE grid services [Gou08]

106

8.2.1.2 The ServiceUnit Interface

MAGGIE implements an interface known as the ServiceUnit. The ServiceUnit acts as the sole

interface required to be implemented by third-party developers. The following methods are

defined within the ServiceUnit interface and are required to be implemented by third-party

developers:

• string getServiceId(): When implemented by a class, the invocation returns the global

unique identifier of the MAGGIE service. The service identifier is defined by third-

party developers and is required to be unique amongst all registered MAGGIE

services. The registration and publication of services in MAGGIE are discussed in

Section 8.2.3.

• string getServiceVersion(): When implemented by a class, the invocation returns the

version number of the MAGGIE service implemented.

• string getService-ame(): When implemented by a class, the invocation returns the

full name of the MAGGIE service implemented.

• string getServiceDescription(): When implemented by a class, the invocation returns

a brief description containing the objectives and functionality of the MAGGIE service

implemented.

• string processTask(string data): When implemented by a class, the invocation of the

method processes incoming data extracted from a Worker Agent. The processTask

method returns the processed result of the data as a string.

The processTask method enables third-party developers to define the structure of the

data parameter and returned results. For example, a developer may choose to

implement XML or user-defined standards to define the data parameter’s structure.

• void processResults(string[] results):When implemented by a class, the invocation

processes an array of strings. The array of strings represents a collection of results

processed by distributed MAGGIE mobile devices. The collection of results is

downloaded via GAP (discussed in Section 7.3.6.1).

• void initialise(): When implemented by a class, the invocation initialises the

MAGGIE service for utilisation by the MAGGIE mobile device user. Third-party

developers typically may wish to initialise graphical user interface (GUI) instances

associated with the MAGGIE service.

107

The ServiceUnit interface introduces a significant level of abstraction in the implementation

and invocation of MAGGIE services. It enables third-party developers to implement a variety

of rich application-specific MAGGIE services (see Figure 8.1). The ServiceUnit interface

frees third-party developers from having to understand the MAGGIE architecture and

associated mechanisms or components.

When third-party developers wish to submit a collection of tasks to be processed by

distributed MAGGIE mobile devices, a method defined in the User Agent needs to be

invoked. The method to be invoked is the submitTasks(Developer-egotiations[]negotiations)

method. The structure Developer-egotiations contains negotiation values determined by

third-party developers and is discussed in Section 8.3.3.2.a. The Developer-egotiations

structure also embeds a task fragment to be processed by a MAGGIE mobile device.

Once the submitTasks method is invoked, the User Agent automatically prompts MAGGIE

mobile device owners to modify consumer negotiation values (discussed in Section 8.3.3).

Once the consumer negotiation values are defined, the User Agent continues to submit the

defined negotiation variables and task fragments. The User Agent and all MAGGIE

components on the mobile device are defined and implemented in the MAGGIE foundation

(see Figure 8.1). Third-party developers need to take a final step to register the implemented

MAGGIE services. This is service initialisation.

8.2.2 Service Initialisation

Third-party developers are expected to manually initialise the User Agent. The User Agent

contains the constructor signature: UserAgent(ServiceUnit[] units). On the invocation of the

constructor, the User Agent receives an array of one or more ServiceUnit instances. The User

Agent automatically lists and registers each passed ServiceUnit, invoking the ServiceUnit

when appropriate. The execution algorithm of the User Agent is discussed in Chapter 9, and

does not fall within the scope of application developers. The publication of MAGGIE

services is discussed below.

8.2.3 Service Publication

When domain-specific MAGGIE services are developed, services are published and

distributed via GAP. The procedures for the publication of MAGGIE services are beyond the

scope of this dissertation, as they are assumed to be trivial. For example, MAGGIE services

may be registered and uploaded via a web interface. Once MAGGIE services are published,

the IWS is utilised to download the correctly configured solution.

108

The IWS enables third-party application developers to develop and publish various solutions

targeted at specific platforms (J2ME MIDP 2.0 and .NET CF) and mobile devices. An

example demonstrating the implementation of a MAGGIE service is given next.

8.2.4 The Sum Service Problem Example

The following example demonstrates how easily and efficiently a MAGGIE service is

implemented.

Assume some developer wishes to implement the following solution known as the Sum

Service: The user wishes to compute the sum of n integers, where n ≥ 2. The sum of the n

integers is to be calculated over a collection of distributed MAGGIE mobile devices. The n

integers are inputted by the user, and the user specifies into how many tasks the n integers

should be grouped. The number of groups is defined as m where m is an integer and m ≥ 2.

Consequently, m distributed MAGGIE mobile devices will be invoked, calculating the sum of

n integers. It is assumed that there will always be m available distributed MAGGIE mobile

devices.

8.2.4.1 Generating and Submitting Tasks

The algorithm in Figure 8.2 is only concerned with the following application logic:

• Retrieving the number of MAGGIE nodes the user wishes to utilise, defined as m.

• Retrieving the number of integers to be read defined as n, and continuing to read n

integers.

• The grouping of n integers into m tasks.

• Supplying the User Agent with a collection of Developer-egotiations for the correct

summation of the n integers.

Figure 8.2 displays the pseudocode implementation of the application logic discussed above.

Additional functionality may be implemented in the pseudocode, but Figure 8.2 demonstrates

only the core application logic.

Following the algorithm described in Figure 8.2, if n has a value of 11 and m a value of 5,

each node will at least process 2 integers. If the input of the 11 integers is 1, 2, 3, 4, 5, 6, 7, 8,

9, 10 and 11, the entries of the array variable tasks are:

109

int m = fetchNumberOfNodes();

int n = fetchNumberOfIntegers();

int interval = n / m;

int lastIndex = 0;

string task = "";

string[] tasks = new string[m];

int[] integers = readIntegers(n);

//Read the first m - 1 tasks.

for (int i = 0; i < m - 1; i++)

{

for (int j = i * interval; j < (i * interval) + interval; j++)

{

tasks[i] = tasks[i] + integers[j] + ";";

lastIndex++;

}

}

//Read the last task data.

for (int i = lastIndex; i < n; i++)

tasks[m - 1] = tasks[m -1] + integers[i] + ";";

DeveloperNegotiations[] negotiations = getNegotiations(tasks);

UserAgent.submitNegotiations(negotiations);

Figure 8.2: Sum Service task generation algorithm

tasks[0] = 1; 2;

tasks[1] = 3; 4;

tasks[2] = 5; 6;

tasks[3] = 7; 8;

tasks[4] = 9; 10; 11

The last line of code in Figure 8.2 displays the only method to be invoked when submitting a

collection of task fragments for distributed processing. The Developer-egotiations structure

is described in Section 8.3.3.2. The following subsection explains the implementation of the

processTask(string data) method defined as part of the Service Unit interface.

8.2.4.2 Processing a Task

As discussed in Section 8.2.1.2, the processTask(string data) method is concerned only with

the processing of task fragments provided by Worker Agents. With regard to the Sum

Service, each node receiving task fragments calculates the sum of integers provided by

another Sum Service instance. The integers are extracted by splitting the received data into

an array of integers, using the ‘;’ character as a delimiter. The integers are simply added and

then returned as a string. Figure 8.3 illustrates the pseudocode demonstrating the application

110

logic discussed above. When implementing the defined values in the previous subsection,

each MAGGIE mobile device yields the following results:

MAGGIE -ode 1 = 3

MAGGIE -ode 2 = 7

MAGGIE -ode 3 = 11

MAGGIE -ode 4 = 15

MAGGIE -ode 5 = 30

The following subsections explain the implementation of the processResult(string[] results)

method defined as part of the ServiceUnit interface.

Figure 8.3: Sum Service processing task fragments algorithm

8.2.4.3 Retrieving and Processing Results

As discussed in Section 8.2.1.2, the processResult(string[] results) method is concerned only

with processing the final task fragment results. With regard to the Sum Service, the original

Sum Service instance calculates the sum of integers retrieved from GAP.

The integers are extracted from the array variable results, and added to a local variable named

sum. Figure 8.4 illustrates the pseudocode implementation of the application logic discussed

above.

When implementing the defined values in the previous section, the final result yields the

answer 66. Additional pseudocode may be implemented to graphically display the final

result. Figure 8.4 only demonstrates the core application logic of the Sum Service.

111

Figure 8.4: Algorithm for processing retrieved results, regarding Sum Service

The Sum Service example is not complex or advanced in nature, but clearly demonstrates the

easy and efficient implementation of a solution. In the context of the Sum Service, a mobile

device only needs to calculate the sum of m integers instead of n integers. The value of n can

be significantly larger than m.

Figure 8.5 displays the possible GUI implementation of the Sum Service where the values of

m and n are inputted by the MAGGIE mobile device user. The first mobile device displayed

in Figure 8.5 is a .NET CF-enabled mobile device, the second being a J2ME MIDP 2.0-

enabled mobile device. The following section discusses the implementation of the negotiation

mechanisms in MAGGIE, enabling negotiations between consumers and producers.

Figure 8.5: Sum Service .2ET CF and J2ME MIDP 2.0 GUI implementations

112

8.3 MAGGIE 2egotiations Implementation

The implementation and utilisation of the supply and demand economic model in MAGGIE

are now described.

8.3.1 The Supply and Demand Economic Model

Economic-based grid computing utilises the services or resources of external parties by

exchanging some form of payment for service and resource utilisation. One such economic

model that stands out as proposed by Buyya is the economic model known as the supply and

demand economic model [Buy00, Buy01].

The demand is defined as the amount of goods or services people are willing to buy at

fluctuating prices. The supply is defined as the amount of goods or services that are offered at

a specific price [Whe96]. An economic environment reaches price equilibrium when the

supply of and demand for services or goods are equal [Buy02, Whe96]. If a state of price

equilibrium is reached, the economic market is regarded as competitive and healthy. Figure

8.6 illustrates the concept of price equilibrium.

In the context of MAGGIE, a producer or supplier supplies their mobile device resources and

MAGGIE services at a specific price for utilisation. The demanding party consists of those

that wish to utilise the mobile device resources and MAGGIE services contributed by the

producer.

When price equilibrium is reached between parties supplying and demanding services and

resources in MAGGIE, both producer and consumer benefit from this economic market state.

Parties demanding the utilisation of mobile devices may do so at reasonable prices. Parties

supplying the utilisation of mobile devices generate a reasonable level of profit. As

illustrated in Figure 8.6, the supply is defined as the number of mobile devices (nodes)

contributing MAGGIE services to MAGGIE. The demand is defined as the price at which

MAGGIE users are willing to pay for the utilisation of MAGGIE services.

Evidently, the objective of MAGGIE is to provide a healthy, yet competitive market for both

consumer and producer. MAGGIE aims to maximise the profits of both the consumer and

producer.

113

Figure 8.6: Price equilibrium graph of MAGGIE (adapted from Whelan and Msefer [Whe96])

8.3.2 The Supply and Demand 2egotiation Variables

The previous subsection motivated the implementation and utilisation of the supply and

demand economic model. As discussed in Chapter 7, each Client Agent instance is embedded

with a Trade Server component. The Trade Server embeds an economic model enabling

negotiation between the Trade Negotiator Agent and Trade Server. In order to successfully

implement the supply and demand economic model, each MAGGIE mobile device user is

able to configure a collection of negotiation variables. The MAGGIE producer negotiation

variables are reflected in the Trade Server and are summarised as follows:

• Peak time price: The price charged for the consumption of resources during peak time

hours.

• Off-peak time price: The price charged for the consumption of resources after peak

time price hours.

• Lunch time price: The price charged for the consumption of resources during lunch

time hours.

114

• Discount: The discount value awarded if a producer is overloaded with existing tasks.

• Raise price: The increased price if there is a large demand for the utilisation of a

MAGGIE service.

• Holiday price: The price charged for the consumption of resources during public

holidays, for example days like Christmas and New Year’s Eve.

• Lunch time hours: The hours defined as lunch time hours of the MAGGIE mobile

device user. For example, the MAGGIE user may define the lunch time hours as 1:00

pm to 2:00 pm.

• Peak time hours: The hours defined as peak time hours of the MAGGIE mobile

device user. For example, the MAGGIE user may define the peak time hours as 9:00

am to 5:00 pm.

The off-peak time hours are the hours that are not in the range of peak time hours and

lunch time hours. From the previous examples given, the off-peak hours are calculated

as 5:00 pm to 9:00 am.

• Discount condition: The integer value indicating how many tasks should be pending

before the MAGGIE mobile device user regards the mobile device as overloaded. If a

MAGGIE mobile device is viewed as overloaded, a discount price is awarded.

• Raise condition: The integer value indicating how many tasks should be pending

before the MAGGIE mobile device user regards the mobile device as overloaded. If a

MAGGIE mobile device is viewed as overloaded, the demand price is increased.

The discount condition and raise condition cannot be of the same value, and the raise

condition must be smaller than the discount condition.

With the implementation of the negotiation values discussed above, MAGGIE producers can

reflect their true requirements. The configurable MAGGIE consumer negotiation variables

will now be discussed.

8.3.3 Consumer 2egotiation Variables

The negotiation variables configured by the MAGGIE consumers are independent of

MAGGIE economic models. The Trade Server compensates for consumer negotiation

variables regardless of the embedded economic model. The implementation of the MAGGIE

consumer negotiation variables is dealt with below.

115

8.3.3.1 Consumer 2egotiation Variables

The MAGGIE consumer negotiation variables can be configured only by MAGGIE mobile

device owners. The MAGGIE consumer negotiations are defined as follows:

• Price per job: The willingness of the consumer to pay per submitted task. The User

Agent allows MAGGIE mobile device users to specify the price per task individually.

• Reliability: Determines the level of reliability the consumer wishes producers to

consist of. The reliability value is discussed at the end of Section 8.3.3.1.

• Margin negotiations factor: The value determining how strict or relaxed a

negotiation may be. The margin negotiations factor value is regarded as a percentage

value and any value larger than 0% is regarded as relaxing the negotiation price by

x%.

For example, consumer Y and producer X are engaged in negotiations and consumer

Y is willing to pay price w. The final negotiation price reached is c more than w and

results in c + w and the relax negotiation factor is r%. If c + w ≤ (w × �

��), the

negotiation price is accepted. The margin negotiations factor enables producers and

consumers to negotiate more realistically without user intervention.

• Maximum allowed tasks pending: The value determining the maximum number of

tasks allowed to be pending on the MAGGIE producer’s mobile device. The value

enables consumers to define what they perceive as overloaded. If this value is -1, then

the number of pending tasks does not play a factor.

• Renegotiation period: The renegotiation period determines how many hours must

elapse before a Worker Agent automatically starts renegotiating for another MAGGIE

mobile device.

As mentioned previously, consumers configure the level of reliability MAGGIE producers

must consist of. Therefore, consumers logically will wish to utilise MAGGIE producers of

high reliability. Consequently, producers in turn will preferably wish to be labelled as highly

reliable.

To solve this problem, MAGGIE does not allow producers to configure their own level of

reliability. MAGGIE automatically calculates the level of reliability of each MAGGIE user as

follows: the number of tasks that are reserved for some device is defined as r and the number

of successfully completed tasks is defined as c. The reliability level is calculated as �� × 100.

The percentage value is stored in GAP and is used to determine the reliability of each

producer as follows:

116

• Extremely poor (0% - 10%).

• Very poor (11% - 20%).

• Poor (21% - 30%).

• Below moderate (31% - 40%).

• Moderate (41% - 50%).

• Above moderate (51% - 60%).

• Good (61% - 70%).

• Very good (71% - 80%).

• Extremely good (81% - 90%).

• Excellent (91% - 100%).

MAGGIE consumers may choose any of the above selected reliability levels when submitting

a collection of tasks for distributed processing. When the Trade Negotiator Agent has

negotiated successfully with Trade Server components, it informs GAP that a reservation has

been made of the designated mobile device. When Worker Agents successfully execute upon

the designated mobile device, they inform GAP that a task was completed successfully.

8.3.3.2 Developer 2egotiation Variables

Developer negotiation variables are required to be implemented by the third-party developers.

These variables are used to determine the minimum hardware specifications of MAGGIE

producers during negotiations. The implementation of developer negotiations is expected

from the third-party developers, because MAGGIE users may not understand the concept of

developer negotiation variables. The developer negotiations variables are defined as follows:

• Minimum CPU: The minimum CPU speed required to process data produced by the

mobile device owner (measured in MHz).

• Minimum RAM: The minimum amount of free RAM required to store and process the data

produced by the mobile device owner (measured in MB).

Developer negotiation variables can be calculated dynamically or statically, depending on the

nature of the application.

117

Implementation of Developer 2egotiation Variables

To aid application developers supplying developer negotiation variables to the User Agent,

the record structure Developer-egotiations has been created. The structure

Developer-egotiations contains three fields:

• Task: The task fragment data required to be processed by MAGGIE mobile device

owners.

• MinimumCPU: The minimum CPU speed required for processing the data.

• MinimumRAM: The minimum RAM required for processing the data.

The implementation of developer negotiation variables determines the minimum resource

specification required to process data. Furthermore, developer negotiation variables can be

calculated individually for each task, enabling high-end and low-end mobile devices to

participate in processing data. Figure 8.7 illustrates the pseudocode implementation of the

Developer-egotiations record structure. It also shows a simple method implementation to

produce Developer-egotiations. The negotiation algorithm implemented by the MAGGIE

supply and demand economic model is given below.

8.3.4 MAGGIE Supply and Demand Algorithm

The supply and demand economic model proves an easy implementation, whilst providing

efficient and dynamic means of negotiations. The negotiation algorithm executed between the

Trade Negotiator Agent and Trade Server is discussed step by step below:

1. Determine if the producer’s CPU speed and amount of free RAM are sufficient for the

consumer negotiation variables. If the CPU speed and amount of free RAM do not

suffice, skip to step 8.

2. Determine if the producer is not overloaded according to the maximum allowed jobs

pending condition. If this is not true, skip to step 8.

3. Determine if the producer’s reliability is sufficient. If this is not true, skip to step 8.

4. Determine the producer’s price according to the appropriate rate as peak time price,

off-peak time price, lunch time price or holiday price.

5. Determine if a discount or raise should be given.

118

Figure 8.7: Implementation of developer negotiation variables

Figure 8.8: Supply and demand economic model negotiation algorithm

119

6. If the consumer’s price equals the producer’s price, accept the negotiation and reserve

the mobile device and continue to step 8, otherwise continue to step 7.

7. Determine if the consumer’s price can be adjusted according to the margin

negotiations factor value and can be accepted as successful.

8. Return the negotiation price reached. If the value is -1, negotiations failed, otherwise

the returned value is the negotiation price reached between consumer and producer.

Figure 8.8 illustrates the pseudocode implementation of the algorithm discussed above. Even

though this algorithm is extremely simple, it proves efficient because both consumer and

producer can reflect their requirements and objectives. The algorithm allows the fluctuation

of prices once negotiation takes place.

8.4 Conclusion

Chapter 8 discussed the strategy implemented by MAGGIE to develop and implement

MAGGIE mobile computing services. It also motivated the implementation of the supply and

demand economic model, in conjunction with consumer and producer negotiation variables.

By implementing the ServiceUnit interface, third-party application developers can implement

domain-specific MAGGIE services efficiently, easily and dynamically. The ServiceUnit

interface enables third-party application developers to concern themselves with only three

concepts of implementing a MAGGIE service:

• The data to be processed by distributed MAGGIE mobile devices.

• The processing of task fragments extracted from Worker Agents.

• The processing of processed task fragments, yielding a final result.

The implementation of the supply and demand economic model allows for the potential

realisation of a healthy and competitive market state to be reached. If such a market state is

realised, both MAGGIE consumers and producers can benefit greatly. MAGGIE consumers

will always strive to attain the best prices, and MAGGIE producers will always strive to

obtain the most profit.

The implementation of consumer and producer negotiation variables allows the MAGGIE

mobile device user complete control over reflected prices and tariffs. The implementation of

developer negotiation variables by third-party application developers can greatly aid

120

negotiation processes in MAGGIE. The dynamic nature of developer negotiation variables

allows each task fragment to be distributed to a mobile device with specific hardware

specifications. The developer negotiation variables do not only aid negotiation processes on a

financial level, but also on a technical level.

Chapter 9 discusses the execution plan of each MAGGIE agent or mobile agent identified in

Chapter 7. It also provides the security mechanisms implemented by MAGGIE to enforce

security.

121

Chapter 9

Agent Execution Plans

“Failing to plan is planning to fail.”

- Alan Lakein

9.1 Introduction

Chapter 8 discussed the implementation strategy of domain-specific or application-specific

MAGGIE services. How MAGGIE supports the implementation of economic models was

also highlighted, as was the implementation of the supply and demand economic model.

Chapter 9 discusses the execution plans (algorithms) of each agent implemented in

MAGGIE. The agents’ execution plan displays how each agent receives input data to reach

its corresponding goal and how each goal is satisfied. Chapter 9 continues to discuss the

implementation of security mechanisms in MAGGIE, providing a secure environment for

MAGGIE agents, mobile devices and users.

9.2 Agent-aiding Components

MAGGIE implements a collection of agents and mobile agents in order to execute correctly

(see Chapter 7). Various mechanisms aid the agents and mobile agents implemented in

MAGGIE.

9.2.1 Client Agent Reservation Entries

MAGGIE automatically calculates the reliability of MAGGIE mobile device users

contributing resources and services to MAGGIE (see Chapter 8). In order to achieve this,

MAGGIE allows agents to create, modify and view Reservation Entries. Reservation Entries

reflect reservations made of the invocation of Client Agent services. All Reservation Entries

are stored in GAP and contain the following structure:

122

• Producer identifier: The unique global identifier of the Client Agent reserved for

service invocation.

• Consumer identifier: The unique global identifier of the Client Agent that will invoke

the service.

• Status: The value reflecting the current status of the Reservation Entry. MAGGIE

differentiates between the following different Reservation Entry status states:

o Pending: The task submitted has been negotiated successfully, but is awaiting

approval to be processed by the authorised MAGGIE consumer.

o Processing: The task is waiting to be processed by the reserved designated

MAGGIE producer.

o Completed: The Reservation Entry executed successfully.

o Failed: The Reservation Entry executed, but errors occurred or the Worker

Agent aborted the designated Client Agent owing to the renegotiation period.

o Cancelled: The reservation was cancelled by the authorised MAGGIE

consumer for reasons discussed in Section 9.3.3.

• Service: The service identifier reflecting the service to be invoked on a MAGGIE

mobile device.

The implementation of Reservation Entries enables MAGGIE to calculate the reliability of

MAGGIE mobile device users. The Reservation Entry also allows MAGGIE mobile device

users to view the process of submitted tasks at any given time.

9.2.2 Worker Agent Storage

GAP implements a mechanism enabling the serialised states of Worker Agents to be stored or

updated. Once a Worker Agent’s state is successfully stored for the first time, a unique

storage key is returned. The storage key is utilised by Job Handler Agents and Worker Agents

to successfully retrieve stored states of Worker Agents. Stored Worker Agent states allow

Worker Agents to resume the last known state they were executing in, and allow Job Handler

Agents to restore Worker Agents that terminated as a result of unexpected errors. The

utilisation of the Worker Agent storage mechanism is discussed in Sections.

123

9.3 Trade 2egotiator Agent

Trade Negotiator Agents migrate from one Broker Domain to the next, negotiating on behalf

of MAGGIE mobile device users. The Trade Negotiator Agent is graphically modelled in

Figure 9.1 as a UML class diagram. The algorithms used by Trade Negotiator Agents to

negotiate with MAGGIE resource producers are explained below.

Figure 9.1: UML class diagram of Trade 2egotiator Agent

124

9.3.1 Trade 2egotiator Agent Initialisation

When the User Agent is signalled to submit a collection of task fragments for distributed

processing, the corresponding Client Agent is signalled to initiate a Trade Negotiator Agent.

The Client Agent in turn provides the following data to the new instance of a Trade

Negotiator Agent:

• -egotiation variables: The negotiation variables configured by the MAGGIE mobile

device owner.

• Task fragments: The task fragments represent the collection of data fragments to be

processed over a collection of distributed mobile devices. The immediate submission

of task fragments enables the Trade Negotiator Agent to supply the Job Handler

Agent with the data to be processed, once negotiations are satisfied.

• Service identifier: The service identifier reflecting the service to be invoked in order

to process the submitted data.

• Virtual organisation identifiers: The collection of VO identifiers the Client Agent is

registered to. These identifiers promote accelerated negotiations as the Trade

Negotiator Agent will first negotiate with Client Agents that reside in identical VOs to

those of the MAGGIE consumer.

9.3.2 Trade 2egotiator Agent Execution Plan

An algorithm enables the Trade Negotiator Agent to negotiate with resource producers and to

migrate to Broker Domains if necessary. The algorithm is executed on the creation or arrival

of a Trade Negotiator Agent in Broker Domains and is discussed step by step below.

1. The digital signature and uniform resource locator (URL) of the Broker Domain is

appended to the history path list of the Trade Negotiator Agent. The history path list

serves as a security mechanism reinforcing the integrity and correct history of the

Trade Negotiator Agent.

2. If the Trade Negotiator Agent has completed all negotiations successfully, continue to

step 8.

3. The next Client Agent is retrieved from the Broker Domain for negotiation purposes.

The first collection of Client Agents is registered to the same VOs as the original

Client Agent that initiated the Trade Negotiator Agent. Similar Client Agents

accelerate negotiations, because VOs in MAGGIE are formed based on similarities

125

between two or more Client Agents. If no Client Agent exists for negotiations,

continue to step 6.

4. The Trade Negotiator Agent records that negotiations are about to be executed with

the extracted Client Agent, and continues negotiations with the embedded Trade

Server component.

5. If the negotiations were successful between the Trade Negotiator Agent and Trade

Server component, the Trade Negotiator Agent signals GAP that a pending

reservation of the Client Agent needs to be recorded. The Trade Negotiator Agent

records the Broker Domain URL the Client Agent resides in, aiding the execution of a

future Job Handler Agent (discussed in Section 9.4.2). Regardless of whether

negotiations were successful or not, continue to step 2.

6. Negotiations have been executed with all possible Client Agents residing in the

Broker Domain. However, not all Trade Negotiator Agent negotiations have been

satisfied successfully. The Trade Negotiator Agent attempts to select a child Broker

Domain not previously visited as its next migration destination. If no such child

Broker Domain exists, the parent Broker Domain is selected.

If no parent Broker Domain exists, the Trade Negotiation Agent is currently residing

in the Broker Agent. Consequently, the Trade Negotiator Agent’s path history list is

cleared and the algorithm is restarted. However, if a Broker Domain was selected for

migration, continue to step 7.

7. The Trade Negotiator Agent releases all resources it utilises and migrates to the

designated Broker Domain.

8. The Trade Negotiator Agent successfully satisfied negotiations and destroys itself,

after storing its serialised state at GAP.

The following subsection describes the approval of successful Trade Negotiator Agent

negotiations via the authorised MAGGIE mobile device user.

9.3.3 2egotiation Approval

When negotiations are satisfied successfully, MAGGIE mobile device users either accept or

decline the negotiation agreements. If negotiations are declined, the corresponding pending

Reservation Entries are modified as cancelled. A user may decline negotiations because the

negotiation prices are too expensive. If negotiation agreements are approved, a Job Handler

Agent is initiated, discussed in the following section.

126

9.4 Job Handler Agent

The Job Handler Agent provides designated MAGGIE mobile devices with task fragments to

be processed and recollects all processed results (see Chapter 7). The Job Handler Agent is

graphically modelled in Figure 9.2 as a UML class diagram. The algorithms utilised by the

Job Handler Agent are given below.

Figure 9.2: UML class diagram of Job Handler Agent

127

9.4.1 Job Handler Agent Initialisation

When MAGGIE mobile device users accept successful negotiations, the corresponding Client

Agent initiates a Job Handler Agent. The Job Handler Agent is provided with the following

data by the Client Agent:

• Task fragments: The task fragments originally submitted by the MAGGIE mobile

device user for distributed processing.

• Designated mobile devices: The list of entries reflecting the designated MAGGIE

mobile devices as provided by the Trade Negotiator Agent. Each entry contains the

following fields:

o Client Agent identifier: The designated Client Agent’s unique identifier.

o Sub-Broker Domain URL: The last reported Broker Domain URL the

designated Client Agent was recorded to be residing in.

o Price: The negotiation price reached during the negotiation process.

• -egotiation variables: The original negotiation variables submitted by the MAGGIE

mobile device user.

• Service identifier: The service identifier of the MAGGIE service to be invoked for

processing the submitted task fragments.

9.4.2 Job Handler Agent Execution Plan

During its life cycle, a Job Handler Agent always resides on the Broker Domain it was

initiated on. The execution plan of the Job Handler Agent that enables it to create, deploy and

monitor Worker Agents is discussed step by step below:

1. The Job Handler Agent initiates the correct number of Worker Agents, which may not

always correspond to the number of submitted tasks. The number of Worker Agents

deployed is determined by the number of unique Broker Domains visited by the Trade

Negotiator Agent where successful negotiations were made.

For example, Trade Negotiator Agent t made successful negotiations with Client

Agents x, y and z. Client Agents x and y resided on Sub-Broker Agent A and Client

Agent z on Sub-Broker Agent B. The Job Handler Agent creates two Worker Agents,

one that will migrate to Client Agents x and y and the other to Client Agent z.

128

The proposed approach is implemented because the likelihood that Client Agents will

reside on the same Broker Domain between logins is high. The proposed approach

holds the following advantages:

o The Job Handler Agent is required to monitor fewer Worker Agents.

o Fewer Worker Agents result in less generated network traffic.

o Fewer Worker Agents result in minimised computer hardware consumption.

2. When all Worker Agents are initiated, the Job Handler Agent stores the initial state of

each Worker Agent in GAP. During the process of storing the Worker Agents, the Job

Handler Agent retrieves the unique storage key for each Worker Agent. The Job

Handler Agent deploys each Worker Agent. The execution plan of the Worker Agent

is discussed in Section 9.5.2.

3. All Worker Agents have been deployed successfully. The Job Handler Agent initiates

threads that listens for incoming heart-beat messages from the deployed Worker

Agents.

In the scenario where a Worker Agent does not respond within 2 minutes, the Worker

Agent is reinitiated and redeployed by the Job Handler Agent. The Job Handler Agent

fetches the stored state of the dead Worker Agent from GAP and redeploys the

Worker Agent. Because of the intermittent and unreliable connectivity exhibited by

wireless networks, 2 minutes is proposed as a realistic time frame in which Worker

Agents can respond rather than a time frame of a few seconds.

4. The Job Handler Agent periodically determines the number of Worker Agents that

have returned successfully. When all the Worker Agents have returned successfully,

continue to step 5. If not all Worker Agents have returned, step 4 is repeated.

5. Each Worker Agent has returned successfully and the Job Handler Agent stores all

retrieved and processed results in GAP. The Job Handler Agent releases all utilised

resources and destroys itself.

The processed results are collected via the authorised MAGGIE mobile device user for the

final assessment.

129

9.4.3 Collecting Processed Results

MAGGIE mobile device users can download complete processed results via GAP. The

downloaded results are handled automatically by the User Agent. The User Agent invokes the

correct ServiceUnit instance and the method processResults(string[] results). The final

processing or assessment of the data is determined by the domain-specific MAGGIE service.

9.5 Worker Agent

The Worker Agent migrates to the designated MAGGIE mobile devices, enabling task

fragments to be processed accordingly (see Chapter 7). In some scenarios, the Worker Agent

may even act as a Trade Negotiator Agent. The Worker Agent is graphically modelled in

Figure 9.3 as a UML class diagram. The Worker Agent is then initialised.

Figure 9.3: UML class diagram of Worker Agent

130

9.5.1 Worker Agent Initialisation

The Worker Agent is initiated by the Job Handler Agent as discussed in Section 9.4.1. The

Job Handler Agent provides the following data to the Worker Agent:

• -egotiation variables: The original negotiation variables submitted by the MAGGIE

mobile device user.

• Service identifier: The service identifier of the MAGGIE service expected to be

invoked.

• Work entries: A collection of Work Entries are provided where each Work Entry

represents a task fragment to be processed by a MAGGIE mobile device. Each Work

Entry contains the following fields:

o Designated producer identifier: The designated Client Agent’s unique

identifier.

o Task fragment: The task fragment to be processed by the designated Client

Agent.

o Price: The negotiation price reached during the negotiation process.

• Storage key: The unique storage key of the Worker Agent used to store its own state.

The algorithm enabling the Worker Agent to process each work entry successfully is

discussed in the following subsection.

9.5.2 Worker Agent Execution Plan

The algorithm described below is executed when a Worker Agent is deployed by a Job

Handler Agent or arrives at a designated Broker Domain when migrating:

1. The Worker Agent stores its current state at GAP by using the storage key provided.

2. The Worker Agent evaluates its execution state. If the execution state is marked as

negotiating, continue to step 7, otherwise continue to step 3.

3. The Worker Agent retrieves the next Work Entry. If no Work Entry exists, continue to

step 6.

131

4. The Worker Agent utilises the look-up mechanism of the Broker Domain it resides in,

retrieving the Broker Domain URL the designated Client Agent resides in. If the

Client Agent was retrieved successfully, the state of the Worker Agent is stored in

GAP and the Worker Agent migrates to the designated Broker Domain. If the Client

Agent was not found, continue to step 5.

5. The Worker Agent determines the time span elapsed regarding the unreachable Client

Agent. If the elapsed time span is equal to or greater than the renegotiation period

defined in the negotiation variables, the Work Entry is marked as abandoned. The

abandoned Work Entry is moved to the list of abandoned Work Entries.

If the Work Entry was marked as abandoned, the corresponding Reservation Entry is

modified as cancelled. Regardless of the outcome, return to step 3.

6. The Worker Agent retrieves the next abandoned Work Entry. If an abandoned Work

Entry does exist, the Worker Agent is required to locate a new Client Agent capable

of processing the Work Entry.

The Worker Agent then utilises the algorithm of the Trade Negotiator Agent as

discussed in Section 9.3.2. The execution state of the Worker Agent is marked as

negotiating and continues to step 7. If no abandoned Work Entries exist, continue to

step 8.

The negotiation variables remain identical, except the willing price to pay value is

modified to the original price reached, and the margin negotiation factor value is set

to 0%. The modified negotiation variables ensure that the MAGGIE mobile device

owner pays the same price as or a lower price than previously reached.

7. The first step of the Trade Negotiator Agent execution plan is executed and followed.

The sole difference between the Worker Agent’s negotiation algorithm and Trade

Negotiator Agent discussed in Section 9.3.2 is step 8: Once step 8 is reached, a new

Work Entry is created and Worker Agent returns to step 1 of the Worker Agent

algorithm.

8. There are no valid or abandoned Work Entries left, so the Worker Agent returns to the

Job Handler Agent.

The execution plan of the Worker Agent described above is illustrated in Figure 9.4. The

Worker Agent has an execution plan when it migrates to the designated Client Agent for

processing.

132

Figure 9.4: UML activity diagram of Worker Agent execution plan

9.5.3 Worker Agent Migration to Mobile Devices

The previous subsection discussed the execution plan of the Worker Agent, but did not

explain how data is transported between Worker Agents and User Agents. The following

subsections explain how Worker Agents migrate to designated User Agents for execution.

133

Worker Agent Docking

Worker Agents migrate to a designated Client Agent to be processed. Once a Worker Agent

arrives in the residing Broker Domain of the designated Client Agent, the Worker Agent is

appended to a First-In, First-Out (FIFO) queue of Worker Agents.

When a Worker Agent is ready for dispatchment to a User Agent for execution, only the

necessary data is extracted from the Worker Agent. The extracted data is provided to the User

Agent and the Worker Agent is removed from the Worker Agent queue. The following data is

extracted from the Worker Agent:

• Storage key: The storage key embedded within the Worker Agent.

• Task fragment: The task fragment to be processed by the User Agent.

• Service identifier: The service identifier of the expected MAGGIE service to be

invoked.

• Job Handler URL: The URL of the Job Handler Agent. The URL enables heart-beat

message notifications to still occur between the Job Handler Agent and Worker

Agent.

After the Worker Agent has stored its state at GAP, the remaining data of the Worker Agent

is destroyed. After the User Agent accepts the incoming Worker Agent successfully, the

Worker Agent’s storage key and processed results are returned to the Client Agent. The

previously stored state of the Worker Agent is retrieved, and the Worker Agent is reinitiated

and executed. The Client Agent modifies the Worker Agent’s state, notifying the reinitialised

Worker Agent that a task was executed successfully, and provides the processed result. The

Worker Agent continues the execution plan at step 1 discussed in Section 9.5.2.

9.6 User Agent

The previous section explained how a Client Agent enables a Worker Agent to process the

task fragments embedded within the Worker Agent on the User Agent. The User Agent is

graphically modelled in Figure 9.5 as a UML class diagram. Now the execution plan of the

User Agent accepting a Worker Agent ready for processing will be discussed. The User

Agent execution plan is illustrated in Figure 9.6.

134

Figure 9.5: UML class diagram of the User Agent

1. The User Agent determines how much free memory (RAM) is available on the mobile

device. The amount measured in MB is posted to the Client Agent, advertising how

much processing memory is available.

2. The Client Agent determines if the first Worker Agent in the queue has a minimum

RAM negotiation value less than or equal to the free memory posted by the User

Agent. If the User Agent contains enough free memory, the necessary data is

extracted from the Worker Agent (see Section 9.5.3). The extracted data is provided

to the User Agent. If there was not enough free memory for execution, step 1 is

repeated.

135

Figure 9.6: UML activity diagram of Worker Agent dispatching onto a User Agent

3. Worker Agent (see Section 9.5.3). The extracted data is provided to the User Agent. If

there was not enough free memory for execution, step 1 is repeated.

4. The Worker Agent data is used to create a scaled-down Worker Agent on the

MAGGIE mobile device and is executed by the User Agent. The User Agent invokes

the correct MAGGIE service by utilising the service identifier provided by the

Worker Agent.

136

The Worker Agent is executed and the result is returned to the Client Agent. The

scaled-down Worker Agent is destroyed and the User Agent repeats step 1.

The execution plan discussed above is repeated until the User Agent is destroyed and the

MAGGIE mobile device application terminates. During the course of the Worker Agent

execution plan, the scaled-down Worker Agent still continues notifying the Job Handler

Agent of its existence. The Worker Agent notifies the User Agent, the User Agent notifies the

Client Agent, which in turn notifies the Job Handler Agent.

The initialisation, execution and behaviour of the agents and mobile agents present in

MAGGIE were highlighted above. Next, the security mechanisms implemented by MAGGIE

to ensure a safe and secure economic mobile computing environment will be pointed out.

9.7 MAGGIE Security

Chapter 5 discussed the security threats and solutions targeted at agents, mobile agents,

mobile agent hosts and mobile devices in J2ME MIDP 2.0 and .NET CF. It is essential that

MAGGIE incorporate security mechanisms to prevent potential attacks against MAGGIE

mobile devices and components. Asymmetric encryption and decryption algorithms are

utilised by MAGGIE.

9.7.1 Rijndael Encryption Algorithm

The Rijndael algorithm was elected as the new AES by the US National Institute of Standards

and Technology (NIST) in 2002 [Jam04]. This algorithm is implemented for the protection of

unclassified government data. It is considered to be so strong that if a machine could be built

retrieving one DES key per second, it would take the machine roughly 149 thousand billion

years to decipher an AES key that has a bit-length of 128 [Jam04].

Owing to the impressive and secure encryption Rijndael provides, MAGGIE utilises the

Rijndael algorithm for symmetric encryption and decryption purposes. MAGGIE specifically

implements a 256-bit key for encryption and decryption of sensitive data. Both Sun

Microsystems’s J2ME MIDP 2.0 and Microsoft’s .NET CF provide Rijndael algorithm

implementations [Sun04A]. The Rijndael algorithm enables successful encryption and

decryption between MAGGIE, J2ME MIDP 2.0 and .NET CF platforms.

137

9.7.2 MAGGIE Mobile Host Protection

Chapter 5 stressed the importance of protecting mobile agent hosts against malicious mobile

agents that may wish to attack or harm the mobile agent host. In MAGGIE, each Broker

Domain may act as an execution environment for Trade Negotiator Agents and Worker

Agents.

To protect each Broker Domain against potentially malicious Trade Negotiator Agents and

Worker Agents, MAGGIE implements the path histories technique discussed in Chapter 5,

Section 5.2.2.2(d). Consequently, the path history of each Worker Agent and Trade

Negotiator Agent is examined by the Broker Domain and also signed by the Broker Domain

itself. The path history of each Trade Negotiator Agent and Worker Agent enables Broker

Domains to accept migrating agents only arriving from trusted MAGGIE Broker Domains.

9.7.3 MAGGIE Mobile Agent Protection

Chapter 5 emphasised the importance of protecting mobile agents against malicious mobile

agents, mobile agent hosts and external threats. In MAGGIE, protecting migrating mobile

agents between Broker Domains is critical. The compromise of Trade Negotiator Agents and

Worker Agents may prove disastrous for one or more parties involved. Two case scenarios

are discussed:

• Scenario one: Assume a Trade Negotiator Agent migrates via various Broker

Domains, negotiating with parties on behalf of user u. Successful negotiations were

made between user u and producer x at price a. Competitors of producer x can capture

and modify price a by increasing the value of a significantly. The modified price may

result in the loss of business for producer x, as user u may decline the offers provided

by the Trade Negotiator Agent.

• Scenario two: Assume that a Worker Agent migrates back and forth between

MAGGIE and a collection of designated MAGGIE mobile devices. An attacker can

successfully steal or modify the results of processed task fragments. The modified

task fragments lead to the Job Handler Agent harvesting incorrectly processed data,

which in turn leads to the MAGGIE mobile device user analysing corrupted results.

It is evident that the protection of mobile agents in MAGGIE is crucial to ensure a fair

economic environment and correct results. To implement mobile agent security, MAGGIE

implements the technique known as the sliding encryption technique discussed in Chapter 5,

Section 5.2.2.1(b).

138

Consequently, the state of the Trade Negotiator Agent and Worker Agent is always encrypted

before and decrypted after migration between Broker Domains. The encryption and

decryption are executed by using a global key in conjunction with the Rijndael algorithm.

The global key is stored and kept secret at every Broker Domain (see Figure 9.7). The

implementation of the global key enables migrating agents to be protected from illegitimate

MAGGIE Broker Domains. The proposed security technique also protects legitimate

MAGGIE Broker Domains from illegitimate MAGGIE mobile agents.

The technique discussed above is also implemented to encrypt and decrypt Worker Agent

data between MAGGIE and MAGGIE mobile devices. The key used is unique and separate

from the global security key embedded in each Broker Domain, and cannot be accessed or

viewed by application developers. The key is hidden because the security key is declared as a

private constant in the underlying MAGGIE libraries (see Figure 9.7). However, the hidden

key can still be retrieved by means of reverse engineering of the MAGGIE mobile device

libraries.

To prevent the exposure of the hidden key, MAGGIE libraries (both J2ME and .NET CF) are

obfuscated using code obfuscators, thus requiring more effort to reverse engineer MAGGIE

libraries. Additionally, MAGGIE expects and demands each device utilising MAGGIE to

support SSL implementations. The distribution of MAGGIE Rijndael symmetric keys is

displayed in Figure 9.7.

9.7.4 Rogue Mobile Devices

An attacker may use the MAGGIE libraries to implement a rogue MAGGIE-enabled

solution. The rogue mobile device pretends to be hosting a collection of legitimate MAGGIE

services, when in actual fact it may alter, ignore or corrupt data and results extracted from

Worker Agents.

To prevent the threat of rogue mobile devices, application developers can embed security

tokens in task fragments, which are extracted and validated by the MAGGIE services.

However, attackers can reverse engineer or decompile the solutions and view the methods of

generating and validating the security token segments. Once more, this is motivation for all

MAGGIE-enabled grid service solutions to be obfuscated, hiding the techniques implemented

to generate and validate security tokens.

9.7.5 Single Sign-on Mechanism

When MAGGIE mobile device users wish to utilise MAGGIE and log in, a username and

139

Figure 9.7: MAGGIE symmetric key distribution

password (login credentials) are provided to GAP. GAP authenticates the login credentials

provided by the user and provides the user with an encrypted security token, by utilising the

Rijndael algorithm. The security token is generated by using a separate symmetric key (see

Figure 9.4) and is unique and separate from the Broker Domain security key and embedded

security key found in MAGGIE libraries.

If a User Agent wishes to invoke any service on a leaf Sub-Broker Domain, it requires the

security token provided for validation. Once the security token is received, it is decrypted and

validated. Every generated security token is unique and embedded within it is the unique

identifier of the MAGGIE mobile device owner. The security tokens provided by each

MAGGIE mobile device enables a Sub-Broker or Broker Domain to determine the

authenticity and ownership of the security token. The process of providing and validating

security tokens eliminates the process of the User Agent logging into MAGGIE each time it

wishes to receive or send data.

9.8 Conclusion

Chapter 9 set out the execution plans of the Trade Negotiator Agent, Job Handler Agent,

Worker Agent and User Agent, explaining how each agent receives tasks and how they are

satisfied. Each agent requires as little interaction as possible from the MAGGIE mobile

device owners on whose behalf they act. The execution plan of each agent clearly indicates

that each agent and mobile agent in MAGGIE is well specialised to satisfy its collection of

tasks.

140

The Job Handler Agent in conjunction with the Worker Agent successfully accommodates

the unpredictable nature of wireless networks via the implementation of heart-beat messages.

The Worker Agent also accommodates the scenario where task fragments are not processed

owing to long inactive periods of MAGGIE users, by acting as a Trade Negotiator Agent.

Security mechanisms are implemented in MAGGIE to ensure a fair and secure economic

environment. MAGGIE utilises primarily the sliding encryption technique to ensure the safe

encryption and decryption of migrating mobile agents in MAGGIE. It uses the Rijndael

algorithm (AES) because of its apparent strength and security, and provides a safe and

reliable execution environment for agents, mobile agents, mobile agent hosts and MAGGIE

mobile device users.

The MAGGIE architecture is compiled of a collection of intelligent, well-defined and role-

specific agents. The implementation of the MAGGIE agents discussed in this chapter enables

the user to participate in MAGGIE with the minimum user intervention required.

Additionally, the security mechanisms of MAGGIE provide a safe execution environment for

all MAGGIE agents and MAGGIE Broker Domains. The safe execution environment of

MAGGIE, in turn, provides a fair and safe economic environment for resource consumers

and resource producers of MAGGIE. Therefore, MAGGIE enforces security and ensures that

sensitive data of resource consumers and resource producers remains confidential and secure.

Chapters 7, 8 and 9 provide the complete collection of components, mechanisms and agents

enabling the implementation, development and utilisation of mobile device resources and

MAGGIE services. Chapter 10 discusses the implementation of the MAGGIE Chess Service,

enabling mobile device users to determine the best playable move from a chessboard

position.

141

Chapter 10

MAGGIE Chess Service Implementation

“Personally, I rather look forward to a computer program winning the

world chess championship. Humanity needs a lesson in humility.”

- Richard Dawkins

10.1 Introduction

Chapters 7, 8 and 9 set out the architecture, service implementation, negotiation mechanisms

and agent execution plans of MAGGIE. Chapter 10 discusses the implementation of the

MAGGIE Chess Service. This service allows a mobile device user to play chess beyond the

resource specifications of a mobile device.

The chess search algorithm selected by MAGGIE is highlighted and reasons are given for the

selection of the search algorithm. Lastly, the implementation of the search algorithm is

discussed, as is the generation of developer negotiations used in the MAGGIE Chess Service.

The correct generation of the developer negotiations is essential, as they enable both high-

and low-end mobile devices to participate in processing a collection of task fragments.

10.2 Algorithm Selection

The chess search algorithm chosen for the MAGGIE Chess Service is the Alpha-Beta pruning

algorithm. This algorithm was chosen based on two facts [Pla96]:

• Cut-offs: Alpha-Beta prunes sub-trees and nodes, potentially examining two times the

square root of the number of nodes present in the game tree [Mar82].

• Memory: The storage efficiency is excellent and is noted as O(d),with d being the

depth.

Alternative search algorithms like SSS* prove more efficient than the Alpha-Beta pruning

algorithm, but are known as being memory intensive [Bha95, Kai91, Pla96, Rei93]. Thus,

SSS* does not prove to be a viable solution for mobile devices and, more particularly,

MAGGIE.

142

MAGGIE primarily supports the execution of asynchronous Worker Agents, where Worker

Agents have little to no interaction with one another. An algorithm such as SSS* may require

more synchronisation amongst Worker Agents. This can increase the network traffic and

decrease the performance of MAGGIE and therefore SSS* is not a viable solution.

Chapter 6 discussed enhancements implemented in the Alpha-Beta pruning algorithm with

the primary focus on chess. The following Alpha-Beta pruning enhancements are

implemented on both lower-end and higher-end mobile devices:

• Aspiration windows.

• Minimal windows.

• Killer heuristics.

• Move ordering.

• Null-move heuristic.

The following Alpha-Beta enhancements are implemented on higher-end MAGGIE mobile

devices:

• Transposition tables.

• Quiescence searches.

The transposition tables and quiescence search techniques are implemented only on higher-

end MAGGIE mobile devices because of larger memory budgets. These techniques may

prove to be too large for the smaller memory budgets of lower-end mobile devices.

10.3 Distributed Alpha-Beta Pruning Algorithms in

MAGGIE

The previous section motivated the selection of the Alpha-Beta pruning algorithm and proved

to be the superior algorithm for mobile devices. Two distributed Alpha-Beta pruning

algorithm strategies are proposed by MAGGIE:

• Normal pruning algorithm.

• Enhanced pruning algorithm.

143

10.3.1 2ormal Pruning Algorithm

The normal pruning algorithm (NPA) is a proposed strategy, dividing a number of game tree

branches into different sections. Each section is distributed to mobile devices for further

analysis. The NPA is targeted at both high-end and low-end mobile devices owing to its

minimal resource constraints.

For example, chessboard position x generates four legal moves: A, B, C and D, which are

coloured red in Figure 10.1. The legal moves A, B, C and D generate sub-trees e, f, g and h,

respectively, and are distributed over four mobile devices. Consequently, each red node is

treated as the first move resulting from position x on distributed MAGGIE mobile devices.

Each distributed mobile device examines only the sub-trees generated by each move, where

an evaluation score is assigned. Ultimately, the four assigned evaluation scores are returned

to the original MAGGIE mobile device. Finally, the best move is determined by selecting the

maximum evaluation score.

Figure 10.1: 2ormal pruning algorithm graph

The proposed NPA is discussed step by step below:

1. Calculate the legal moves originating from the initial position X to a depth of 1.

2. If n number of moves were generated, where n ≥ 1 then let �, ��, …. ��, �� reflect

each move. Each move is distributed over mobile devices �, ��, …. ��, ��.

144

3. Each distributed mobile device analyses the position utilising the Alpha-Beta pruning

algorithm, assigning an evaluation score to each move. Each mobile device generates

results �, ��, …. ��, ��, with each result representing the assigned evaluation score.

The collection of evaluation scores is returned to the original mobile device for final

assessment.

4. The maximum evaluation score is retrieved by invoking a maximum function known

as max(�, ��, …. ��, ��), where parameter a represents an integer and i ≥ 1.

Invoking max returns the maximum evaluation score ��, with 1 ≤ ! ≤ ". The

retrieved evaluation score ��’s corresponding move �� is executed.

The proposed NPA is straightforward, but proves efficient as each mobile device is required

to analyse only a small subset of the entire game tree.

10.3.2 Enhanced Pruning Algorithm

The NPA proves ideal for extremely resource-constrained mobile devices. However, it might

underutilise a mobile device containing larger memory budgets or computational capabilities.

The proposed enhanced pruning algorithm (EPA) is viewed as a halt-continue Alpha-Beta

pruning algorithm. The original mobile device analyses the game tree to a specific depth, and

distributed mobile devices analyse the provided moves to a deeper depth.

In the EPA, only the n highest evaluation scored moves are analysed, where n ≥ 1 and n is

defined by the user. The EPA enables moves that may not seem as strong6 to be analysed to a

deeper depth. For example, a sacrifice might not seem strong at a specific depth, but can

prove to be a winning move at a deeper depth. The EPA is discussed step by step below:

1. An initial chessboard position X is analysed to depth d by utilising the Alpha-Beta

pruning algorithm, resulting in generated moves defined as ", "� … "�, "� where i

≥ 1. Each generated move contains an assigned evaluation score and is ordered from

the highest to the lowest score. Consequently, " reflects the highest scored move at

depth d, and "� reflects the lowest scored move at depth d.

2. The top n moves are extracted, where n ≥ 1 and n is defined by the user. The top n

moves are defined as ', '�, … '�, '�.

3. Each move in ', '�, … '�, '� is analysed over mobile devices �, ��, …. ��,

�� to a depth of (, where ( ≥ d.

6 The word strong is referred to as a chess move that may ensure or improve probability of victory.

145

4. Each distributed mobile device analyses the move provided and generates results �,

��, …. ��, ��.

5. The maximum result entry is retrieved by invoking a maximum function known as

max(�, ��, …. �), �)), where parameter a represents an integer and k ≥ 1.

Invoking max returns the maximum evaluation score ��, with 1 ≤ ! ≤ *. The

retrieved evaluation score ��’s corresponding move "� is executed.

It is evident that the proposed EPA enables more capable MAGGIE mobile devices to firstly

analyse a position to a depth of d. Distributed MAGGIE mobile devices then analyse a

position to a depth of (. Consequently, only the most promising moves are further analysed

to a depth of ( (see Figure 10.2).

10.3.3 EPA Advantages and Disadvantages

The EPA has the following inherent advantages:

• Stronger moves are analysed to a deeper level and an initial weaker move may prove

stronger at a deeper depth.

• Only a specified number of moves are analysed over a collection of distributed

MAGGIE mobile devices. This translates into the fact that a user does not need to

analyse all generated moves originating from a chessboard position. This means that a

user will pay less for better results.

The EPA has the following disadvantage:

• A chess move may initially appear extremely weak but instead may lead to a stronger

or even forced win position. Initial weak moves are commonly classified as sacrificial

moves, where a higher-order piece is sacrificed for a lower-order piece. The sacrificial

move then exploits the opponent’s position at a deeper depth.

The implementation of the developer negotiation variables utilised by the MAGGIE Chess

Service is now explained.

146

Figure 10.2: Effects of EPA on a game tree

10.4 Determining Developer 2egotiation Variables

Developers of domain-specific MAGGIE services are required to supply MAGGIE with

developer negotiation variables. These variables are embedded with the minimum hardware

specifications needed to process task fragments.

10.4.1 Size Prediction of a Chess Alpha-Beta Tree

The MAGGIE Chess Service aims to determine the average number of moves that may

originate from a chessboard position. It is crucial to the MAGGIE Chess Service to calculate

the most accurate number of moves originating from a chessboard.

For example, a chessboard position generates a game tree of z nodes, where approximately x

nodes are evaluated and the size of each node is y bytes. The mobile device evaluating the

position requires an average of y × x bytes to prevent out of memory errors. Such a

147

mechanism would allow the MAGGIE Chess Service to approximate the required primary

memory (RAM) needed by a producer in evaluating a chessboard position.

10.4.1.1 Chess Alpha-Beta Prediction Problems

The number of leaf nodes generated in a game tree with a depth of d and an expansion factor

of W is calculated as +, [Pla96]. The same approach is implemented in determining the

number of moves generated from a chessboard position to depth d.

In chess, however, the expansion factor can vary greatly from one position to the next. A

chessboard position may generate an average of 40 legal moves at any given time. However,

when a king is placed in check, this can drop to as little as 1 legal move. The fluctuating

expansion factor means that the formula +, does not suffice. Four approaches are proposed

in order to calculate the game tree size originating from a chessboard position:

• Single side prediction (SSP).

• Single side adaptive prediction (SSAP).

• Double side prediction (DSP).

• Double side adaptive prediction (DSAP).

The four approaches listed above are classified into two broad categories:

• Prediction formulae (PF).

• Adaptive prediction formulae (APF).

The SSP and DSP are classified as prediction formulae and SSAP and DSAP as adaptive

prediction formulae.

10.4.1.2 The Prediction Formula

The proposed PF is a straightforward formula in predicting the game tree to a specific depth

of a chessboard position. The PF formula is noted as f (w, d) = -,, where w is the expansion

factor and d is the depth that must be searched to. Consequently, the PF implements the

original formula used to predict Alpha-Beta tree sizes.

148

10.4.1.3 The Adaptive Prediction Formula

The proposed APF is an extension of the PF. The APF implements the formula noted as

f (w, d, z) = (w + z(d – 1)) × (w + z(d – 2)) × ..... × (w – z(0)). Parameters w and d serve as

the parameters defined in the PF. Variable z is defined as the adaptive factor and is

determined based on the current state of the chessboard position. To determine the value of z,

the nature of a typical chess game must first be understood. A chess game resides in one of

three states:

• The opening game.

• The middle game.

• The end game.

If a chess game resides in the opening game state, the number of possible moves (expansion

factor) is likely to increase over time as pieces develop. If a chess game resides in the middle

game, one of two positions will follow [Wil06]:

• Closed position: A closed position is defined as a position where few to no open files

and ranks exist on a chessboard, and pieces’ mobility is limited. Consequently, few to

no exchanges are made, leaving the chessboard with many pieces on both sides.

• Open position: An open position is defined as a position where moderate to many

open files and ranks exist on a chessboard, and pieces’ mobility is developed.

Consequently, some exchanges are made, leaving the chessboard with fewer pieces on

both sides.

Regardless of the position, both lead to a smaller number of possible moves. Closed positions

lead to cramped pieces and open positions lead to fewer pieces, both leading to a smaller

number of possible moves.

When a chess game resides in the end game state, the number of pieces on the chessboard is

much smaller, leading to a significant decline in the number of moves allowed. Consequently,

the value of z is determined by the current state the chessboard resides in. The following

values can be assigned to z:

• Opening game: The value is +1, because pieces will develop in the opening game,

leading to more possible moves.

• Middle game: The value is -0.5, because a position will lead to either a closed or open

position, both leading to a small decline in possible moves.

149

• End game: This value is -1, because the position will lead to a smaller number of

playable pieces, leading to a decline in possible moves.

The APF adapts the expansion factor with each depth, compensating for the increase and

decrease in the number of moves. The following example displays the APF when the chess

game resides in the middle game state. The parameters w, d and z contain the values 23, 4 and

-0.5, respectively:

APF(23, 4) = (23 + (4 – 1)(-0.5)) (23 + (4 – 2)(-0.5)) (23 + (4 – 3)(-0.5)) (23 + (4 – 4)(-0.5))

= (23 + (3)(-0.5)) (23 + (2)(-0.5)) (23 + (1)(-0.5)) (23 + (0)(-0.5))

= (23 – 1.5) (23 – 1) (23 – 0.5) (23)

= (21.5) (22) (22.5) (23)

= 244777.5

= 244778

Both the PF and APF receive the expansion factor as a parameter. The formulae implemented

in determining the expansion factor are given below.

10.4.1.4 Single Side Expansion Factor

The SSE formula calculates the expansion factor by taking into account the number of

possible moves that can be played by one side. The side that is taken into account is the side

that is to play. If the playing side is in check, the average number of moves of the opponent’s

side is determined, and the expansion factor is calculated as the average numbers of moves by

both sides.

10.4.1.5 Double Side Expansion Factor

The DSE formula calculates the expansion factor by investigating both sides. The number of

possible moves of the playing side is first determined. Every possible move is executed, and

the number of possible moves of the opposite side is determined. The expansion factor is

calculated as the average numbers of playable moves by both sides. The DSE in algebraic

notation is as follows:

The playing side generates n number of moves where the n moves are defined as

�, ��, �. … ��, ��, ��. Each move is played and the number of moves of the opposite

side is determined and is notated as /� for every move �� , where 0 ∈ 2, 0 ≥ 1 �"( 0 ≤". The DSE value is formulated as (" + (/ + /� + /. + /�� + /� + /�) ÷ ") ÷ 2.

150

As seen above there are various formulae that MAGGIE could implement in order to

calculate the expansion factor and the size of the game tree. The methods implemented to

determine which combination of proposed formulae proves superior in predicting the game

tree size are now explained.

10.4.2 The Superior Approach

Two formulae were proposed for calculating the expansion factor, namely the SSE and DSE.

Two proposed formulae were also provided in calculating the number of chess positions

resulting from a chessboard position, namely the PF and APF. The following four approaches

are proposed (see Section 10.4.1.1):

• Single side prediction (SSP): The SSP implements the single side expansion factor in

conjunction with the PF.

• Single side adaptive prediction (SSAP): The SSAP implements the single side

expansion factor in conjunction with the APF.

• Double side prediction (DSP): The DSP implements the double side expansion factor

in conjunction with the PF.

• Double side adaptive prediction (DSAP): The DSAP implements the double side

expansion factor in conjunction with the APF.

In order to illustrate which of the four proposed approaches prove the most superior, 18 chess

games were analysed. Ten of the games were analysed to a depth of 4 and are famous games

played by Grandmaster Garry Kasparov. Five of the games were analysed to a depth of 5 and

are famous games played by Grandmaster Robert James Fischer (Bobby Fischer). Three of

the games were analysed to a depth of 6 and are famous games played by Grandmaster Jose

Raul Capablanca. The analysis data generated for the 18 chess games is listed in Appendix A

and summarised in Table 10.1. The following columns are defined in Table 10.1:

• Depth: The depth to which the number of moves was analysed.

• -umber of games: The number of games that were analysed to the specific depth.

• Real count (RC): The actual average number of possible moves calculated to a

specific depth. The calculation of the RC value is discussed in Appendix A, Section

A.2.

151

• SSP, SSAP, SSAP, DSP and DSAP: The average number of possible moves predicted

by SSP, SSAP, DSP and DSAP.

The Total row displays how well each proposed approach performed when compared to the

real count value. Table 10.1 clearly shows that at all depths, the DSP proved most accurate

and is therefore implemented by MAGGIE.

Figures 10.3, 10.4 and 10.5 display the line graphs representing the real count, SSP, SSAP,

DSP and DSAP at depths 4, 5 and 6, respectively. The y-axis of the graphs depicts the

number of moves predicted or counted. The x-axis of the graphs depicts the specified chess

game played.

Depth Number of Games RC SSP SSAP DSP DSAP

4 10 1688678.56 2231892.76 2069290.36 1725725.36 1588300.94

75.66% 81.61% 97.85% 94.06%

5 5 71445325.38 99043404.16 87746921.26 72880962.28 64291729.8

72.14% 81.42% 98.03% 89.99%

6 3 2005850899 3335639998 2242110966 2317715606 1890661402

60.13% 89.46% 86.54% 94.26%

Total 73.90% 81.51% 97.94% 92.02%

Table 10.1: Accuracy analysis of SSP, SSAP, DSP and DSAP

Figure 10.3: SSP vs. SSAP vs. DSP vs. DSAP at depth 4

0

500000

1000000

1500000

2000000

2500000

3000000

3500000

4000000

4500000

5000000

1 2 3 4 5 6 7 8 9 10

Real Count

SSP

SSAP

DSP

DSAP

152



The analysis data displayed in the above graphs clearly indicates that the DSP proves to be

the most accurate approach stemming from the experimental data in Appendix A.

Consequently, the DSP is the proposed approach implemented by MAGGIE in order to

accurately approximate the game tree size of a chessboard position. The final step in

calculating the developer negotiations in the MAGGIE Chess Service is explained in the

following subsection.

0

20000000

40000000

60000000

80000000

10000000

12000000

14000000

1 2 3 4 5

Real Count

SSP

SSAP

DSP

DSAP

0

50000000

1E+09

1.5E+09

2E+09

2.5E+09

3E+09

3.5E+09

4E+09

4.5E+09

1 2 3

Real Count

SSP

SSAP

DSP

DSAP

153

10.4.2.1 Calculating the Developer 2egotiations

If a game tree generates -, nodes, a well-implemented Alpha-Beta pruning algorithm with

strong move ordering strategies approximately searches 7-, nodes [Pla96]. The DSP proves

to be the most accurate approach in predicting the size of the game tree to a specific depth.

By utilising DSP, the approximate number of nodes evaluated is 7�, where x is the value

returned by DSP.

In the context of MAGGIE, the nodes of a propagated game tree are represented by the class

ChessMove, representing a chess move. The size of ChessMove is approximately 28 bytes

and the following formula is implemented to determine the approximate MB of RAM

required:

�7� × 28� ÷ 1024�

The value x is determined by the DSP function and 1024� is the constant number used to

convert bytes to megabytes. The proposed formula enables low-end devices to evaluate

potential small game trees and high-end devices to evaluate small and large game trees. With

the implementation of the DSP and the formula defined above, both higher- and lower-end

mobile devices can participate efficiently in the evaluation of one chessboard position.

A well implemented Alpha-Beta algorithm only requires memory as it traverses through the

game tree and does not necessarily require the amount of free memory as calculated by the

DSP. However, the amount of free memory calculated by the DSP is crucial for the following

reasons:

• Mobile device manufacturers may implement different garbage collection algorithms,

resulting in different behaviours of memory management.

• As discussed in Section 10.2, only higher-end MAGGIE mobile devices implement

transposition tables. The Trade Negotiator Agent has no knowledge of whether a

MAGGIE Chess Service utilises transposition tables or not. Therefore, the MAGGIE

Chess Service consumer always assumes that MAGGIE Chess Services producers

implement transposition tables and requires more memory. This assumption enforces

a fail-safe approach to the highest extent in order to prevent out-of-memory errors.

If a chessboard position is analysed and more memory is utilised than expected, out-of-

memory exceptions can be dealt with by the MAGGIE Chess Service.

154

10.4.2.2 Fault-tolerance Mechanisms

The calculation of the approximate size of RAM required to analyse a chessboard position

was explained above. However, the prediction size might be too small, resulting in the mobile

device running out of memory whilst evaluating a chessboard position. To solve this

problem, an algorithm is implemented to recover from such scenarios. The algorithm is

discussed step by step below when an out-of-memory error occurs:

1. It is now known that at a depth of d, an out-of-memory exception was generated. The

value d is decremented with a value of 1.

2. Repeat the Alpha-Beta pruning algorithm to a depth of d - 1. If an error occurs once

more, repeat step 1 until the Alpha-Beta pruning algorithm executes successfully.

The algorithm defined above ensures that a MAGGIE mobile device will ultimately and

successfully evaluate a chessboard position. It must be remembered that the DSP is an

approximation formula. It can predict a value that is smaller than the actual nodes evaluated

by the Alpha-Beta pruning algorithm. It is to be noted that during the testing phases of the

MAGGIE prototype, no out-of-memory errors were generated.

10.5 Conclusion

Chapter 10 motivated the selection of the Alpha-Beta pruning algorithm for mobile devices.

This pruning algorithm was chosen for its simplicity, memory-storage efficiency and cut-off

capabilities [Pla96].

Two distributed Alpha-Beta pruning algorithms were proposed: the normal pruning algorithm

(NPA) and the enhanced pruning algorithm (EPA). The NPA proves most suitable for lower-

end mobile devices because of the smaller computational and memory constraints it exhibits.

The EPA proves most suitable for higher-end mobile devices as it requires larger

computational and memory storage requirements from a mobile device.

The implementation of the NPA and EPA enables both lower- and higher-end mobile devices

to utilise the MAGGIE Chess Service efficiently.

Chapter 10 discussed the strategy implemented in predicting the approximate number of

nodes that will be evaluated in the Alpha-Beta pruning algorithm. Four approaches were

proposed to approximate the size of a chess game tree:

155





From the analysis data generated in Appendix A, it is shown that the DSP proves to be the

superior approach. The utilisation of the DSP enables the MAGGIE Chess Service to

approximate a fairly accurate size of a chess game tree. The DSP values in conjunction with

the developer’s negotiation variables enable lower-end devices to evaluate smaller game

trees. Similarly, higher-end devices can evaluate larger game trees. The implementation of

the DSP and developer’s negotiation variables enables a large scope of mobile devices to

participate in the evaluation of chessboard positions.

Chapter 10 showed that the implementation of the MAGGIE Chess Service requires as little

knowledge of the MAGGIE architecture as possible. The MAGGIE architecture allows third-

party developers to focus only on the implementation of the service logic. In this chapter the

implementation of the distributed Alpha-Beta pruning algorithm functionality was

highlighted. It has been shown that MAGGIE has successfully implemented a distributed and

asynchronous Alpha-Beta pruning algorithm as part of a MAGGIE grid service. Additionally,

the DSP has shown to accurately approximate the number of moves that may stem from a

chessboard position. Therefore, the DSP approximates the number of moves that may be

evaluated by the Alpha-Beta algorithm. More importantly, this chapter shows that a complex

grid service can be implemented in MAGGIE, providing domain-specific and application-

specific MAGGIE grid services.

Thus far, the general architecture and interacting component of MAGGIE have been

discussed (Chapters 7, 8 and 9). The implementation of the MAGGIE Chess Service

demonstrates how a computationally intensive task can be implemented seamlessly in

MAGGIE. Chapter 11 discusses the implementation of the MAGGIE prototype, discussing

the objectives reached by implementing the MAGGIE prototype.

156

Chapter 11

MAGGIE Prototype and Implementation

“He who loves practice without theory is like the sailor who boards

ship without a rudder and compass and never knows where he may

cast.”

- Leonardo da Vinci

11.1 Introduction

Chapters 7, 8, 9 and 10 provided the architecture, design and mobile agent execution plans of

MAGGIE and a MAGGIE Chess Service implementation. Chapter 10 set out the

implementation details of the MAGGIE prototype.

Many interesting and satisfactory characteristics have stemmed from the MAGGIE prototype.

Chapter 11 discusses the characteristics such as the optimised performance for mobile

devices, semi-heterogeneous grid computing behaviour, ease of implementation and ease of

use. It also provides a step-by-step discussion of how MAGGIE consumers and producers can

utilise MAGGIE and the MAGGIE Chess Service.

11.2 Technology Utilisation

A variety of technologies were utilised to realise the MAGGIE prototype. The following were

the motivation behind the technologies implemented by MAGGIE.

11.2.1 Implementation of MAGGIE Broker Domains

The MAGGIE Broker Domains and web service interfaces were implemented with the

Microsoft .NET Framework 2.0 and the C# programming language. The Microsoft .NET

Framework was used because of the extensive embedded web service support provided to

developers. GAP uses the Microsoft SQL Server 2005 for the storage and retrieval of data.

MAGGIE Broker Domain components can be replaced by similar technology platforms for

two reasons:

157

• Web services: Web services implement Internet protocol standards such as XML,

SOAP and HTTP. The Internet protocol standards enable the invocation of web

services regardless of technology platforms used to implement them.

• String data exchange: Data exchanges between MAGGIE mobile devices and

MAGGIE are compiled of standard strings (text) and are not the serialisation of

objects or components. The exchange of strings allows various platforms and

technologies to send and receive data to and from the MAGGIE infrastructure.

11.2.2 Implementation of MAGGIE Mobile Device Software

The following mobile device platforms have been used to provide MAGGIE mobile device

software:

• J2ME: The Sun Microsystems’s Java Micro-edition Platform 2 (J2ME) was used,

enabling the utilisation of lower-end mobile devices. The use of J2ME in the

MAGGIE prototype allows MAGGIE to be regarded as a realistic and dynamic

solution.

• .-ET CF: The Microsoft .NET Compact Framework (.NET CF) was used, enabling

the utilisation of higher-end mobile devices. The use of higher-end mobile devices

demonstrates the dynamic and realistic nature of the MAGGIE prototype.

The fact that both J2ME and .NET CF solutions are provided by MAGGIE proves that a wide

variety of technologies can be implemented and utilised in MAGGIE as required. Figure 11.1

displays the use of technologies in the MAGGIE prototype. The following section discusses

the prototype implementation of the mobile device software in MAGGIE.

Figure 11.1: Technologies applied in MAGGIE prototype

158

11.3 MAGGIE Device Implementations

The implementations of various concepts commonly discussed in MAGGIE on the J2ME

MIDP 2.0 and .NET CF technologies are provided below.

11.3.1 Economic Model Implementation

As discussed in Chapter 7, each MAGGIE mobile device user may configure a collection of

negotiation variables that are specific to the supply and demand economic model. These

variables have been implemented successfully in both the .NET CF and J2ME MIDP 2.0

environments. Figure 11.2 displays the GUI of each mobile device platform. MAGGIE

demonstrates how easily its users can reflect their true requirements.

11.3.2 2egotiations

MAGGIE mobile device users may view different negotiations of submitted jobs at any given

time. The user can download and view four different negotiations retrieved from GAP:

• Incomplete negotiations: Incomplete negotiations represent submitted tasks that have

not yet been successfully negotiated.

• Completed negotiations: Complete negotiations represent submitted tasks that have

been successfully negotiated. The user may then choose to either accept or cancel the

negotiations. If the negotiations are accepted, the corresponding Job Handler Agent is

initiated and executed.

• Processing negotiations: Processing negotiations represent submitted tasks waiting to

be processed by the designated distributed MAGGIE mobile devices.

• Complete processed negotiations: Complete processed negotiations represent

submitted and successfully processed task fragments. When complete processed

negotiations are downloaded, the user may then download the processed results. After

the processed results are downloaded, the User Agent invokes the appropriate

ServiceUnit for final assessment of the processed results.

A MAGGIE mobile device user can view the exact details of every negotiation downloaded

from GAP. By doing so, the user can easily view the status and progress of submitted tasks.

The GUI component that displays the negotiation details is illustrated in Figure 11.3. The

159

Figure 11.2: GUI implementation of supply and demand model negotiation variables

Figure 11.3: Detailed negotiation form depicting negotiation details of submitted jobs

160

following subsection deals with the invocation of a MAGGIE service residing on a MAGGIE

mobile device from a user’s perspective.

11.3.3 Running Maggie Services

MAGGIE mobile device users can easily display MAGGIE services available on their mobile

devices. They may choose either to view a detailed description of the MAGGIE service or to

invoke the MAGGIE service. Once the MAGGIE service is invoked and initialised, the user

may utilise the MAGGIE service accordingly. Figure 11.4 illustrates the GUI component that

describes the details of a MAGGIE service.

11.3.4 Submitting Jobs

With the execution of a MAGGIE service, users may wish to submit a collection of tasks for

distributed processing via MAGGIE mobile devices. Prior to the submission of tasks, a list

displaying the task fragments is provided to the MAGGIE mobile device user. The user may

then configure the price, reliability value, renegotiation periods, etc. (see Chapter 8) of each

task individually.

Figure 11.5 illustrates the GUI component that enables users to modify negotiation variables

of a single task fragment. When the negotiation variables of each task fragment are modified,

the user may simply submit task fragments for distributed processing.

11.4 2otable MAGGIE characteristics

The implementation of MAGGIE resulted in interesting observations and has proven key

concepts discussed in the previous chapters.

11.4.1 Simple Service Implementation

The functionality discussed in Sections 11.3.1 to 11.3.3 are automatically provided by

MAGGIE and do not need to be implemented manually by MAGGIE developers. The

automated nature of MAGGIE satisfies the primary goal of MAGGIE: providing a mobile

computing architecture as generic as possible, supporting the implementation of domain-

specific mobile computing services.

161

Figure 11.4: Form depicting MAGGIE-specific grid service information

Figure 11.5: Form depicting negotiation values of a job to be submitted

162

11.4.2 Ease of Use

The functionality discussed in Sections 11.3.1 to 11.3.3 is in essence the only functionality

MAGGIE mobile device users need to use. Consequently, MAGGIE is an easy-to-use

application. It enables users that know little to nothing of mobile grid computing to utilise the

full potential and raw processing power of the entire MAGGIE prototype.

11.4.3 Optimised for Mobile Devices

A small collection of the functionality of the MAGGIE architecture and prototype is

embedded onto MAGGIE mobile devices. The majority of components successfully

governing MAGGIE are embedded onto non-mobile device machines (computers, web

servers, database servers, etc.). The distributed functionality of MAGGIE proves that

MAGGIE mobile devices are only utilised when task fragments require processing. The

intelligent utilisation of MAGGIE mobile devices forces minimised communications between

MAGGIE and MAGGIE devices. Minimised communications harbour many advantages for

mobile device owners, such as:

• Minimal battery utilisation: Minimised communications will not deplete the mobile

device battery at an accelerated pace. This may motivate mobile device owners to

donate mobile device resources to MAGGIE.

• Lower GPRS costs: GPRS tariffs are charged according to how much data is sent and

received between data provider and data consumer. The minimised communications

result in lower GPRS costs, which in turn may prove more profitable for MAGGIE

mobile device users.

• Maximised resource utilisation: As a result of minimised communications, MAGGIE

mobile devices do not spend much time or resources on the provision or assessment of

data. Only the maximum available resources are utilised to process task fragments

extracted from incoming Worker Agents, and not for the administration of data

components.

Figure 11.6 illustrates the distribution of MAGGIE’s functionality. It shows that mobile

devices are utilised primarily as the execution platforms of Worker Agents and not as

negotiation mechanisms. The figures illustrated in Figure 11.6 are based on the number of

components created for the implementation of the MAGGIE prototype, and lines of code

distributed over MAGGIE components.

Figure 11.6: Functionality distribution over main components of MAGGIE

11.4.4 Semi-heterogeneous

One of the future research goals is to extend MAGGIE

mobile devices such as desktop c

computational machine into MAGGIE will result in a heterogen

The .NET CF is a subcollection of the complete .NET Framework

Consequently, code or application

computers that utilise the Microsoft .NET Framework. The cross

between .NET and .NET CF enables

computers. This results in the full utilisation

computers. Additionally, because MAGGIE

communication between interacting

platform for any web service enabled machine to

However, this does not mean that MAGGIE is a true

It is optimised for mobile devices and mobile devices only and therefore

as a true heterogeneous grid computing solution

implemented only as discussed

and capabilities of desktop computers

heterogeneous grid computing solutio

computational capabilities of desktop computers.

Chapter 12.

26.29 %

MAGGIE Functionality Distribution

163


eterogeneous Grid Computing Solution

One of the future research goals is to extend MAGGIE to enable the integration of

desktop computers, supercomputers, etc. The integratio

computational machine into MAGGIE will result in a heterogeneous grid computing solution.

he .NET CF is a subcollection of the complete .NET Framework (see Chapter 4)

code or applications developed in .NET CF will execute successf

Microsoft .NET Framework. The cross-platform compatibility

enables .NET CF MAGGIE services to execute on

in the full utilisation of the resource capabilities of

because MAGGIE implements web service technology

communication between interacting MAGGIE components, MAGGIE provides

service enabled machine to utilise MAGGIE.

n that MAGGIE is a true heterogeneous grid computing solution.

is optimised for mobile devices and mobile devices only and therefore can

ous grid computing solution. If MAGGIE applications are

discussed in previous chapters, much of the potential power

of desktop computers are neglected. To fully allow MAGGIE to be

grid computing solution, additional functionality is required to harvest

desktop computers. The required functionality is discussed in

10.82 %

62.89 %

MAGGIE Functionality Distribution

Mobile Device

Web Services

GAP


the integration of non-

The integration of any

ous grid computing solution.

(see Chapter 4).

execute successfully on

platform compatibility

to execute on desktop

es of desktop

implements web service technology for the

provides a future

grid computing solution.

cannot be classified

. If MAGGIE applications are utilised and

, much of the potential power, resources

neglected. To fully allow MAGGIE to become a

n, additional functionality is required to harvest the

The required functionality is discussed in

Mobile Device

Web Services

164

Figure 11.7: Identical source code executing in .2ET Framework (left) and.2ET CF (right)

Figure 11.7 displays how the same application appears on a normal desktop computer (left)

and on a mobile device (right). No modifications of the source code or application itself were

made. The following section provides a step-by-step example of how MAGGIE, in

conjunction with the MAGGIE Chess Service, is utilised.

11.5 MAGGIE Usage Example

The discussion in this section illustrates how a MAGGIE resource consumer and MAGGIE

resource producer would utilise MAGGIE.

11.5.1 MAGGIE Chess Service Initialisation

Assume that a MAGGIE resource consumer wishes to utilise the MAGGIE Chess Service. It

will be assumed that the consumer will be using a J2ME-enabled mobile device throughout

the usage example of MAGGIE. After the consumer has successfully logged into MAGGIE,

the consumer is provided with a list of possible commands. The consumer wishes to display

all available MAGGIE services and executes the Services command. All available MAGGIE

services are listed and the consumer chooses to run the MAGGIE Chess Service. Once the

165

MAGGIE Chess Service is invoked, a graphical representation of a chessboard is provided to

the consumer. The GUI component (illustrated in Figure 11.8) enables the consumer to

execute the initial playing move or to set up a specific chessboard position for analysis. For

the usage example, the consumer decides to play the move e2-e4. The following are the steps

when the consumer wishes to submit the chessboard position for distributed processing.

11.5.2 MAGGIE Task Data Submission

When the consumer has decided on the appropriate chessboard position to be analysed,

he/she would wish to submit the chessboard position for distributed analysis. The consumer

wishes to analyse the chessboard position with the proposed EPA with an initial search depth

of 2. He/she wishes to analyse only the top 12 moves that originate from the chessboard

position over a number of three distributed mobile devices. The GUI component depicting the

EPA (and NPA) data is illustrated in Figure 11.9.

Figure 11.8: MAGGIE Chess Service initialisation

166

When the consumer has successfully configured the distributed processing settings, the

Submit command is executed in the bottom right-hand menu. The consumer is then provided

with a list of the negotiation jobs (task fragments) that will be submitted to MAGGIE for

distributed processing. The consumer may then select any of the negotiation jobs and

configure the negotiation variables embedded within the selected negotiation job. As

illustrated in Figure 11.9, the consumer may configure any of the consumer negotiation

variables. He/she can also view the minimum CPU speed and RAM size required to process

the task fragment, and can also view the task fragment to be processed.

The above process is repeated until the consumer is satisfied with the negotiation variables of

each negotiation job. When the consumer is satisfied, the negotiation jobs are submitted to

MAGGIE. The steps taken by the consumer to view the progress of the submitted jobs and

how a MAGGIE resource producer comes into play in the usage example will now be

explained.

Figure 11.9: Submission of MAGGIE Chess Service data

167

11.5.3 Tracking Submitted Consumer Tasks

Once the data is submitted to MAGGIE, the appropriate Trade Negotiator Agent is initiated,

negotiating with other MAGGIE producers.

During the period that the Trade Negotiator Agent discovers and negotiates with potential

producers, a MAGGIE resource producer configures the supply and demand economic model

specific negotiation variables (see Figure 11.10). The producer specifies negotiation variables

such as the peak time hours, lunch time hours, peak time tariff, etc. It is assumed that the

producer utilises a .NET CF-enabled mobile device.

After the producer submits the supply and demand economic model negotiation variables, the

consumer wishes to view the progress of its previously submitted tasks. The consumer

executes the -egotiations command and is provided with a list of possible negotiations to

download. The consumer chooses the Incomplete -egotiations command (see Figure 11.10),

as it will display all negotiations that have not yet been successfully negotiated. When the

consumer downloads the list of incomplete negotiations, he/she may then download and view

the exact negotiation details.

As illustrated in Figure 11.10, the consumer can immediately recognise that one out of three

task fragments has been successfully negotiated thus far. When the consumer downloads and

views the exact negotiation details as illustrated in Figure 11.10, he/she can deduce the

following information: negotiation job one was successfully negotiated at a price of R0,25

with producer user3. The user can periodically track the progress of his/her submitted tasks.

The approach described above is followed when a consumer wishes to track the progress of

any negotiations submitted by the consumer (see Section 11.3.2). Next, the steps taken by the

consumer to finally process the submitted task fragments and to display the final result are

explained.

11.5.4 Processing the Submitted Task Fragments

As shown above, the consumer can keep real-time track of submitted negotiations. It is now

assumed that every negotiation submitted by the consumer has been negotiated successfully.

The user downloads the complete negotiation details in a fashion similar to that discussed in

the previous subsection. The user can either accept or decline the complete negotiations via

the GUI component that displays the details of the complete negotiations.

The consumer accepts the negotiations and a Job Handler Agent is initiated. This agent

initiates the correct number of Worker Agents for distributed processing. During the period

168

A.1 Producer configures & submits Supply And Demand Negotiation Variables

B.1 Consumer wishes to download the incomplete negotiations.

B.2 Consumer downloads allincomplete negotiations

B.3 Consumer downloads and views theincomplete negotiation details

Figure 11.10: Keeping track of MAGGIE submitted negotiations

169

that the Worker Agents attempt to process the task fragments assigned to them, the consumer

can once again keep track of all task fragments currently being processed. As illustrated in

Figure 11.11, the consumer eventually notices that each of the previously submitted task

fragments have been processed by the designated producers. At this stage, the consumer may

download and process the processed results by executing the Process command in the bottom

right-hand corner.

The consumer downloads the processed results and the User Agent automatically invokes the

appropriate MAGGIE service. In the context of the usage example, the MAGGIE Chess

Service is invoked and the processed results are analysed. Finally, the processed results are

displayed in the form of the best move originating from the chessboard position in Figure

11.8.

Figure 11.11: Final data assessment of submitted task fragments

170

The usage example provided demonstrates how easily MAGGIE consumers and producers

can participate in MAGGIE services. MAGGIE users need the minimum knowledge of

mobile computing or MAGGIE in order to participate in MAGGIE grid services.

11.6 Conclusion

The MAGGIE prototype implementation has provided interesting and favourable results. It

has successfully reflected all proposed functionality, design and implementation strategies

discussed throughout Chapters 7 to 10.

The MAGGIE prototype was implemented successfully on both the J2ME MIDP 2.0 and

.NET CF environment. MAGGIE can even be used on a normal desktop computer supporting

Microsoft .NET Framework 2.0 or later. Consequently, MAGGIE can to some extent support

true heterogeneous grid computing.

More importantly, it has been shown and proven that MAGGIE is indeed an extremely

optimised, attractive and realistic solution regarding the problem of migrating traditional grid

computing paradigms to mobile devices. MAGGIE successfully addresses critical mobile

computing issues such as GPRS cost tariffs, minimum battery utilisation and motivating users

to participate in mobile computing.

The rating of the MAGGIE Chess Service is beyond the scope of this dissertation and is

therefore not discussed. The objective of the MAGGIE Chess Service was to implement a

distributed chess grid service targeted specifically at mobile devices. Determining the rating

of the MAGGIE Chess Service would be difficult and time consuming, as the processes

discussed in Section 11.5 would have to be repeated to determine the response to each move

played in a chess game.

The usage example provided in Chapter 11 demonstrates the user-friendliness of MAGGIE.

MAGGIE users can keep real-time track of submitted negotiations and task fragments as they

are processed. Most importantly, the usage example demonstrated how easily and effortlessly

a user can participate in MAGGIE services.

The next chapter contains the final conclusions reached regarding MAGGIE and discusses

future research goals.

171

Chapter 12

Conclusion and Future Research

“Success is to be measured not so much by the position that one has

reached in life as by the obstacles which he has overcome.”

- Booker T. Washington

12.1 Introduction

Chapters 7 to 11 addressed the implementation of MAGGIE, an economic mobile computing

architecture that is as generic as possible. The following concepts of MAGGIE were

discussed:

• The general architecture of MAGGIE (Chapter 7).

• The service implementation strategy and negotiation mechanisms of MAGGIE

(Chapter 8).

• The agent and mobile agent execution plans in MAGGIE (Chapter 9).

• The implementation of the MAGGIE Chess Service (Chapter 10).

• The prototype implementation of MAGGIE (Chapter 11).

Chapter 12 provides the final conclusions drawn from the above chapters and similar

solutions to MAGGIE, and explains how MAGGIE is unique. Possible future research work

that may be conducted on MAGGIE is also included.

12.2 MAGGIE Objectives Reached

Many objectives have been reached regarding the implementation of MAGGIE in this

dissertation.

172

12.2.1 Optimised Mobile Device Support

With mobile devices growing in popularity and computing capabilities, there is no doubt that

they will become more capable of handling complex software applications. With this taken

into account, implementations similar to MAGGIE have a bright and prosperous future

indeed, paving the way for mobile computing. However, mobile devices are still considered

to be resource constrained and introduce many obstacles in mobile computing. MAGGIE

addresses many of the issues of mobile grid computing, which are summarised as follows:

• Resource constrained: Mobile devices do not contain the same computational and

storage capabilities compared to desktop computers, micro-computers,

supercomputers and mainframe computers. The resource constraints of mobile

devices pose many obstacles and raise doubts as to how mobile devices may

contribute to a grid computing environment. MAGGIE solves the introduced obstacle

by implementing mobile agent technology paradigms.

By implementing mobile agent technologies into MAGGIE, a MAGGIE mobile

device is truly only utilised when fragments of data need to be processed. The

autonomous nature of agents and mobile agents enforces the intelligent invocation

and utilisation of mobile devices for distributed processing. The fact that the majority

of agents and components governing MAGGIE are not embedded in mobile devices

ensures that the maximum resource capabilities of mobile devices are harvested for

mobile computing.

The implementation of Worker Agents in MAGGIE reinforces the intelligent and

efficient utilisation of the MAGGIE mobile devices’ battery. The battery power of

mobile devices is used primarily for processing data fragments retrieved from the

Worker Agent. The battery is not used for managing or governing MAGGIE

components or data.

• Intermittent network connections: Mobile devices exhibit wireless network

technologies that are considered slow, unpredictable and intermittent. The weak

network connectivity of mobile devices introduces many obstacles into mobile

computing, as volumes of data are exchanged between MAGGIE and mobile devices.

MAGGIE solves the above obstacle once again by implementing mobile agent

technology. The implementation of Worker Agents reduces the generated wireless

network traffic between MAGGIE and MAGGIE mobile devices. The Worker Agent

provides small volumes of data to be processed by the User Agent residing on the

mobile device.

173

The minimised communications between MAGGIE and MAGGIE mobile devices can

result directly in more cost-effective GPRS costs. GPRS is a network technology

where data consumers pay for the amount of data sent and received. The minimised

communication ensures that MAGGIE mobile device users may generate more profit,

as less money is spent on GPRS costs.

Furthermore, MAGGIE supports the unpredictable nature of wireless networks with

the implementation of heart-beat messages. These messages are sent and received

between Worker Agents and Job Handler Agents. In the scenario where a message is

not received within a pre-defined time frame, the Worker Agent is recreated and

redistributed by the Job Handler Agent. The redeployed Worker Agent embeds the

last saved state it resided in, enabling MAGGIE to compensate for the unpredictable

nature of wireless networks.

• Mobile device user motivation: One of the largest obstacles weakening the motivation

for mobile computing may not stem from a technological or technical point of view,

but rather from mobile device users themselves. The obstacle concerns the motivation

of mobile device users to participate in projects similar to MAGGIE. They may be

reluctant to contribute their mobile device resources to MAGGIE. The contribution of

mobile device resources results in faster battery depletion and higher GPRS costs.

MAGGIE implements the economic model better known as the supply and demand

model in conjunction with a collection of configurable negotiation variables. Both

producers and consumers of mobile device resources can configure the negotiation

variables. With the implementation of economic models, healthy and competitive

market environments are created. The implementation of the supply and demand

economic model enables producers to maximise their profits and consumers to find

the best prices for processing data. The economic nature of MAGGIE can motivate

users to participate in MAGGIE.

As mentioned in the previous paragraphs, MAGGIE is highly optimised for mobile

devices. It ensures efficient battery power utilisation, lowered GPRS costs and

maximum resource utilisation. Such characteristics of MAGGIE can also motivate

users to participate in MAGGIE.

It is evident from the above that MAGGIE is optimised and well suited not only for mobile

devices, but also for mobile device users. The MAGGIE architecture is specifically designed

for mobile devices and their inherent disadvantages, resulting in a true mobile computing

solution.

174

12.2.2 Generic Mobile Grid Computing Environment

Sun Microsystems’s Java Micro-edition Platform 2 (J2ME) and Microsoft’s .NET Compact

Framework (.NET CF) do not support the execution of mobile code embedded within mobile

agents. The lack of mobile code support is mainly due to security concerns and resource

constraints introduced by mobile devices. This inherent disadvantage does not enable data or

services to be rendered dynamically on a mobile device.

MAGGIE addresses this obstacle by providing interfaces enabling third-party developers to

implement domain-specific MAGGIE services. Instances of MAGGIE services are

dynamically handled by the User Agent residing on the mobile device. The proposed

approach enables third-party developers to concern themselves only with the following:

• The provision of task fragments and developer negotiations for distributed processing.

• The processing of task fragments extracted from Worker Agents.

• The processing of processed task fragments.

The proposed approach enables third-party developers to utilise the functionality of both the

MAGGIE and the underlying mobile device software development platform. The major

contributions of the implementation strategy of MAGGIE services is that third-party

developers do not need prior in-depth knowledge of the interacting components, mechanisms

and architecture of MAGGIE.

12.2.3 Efficient 2egotiation Mechanisms

MAGGIE supports a collection of negotiation variables that underlie the negotiations

between MAGGIE resource consumers and MAGGIE resource producers. The following

negotiation variables are provided by MAGGIE:

• Consumer negotiation variables: MAGGIE resource consumers can configure a

collection of negotiation variables for the distributed processing of tasks.

• Producer negotiation variables: MAGGIE resource producers can configure a

collection of negotiation variables for the consumption of mobile device resources.

The producer negotiation variables proposed by MAGGIE are specific to the supply

and demand economic model implementation.

175

• Developer negotiation variables: Developer negotiation variables ensure that more

computationally intensive task fragments are processed by the appropriate mobile

device. These variables embed the minimum mobile device hardware specifications to

process task fragments.

The negotiation variables listed above enable MAGGIE mobile device users and services to

easily reflect their true requirements and objectives. The implementation of economic models

in MAGGIE supports more realistic and fluctuating negotiations, rather than a fixed

algorithm.

12.2.4 Well-defined architecture

The architecture of MAGGIE is compiled primarily of agents and mobile agents. Each of the

agents and mobile agents in MAGGIE contain well-defined interfaces and objectives. The

execution plans of each agent and mobile agent proposed in MAGGIE ensure an intelligent,

robust, flexible, dynamic and efficient architecture. MAGGIE exhibits several levels of

abstractions. These abstractions enable MAGGIE to evolve to support future developments

and enhancements. The abstractions provided by MAGGIE are as follows:

• The implementation of economic models.

• The representation of users in MAGGIE.

• The implementation of MAGGIE services.

12.2.5 Implementation of the MAGGIE Chess Service

The dissertation proposed the successful implementation of the MAGGIE Chess Service, a

distributed mobile computing chess service. Two proposed implementations were provided in

order to implement the Alpha-Beta pruning algorithm in a mobile computing environment:

the normal pruning algorithm (NPA) and the enhanced pruning algorithm (EPA). The NPA

and EPA both enable lower-end and higher-end distributed mobile devices to calculate the

best move originating from a chessboard position.

The NPA is well suited for mobile devices that exhibit smaller memory budgets and

computational capabilities. The EPA is well suited for mobile devices that exhibit larger

memory budgets and computational capabilities.

176

Four approaches were proposed in approximating the size of a game tree stemming from a

chessboard position. The four proposed approaches are:





The most superior approach in approximating the size of a game tree proved to be the DSP

based on the analysis data generated in Appendix A. The DSP sufficiently aids the generation

of accurate and realistic developer negotiations variables. It realistically allows lower-end

mobile devices to analyse smaller sub-trees and higher-end mobile devices to analyse larger

sub-trees. With the implementation of the DSP, lower-end and higher-end mobile devices can

participate in the utilisation of the MAGGIE Chess Service.

The MAGGIE Chess Service demonstrates how a computationally intensive application may

be implemented into MAGGIE. The implementation of the MAGGIE Chess Service supports

the notion that third-party developers only need to concern themselves with the

implementation of the service logic.

12.2.6 Implementation of Security Mechanisms

The implementation of the security mechanisms discussed in Chapter 9 ensures that

MAGGIE can function as a fair, reliable and secure economic mobile computing

environment. The MAGGIE architecture enables third-party developers to implement custom

security mechanisms or tokens in the implemented MAGGIE services. MAGGIE motivates

third-party developers to utilise code obfuscation techniques, resulting in more effort to

reverse engineer MAGGIE services. Finally, MAGGIE utilises the Rijndael (AES) algorithm

to ensure security of a high standard for all its interacting components and users.

12.2.7 Semi-heterogeneous Grid Computing Behaviour

As discussed in Chapter 11, code or applications developed in the .NET CF environment can

execute without modifications in the .NET environment. MAGGIE thus exhibits

heterogeneous grid computing behaviour to a certain extent. MAGGIE cannot be viewed as a

heterogeneous grid computing solution owing to its optimised and specialised approach

177

towards mobile devices. If MAGGIE services are to utilise the .NET environment, much of

the computational and resource capabilities of a desktop computer will be neglected.

However, MAGGIE does prove that heterogeneous grid computing is a possibility. By using

technologies such as the .NET CF and NET Framework, heterogeneous grid computing is a

realistic implementation of grid computing.

12.2.8 Ease of Use

The MAGGIE mobile device software enables users with no to little knowledge of mobile

computing to use MAGGIE services. With this software users can track the status and

progress of submitted negotiations and task fragments in a real-time fashion. The usage

example provided in Chapter 11 demonstrates the user-friendliness of MAGGIE and how

MAGGIE can be utilised to submit task fragments for successful distributed processing.

It is evident that MAGGIE addresses a number of critical obstacles for mobile computing. It

provides a platform that is as generic as possible for third-party developers to implement a

wide array of application and domain-specific grid services. It provides a realistic and

efficient approach to integrate mobile devices into grid computing, enabling mobile devices

to execute complex software applications. Most importantly, the MAGGIE architecture

provides a means to third-party application developers, resource consumers and resource

producers to participate in MAGGIE with little to no prior knowledge of mobile computing

or the MAGGIE architecture. MAGGIE is an economic mobile computing solution,

optimised specifically for mobile and resource-constrained devices.

The MAGGIE architecture is compared to existing grid and mobile computing solutions in

the following section.

12.3 Benchmarking

MAGGIE is compared to three similar grid computing solutions in the following subsections.

The key similarities and differences are revealed between MAGGIE and other grid

computing solutions and architectures.

12.3.1 Mobile OGSI .2ET

Mobile OGSI.NET supports the hosting of different grid services that can be used on a

mobile device [Was04]. Each grid service embeds the application logic of the service that

resides on the mobile device. Each mobile device that uses Mobile OGSI.NET registers its

178

available grid services, and can be discovered and invoked by other Mobile OGSI.NET users.

The mobile grid services are implemented by using web services utilising the .NET Compact

Framework (.NET CF) foundation.

MAGGIE follows a similar approach as proposed in Mobile OGSI.NET, by enabling mobile

devices to register the collection of MAGGIE services it offers to other MAGGIE mobile

device users. Like Mobile OGSI.NET, MAGGIE parses all incoming requests and relays the

incoming requests to the appropriate grid service on to the mobile device owner. Finally, the

processed results are returned to the original requesting MAGGIE mobile device user

[Gou08].

MAGGIE is unique in the sense that services can be implemented in both J2ME MIDP 2.0

and .NET CF. MAGGIE allows J2ME MIDP 2.0 and .NET CF enabled devices to utilise

MAGGIE services, where as Mobile OGSI.NET only allows .NET CF-enabled devices to

participate in Mobile OGSI.NET [Gou08].

12.3.2 Globus Infrastructure Toolkit

The Globus system was designed to achieve an integration of applications, middleware and

networks that create a collection of free resources [Fos97]. Globus provides a low-level

toolkit to third-party application developers for developing grid services. The low-level

services provided by Globus include:

• Authentication.

• Security.

• Communications.

• Network information.

• Data access.

The Globus toolkit can be used efficiently to develop higher-level grid services and even

scheduler mechanisms on each Globus infrastructure node. Similar to Globus, MAGGIE

provides third-party developers with a collection of interfaces and libraries to implement

application-specific services. Third-party application developers only have to concern

themselves with the development of providing the service-specific data and the appropriate

processing of it. All other MAGGIE-specific services and processes are handled

automatically by the underlying MAGGIE architecture, libraries and foundation. The

proposed approach enables MAGGIE to contain a wide and vast array of different services

179

and applications that can be utilised by different mobile device users, and this is similar to

Globus.

MAGGIE provides a much simpler means of implementing services and does not burden the

application developer with issues such as data communication and access, authentication and

resource allocation. Such issues have to be implemented by application developers in Globus

[Gou08].

12.3.3 The ChessBrain II Project

The ChessBrain II Project was created initially as a research platform for massively

distributed, inhomogeneous, speed-critical computations over the Internet. Owing to the

nature of chess and parallel game tree search algorithms, chess was chosen for the

ChessBrain II Project [Fra06]. The ChessBrain II Project has been recorded in the World

Guinness Book of Records for the largest number of interconnected computers used to play

one single game of chess. The architecture of ChessBrain II is divided into three main layers

[Fra06]:

• Super-ode: The central server responsible for the distribution and partitioning of

work units in the ChessBrain environment.

• Cluster-ode: The ClusterNode manages local and distributed groups of PeerNodes.

• Peer-ode: The PeerNode serves as the computational computer node that processes

distributed work units.

The ChessBrain II Project enables a community of contributed computers to concurrently and

independently evaluate segments of a chess game tree. The leaf nodes of a chess game tree

are distributed to PeerNodes for further processing [Fra96]. Similarly, MAGGIE enables

mobile devices to concurrently and independently evaluate segments of a chess game tree.

However, it does not evaluate leaf nodes, but rather evaluates the playable moves originating

from a chessboard position to a specific depth.

The ChessBrain II Project relies on a community of computers to successfully analyse a chess

game in a distributed fashion. Users contributing resources to the ChessBrain II Project gain

no economic reward for their contribution. Users may question why they should contribute

their idle resources for distributed processing. However, MAGGIE motivates users to

participate in MAGGIE by rewarding them with some form of payment via the

implementation of economic models into MAGGIE. MAGGIE may prove to motivate a

larger number of users to participate in grid computing than the ChessBrain II Project. The

180

potential attraction of larger numbers of users is due to the mimicking nature of economic

environments in MAGGIE.

Lastly, the ChessBrain II Project is only targeted at conventional desktop computers that are

connected via the Internet. MAGGIE exclusively targets the utilisation of low-end and high-

end mobile devices.

It is evident from the above comparison that MAGGIE incorporates approaches by

successfully implemented grid computing solutions. However, it exhibits a large number of

unique differences when compared to such solutions. The following section discusses the

future research work of MAGGIE.

12.4 Future Research Work

There is much room for improvement in MAGGIE, and the research opportunities that exist

associated with MAGGIE are set out below.

12.4.1 Heterogeneous Grid Computing

MAGGIE does provide heterogeneous grid computing to some extent (see Chapter 11 and

Section 12.2.7). However, by simply implementing MAGGIE services onto desktop

computers without modification, much of the potential, power and capabilities of non-mobile

devices go to waste. Consequently, more components and mechanisms are to be implemented

if a true heterogeneous grid computing environment is to be realised.

The combined numbers of mobile devices and the strength of desktop computers (or higher)

can form a mobile computing environment with immense computational capabilities. The

partnership between mobile devices and more powerful machines in grid computing can

introduce a wide and rich variety of hardware resources and grid computing services.

12.4.2 Integration with Existing Grid Computing Projects

The MAGGIE prototype acts as a complete stand-alone mobile computing solution. Future

research work includes the integration of MAGGIE with existing popular grid computing

projects such as:

181

• Legion.

• Nimrod/G.

• Globus.

The above grid computing projects operate on a set of pre-defined standards. Integrating

MAGGIE with one or more of the above grid computing solutions could prove to build

powerful grid computing solutions. The ultimate goal of the above research field would be to

enable the cohesive co-operation of MAGGIE with existing grid computing solutions.

12.4.3 Custom Scheduling and 2egotiation Components

The prototype of MAGGIE implements pre-defined mechanisms associated with the

scheduling of tasks and negotiations between consumer and producer. The mechanisms

responsible for such functionality reside only on remote and fixed server back-ends for three

reasons:

• Mobile devices do not have the appropriate network and processing capabilities to

host scheduling and negotiation mechanisms.

• The third-party developers implementing domain-specific MAGGIE services may in

general not be interested in developing such mechanisms.

• If negotiations between consumers and producers were to take place on the mobile

device, the battery power of a mobile device will be depleted much faster.

Additionally, a MAGGIE mobile device owner may spend more money on

negotiations than receiving money owing to maximised communications via wireless

networks.

However, this does not mean that some organisations, groups or individuals may not wish to

implement custom scheduling and negotiation mechanisms. Consequently, future research

work includes the development and implementation strategy of such mechanisms.

Furthermore, research must also be conducted into how such custom mechanisms may reside

on a Sub-Broker Domain and not on the physical mobile device.

182

12.4.4 Support for True Mobile Code

True mobile code is not supported by mobile devices and mobile device software

development platforms. If a heterogeneous grid computing environment were to exist, true

code mobility could be implemented only over the region that exists out of conventional

computers. The implementation of mobile code would eliminate the utilisation of mobile

devices, and the heterogeneous grid computing solution would devolve into a conventional

grid computing solution.

Research must be done in this field of how mobile agents, embedded with mobile code, may

execute on both conventional computers and mobile devices. Such an approach may be where

the mobile code and mobile data embedded within a mobile agent are separate. The mobile

agent provides data to mobile devices for processing, and provides data and code to

conventional computers.

12.4.5 Implementing Semantic Meaning

The MAGGIE prototype requires MAGGIE mobile device users to be knowingly aware of

the existence of a MAGGIE service in order to utilise it. A MAGGIE user is not able to

search for services satisfying specialised search criteria. Thus future research includes the

implementation of semantic meta-data into MAGGIE services. This would enable the

automated discovery and invocation of MAGGIE services on MAGGIE mobile devices.

12.4.6 Additional Economic Models

The MAGGIE prototype only supports the implementation of the supply and demand

economic model. Future research work includes the provision of additional economic models

in MAGGIE. Additional economic models will enable producers to choose which economic

model they may benefit from the most.

12.5 Final Conclusion

Chapter 12 listed the many objectives that have been satisfied by the implementation of

MAGGIE. MAGGIE produces many favourable and satisfactory results in the context of

mobile computing. How MAGGIE may evolve and grow to an even stronger and promising

mobile computing solution was also discussed in this chapter.

183

The prototype implementation of MAGGIE provides compelling arguments supporting the

notion of mobile computing. With the ever-growing popularity of mobile devices and their

increasing networking, processing and storage capabilities, economic mobile computing is

becoming an attractive solution.

Not only has MAGGIE contributed in the sense of mobile computing, but also in the context

of distributed chess-searching algorithms. The MAGGIE chess grid service provides a means

of approximating the number of chess moves originating from one chessboard position. The

MAGGIE Chess Service enables low-end and high-end mobile devices to concurrently,

cohesively and independently evaluate segments of a chess game tree.

The successful implementation of MAGGIE proves that mobile computing certainly has a

strong and promising future.

184

References

[Aho07] Tomi T. Ahonen. 2.7 billion phone subscriptions 2006 now verified by

Informa. Communities Dominate Brands, April 2007. As seen on 04 June

2007 at http://communities-

dominate.blogs.com/brands/2007/04/27_billion_phon.html

[Alt07] Jorn Altmann, Costas Courboubetis, John Darlington and Jeremy Cohen.

GridEcon – The Economic-Enhanced -ext-Generation Internet, GECON

2007, LNCS 4685, Springer 2007

[Aou05] Hamed Aouadie and Mohamed Ben Ahmed. Mobile Agents Security, 2nd

International Conference on Mobile Technology, Applications and Systems,

November 2005

[Ara07] Nobuo Araki, Kazuhiro Yoshida, Yoshimasa Tsuruoka and Jun'ichi Tsujii.

Move Prediction in Go with the Maximum Entropy Method, Proceedings of the

2007 IEEE Symposium in Computational Intelligence and Games (CIG 2007),

2007

[Bar03] Alexander Barmouta and Rajkumar Buyya. GridBank: A Grid Accounting

Services Architecture (GASA) for Distributed Systems Sharing and

Integration, Proceedings of the International Parallel and Distributed

Processing Symposium (IPDPS'03), April 2003

[Bar03A] Denise Barnes. Fundamentals of Microsoft .-ET Compact Framework

Development for the Microsoft .-ET Framework Developer, Microsoft

Developer Network Technical Articles, December 2003

[Ber90] Hans Berliner, Danny Kopec and Ed Northam. A Taxonomy of Concepts for

Evaluating Chess Strength, Proceedings of Supercomputing '90, New York,

USA, November 1990

[Ber05] Maamoun Bernichi and Fabrice Mourlin. Java Mobile Agents for Monitoring

Mobile Activities, EUROCON 2005, Serbia & Montenegro, Belgrade,

November 2005

[Bha95] Subir Bhattacharya. Experimenting with Revisits in Game Tree Search,

Proceedings of the 14th International Joint Conference on Artificial

Intelligence (IJCAI-95), Volume 1, pages 243-249, Montreal, Canada, August

1995

185

[Bjo00] Yngvi Bjornsson and T. Anthony Marsland. Multi-Cut AlphaBeta Pruning in

Game-Tree Search. Theoretical Computer Science, Volume 252, number 1-2,

December 2000

[Bjo00A] Yngvi Bjornsson and T. Anthony Marsland, Risk Management in Game-Tree

Pruning. Information Sciences, Volume 122, Number 1, pages 12-41, 2000

[Bor02] Niklas Borselius, Mobile Agent Security. Electronics & Communication

Engineering Journal, Volume 14, Number 5, IEEE, London, UK, October

2002

[Buy00] Rajkumar Buyya, Steve Chapin and David DiNucci. Architectural Models for

Resource Management in the Grid, Proceedings of the First IEEE/ACM

International Workshop on Grid Computing (GRID '00), December 2000

[Buy00A] Rajkumar Buyya, David Abramson and Jonathan Giddy. An Architecture for a

Resource Management and Scheduling System in a Global Computational

Grid, Proceedings of the HPC ASIA '00, the 4th International Conference on

High Performance Computing in Asia-Pacific Region, IEEE Computer

Society Press, Beijing, China, May 2000

[Buy00B] Rajkumar Buyya, David Abramson and Jonathan Giddy. An Economy Driven

Resource Management Architecture for Global Computational Power Grids,

The 2000 International Conference on Parallel and Distributed Processing

Techniques and Applications (PDPTA 2000), Las Vegas, USA, 26-29 June

2000

[Buy01] Rajkumar Buyya, Jonathan Giddy and David Abramson. An Evaluation of

Economy-based Resource Trading and Scheduling on Computational Power

Grids for Parameter Sweep Applications, Proceedings of the 2nd International

Workshop on Active Middleware Services (AMS 2000), Kluwer Academic

Press, Pittsburgh, USA, August 2000

[Buy01A] Rajkumar Buyya, Jonathan Giddy and David Abramson. A Case for Economy

Grid Architecture for Service-Oriented Grid Computing, 10th IEEE

International Heterogeneous Computing Workshop (HCW 2001), In

conjunction with IPDPS 2001, San Francisco, California, USA, April 2001

[Buy02] Rajkumar Buyya. Economic-based Distributed Resource Management and

Scheduling for Grid Computing. PhD Thesis, School of Computer Science and

Software Engineering, Monash University, Melbourne, Australia, April 2002

186

[Buy02A] Rajkumar Buyya, David Abramson, Jonathan Giddy and Heinz Stockinger.

Economic Models for Resource Management and Scheduling in Grid

Computing. Special Issue on Grid Computing Environments, The Journal of

Concurrency and Computation: Practice and Experience (CCPE), Wiley Press,

USA, May 2002

[Cai04] Giovanni Caire, Giovanni Rimassa and Fabio Bellifemine. JADE: A Versatile

Run-time for Distributed Applications on Mobile Terminals and -etworks,

2004 IEEE International Conference on Systems, Man and Cybernetics,

October 2004

[Cam99] Murray Campbell. Knowledge Discovery in Deep Blue. Communications of

the ACM, Volume 42, Number 11, pages 65-67, November 1999

[Cha00] Patricia Charlton, Roldano Cattoni, Alessandra Potrich and Ebrahim A.

Mamdani. Evaluating the FIPA Standards and Its Role in Achieving

Cooperation in Multi-agent Systems, Proceedings of the 33rd Hawaii

International Conference on System Sciences, January 2007

[Chu04] David C. Chu and Marty Humphrey. Mobile OGSI.-ET: Grid Computing on

Mobile Devices, Proceedings of the Fifth IEEE/ACM International Workshop

on Grid Computing (GRID'04), November 2004

[Cia00] Paolo Ciancarini and Michael Wooldridge. Agent-Oriented Software

Engineering: State of the Art, Proceedings of the 2000 International

Conference on Software Engineering, 2000

[Cit08] The Citizen, 1.1 billion mobiles sold around the world in 2007: Study, Paris

AFP (Agence France-Presse), January 2008

[Cor99] Antonio Corradi, Rebecca Montanari and Cesare Stefanelli. Security Issues in

Mobile Agent Technology, 7th IEEE Workshop on Future Trends of

Distributed Computing Systems, Cape Town, South Africa, December 1999

[Cor99A] Antonia Corradi, Rebecca Montanari and Cesare Stefanelli. Mobile Agents

Protection in the Internet Environment, 23rd Annual International Computer

Software and Applications Conference, 1999

[Ell00] Carl Ellison and Bruce Schneider. Ten Risks of PKI: What You're -ot Being

Told about Public Key Infrastructure. Computer Security Journal, Volume 16,

Number 1, pages 1-7, 2000

187

[Epp99] David Eppstein. Which -odes to Search: Full-width vs. Selective Search.

Computer Science Lecture Notes, Strategy and board game programming,

Department of Information and Computer Science, University of California,

California, USA, February 1999

[Fer03] Luis Ferreira, Viktors Berstis, Jonathan Armstrong, Mike Kendzierski,

Andreas Neukoetter, Masanobu Takagi, Richard Bing-Wo, Adeeb Amir, Ryo

Murakawa, Olegorio Hernandez, James Magowan and Norbert Bieberstein.

Introduction to Grid Computing with Globus. IBM Redbooks, International

Technical Support Organization, ISBN 0738427969, September 2003

[Fer05] Luis Ferreira, Mariano Batista, Sebastian Fibra, Chin Yau Lee, Carlos

Alexandre Queiroz Silva, Joao Almeida, Fabiano Lucchese and Nam Keung.

Grind Computing Products and Services. IBM Redbooks, International

Technical Support Organizations, ISBN-0738491780, August 2005

[Fos97] Ian Foster and Carl Kesselman. Globus: A Metacomputing Infrastructure

Toolkit. International Journal of Supercomputer Applications and High

Performance Computing, 1997

[Fos98] Ian Foster, Carl Kesselman, Gene Tsudik and Steven Tuecke. A Security

Architecture for Computational Grids, Proceedings of the 5th ACM

Conference on Computer and Communication Security, pages 83-92, July

1998

[Fos01] Ian Foster, Carl Kesselman and Steven Tuecke. The Anatomy of the Grid.

Enabling Scalable Virtual Organizations, International Journal of

Supercomputer Applications, 2001

[Fos02] Ian Foster. What is the Grid? A Three Point Checklist. Daily News and

Information for the Global Grid Community, Volume 1, Number 6, July 2002.

[Fos04] Ian Foster, Nicholas R. Jennings and Carl Kesselman. Brain meets Brawn.

Why Grid and Agents need Each Other, Proceedings of the 3rd International

Conference on Autonomous Agents and Multi-Agent Systems, New York,

USA, 2004

[Fos05] Ian Foster. Globus Toolkit Version 4: Software for Service-Oriented Systems,

H. Jin, D. Reed and W. Jiang (Eds.): NPC 2005, LNCS 3779, pages 2 – 13,

IFIP International Federation for Information Processing, 2005

188

[Fra96] Stan Franklin and Art Graesser. Is it an Agent, or just a Program? A

Taxonomy for Autonomous Agents, Proceedings of the Third International

Workshop on Agent Theories, Architectures and Languages, Springer-Verlag,

1996

[Fra06] Colin M. Frayn, Carlos Justiniano and Kevin Lew. ChessBrain II - A

Hierarchical Infrastructure for Distributed Inhomogeneous Speed-Critical

Computation, IEEE Symposium on Computational Intelligence and Games

(CIG06), Nevada, USA, May 2006

[Fuk03] Munehiro Fukuda, Yuichiro Tanaka, Nayoa Suzuki, Lubomir F. Bic and

Shinya Kobayashi. A Mobile-Agent-Based PC Grid, Proceedings of the

Autonomic Computing Workshop Fifth Annual International Workshop on

Active Middleware Services (AMS' 03), June 2003

[Fur97] Johannes Furnkranz. Knowledge Discovery in Chess Database: A Research

Proposal, Technical Report OEFAI-TR-97-22, Austrian Research Institute for

Artificial Intelligence, 1997

[Gli02] Roch H. Glitho, Edgar Olougouna, Samuel Pierre and Ecole Polytechnique.

Mobile Agents and Their Use for Information Retrieval: A Brief Overview and

An Elaborate Case Study, IEEE Network, January/February 2002

[Gok03] Aniruddha S. Gokhale and Balachandran Natarajan. GriT: A CORBA-based

GRID Middleware Architecture, Proceedings of the 36th Hawaii International

Conference on System Sciences IEEE, January 2003

[Gom03] Dave Gomboc, Tony Anthony Marsland and Michael Buro. Evaluation

Function Tuning via Ordinal Correlation, 10th International Conference on

Advances in Computer Games (ACG-10), Styria, Austria, November 2003

[Gou08] Gerard Gouws, Elizabeth Ehlers and Ockmer L. Oosthuizen. Economic Mobile

Computing utilizing Mobile Devices forming Virtual Organizations,

Proceedings of the TMCE 2008 Symposium, pages 1101-1112, ISBN 978-90-

5155-044-3, Izmir, Turkey, April 2008

[Gre98] Michael S. Greenberg, Jennifer C. Byington, Theophany Holding and David

G. Harper. Mobile Agents and Security. IEEE Communications Magazine,

July 1998

[Gri01] Martin L. Griss and Gilda Pour. Accelerating Development with Agent

Components. Computer Magazine, Volume 34, Number 5, pages 37-43, May

2001

189

[Gri05] Andrew S. Grimshaw and Anand Natrajan. Legion: Lessons Learned Building

a Grid Operating System, Proceedings of the IEEE, Volume 93, Number 3,

March 2005

[Gua00] Xudon Guan, Yiling Yang and Jinyuan You. POM - A Mobile Agent Security

Model against Malicious Hosts, The 4th International Conference/Exhibition

on High Performance Computing in the Asia-Pacific Region, 2000

[Guo04] Shang-Fen Guo, Wei Zhang, Dan Man and Wen-Li Zhang. Grid Mobile

Service: Using Mobile Software Agents in Grid Mobile Service, Proceedings

of the Third International Conference on Machine Learnings and Cybernetics,

Shanghai, August 2004

[Has00] Wolfgang Haschek, Javier Jaen-Martinez, Asad Samar, Heinz Stockinger and

Kurt Stockinger. Data Management in an International Data Grid Project,

IEEE/ACM International Workshop on Grid Computing (Grid'2000),

Bangalore India, December 2000

[Hor99] Erika Horn, Mario Kupries and Thomas Reinke. Properties and Models of

Software Agents and Prefabrication for Agent Application Systems,

Proceedings of the 32nd Hawaii International Conference on System Sciences,

1999

[Hu06] Wen-Chen Hu. Client-Side Handled Computing and Java 2 Platform, Micro

Edition (J2ME), 39th Midwest Instruction and Computing Symposium, Iowa

Wesleyan College, Mt. Pleasant, IA, USA, April 2006

[Jac05] Bart Jacob, Michael Brown, Kentaro Fukui and Nihar Trivedi. Introduction to

Grid Computing. IBM Red Books, International Technical Support

Organization, ISBN - 0738494003, December 2005

[Jai00] Ravi Jain, Farooq Anjum and Amjad Umar. A Comparison of Mobile Agent

and Client-Server Paradigms for Information Retrieval Tasks in Virtual

Enterprises, Conference on Research Challenges, Buffalo, New York, USA,

April 2000

[Jai00A] Ravi Jain and Farooq Anjum. Mobile Agents for Personalized Information

Retrieval: When are They a Good Idea? IEEE Wireless Communications and

Networking Conference, 2000

[Jam04] Tariq Jamil. The Rijndael Algorithm, IEEE Potentials, pages 36-38, May 2004

190

[Jan02] Wayne Jansen. Countermeasures for Mobile Agent Security. Computer

Communications, Special Issue on Advanced Security Techniques for

Network Protection, Elsevier Science BV, November 2002

[Jen01] Nicholas R. Jennings. An Agent-based Approach for Building Complex

Software Systems, Communications of the ACM, Volume 44, Number 4, April

2001

[Jin05] Hai Jin and Li Qi. ChinaGrid and its Impact to Science and Education in

China, International Conference on Collaborative Computing: Networking,

Applications and Work Sharing, December 2005

[Jun98] Andreas Junghanns. Are There Practical Alternatives to Alpha-Beta? ICCA

Journal, March 1998

[Jun02] Cao Junwei, Daniel Spooner, James D. Turner, Stephen A. Jarvis, Darren J.

Kerbyson, Subhash Saini and Graham R. Nudd. Agent-based Resource

Management for Grid Computing, 2nd IEEE/ACM International Symposium

on Cluster Computing and the Grid, May 2002

[Kai91] Hermann Kaindl, Reza Shams and Helmut Horacek. Minimax Search

Algorithm With and Without Aspiration Windows, IEEE Transactions on

Pattern Analysis and Machine Intelligence, Volume 13, Number 12, December

1991

[Kau05] Larry Kaufman (International Master). All About Doubled Pawns. Chess Life

Magazine, May 2005

[Kau99] Larry Kaufman (International Master). The Evaluation of Material

Imbalances. Chess Life Magazine, March 1999

[Kim99] Minjeon Kim, Seungyun Lee, Injae Park, Jintae Kim and Sooyong Park.

Agent-oriented Software Modelling, Software Engineering Conference, Sixth

Asia Pacific Proceedings, 1999

[Kim03] Phyoung Jung Kim and Young Ju Noh. Mobile Agent System Architecture for

Supporting Mobile Market Application Service in Mobile Computing

Environment, 2003 International Conference on Geometric Modeling and

Graphics, July 2003

[Kli07] Andre N. Klingsheim, Vebjorn Moen and Kjell J. Hole. Challenges in

Securing -etworked J2ME Applications. Computer Magazine, Volume 40,

Number 2, February 2007

191

[Kol04] Otto Kolsi and Teemupekka Virtanen. MIDP 2.0 Security Enhancements,

Proceedings of the 37th Hawaii International Conference on System Sciences,

2004

[Kra02] Klaus Krauter, Rajkumar Buyya and Muthucumaru Maheswaran. A Taxonomy

and Survey of Grid Resource Management Systems for Distributed

Computing, International Journal of Software Practice and Experience (SPE),

Wiley Press, New York, USA, May 2002

[Lan99] Danny B. Lange and Mitsuru Oshima. Seven Good Reasons for Mobile

Agents. Communications of the ACM, Volume 42, Number 3, March 1999

[Leo06] Peter Leong, Chunyan Miao and Bu-Sung Lee. Agent Oriented Software

Engineering for Grid Computing, Proceedings of the Sixth IEEE International

Symposium on Cluster Computing and the Grid Workshops, May 2006

[Lew96] Mike Lewis and Andrew Grimshaw. The Core Legion Object Model,

Proceedings of the 5th IEEE International Symposium on High Performance

Distributed Computing, Syracuse, New York, USA, August 1996

[Li05] Sheng-Tun Li, Li-Yen Shue and Huang-Chih Hsieh. The Development of a

PDA-based Communication Architecture for Surveillance Services.

International Journal of Internet Protocol Technology, Volume 1, Number 1,

2005

[Lop06] Rafael Fernandes Lopes and Francisco Jose da Silva. Fault Tolerance in a

Mobile Agent Based Computational Grid, Proceedings of the Sixth IEEE

International Symposium on Cluster Computing and the Grid Workshops,

May 2006

[Mak06] Shamila Makki and Subbarao V. Wunnava. Application of Mobile Agents in

Managing the Traffic in the -etwork and Improving the Reliability and

Quality of Service. IANENG International Journal of Computer Science, 32:4,

ICJS_32_4_16, November 2006

[Mar81] Tony Anthony Marsland and Murray Campbell. A Survey of Enhancements to

the Alpha-Beta Algorithm, Proceedings of the ACM '81 Conference, pages

109-114, New York, USA, 1981

[Mar82] Tony Anthony Marsland and Murray Campbell. Parallel Search of Strongly

Ordered Game Trees. Computing Surveys, Volume 14, Number 4, December

1982

192

[Mar87] T. Anthony Marsland, Alexander Reinefeld and Jonathan Schaeffer. Low

Overhead Alternatives to SSS. Artificial Intelligence, pages 185-199, 1987

[Mar92] T. Anthony Marsland. Computer Chess and Search, S. Shapiro (Ed.):

Encyclopedia of Artificial Intelligence, 1992

[McC06] Dylan Loeb McClain. Once Again, Machine Beats Human at Chess. The New

York Times, New York City, USA. December, 2006. As seen on 18 March

2008 at http://www.nytimes.com/2006/12/05/crosswords/chess/05cnd-

chess.html?_r=1 .

[Mc207] Paul McNamara. 3.3 billion Mobile Accounts: One for Every Two Earthlings,

Net Buzz, Network World, December 2007

[Meg06] Friedel van Megen, Andreas Timm-Giel, Ivo Salmre and Carmelita Görg.

Smart -etworking Requests: Supporting Application Development Relying on

-etwork Connectivity for Wearable Computers, IFAWC 2006

3rd International Forum on Applied Wearable Computing, Bremen, Germany,

March 2006

[Mic03] Microsoft Corporation, Obfuscating Smart Device Applications. Microsoft

Developers Network, April 2003

[Mic08] Microsoft Corporation, .NET Compact Framework 3.5 Redistributable.

Microsoft Download Center and Microsoft .NET Compact Framework 3.5

Product Release Notes, March 2008

[Mil99] Dejann Milojicic. Trend Wars: Mobile Agent Applications, IEEE

Concurrency, July-September 1999

[Mot07] Daniel Moth. Write Code Once for Both Mobile and Desktop Apps. Microsoft

Developers Network, July 2007

[2ec98] George C. Necula and Peter Lee. Safe, Untrusted Agents using Proof-carrying

Code. G. Vigna (Ed.): Mobile Agents and Security, Volume 1419 in LNCS,

pages 61-91, Springer-Verlag, Berlin, 1998

[2ok06] Nokia Corporation. Browser Characteristics in Nokia GSM Devices, Version

1.9, Forum Nokia, May 2006

[2oo04] Guido J. van't Noordende, Frances M.T. Brazier and Andrew S. Tanenbaum.

Security in a Mobile Agent System, First IEEE Symposium on Multi-Agent

Security and Survivability, Philadelphia, USA, August 2004

193

[Ord96] Joann J. Ordille. When Agents Roam, Who can You Trust? Proceedings of the

First Conference on Emerging Technologies and Applications in

Communications, Portland, Oregon, May 1996

[Ort04] Enrique Ortiz. A Survey of J2ME Today, Sun Developer Network (SDN),

October 2004. As seen on 05 June 2007 at

http://developers.sun.com/techtopics/mobility/getstart/articles/survey/

[Pet05] Laurentiu Lucian Petrea. Mobile Code Platform for Ad Hoc -etworks, IEEE

INFOCOM 2005, Student Workshop, Miami, Florida, March 2005

[Pet05A] Laurentiu Lucian Petrea and Dan Grigoras. Towards Introducing Code

Mobility on J2ME, Proceedings of the 4th International Symposium on

Parallel and Distributed Computing (ISPDC'05), July 2005

[Pet06] Laurentiu Lucian Petrea and Dan Grigoras. Dynamic Class Provisioning on

Mobile Devices, Proceedings on the Fifth International Symposium on Parallel

and Distributed Computing (ISPDC'06), Timisoara, July 2006

[Pha98] Vu Ahn Pham and Ahmed Karmouch. Mobile Software Agents: An Overview.

IEEE Communications Magazine, July 1998

[Pha02] Thomas Phan, Lloyd Huang and Chris Dulan. Challenge: Integrating Mobile

Wireless Devices into the Computational Grid, Proceedings of the 8th ACM

International Conference on Mobile Computing and Networking (MobiCom'

02), Atlanta, USA, September 2002

[Pin03] Mike Pini. Writing Mobile Wireless Applications. Intel's Technology@Intel

Magazine, November 2003

[Pla96] Aske Plaat. Research ReSearch & Re-Search. PhD Thesis, Department of

Computer Science, Erasumus University of Rotterdam, Netherlands, June

1996

[Ple05] Anton du Plessis and Antoinette Louw. The Tide is Turning, The 2004/04

SAPS Crime Statistics. Institute for Security Studies, SA Crime Quarterly,

Number 12, June 2005

[Pog04] Agostino Poggi, Michele Tomaiuolo and Paola Turci. Extending JADE for

Agent Grid Applications, Proceedings of the 13th IEEE International

Workshop on Enabling Technologies: Infrastructure for Collaborative

Enterprises, June 2004

194

[Pou06] Gilda Pour and Nivedita Laad. Enhancing the Horizons of Mobile Computing

with Mobile Agent Components, Proceedings of the 5th IEEE/ACIS

International Conference on Computer and Information Science and 1st

IEEE/ACIS International Workshop on Component Based Software

Engineering, Software Architecture and Reuse, July 2006

[Qi01] Lin Qi and Lu Yu. Mobile Agent-based Security Model for Distributed

System, 2001 IEEE International Conference on Systems, Man and

Cybernetics, Tucson, Arizona, USA, October 2001

[Rei93] Alexander Reinefeld. A Minimax Algorithm Faster than Alpha-Beta,

Proceedings of the 7th Computer Chess Conference, Maastricht, Netherlands,

July 1993

[Ren05] Oscar M.C. Rendon, Francisco O.M. Pabon, Marlon J.G. Vargas and Javier

A.H. Guaca. Architectures for Web Services Access from Mobile Services,

Third Latin American Web Congress, LA-WEB 2005, November 2005

[Rig03] Roger Riggs, Antero Taivalsaari, Jim van Peursem, Jyri Huopaniemi, Mark

Patel and Aleksi Uotila. Programming Wireless Devices with The Java 2

Platform Micro Edition, Second Edition. Sun Microsystems, ISBN 0-321-

19798-4, June 2003

[Rio98] James Riordan and Bruce Schneier. Environmental Key Generation Towards

Clueless Agents. G. Vigna (Ed.): Mobile Agents and Security, Volume 1419 in

LNCS, pages 15-24, Springer-Verlag, Berlin, 1998

[Roo02] Larry Roof. Getting Started with Visual Studio .-ET and the Microsoft .-ET

Compact Framework, Microsoft Developer Network Technical Articles,

March 2002. As seen on 07 June 2007 at

http://msdn2.microsoft.com/en-s/library/aa446534.aspx

[Ros04] Philip E. Ross, Psyching out Computer Chess Players, IEEE Spectrum,

February 2004

[Rot01] Jorg Roth and Claus Unger. Using Handheld Devices in Synchronous

Collaborative Scenarios. Personal and Ubiquitous Computing, Volume 5,

Number 4, London, UK, December 2001

195

[Sam04] George Samaras. Mobile Agents: What about Them? Did They Deliver What

They Promised? Are They Here to Stay? Proceedings of the 2004 IEEE

International Conference on Mobile Data Management (MDM'04), 2004

[Sat93] Mahadev Satyanarayanan. Mobile Computing. Computer Magazine,

September 1993

[Sat96] Mahadev Satyanarayanan. Fundamental Challenges in Mobile Computing,

14th and 15th ACM Symposia on Principles of Distributed Computing,

Philadelphia, PA, USA, May 1996

[Sch89] Jonathan Schaeffer. The History and Alpha-Beta Search Enhancements in

Practice, IEEE Transactions on Pattern Analysis and Machine Intelligence,

Volume II, Number II, November 1989

[Sha50] Claude E. Shannon. Programming a Computer for Playing Chess.

Philosophical Magazine, Series 7, Volume 41, Number 314, March 1950

[Sim05] Kent I. Simonsen, Vebjorn Moen and Kjell J. Hole. Attack on Sun's MIDP

Reference Implementation of SSL, Proceedings of the 10th Nordic Workshop

Secure IT-Systems, pages 96-103, 2005

[Sim05A] Kwang M. Sim. A Survey of Bargaining Models for Grid Resource Allocation,

ACM SIGECOM: E-commerce exchange, Volume 5, Number 5, December

2005

[Sun02] Sun Microsystems. Mobile Information Device Profile Specification Version

2.0 Final Release, Technical White Paper, JSR 118 Expert Group, Java

Community Process, November 2002

[Sun03] Sun Microsystems. Connected Limited Device Configuration Specification

Version 1.1, Sun Microsystems Technical White Paper, March 2003

[Sun04] Sun Microsystems. Java 2 Platform, Micro Edition (J2ME) Web Services, Sun

Micro Systems Technical White Paper, July 2004

[Sun04A] Sun Microsystems. Security and Trust Services API (SATSA). Java Platform,

Micro Edition, White Paper, July 2004

[Sun05] Sun Microsystems. CDC: Java Platform Technology for Connected Devices,

Java Platform, Micro Edition, White Paper, June 2005

196

[Tao05] Tao Guan, Ed Zulaska and David de Roure. A Grid Service Infrastructure for

Mobile Devices, Proceedings of the First International Conference on

Semantics, Knowledge, and Grid (SKG 2005), November 2005

[Vas04] Luminita Vasiu and Qusay H. Mahmoud. Mobile Agents in Wireless Devices.

Computer Magazine, February 2004

[Ven06] Srikumar Venugopal. Scheduling Distributed Data-intensive Applications on

Global Grids. PhD Thesis, Department of Computer Science and Software

Engineering, University of Melbourne, Australia, July 2006

[Vol06] Nikoloas Volanis and Jos Dumortier. A European Legal Approach to Grid

Computing, Second IEEE International Conference on e-Science and Grid

Computing, December 2006

[Wan04] Ying-Hong Wang, Ching-Lin Wang and Liao Cheng Horng. Mobile Agent

Protection and Verification in the Internet Environment, Proceedings of the

4th International Conference on Computer and Information Technology

(CIT'04), Volume 00, 2004

[Wan06] Zhi Wang, Qi Chen and Chuanshan Gao. Implementing Grid Computing over

Mobile Ad-Hoc -etworks based on Mobile Agent, Proceedings of the Fifth

International Conference on Grid and Cooperative Computing Workshops,

October 2006

[Was04] Glenn Wasson, Norm Beekwilder, Mark Morgan and Marty Humphrey.

OGSI.-ET: OGSI-compliance on the .-ET Framework, Proceedings of the 4th

IEEE/ACM International Symposium on Cluster Computing and the Grid

(ccGrid '04), Chicago, Illinois, USA, April 2004

[Wei98] Jun Wei, Tao He and Tao Huang. Challenges of Communication in Mobile

Computing, Proceedings of the Technology of Object-Oriented Languages,

TOOLS 27, Beijing, China, September 1998

[Whe96] Joseph Whelan and Kamil Msefer. Economic Supply & Demand. MIT System

Dynamics in Education Project, January 1996

[Wil06] James Wilson. Chess Terminology. Chess Success Secrets. As seen on 23

September 2008 at www.chess-success.com, 2006

[Wil07] Jim Wilson. What's -ew for Developers in Windows Mobile 6. Microsoft

Developers Network Library, February 2007

197

[Woo99] Michael J. Wooldridge and Nicholas R. Jennings. Software Engineering with

Agents: Pitfalls and Pratfalls. IEEE Internet Computing, May-June 1999

[Yan05] Yanxiang He, Weidong Wen, Huin Jin and Haowen Liu. Agent-based Mobile

Service Discovery in Grid Computing, Fifth International Conference on

Computer and Information Technology, Washington, USA, September 2005

[Zou06] Wanhong Zou, Xiuzi Ye, Wei Peng and Zhiyang Chen. A Brief Review on

Application of Mobile Computing in Construction, First International Multi-

Symposium on Computer and Computational Sciences, 2006 IMSCCS'06,

April 2006

198

Appendix A

A.1 Introduction

Appendix A displays the analysis data generated from 18 well-known chess games retrieved

from http://www.chessgames.com. The generated analysis data proves the accuracy of the

prediction formulae proposed in Chapter 11. The proposed prediction formulae are:

• Single side prediction.

• Single side adaptive prediction.

• Double side prediction.

• Double side adaptive prediction.

A.2 Analysis Data

The generated analysis data of each game is summarised in tables throughout Sections A.4 to

A.6. The tables all depict the following columns:

• Move: The move that was played in the chess game.

• Single side expansion: The single side expansion factor that was calculated after the

move was played.

• Double side expansion: The double side expansion factor that was calculated after the

move was played.

• Real count: The number of actual playable positions that exist after the move was

played to the specified depth. The RC value is calculated by the custom application

(see Section A.3) by traversing through each chess move originating from a

chessboard position’s game tree.

• Single side prediction: The single side prediction value that was calculated to the

specified depth.

199

• Single side adaptive prediction: The single side adaptive prediction value that was

calculated to a specified depth.

• Double side prediction: The double side prediction value that was calculated to a

specified depth.

• Double side adaptive prediction: The double side adaptive prediction value that was

calculated to a specified depth.

The final row of each table displays the average values of the RC, SSP, SSAP, DSP and

DSAP. The percentage value indicates how close the SSP, SSAP, DSP and DSAP values are

to the RC value.

A.3 Generation of Analysis Data

The data was generated by implementing a custom-designed application that calculates

analysis data for SSE, DSE, SSP, SSAP, DSP and DSAP values. The chess game moves are

retrieved from the website of http://www.chessgames.com and read into the custom-designed

application (figure A.1). When all moves are read into the application, the prediction values

are calculated after each move. The prediction data was exported to a tab-delimited text file

and the text file was imported into Microsoft Excel 2007. The tables in Sections A.4 to A.6

were copied over into MSWord 2007.

Figure A.1: Custom chess tool application utilised for data generation

200

A.4 Depth 4 Analysis Data

All games analysed in this section are famous games played by Grand Master Garry

Kasparov, and were analysed to a depth of 4.

Table A.1

Depth: 4

Game: Anatoli Karpov vs. Garry Kasparov, World Championships, 1985 (0-1)

Move SSE DSE RC SSS SSC DSS DSC

e2-e4 20 25 405375 160000 212520 390625 491400

c7-c5 30 25 482304 810000 982080 390625 491400

Kng1-f3 22 24 440548 234256 303600 331776 421200

e7-e6 28 28 698141 614656 755160 614656 755160

d2-d4 30 32 1180462 810000 982080 1048576 1256640

c5xd4 37 34 1341081 1874161 2193360 1336336 1585080

Knf3xd4 31 35 1542248 923521 1113024 1500625 1771560

Knb8-c6 42 38 2091804 3111696 3575880 2085136 2430480

Knd4-b5 35 37 1833694 1500625 1771560 1874161 2193360

d7-d6 42 36 1687087 3111696 2824080 1679616 1499400

c2-c4 33 37 1726711 1185921 1047552 1874161 1678320

Kng8-f6 43 36 1688607 3418801 3109932 1679616 1499400

Knb1-c3 32 37 1860248 1048576 922560 1874161 1678320

a7-a6 44 38 2003603 3748096 3416952 2085136 1872792

Knb5-a3 34 37 1855833 1336336 1184832 1874161 1678320

d6-d5 42 40 2653291 3111696 2824080 2560000 2311920

c4xd5 40 41 2890465 2560000 2311920 2825761 2558400

e6xd5 44 42 3236875 3748096 3416952 3111696 2824080

e4xd5 42 41 2939544 3111696 2824080 2825761 2558400

Knc6-b4 41 38 2100150 2825761 2558400 2085136 1872792

Bf1-e2 38 38 2243273 2085136 1872792 2085136 1872792

Bf8-c5 41 42 3067560 2825761 2558400 3111696 2824080

O-O 46 40 2645575 4477456 4098600 2560000 2311920

O-O 36 38 2365600 1679616 1499400 2085136 1872792

Be2-f3 42 38 2247176 3111696 2824080 2085136 1872792

Bc8-f5 35 42 3033969 1500625 1335180 3111696 2824080

Bc1-g5 49 44 3757925 5764801 5306112 3748096 3416952

Rf8-e8 40 47 4762691 2560000 2311920 4879681 4475340

Qd1-d2 56 49 5682243 9834496 9147600 5764801 5306112

b7-b5 44 48 5246097 3748096 3416952 5308416 4877472

Ra1-d1 54 45 4259216 8503056 7887672 4100625 3746160

Knb4-d3 38 46 4443024 2085136 1872792 4477456 4098600

Kna3-b1 56 44 3684406 9834496 9147600 3748096 3416952

h7-h6 34 46 3954282 1336336 1184832 4477456 4098600

Bg5-h4 59 45 3832935 12117361 11313132 4100625 3746160

b5-b4 32 44 3301309 1048576 922560 3748096 3416952

Knc3-a4 56 44 3503639 9834496 9147600 3748096 3416952

Bc5-d6 32 43 3283407 1048576 922560 3418801 3109932

Bh4-g3 55 43 3357073 9150625 8500140 3418801 3109932

Ra8-c8 32 44 3500664 1048576 922560 3748096 3416952

201

b2-b3 57 45 3725037 10556001 9831360 4100625 3746160

g7-g5 32 43 3215998 1048576 922560 3418801 3109932

Bg3xd6 49 43 3598418 5764801 5306112 3418801 3109932

Qd8xd6 30 44 3146497 810000 706440 3748096 3416952

g2-g3 60 45 3603760 12960000 12113880 4100625 3746160

Knf6-d7 32 44 3377287 1048576 922560 3748096 3416952

Bf3-g2 60 45 3458269 12960000 12113880 4100625 3746160

Qd6-f6 32 43 3249616 1048576 922560 3418801 3109932

a2-a3 59 45 3482361 12117361 11313132 4100625 3746160

a6-a5 32 44 3312441 1048576 922560 3748096 3416952

a3xb4 60 46 3841308 12960000 12113880 4477456 4098600

a5xb4 32 43 3194062 1048576 922560 3418801 3109932

Qd2-a2 58 43 2878555 11316496 10552752 3418801 3109932

Bf5-g6 29 43 2823905 707281 613872 3418801 3109932

d5-d6 56 43 3153101 9834496 9147600 3418801 3109932

g5-g4 31 43 3003714 923521 809100 3418801 3109932

Qa2-d2 57 45 3728302 10556001 9831360 4100625 3746160

Kg8-g7 35 44 3457104 1500625 1335180 3748096 3416952

f2-f3 57 43 2990104 10556001 9831360 3418801 3109932

Qf6xd6 31 43 3055353 923521 809100 3418801 3109932

f3xg4 60 49 4934437 12960000 12113880 5764801 5306112

Qd6-d4+ 60 32 457055 12960000 12113880 1048576 922560

Kg1-h1 62 50 5123716 14776336 13842120 6250000 5762400

Knd7-f6 39 49 4956236 2313441 2083692 5764801 5306112

Rf1-f4 61 49 5117892 13845841 12956400 5764801 5306112

Knf6-e4 35 44 3540006 1500625 1335180 3748096 3416952

Qd2xd3 52 44 3773322 7311616 6762600 3748096 3416952

Kne4-f2+ 54 28 233102 8503056 7887672 614656 530712

Rf4xf2 52 49 5417107 7311616 6762600 5764801 5306112

Bg6xd3 36 45 3496450 1679616 1499400 4100625 3746160

Rf2-d2 60 43 2503287 12960000 12113880 3418801 3109932

Qd4-e3 27 40 2159735 531441 456300 2560000 2311920

Rd2xd3 46 37 1883105 4477456 3916440 1874161 1585080

Rc8-c1 30 37 1734817 810000 657720 1874161 1585080

Kna4-b2 47 36 1569784 4879681 4280760 1679616 1413720

Qe3-f2 29 38 1673492 707281 570024 2085136 1771560

Knb1-d2 49 37 1638873 5764801 5085024 1874161 1585080

Rc1xd1+ 44 23 110454 3748096 3258024 279841 212520

Knb2xd1 39 31 822268 2313441 1974024 923521 755160

Re8-e1+ 35 18 43567 1500625 1256640 104976 73440

Average: 2803925 4667306 4331139 3014728 2771002

Percentage: 60.08 64.74 93.01 98.83

202

Table A.2

Depth: 4

Anatoli Karpv vs. Garry Kasparov, Linares, 1993 (0 - 1)


d2-d4 20 24 361792 160000 212520 331776 421200

Kng8-f6 28 24 425466 614656 755160 331776 421200

c2-c4 22 25 485415 234256 303600 390625 491400

g7-g6 30 26 527522 810000 982080 456976 570024

Knb1-c3 23 27 639584 279841 358800 531441 657720

Bf8-g7 33 29 779565 1185921 1413720 707281 863040

e2-e4 26 32 1118193 456976 570024 1048576 1256640

d7-d6 40 36 1736487 2560000 2961840 1679616 1974024

f2-f3 34 34 1474494 1336336 1585080 1336336 1585080

O-O 36 33 1336437 1679616 1499400 1185921 1047552

Bc1-e3 32 36 1625014 1048576 922560 1679616 1499400

e7-e5 40 35 1645056 2560000 2311920 1500625 1335180

Kng1-e2 32 35 1585462 1048576 922560 1500625 1335180

Qc7-c6 39 35 1656567 2313441 2083692 1500625 1335180

Qd1-d2 33 35 1549571 1185921 1047552 1500625 1335180

Knb8-d7 37 32 1169679 1874161 1678320 1048576 922560

Ra1-d1 28 30 965998 614656 530712 810000 706440

a7-a6 33 30 958140 1185921 1047552 810000 706440

d4xe5 29 35 1541996 707281 613872 1500625 1335180

Knd7xe5 39 37 1951601 2313441 2083692 1874161 1678320

b2-b3 36 36 1864960 1679616 1499400 1679616 1499400

b7-b5 40 38 2168346 2560000 2311920 2085136 1872792

c4xb5 37 37 2067363 1874161 1678320 1874161 1678320

a6xb5 38 39 2401574 2085136 1872792 2313441 2083692

Qd2xd6 41 46 4156980 2825761 2558400 4477456 4098600

Knf6-d7 55 45 3425194 9150625 8500140 4100625 3746160

f3-f4 37 42 2902564 1874161 1678320 3111696 2824080

b5-b4 50 42 2869836 6250000 5762400 3111696 2824080

Knc3-b1 36 39 2421779 1679616 1499400 2313441 2083692

Kne5-g4 46 43 3356987 4477456 4098600 3418801 3109932

Be3-d4 41 41 2912735 2825761 2558400 2825761 2558400

Bg7xd4 35 40 2349894 1500625 1335180 2560000 2311920

Qd6xd4 35 36 1682472 1500625 1335180 1679616 1499400

Ra8xa2 36 36 1757600 1679616 1499400 1679616 1499400

h2-h3 39 37 1788220 2313441 2083692 1874161 1678320

Qc6-c5 35 35 1603360 1500625 1335180 1500625 1335180

Qd4-g1 40 32 1052741 2560000 2311920 1048576 922560

Kng4-f6 26 29 854458 456976 390000 707281 613872

e4-e5 33 29 864600 1185921 1047552 707281 613872

Knf6-e4 25 33 1141906 390625 331200 1185921 1047552

h3-h4 41 33 1204729 2825761 2558400 1185921 1047552

Qc5-c4 29 36 1701937 707281 613872 1679616 1499400

Kne2-c1 46 37 1876156 4477456 4098600 1874161 1678320

Qc4-c3 31 37 1840417 923521 809100 1874161 1678320

Knc1xa2 31 31 1136641 923521 809100 923521 809100

203

Qc3-c2 33 37 1820189 1185921 1047552 1874161 1678320

Qg1-d4 43 40 2481995 3418801 3109932 2560000 2311920

c2xd1 : Q+ 31 16 68096 923521 809100 65536 50400

Ke1xd1 31 33 1273793 923521 809100 1185921 1047552

Knd7-c5 29 34 1434893 707281 613872 1336336 1184832

Qd4xd8 30 31 954393 810000 706440 923521 809100

Rf8xd8+ 37 21 151124 1874161 1678320 194481 159600

Kd1-c2 38 29 642511 2085136 1872792 707281 613872

Kne4-f2 21 29 622834 194481 159600 707281 613872

Average: 1562728 1787420 1653108 1538382 1417784

Percentage: 87.43 94.53 98.44 90.72

Table A.3

Depth: 4

Garry Kasparov vs. Anatoli Karpv, World Championships, 1990 (1-0)


d2-d4 20 24 361792 160000 212520 331776 421200

Kng8-f6 28 24 425466 614656 755160 331776 421200

c2-c4 22 25 485415 234256 303600 390625 491400

g7-g6 30 26 527522 810000 982080 456976 570024

Knb1-c3 23 27 639584 279841 358800 531441 657720

Bf8-g7 33 29 779565 1185921 1413720 707281 863040

e2-e4 26 32 1118193 456976 570024 1048576 1256640

d7-d6 40 36 1736487 2560000 2961840 1679616 1974024

f2-f3 34 34 1474494 1336336 1585080 1336336 1585080

O-O 36 33 1336437 1679616 1499400 1185921 1047552

Bc1-e3 32 36 1625014 1048576 922560 1679616 1499400

e7-e5 40 35 1645056 2560000 2311920 1500625 1335180

Kng1-e2 32 35 1585462 1048576 922560 1500625 1335180

Qc7-c6 39 35 1656567 2313441 2083692 1500625 1335180

Qd1-d2 33 35 1549571 1185921 1047552 1500625 1335180

Knb8-d7 37 32 1169679 1874161 1678320 1048576 922560

Ra1-d1 28 30 965998 614656 530712 810000 706440

a7-a6 33 30 958140 1185921 1047552 810000 706440

d4xe5 29 35 1541996 707281 613872 1500625 1335180

Knd7xe5 39 37 1951601 2313441 2083692 1874161 1678320

b2-b3 36 36 1864960 1679616 1499400 1679616 1499400

b7-b5 40 38 2168346 2560000 2311920 2085136 1872792

c4xb5 37 37 2067363 1874161 1678320 1874161 1678320

a6xb5 38 39 2401574 2085136 1872792 2313441 2083692

Qd2xd6 41 46 4156980 2825761 2558400 4477456 4098600

Knf6-d7 55 45 3425194 9150625 8500140 4100625 3746160

f3-f4 37 42 2902564 1874161 1678320 3111696 2824080

b5-b4 50 42 2869836 6250000 5762400 3111696 2824080

Knc3-b1 36 39 2421779 1679616 1499400 2313441 2083692

Kne5-g4 46 43 3356987 4477456 4098600 3418801 3109932

Be3-d4 41 41 2912735 2825761 2558400 2825761 2558400

204

Bg7xd4 35 40 2349894 1500625 1335180 2560000 2311920

Qd6xd4 35 36 1682472 1500625 1335180 1679616 1499400

Ra8xa2 36 36 1757600 1679616 1499400 1679616 1499400

h2-h3 39 37 1788220 2313441 2083692 1874161 1678320

Qc6-c5 35 35 1603360 1500625 1335180 1500625 1335180

Qd4-g1 40 32 1052741 2560000 2311920 1048576 922560

Kng4-f6 26 29 854458 456976 390000 707281 613872

e4-e5 33 29 864600 1185921 1047552 707281 613872

Knf6-e4 25 33 1141906 390625 331200 1185921 1047552

h3-h4 41 33 1204729 2825761 2558400 1185921 1047552

Qc5-c4 29 36 1701937 707281 613872 1679616 1499400

Kne2-c1 46 37 1876156 4477456 4098600 1874161 1678320

Qc4-c3 31 37 1840417 923521 809100 1874161 1678320

Knc1xa2 31 31 1136641 923521 809100 923521 809100

Qc3-c2 33 37 1820189 1185921 1047552 1874161 1678320

Qg1-d4 43 40 2481995 3418801 3109932 2560000 2311920

c2xd1 : Q+ 31 16 68096 923521 809100 65536 50400

Ke1xd1 31 33 1273793 923521 809100 1185921 1047552

Knd7-c5 29 34 1434893 707281 613872 1336336 1184832

Qd4xd8 30 31 954393 810000 706440 923521 809100

Rf8xd8+ 37 21 151124 1874161 1678320 194481 159600

Kd1-c2 38 29 642511 2085136 1872792 707281 613872

Kne4-f2 21 29 622834 194481 159600 707281 613872

d2-d4 20 24 361792 160000 212520 331776 421200

Kng8-f6 28 24 425466 614656 755160 331776 421200

c2-c4 22 25 485415 234256 303600 390625 491400

g7-g6 30 26 527522 810000 982080 456976 570024

Knb1-c3 23 27 639584 279841 358800 531441 657720

Bf8-g7 33 29 779565 1185921 1413720 707281 863040

e2-e4 26 32 1118193 456976 570024 1048576 1256640

d7-d6 40 36 1736487 2560000 2961840 1679616 1974024

f2-f3 34 34 1474494 1336336 1585080 1336336 1585080

O-O 36 33 1336437 1679616 1499400 1185921 1047552

Bc1-e3 32 36 1625014 1048576 922560 1679616 1499400

e7-e5 40 35 1645056 2560000 2311920 1500625 1335180

Kng1-e2 32 35 1585462 1048576 922560 1500625 1335180

Qc7-c6 39 35 1656567 2313441 2083692 1500625 1335180

Qd1-d2 33 35 1549571 1185921 1047552 1500625 1335180

Knb8-d7 37 32 1169679 1874161 1678320 1048576 922560

Ra1-d1 28 30 965998 614656 530712 810000 706440

a7-a6 33 30 958140 1185921 1047552 810000 706440

d4xe5 29 35 1541996 707281 613872 1500625 1335180

Knd7xe5 39 37 1951601 2313441 2083692 1874161 1678320

b2-b3 36 36 1864960 1679616 1499400 1679616 1499400

b7-b5 40 38 2168346 2560000 2311920 2085136 1872792

c4xb5 37 37 2067363 1874161 1678320 1874161 1678320

a6xb5 38 39 2401574 2085136 1872792 2313441 2083692

Qd2xd6 41 46 4156980 2825761 2558400 4477456 4098600

Knf6-d7 55 45 3425194 9150625 8500140 4100625 3746160

f3-f4 37 42 2902564 1874161 1678320 3111696 2824080

205

Average: 1489605.8 1674963 1681746 1614521 1548606

Percentage: 88.93 88.57 92.26 96.19

Table A.4

Depth: 4

Garry Kasparov vs. Lajos Portisch, 2iksic, 1983 (1-0)


d2-d4 20 24 361792 160000 212520 331776 421200

Kng8-f6 28 24 425466 614656 755160 331776 421200

c2-c4 22 25 485415 234256 303600 390625 491400

e7-e6 30 28 737233 810000 982080 614656 755160

Kng1-f3 28 29 801906 614656 755160 707281 863040

b7-b6 32 30 869857 1048576 1256640 810000 982080

Knb1-c3 29 31 1067457 707281 863040 923521 1113024

Bc8-b7 35 34 1393788 1500625 1771560 1336336 1585080

a2-a3 34 34 1465798 1336336 1585080 1336336 1585080

d7-d5 36 34 1450431 1679616 1499400 1336336 1184832

c4xd5 37 35 1652086 1874161 1678320 1500625 1335180

Knf6xd5 34 35 1661354 1336336 1184832 1500625 1335180

e2-e3 39 37 1999065 2313441 2083692 1874161 1678320

Knd5xc3 31 37 1838862 923521 809100 1874161 1678320

b2xc3 38 34 1405662 2085136 1872792 1336336 1184832

Bf8-e7 31 33 1405038 923521 809100 1185921 1047552

Bf1-b5+ 36 21 267956 1679616 1499400 194481 159600

c7-c6 36 34 1410085 1679616 1499400 1336336 1184832

Bb5-d3 34 36 1767834 1336336 1184832 1679616 1499400

c6-c5 40 37 1973701 2560000 2311920 1874161 1678320

O-O 37 36 1674071 1874161 1678320 1679616 1499400

Knb8-c6 36 36 1854123 1679616 1499400 1679616 1499400

Bc1-b2 38 37 2075083 2085136 1872792 1874161 1678320

Ra8-c8 38 37 1948662 2085136 1872792 1874161 1678320

Qd1-e2 37 37 2005840 1874161 1678320 1874161 1678320

Qd8-c7 38 40 2481558 2085136 1872792 2560000 2311920

Ra1-d1 43 38 2161328 3418801 3109932 2085136 1872792

O-O 35 36 1835518 1500625 1335180 1679616 1499400

c3-c4 39 35 1537266 2313441 2083692 1500625 1335180

c5xd4 34 36 1878315 1336336 1184832 1679616 1499400

e3xd4 41 37 2037094 2825761 2558400 1874161 1678320

Knc6-a5 35 38 2293776 1500625 1335180 2085136 1872792

d4-d5 43 41 2954924 3418801 3109932 2825761 2558400

e6xd5 41 40 2812199 2825761 2558400 2560000 2311920

c4xd5 44 42 3456223 3748096 3416952 3111696 2824080

206

Bb7xd5 42 45 4252457 3111696 2824080 4100625 3746160

Bd3xh7+ 43 22 178592 3418801 3109932 234256 194040

Kg8xh7 40 44 3669053 2560000 2311920 3748096 3416952

Rd1xd5 45 47 4303480 4100625 3746160 4879681 4475340

Kh7-g8 51 45 3900414 6765201 6247500 4100625 3746160

Bb2xg7 39 45 4017018 2313441 2083692 4100625 3746160

Kg8xg7 46 43 3341937 4477456 4098600 3418801 3109932

Knf3-e5 41 43 3357774 2825761 2558400 3418801 3109932

Rf8-d8 46 43 3475089 4477456 4098600 3418801 3109932

Qe2-g4+ 49 27 430241 5764801 5306112 531441 456300

Kg7-f8 50 40 2378502 6250000 5762400 2560000 2311920

Qg4-f5 34 40 2412358 1336336 1184832 2560000 2311920

f7-f6 47 37 1906185 4879681 4475340 1874161 1678320

Kne5-d7+ 41 23 323146 2825761 2558400 279841 233772

Kf8-e8 43 34 1421536 3418801 3109932 1336336 1184832

Rd8xd7 39 37 1964815 2313441 2083692 1874161 1678320

Rd5xd7 34 36 1794180 1336336 1184832 1679616 1499400

Qc7-c5 39 35 1694682 2313441 2083692 1500625 1335180

Qf5-h7 34 35 1381594 1336336 1184832 1500625 1335180

Rc8-c7 35 30 949104 1500625 1335180 810000 706440

Qh7-h8+ 34 17 27989 1336336 1184832 83521 65280

Kf8-f7 34 29 799484 1336336 1184832 707281 613872

Rd7-d3 33 35 1358068 1185921 1047552 1500625 1335180

Kna5-c4 38 33 1181804 2085136 1872792 1185921 1047552

Rf1-d1 34 35 1491532 1336336 1184832 1500625 1335180

Knc4-e5 39 33 1306021 2313441 2083692 1185921 1047552

Qh8-h7+ 37 20 112765 1874161 1678320 160000 129960

Kf7-e6 37 32 1162141 1874161 1678320 1048576 922560

Qh7-g8+ 41 21 90146 2825761 2558400 194481 159600

Ke6-f5 44 36 1556804 3748096 3416952 1679616 1499400

g2-g4+ 42 22 139496 3111696 2824080 234256 194040

Kf5-f4 42 36 1705262 3111696 2824080 1679616 1499400

Rd3-d4+ 36 19 82261 1679616 1499400 130321 104652

Kf4-f3 41 34 1324029 2825761 2558400 1336336 1184832

Qg8-b3+ 40 21 115630 2560000 2311920 194481 159600

Average: 1672177 2293139 2104873 1630960 1495235

72.92 79.44 97.54 89.42

207

Table A.5

Depth: 4

Garry Kasparov vs. Viswanathan Anand, World Championships, 1995 (1-0)


e2-e4 20 25 405375 160000 212520 390625 491400

e7-e5 29 28 728887 707281 863040 614656 755160

Kng1-f3 29 27 665063 707281 863040 531441 657720

Knb8-c6 27 28 750862 531441 657720 614656 755160

Bf1-b5 30 30 908001 810000 982080 810000 982080

a7-a6 32 31 1013312 1048576 1256640 923521 1113024

Bb5-a4 32 29 764962 1048576 1256640 707281 863040

Kng8-f6 27 28 698736 531441 657720 614656 755160

O-O 30 27 616039 810000 982080 531441 657720

Knf6xe4 25 31 943423 390625 331200 923521 809100

d2-d4 39 35 1628784 2313441 2083692 1500625 1335180

b7-b5 32 35 1630415 1048576 922560 1500625 1335180

Ba4-b3 39 36 1698076 2313441 2083692 1679616 1499400

d7-d5 31 38 1974430 923521 809100 2085136 1872792

d4xe5 46 39 2288750 4477456 4098600 2313441 2083692

Bc8-e6 32 39 2353858 1048576 922560 2313441 2083692

Knb1-d2 48 35 1370171 5308416 4877472 1500625 1335180

Kne4-c5 23 33 1126509 279841 233772 1185921 1047552

c2-c3 43 33 1251631 3418801 3109932 1185921 1047552

d5-d4 26 36 1602467 456976 390000 1679616 1499400

Knf3-g5 45 39 2338144 4100625 3746160 2313441 2083692

d4xc3 33 41 2664492 1185921 1047552 2825761 2558400

Kng5xe6 46 39 2316717 4477456 4098600 2313441 2083692

f7xe6 27 34 1359427 531441 456300 1336336 1184832

b2xc3 40 34 1405143 2560000 2311920 1336336 1184832

Qd8-d3 29 38 1904668 707281 613872 2085136 1872792

Bb3-c2 49 38 1931006 5764801 5306112 2085136 1872792

Qd3xc3 31 37 1978256 923521 809100 1874161 1678320

Knd2-b3 45 41 2695497 4100625 3746160 2825761 2558400

Knc5xb3 38 40 2597396 2085136 1872792 2560000 2311920

Bc2xb3 44 39 2121725 3748096 3416952 2313441 2083692

Knc6-d4 32 37 1849797 1048576 922560 1874161 1678320

Qd1-g4 46 41 2460405 4477456 4098600 2825761 2558400

Qc3xa1 38 34 1385417 2085136 1872792 1336336 1184832

Bb3xe6 32 34 1365726 1048576 922560 1336336 1184832

Ra8-d8 39 34 1416724 2313441 2083692 1336336 1184832

Bc1-h6 35 36 1628026 1500625 1335180 1679616 1499400

Qa1-c3 41 40 2488761 2825761 2558400 2560000 2311920

Bh6xg7 45 40 2345540 4100625 3746160 2560000 2311920

208

Qc3-d3 38 38 2080083 2085136 1872792 2085136 1872792

Bg7xh8 44 39 2126579 3748096 3416952 2313441 2083692

Qd3-g6 36 36 1810137 1679616 1499400 1679616 1499400

Bh8-f6 39 38 2009776 2313441 2083692 2085136 1872792

Bf8-e7 39 37 1909964 2313441 2083692 1874161 1678320

Bf6xe7 34 37 1715987 1336336 1184832 1874161 1678320

Qg6xg4 31 32 979250 923521 809100 1048576 922560

Be6xg4 21 24 340921 194481 143640 331776 255024

Ke8xe7 23 24 331390 279841 212520 331776 255024

Rf1-c1 26 26 465879 456976 358800 456976 358800

c7-c6 29 26 428122 707281 570024 456976 358800

f2-f4 24 25 391370 331776 255024 390625 303600

a6-a5 29 26 430085 707281 570024 456976 358800

Kg1-f2 24 28 559797 331776 255024 614656 491400

a5-a4 32 28 537595 1048576 863040 614656 491400

Kf2-e3 24 26 448021 331776 255024 456976 358800

b5-b4 31 28 519923 923521 755160 614656 491400

Bg4-d1 27 25 400038 531441 421200 390625 303600

a4-a3 24 24 352875 331776 255024 331776 255024

g2-g4 26 23 278493 456976 358800 279841 212520

Rd8-d5 21 22 234602 194481 143640 234256 175560

Rc1-c4 24 21 213522 331776 255024 194481 143640

c6-c5 20 20 164753 160000 116280 160000 116280

Ke3-e4 21 19 144993 194481 143640 130321 93024

Rd5-d8 18 21 214208 104976 73440 194481 143640

Rc4xc5 26 24 315241 456976 358800 331776 255024

Knd4-e6 22 24 288389 234256 175560 331776 255024

Rc5-d5 23 21 212514 279841 212520 194481 143640

Rd8-c8 22 24 284170 234256 175560 331776 255024

f4-f5 28 24 267704 614656 491400 331776 255024

Rc8-c4+ 24 14 39001 331776 255024 38416 24024

Ke4-e3 25 23 259604 390625 303600 279841 212520

Kne6-c5 21 19 165038 194481 143640 130321 93024

g4-g5 22 22 227145 234256 175560 234256 175560

Rc4-c1 25 22 232547 390625 303600 234256 175560

Rd5-d6 20 24 311771 160000 116280 331776 255024

Average: 1124855 1379465 1256358 1138090 1029876

Percentage: 81.54 89.53 98.84 91.56

209

Table A.6

Depth: 4

Garry Kasparov vs. Vladimir Kramnik, 1994 (1-0)


e2-e4 20 25 405375 160000 212520 390625 491400

c7-c5 30 25 482304 810000 982080 390625 491400

Knb1-c3 22 26 549504 234256 303600 456976 570024

Knb8-c6 32 28 722790 1048576 1256640 614656 755160

Kng1-e2 26 24 426437 456976 570024 331776 421200

Kng8-f6 23 25 492246 279841 358800 390625 491400

d2-d4 29 29 822043 707281 863040 707281 863040

c5xd4 30 28 791614 810000 982080 614656 755160

Kne2xd4 27 34 1390388 531441 657720 1336336 1585080

e7-e5 42 37 1891635 3111696 2824080 1874161 1678320

Knd4-b5 31 35 1517371 923521 809100 1500625 1335180

d7-d6 40 36 1742186 2560000 2311920 1679616 1499400

Bc1-g5 33 38 2095176 1185921 1047552 2085136 1872792

a7-a6 45 39 2228862 4100625 3746160 2313441 2083692

Knb5-a3 35 39 2273795 1500625 1335180 2313441 2083692

b7-b5 43 38 2172596 3418801 3109932 2085136 1872792

Knc3-d5 33 38 2080770 1185921 1047552 2085136 1872792

Bf8-e7 46 39 2198219 4477456 4098600 2313441 2083692

Bg5xf6 31 36 1632149 923521 809100 1679616 1499400

Be7xf6 39 35 1514686 2313441 2083692 1500625 1335180

c2-c3 33 36 1713829 1185921 1047552 1679616 1499400

O-O 41 35 1513024 2825761 2558400 1500625 1335180

Kna3-c2 31 35 1499399 923521 809100 1500625 1335180

Ra8-b8 40 34 1476241 2560000 2311920 1336336 1184832

Qh2-h4 31 35 1586466 923521 809100 1500625 1335180

Knc6-e7 41 33 1299157 2825761 2558400 1185921 1047552

Knd5xf6+ 39 20 88114 2313441 2083692 160000 129960

g7xf6 36 31 969905 1679616 1499400 923521 809100

Qd1-d2 27 32 1091065 531441 456300 1048576 922560

Bc8-b7 38 32 1075364 2085136 1872792 1048576 922560

Bf1-d3 27 32 1064835 531441 456300 1048576 922560

d6-d5 38 31 1036328 2085136 1872792 923521 809100

e4xd5 28 34 1386100 614656 530712 1336336 1184832

Qd8xd5 41 37 2008896 2825761 2558400 1874161 1678320

O-O-O 36 37 1892986 1679616 1499400 1874161 1678320

e5-e4 36 36 1748932 1679616 1499400 1679616 1499400

Bd3-e2 38 38 2144831 2085136 1872792 2085136 1872792

Qd5xa2 40 36 1606231 2560000 2311920 1679616 1499400

Qd2-h6 31 36 1547465 923521 809100 1679616 1499400

Qa2-e6 48 39 2046906 5308416 4877472 2313441 2083692

Knc2-d4 34 39 1961272 1336336 1184832 2313441 2083692

Qe6-b6 45 36 1573215 4100625 3746160 1679616 1499400

Rh1-h3 30 38 1742718 810000 706440 2085136 1872792

Kg8-h8 47 38 2011712 4879681 4475340 2085136 1872792

Be2-g4 32 39 2012308 1048576 922560 2313441 2083692

Rf8-g8 47 40 2463411 4879681 4475340 2560000 2311920

210

Knd4-e6 38 42 2761261 2085136 1872792 3111696 2824080

Rg8-g6 48 41 2533005 5308416 4877472 2825761 2558400

Qh6-f4 39 43 3303538 2313441 2083692 3418801 3109932

Rb8-e8 51 44 3533832 6765201 6247500 3748096 3416952

Rd1-d6 38 42 2963862 2085136 1872792 3111696 2824080

Kne7-d5 44 41 2807053 3748096 3416952 2825761 2558400

Qh4-h5 39 41 2737049 2313441 2083692 2825761 2558400

Knd5xf4 39 39 2244866 2313441 2083692 2313441 2083692

Qh5xg6 39 39 2120524 2313441 2083692 2313441 2083692

Qb6xd6 33 38 1721786 1185921 1047552 2085136 1872792

Rh3xh7+ 32 16 35797 1048576 922560 65536 50400

Kh8-g8 32 35 1287441 1048576 922560 1500625 1335180

Qg6-g7 43 33 1002198 3418801 3109932 1185921 1047552

Qg6xf7+ 29 15 29329 707281 613872 50625 38220

Kg8xh7 29 33 1041136 707281 613872 1185921 1047552

f7xe8 : Q 35 33 874127 1500625 1335180 1185921 1047552

Knf4xe6 30 29 644983 810000 657720 707281 570024

Bg4-f5+ 30 16 50054 810000 657720 65536 43680

Kh7-g7 30 28 608021 810000 657720 614656 491400

Qe8-g6+ 24 13 29992 331776 255024 28561 17160

Kg7-f8 24 25 394518 331776 255024 390625 303600

Qg6xf6+ 28 15 39315 614656 491400 50625 32760

Kf8-e8 28 27 512396 614656 491400 531441 421200

Bf5xe6 28 29 534790 614656 491400 707281 570024

Qd6-f8 37 26 373051 1874161 1585080 456976 358800

Be6-d7+ 31 16 18070 923521 755160 65536 43680

Average 1419345 1840837 1676395 1464611 1332272

77.1 84.67 96.91 93.87

Table A.7

Depth: 4

Garry Kasparov vs. X3D Fritz, Man-Machine World Chess

Championships, 2004, (1-0)

Move SSE DSE RC SSP SSAP DSP DSAP

Kng1-f3 20 21 233491 160000 212520 194481 255024

Kng8-f6 22 21 275111 234256 303600 194481 255024

c2-c4 22 23 329732 234256 303600 279841 358800

e7-e6 24 25 506999 331776 421200 390625 491400

Knb1-c3 28 27 675463 614656 755160 531441 657720

d7-d5 29 30 917972 707281 863040 810000 982080

d2-d4 32 33 1265913 1048576 1256640 1185921 1413720

c7-c6 35 33 1359328 1500625 1771560 1185921 1413720

e2-e3 33 33 1354461 1185921 1413720 1185921 1413720

a7-a6 35 33 1290032 1500625 1335180 1185921 1047552

c4-c5 28 31 1076204 614656 530712 923521 809100

211

Knb8-d7 36 31 1054340 1679616 1499400 923521 809100

b2-b4 27 32 1121054 531441 456300 1048576 922560

a6-a5 38 33 1243491 2085136 1872792 1185921 1047552

b4-b5 27 31 1012359 531441 456300 923521 809100

e6-e5 36 31 1054879 1679616 1499400 923521 809100

Qd1-a4 26 31 1063920 456976 390000 923521 809100

Qd8-c7 37 32 1218559 1874161 1678320 1048576 922560

Bc1-a3 28 33 1266623 614656 530712 1185921 1047552

e5-e4 36 33 1349434 1679616 1499400 1185921 1047552

Knf3-d2 30 33 1334707 810000 706440 1185921 1047552

Bf8-e7 37 35 1650214 1874161 1678320 1500625 1335180

b5-b6 32 36 1707235 1048576 922560 1679616 1499400

Qc7-d8 40 32 1099159 2560000 2311920 1048576 922560

h2-h3 24 32 1051151 331776 279312 1048576 922560

O-O 40 30 908301 2560000 2311920 810000 706440

Knd2-b3 21 28 712047 194481 159600 614656 530712

Be7-d6 37 32 1172873 1874161 1678320 1048576 922560

Ra1-b1 28 32 1152155 614656 530712 1048576 922560

Bd6-e7 36 28 763606 1679616 1499400 614656 530712

Knb3xa5 22 31 982360 234256 194040 923521 809100

Knd7-b8 41 34 1412883 2825761 2558400 1336336 1184832

Ba3-b4 27 32 1114585 531441 456300 1048576 922560

Qd8-d7 37 31 1049630 1874161 1678320 923521 809100

Rb1-b2 25 31 1036245 390625 331200 923521 809100

Qd7-e6 38 32 1180470 2085136 1872792 1048576 922560

Qa4-d1 26 35 1460473 456976 390000 1500625 1335180

Knf6-d7 44 37 1972567 3748096 3416952 1874161 1678320

a2-a3 31 37 1855474 923521 809100 1874161 1678320

Qe6-h6 44 37 1864407 3748096 3416952 1874161 1678320

Kna5-b3 33 37 1829612 1185921 1047552 1874161 1678320

Be7-h4 39 34 1460235 2313441 2083692 1336336 1184832

Qd1-d2 31 30 1006338 923521 809100 810000 706440

Knd7-f6 32 30 902104 1048576 922560 810000 706440

Ke1-d1 29 31 1034272 707281 613872 923521 809100

Bc8-e6 35 32 1150490 1500625 1335180 1048576 922560

Kd1-c1 30 31 1147126 810000 706440 923521 809100

Rf8-d8 34 33 1350862 1336336 1184832 1185921 1047552

Rb2-c2 33 32 1218201 1185921 1047552 1048576 922560

Knb8-d7 32 33 1347139 1048576 922560 1185921 1047552

Kc1-b2 34 34 1518731 1336336 1184832 1336336 1184832

Knd7-f8 34 34 1476749 1336336 1184832 1336336 1184832

a3-a4 33 34 1476299 1185921 1047552 1336336 1184832

Knf8-g6 35 35 1665132 1500625 1335180 1500625 1335180

a4-a5 34 34 1492223 1336336 1184832 1336336 1184832

Kng6-e7 34 34 1580289 1336336 1184832 1336336 1184832

212

a5-a6 35 35 1669892 1500625 1335180 1500625 1335180

b7xa6 36 35 1627225 1679616 1499400 1500625 1335180

Knb3-a5 33 35 1613808 1185921 1047552 1500625 1335180

Rd8-b8 37 34 1477565 1874161 1678320 1336336 1184832

g2-g3 30 34 1424554 810000 706440 1336336 1184832

Bh4-g5 38 33 1364387 2085136 1872792 1185921 1047552

Bf1-g2 29 35 1502729 707281 613872 1500625 1335180

Qh6-g6 41 35 1520958 2825761 2558400 1500625 1335180

Kb2-a1 29 34 1373738 707281 613872 1336336 1184832

Kg8-h8 39 35 1560763 2313441 2083692 1500625 1335180

Knc3-a2 31 33 1254802 923521 809100 1185921 1047552

Be6-d7 35 33 1267520 1500625 1335180 1185921 1047552

Bb4-c3 31 31 1063049 923521 809100 923521 809100

Knf6-e8 32 32 1150615 1048576 922560 1048576 922560

Kna2-b4 32 34 1423830 1048576 922560 1336336 1184832

Kh8-g8 36 34 1441116 1679616 1499400 1336336 1184832

Rh1-b1 32 34 1470663 1048576 922560 1336336 1184832

Bd7-c8 37 33 1324275 1874161 1678320 1185921 1047552

Rc2-a2 30 34 1442751 810000 706440 1336336 1184832

Bg5-h6 39 33 1319147 2313441 2083692 1185921 1047552

Bg2-f1 28 33 1249685 614656 530712 1185921 1047552

Qg6-e6 38 32 1212539 2085136 1872792 1048576 922560

Qd2-d1 27 35 1510407 531441 456300 1500625 1335180

Kne8-f6 44 34 1307027 3748096 3416952 1336336 1184832

Qd1-a4 24 32 1099528 331776 279312 1048576 922560

Bc8-b7 39 33 1282992 2313441 2083692 1185921 1047552

Kna5xb7 28 34 1384110 614656 530712 1336336 1184832

Rb8xb7 37 35 1608685 1874161 1678320 1500625 1335180

Knb4xa6 33 36 1698829 1185921 1047552 1679616 1499400

Qe6-d7 39 36 1676568 2313441 2083692 1679616 1499400

Qa4-c2 33 35 1622922 1185921 1047552 1500625 1335180

Kg8-h8 38 36 1789380 2085136 1872792 1679616 1499400

Rb1-b3 35 35 1628284 1500625 1335180 1500625 1335180

Average: 1282810 1336709 1213275 1181075 1067490

Percentage: 95.97 94.58 92.07 83.21

213

Table A.8

Depth: 4

Garry Kasparov vs. Veselin Topalov, 2etherlands, 1999 (1-0)


NONE 20 20 197281 160000 212520 160000 212520

e2-e4 20 25 405375 160000 212520 390625 491400

d7-d6 30 28 639961 810000 982080 614656 755160

d2-d4 27 32 1043713 531441 657720 1048576 1256640

Kng8-f6 38 33 1215611 2085136 2430480 1185921 1413720

Knb1-c3 30 34 1312508 810000 982080 1336336 1585080

g7-g6 39 34 1369592 2313441 2686320 1336336 1585080

Bc1-e3 31 36 1602007 923521 1113024 1679616 1974024

Bf8-g7 42 37 1883893 3111696 3575880 1874161 2193360

Qd1-d2 34 36 1700359 1336336 1585080 1679616 1974024

c7-c6 39 36 1837258 2313441 2083692 1679616 1499400

f2-f3 35 37 1930399 1500625 1335180 1874161 1678320

b7-b5 39 37 1901530 2313441 2083692 1874161 1678320

Kng1-e2 36 35 1584057 1679616 1499400 1500625 1335180

Knb8-d7 35 33 1339560 1500625 1335180 1185921 1047552

Be3-h6 30 33 1317328 810000 706440 1185921 1047552

Bg7xh6 34 33 1319301 1336336 1184832 1185921 1047552

Qd2xh6 26 32 1116498 456976 390000 1048576 922560

Bc8-b7 40 34 1368355 2560000 2311920 1336336 1184832

a2-a3 29 34 1354246 707281 613872 1336336 1184832

e7-e5 41 35 1442797 2825761 2558400 1500625 1335180

O-O-O 29 32 1063985 707281 613872 1048576 922560

Qd8-e7 35 31 1054962 1500625 1335180 923521 809100

Kc1-b1 28 32 1177245 614656 530712 1048576 922560

a7-a6 38 32 1144572 2085136 1872792 1048576 922560

Kne2-c1 27 33 1234254 531441 456300 1185921 1047552

O-O-O 40 34 1350083 2560000 2311920 1336336 1184832

Knc1-b3 28 35 1428902 614656 530712 1500625 1335180

e5xd4 43 37 1932741 3418801 3109932 1874161 1678320

Rd1xd4 30 37 1945333 810000 706440 1874161 1678320

c6-c5 46 39 2320033 4477456 4098600 2313441 2083692

Rd4-d1 32 38 2099545 1048576 922560 2085136 1872792

Knd7-b6 45 41 2792475 4100625 3746160 2825761 2558400

g2-g3 38 41 2846836 2085136 1872792 2825761 2558400

Kc8-b8 46 44 3593405 4477456 4098600 3748096 3416952

Knb3-a5 41 43 3291533 2825761 2558400 3418801 3109932

Bb7-a8 46 42 3151282 4477456 4098600 3111696 2824080

Bf1-h3 39 43 3215087 2313441 2083692 3418801 3109932

d6-d5 48 42 3069345 5308416 4877472 3111696 2824080

214

Qh6-f4+ 47 26 368311 4879681 4475340 456976 390000

Kb8-a7 49 42 2936258 5764801 5306112 3111696 2824080

Rh1-e1 38 42 2997049 2085136 1872792 3111696 2824080

d5-d4 46 42 3212411 4477456 4098600 3111696 2824080

Knc3-d5 41 45 3586681 2825761 2558400 4100625 3746160

Knb6xd5 44 40 2641791 3748096 3416952 2560000 2311920

e4xd5 40 43 3194380 2560000 2311920 3418801 3109932

Qe7-d6 47 41 2864843 4879681 4475340 2825761 2558400

Rd1xd4 38 44 3399680 2085136 1872792 3748096 3416952

c5xd4 45 41 2655814 4100625 3746160 2825761 2558400

Re1-e7+ 42 25 448059 3111696 2824080 390625 331200

Ka7-b6 45 39 2335432 4100625 3746160 2313441 2083692

Qf4xd4+ 49 25 134699 5764801 5306112 390625 331200

Kb6xa5 48 40 2328281 5308416 4877472 2560000 2311920

b2-b4+ 26 14 73435 456976 390000 38416 28392

Ka5-a4 46 41 2488508 4477456 4098600 2825761 2558400

Qd4-c3 36 37 1806732 1679616 1499400 1874161 1678320

Qd6xd5 39 39 2163527 2313441 2083692 2313441 2083692

Re7-a7 41 36 1629172 2825761 2558400 1679616 1499400

Ba8-b7 30 34 1371375 810000 706440 1336336 1184832

Ra7xb7 40 36 1652707 2560000 2311920 1679616 1499400

Qd5-c4 31 36 1583003 923521 809100 1679616 1499400

Qc3xf6 40 37 1751736 2560000 2311920 1874161 1678320

Ka4xa3 40 38 1688822 2560000 2311920 2085136 1872792

Qf6xa6+ 35 18 36059 1500625 1335180 104976 83232

Ka3xb4 35 33 1170478 1500625 1335180 1185921 1047552

c2-c3+ 33 18 129704 1185921 1047552 104976 83232

Kb4xc3 33 35 1248750 1185921 982080 1500625 1256640

Qa6-a1+ 31 17 121698 923521 755160 83521 57120

Kc3-d2 32 34 1181557 1048576 863040 1336336 1113024

Qa1-b2+ 29 17 144936 707281 570024 83521 57120

Kd2-d1 36 35 1287511 1679616 1413720 1500625 1256640

Bh3-f1 43 37 1352108 3418801 2961840 1874161 1585080

Rd8-d2 33 35 1380916 1185921 982080 1500625 1256640

Rb7-d7 40 35 1241333 2560000 2193360 1500625 1256640

Rd2xd7 28 30 719606 614656 491400 810000 657720

Bf1xc4 25 28 469255 390625 303600 614656 491400

b5xc4 27 23 248749 531441 421200 279841 212520

Qb2xh8 19 19 148359 130321 93024 130321 93024

Rd7-d3 22 20 157145 234256 175560 160000 116280

Qh8-a8 20 21 191086 160000 116280 194481 143640

c4-c3 24 20 140891 331776 255024 160000 116280

Qa8-a4+ 22 13 33518 234256 175560 28561 17160

Kd1-e1 29 23 205112 707281 570024 279841 212520

f3-f4 20 21 195363 160000 116280 194481 143640

215

f7-f5 25 20 141462 390625 303600 160000 116280

Average: 1504136 2021686 1856417 1550751 1421646

Percentage 74.4 81.02 96.99 94.52

Table A.9

Depth: 4

Micheal Adams vs. Garry Kasparov, Linares, 2005 (0 - 1)


e2-e4 20 25 405375 160000 212520 390625 491400

c7-c5 30 25 482304 810000 982080 390625 491400

Kng1-f3 22 24 440548 234256 303600 331776 421200

d7-d6 28 28 669852 614656 755160 614656 755160

d2-d4 30 32 1168453 810000 982080 1048576 1256640

c5xd4 37 32 1108605 1874161 2193360 1048576 1256640

Knf3xd4 28 34 1314228 614656 755160 1336336 1585080

Kng8-f6 42 36 1569427 3111696 3575880 1679616 1974024

Knb1-c3 31 36 1719063 923521 1113024 1679616 1974024

a7-a6 43 36 1591247 3418801 3109932 1679616 1499400

Bc1-e3 30 37 1846798 810000 706440 1874161 1678320

e7-e6 46 36 1672279 4477456 4098600 1679616 1499400

Bf1-e2 28 36 1637507 614656 530712 1679616 1499400

Qd8-c7 45 38 2092544 4100625 3746160 2085136 1872792

Qd1-d2 33 39 2237490 1185921 1047552 2313441 2083692

b7-b5 45 39 2322497 4100625 3746160 2313441 2083692

a2-a3 35 40 2437312 1500625 1335180 2560000 2311920

Bc8-b7 46 40 2583217 4477456 4098600 2560000 2311920

f2-f3 36 39 2424152 1679616 1499400 2313441 2083692

Knb8-c6 44 41 2919235 3748096 3416952 2825761 2558400

O-O-O 40 38 2184182 2560000 2311920 2085136 1872792

b5-b4 38 39 2346994 2085136 1872792 2313441 2083692

a3xb4 39 37 2081474 2313441 2083692 1874161 1678320

Knc6xb4 36 38 2204601 1679616 1499400 2085136 1872792

g2-g4 43 38 2095524 3418801 3109932 2085136 1872792

Bf8-e7 35 39 2337782 1500625 1335180 2313441 2083692

g4-g5 44 38 2101811 3748096 3416952 2085136 1872792

Knf6-d7 33 39 2257194 1185921 1047552 2313441 2083692

h2-h4 46 39 2330896 4477456 4098600 2313441 2083692

Knd7-c5 34 38 2057559 1336336 1184832 2085136 1872792

Kc1-b1 44 40 2582017 3748096 3416952 2560000 2311920

Ra8-b8 36 38 2324189 1679616 1499400 2085136 1872792

h4-h5 41 39 2418018 2825761 2558400 2313441 2083692

O-O 37 38 2251388 1874161 1678320 2085136 1872792

g5-g6 41 40 2719623 2825761 2558400 2560000 2311920

Be7-f6 40 40 2730593 2560000 2311920 2560000 2311920

Rd1-g1 42 42 3270602 3111696 2824080 3111696 2824080

Bb7-a8 43 43 3686383 3418801 3109932 3418801 3109932

216

Be3-g5 45 45 3931000 4100625 3746160 4100625 3746160

Bf6-e5 46 45 4126260 4477456 4098600 4100625 3746160

g6xh7+ 44 23 184392 3748096 3416952 279841 233772

Kg8xh7 44 45 4340261 3748096 3416952 4100625 3746160

Knd4-b3 48 46 4736622 5308416 4877472 4477456 4098600

Knb4xc2 48 49 5646995 5308416 4877472 5764801 5306112

Knb3xc5 48 48 5360475 5308416 4877472 5308416 4877472

Knc2-a3+ 46 24 311684 4477456 4098600 331776 279312

Kb1-a2 46 48 5334172 4477456 4098600 5308416 4877472

Qc7xc5 46 47 4800553 4477456 4098600 4879681 4475340

Knc3-a4 53 48 5088633 7890481 7308912 5308416 4877472

Kna3-c2 46 49 5125180 4477456 4098600 5764801 5306112

Ka2-b1 54 48 4963350 8503056 7887672 5308416 4877472

Qc5-a3 45 46 4088824 4100625 3746160 4477456 4098600

Average: 2589641.6 3000377.9 2784135.2 2580073 2390586.7

Percentage: 86.31 93.01 99.63 92.31

Table A.10

Depth: 4

Vladimir Kramnik vs. Garry Kasparov, Germany, 1994 (0-1)


d2-d4 20 24 361792 160000 212520 331776 421200

Kng8-f6 28 24 425466 614656 755160 331776 421200

c2-c4 22 25 485415 234256 303600 390625 491400

g7-g6 30 26 527522 810000 982080 456976 570024

Knb1-c3 23 27 639584 279841 358800 531441 657720

Bf8-g7 33 29 779565 1185921 1413720 707281 863040

e2-e4 26 32 1118193 456976 570024 1048576 1256640

d7-d6 40 36 1736487 2560000 2961840 1679616 1974024

Kng1-f3 34 35 1654167 1336336 1585080 1500625 1771560

O-O 38 34 1500298 2085136 1872792 1336336 1184832

Bf1-e2 32 34 1520043 1048576 922560 1336336 1184832

e7-e5 38 34 1533262 2085136 1872792 1336336 1184832

d4-d5 30 33 1315417 810000 706440 1185921 1047552

a7-a5 37 33 1383450 1874161 1678320 1185921 1047552

Bc1-g5 30 35 1605506 810000 706440 1500625 1335180

h7-h6 41 35 1648733 2825761 2558400 1500625 1335180

Bg5-h4 31 33 1355147 923521 809100 1185921 1047552

Knb8-a6 36 33 1334385 1679616 1499400 1185921 1047552

O-O 31 32 1184410 923521 809100 1048576 922560

Bc8-d7 33 34 1453543 1185921 1047552 1336336 1184832

Knf3-d2 36 34 1470955 1679616 1499400 1336336 1184832

Kna6-c5 32 35 1573546 1048576 922560 1500625 1335180

b2-b3 39 33 1311035 2313441 2083692 1185921 1047552

Knf6xe4 32 37 1897965 1048576 922560 1874161 1678320

Bh4xd8 39 35 1619893 2313441 2083692 1500625 1335180

Kne4xc3 29 36 1548803 707281 613872 1679616 1499400

217

Qd1-e1 43 35 1470485 3418801 3109932 1500625 1335180

Rf8xd8 24 34 1198026 331776 279312 1336336 1184832

Ra1-c1 46 34 1194761 4477456 4098600 1336336 1184832

Knc3xa2 22 31 859247 234256 194040 923521 809100

Rc1-a1 41 32 969415 2825761 2558400 1048576 922560

Kna2-b4 25 34 1205254 390625 331200 1336336 1184832

Be2-d1 44 34 1311146 3748096 3416952 1336336 1184832

e5-e4 24 36 1387900 331776 279312 1679616 1499400

Ra1-b1 48 34 1067071 5308416 4877472 1336336 1184832

Rd8-e8 20 35 1149371 160000 129960 1500625 1335180

Qe1-e3 50 40 2352079 6250000 5762400 2560000 2311920

f7-f5 31 39 2021715 923521 809100 2313441 2083692

h2-h4 47 39 2088847 4879681 4475340 2313441 2083692

Re8-f8 31 38 1937662 923521 809100 2085136 1872792

g2-g3 46 37 1837953 4477456 4098600 1874161 1678320

Ra8-e8 29 35 1516340 707281 613872 1500625 1335180

Kg1-g2 42 37 1878817 3111696 2824080 1874161 1678320

Knb4-d3 32 37 1766281 1048576 922560 1874161 1678320

Rf1-g1 42 37 1845208 3111696 2824080 1874161 1678320

f5-f4 30 38 1928456 810000 706440 2085136 1872792

g3xf4 46 38 2001433 4477456 4098600 2085136 1872792

Rf8xf4 31 41 2397637 923521 809100 2825761 2558400

h4-h5 52 40 2244053 7311616 6762600 2560000 2311920

g6-g5 29 39 2069339 707281 613872 2313441 2083692

Rg1-f1 51 38 1861018 6765201 6247500 2085136 1872792

Rf4-h4 28 38 1743998 614656 530712 2085136 1872792

Rf1-h1 50 40 2242449 6250000 5762400 2560000 2311920

Rh4-f4 32 41 2373630 1048576 922560 2825761 2558400

Rh1-f1 51 38 1861018 6765201 6247500 2085136 1872792

Re8-f8 28 38 1729078 614656 530712 2085136 1872792

f2-f3 49 36 1457681 5764801 5306112 1679616 1499400

Rf4-h4 25 38 1514765 390625 331200 2085136 1872792

f3xe4 54 42 2428533 8503056 7887672 3111696 2824080

Knd3-f4+ 49 27 349097 5764801 5306112 531441 456300

Kg2-g1 51 38 1660240 6765201 6247500 2085136 1872792

Knc5-d3 27 39 1714719 531441 456300 2313441 2083692

e4-e5 49 38 1955896 5764801 5306112 2085136 1872792

Knd3xe5 31 39 1865171 923521 809100 2313441 2083692

Rb1-c1 48 39 2118442 5308416 4877472 2313441 2083692

Rh4-h3 33 40 2183420 1185921 1047552 2560000 2311920

Knd2-f3 47 38 1909717 4879681 4475340 2085136 1872792

g5-g4 31 38 1854080 923521 809100 2085136 1872792

Knf3xe5 41 37 2013918 2825761 2558400 1874161 1678320

Rh3xe3 24 34 1139175 331776 279312 1336336 1184832

Kne5xd7 45 33 932339 4100625 3746160 1185921 1047552

Knf4-h3+ 43 23 120455 3418801 3109932 279841 233772

Kg1-g2 43 34 1015217 3418801 3109932 1336336 1184832

Rf8xf1 18 29 479649 104976 83232 707281 613872

Kg2xf1 33 24 295361 1185921 1047552 331776 279312

g4-g3 17 23 253602 83521 65280 279841 233772

Kf1-g2 31 24 317278 923521 809100 331776 279312

218

Knh3-f4+ 36 19 56827 1679616 1499400 130321 104652

Average: 1437562.2 2317024.7 2135457.4 1544062.6 1408511.7

Percentage: 62.04 67.32 93.1 97.98


All games analysed in this section were played by famous Grand Master Robert James

Fischer and were analysed to a depth of 5.

Table A.11

Depth: 5

Donald Byrne vs. Robert James Fischer, Rosenwald Memorial, 1956


Kng1-f3 20 21 5723532 3200000 5100480 4084101 6375600

Kng8-f6 22 21 7113079 5153632 7893600 4084101 6375600

c2-c4 22 23 8452741 5153632 7893600 6436343 9687600

g7-g6 24 23 10097180 7962624 11793600 6436343 9687600

Knb1-c3 23 25 12616156 6436343 9687600 9765625 14250600

Bf8-g7 28 26 17972406 17210368 24165120 11881376 17100720

d2-d4 26 30 24884829 11881376 17100720 24300000 33390720

O-O 35 29 29257926 52521875 69090840 20511149 28480320

Bc1-f4 25 33 31398863 9765625 14250600 39135393 52307640

d7-d5 42 36 71729371 130691232 112963200 60466176 50979600

Qd1-b3 32 38 68836501 33554432 27676800 79235168 67420512

d5xc4 45 39 104108925 184528125 161084880 90224199 77096604

Qb3xc4 34 41 95658859 45435424 37914624 115856201 99777600

c7-c6 50 42 130334802 312500000 276595200 130691232 112963200

e2-e4 35 43 110232181 52521875 44060940 147008443 127507212

Knb8-d7 53 40 108057161 418195493 372754512 102400000 87852960

Ra1-d1 28 39 66908435 17210368 13798512 90224199 77096604

Knd7-b6 52 42 140800294 380204032 338130000 130691232 112963200

Qc4-c5 33 44 120487384 39135393 32474112 164916224 143511984

Bc8-g4 56 47 219229119 550731776 493970400 229345007 201390300

Bf4-g5 37 43 132399986 69343957 58741200 147008443 127507212

Knb6-a4 50 45 186630625 312500000 276595200 184528125 161084880

Qc5-a3 41 41 125400850 115856201 99777600 115856201 99777600

Knf6xe4 42 45 174847215 130691232 112963200 184528125 161084880

Bg5xe7 49 45 189092224 282475249 249387264 184528125 161084880

Kna4xc3 40 45 165621082 102400000 87852960 184528125 161084880

b2xc3 45 42 136669730 184528125 161084880 130691232 112963200

Qd8-b6 40 43 140323948 102400000 87852960 147008443 127507212

219

Bf1-c4 46 45 181349392 205962976 180338400 184528125 161084880

Kne4xc3 47 45 183408498 229345007 201390300 184528125 161084880

Be7-c5 44 42 129656127 164916224 143511984 130691232 112963200

Rf8-e8+ 49 27 20214424 282475249 249387264 14348907 11407500

Ke1-f1 51 45 180070884 345025251 306127500 184528125 161084880

Bg4-e6 41 43 140675791 115856201 99777600 147008443 127507212

Bc5xb6 39 41 101090943 90224199 77096604 115856201 99777600

Be6xc4+ 46 24 4093093 205962976 180338400 7962624 6144864

Kf1-g1 47 40 97395152 229345007 201390300 102400000 87852960

Knc3-e2+ 41 21 1828954 115856201 99777600 4084101 3032400

Kg1-f1 41 37 71195443 115856201 99777600 69343957 58741200

Kne2xd4+ 44 23 6075978 164916224 143511984 6436343 4909212

Kf1-g1 45 40 105895961 184528125 161084880 102400000 87852960

Knd4-e2+ 44 22 2767189 164916224 143511984 5153632 3880800

Kg1-f1 44 41 112296626 164916224 143511984 115856201 99777600

Kne2-c3+ 46 24 5251397 205962976 180338400 7962624 6144864

Kf1-g1 47 43 133459712 229345007 201390300 147008443 127507212

a7xb6 36 41 86313208 60466176 50979600 115856201 99777600

Qa3-b4 51 43 138684011 345025251 306127500 147008443 127507212

Ra8-a4 37 41 90968324 69343957 58741200 115856201 99777600

Qb4xb6 49 42 132950755 282475249 249387264 130691232 112963200

Knc3xd1 26 37 41618156 11881376 9360000 69343957 58741200

h2-h3 49 38 81898373 282475249 249387264 79235168 67420512

Ra4xa2 27 39 51480065 14348907 9687600 90224199 69090840

Kg1-h2 53 41 116643774 418195493 344362200 115856201 89927760

Knd1xf2 35 44 99503341 52521875 38955840 164916224 130320960

Rh1-e1 54 46 178522417 459165024 379501200 205962976 164490480

Re8xe1 27 40 43819500 14348907 9687600 102400000 78960960

Knf3xe1 42 32 33479411 130691232 102080160 33554432 24165120

Bc4-d5 24 31 19813001 7962624 5100480 28629151 20389320

Qb6-d8+ 23 12 595292 6436343 4037880 248832 95040

Bg7-f8 23 28 13926050 6436343 4037880 17210368 11793600

Kne1-f3 32 29 23634887 33554432 24165120 20511149 14250600

Knf2-e4 25 29 17038767 9765625 6375600 20511149 14250600

Qd8-b8 34 28 19220650 45435424 33390720 17210368 11793600

b7-b5 24 28 15605471 7962624 5100480 17210368 11793600

h3-h4 33 28 20949365 39135393 28480320 17210368 11793600

h7-h5 23 27 13449180 6436343 4037880 14348907 9687600

Knf3-e5 32 27 17179899 33554432 24165120 14348907 9687600

Kg8-g7 22 29 15059367 5153632 3160080 20511149 14250600

Kh2-g1 39 30 24574017 90224199 69090840 24300000 17100720

Bf8-c5+ 41 22 2171951 115856201 89927760 5153632 3160080

Kg1-f1 41 31 24293497 115856201 89927760 28629151 20389320

Kne4-g3+ 42 21 658065 130691232 102080160 4084101 2441880

Kf1-e1 42 31 22598179 130691232 102080160 28629151 20389320

220

Bc5-b4+ 40 20 600981 102400000 78960960 3200000 1860480

Ke1-d1 40 30 19900225 102400000 78960960 24300000 17100720

Bd5-b3+ 40 20 571109 102400000 78960960 3200000 1860480

Kd1-c1 40 29 18754865 102400000 78960960 20511149 14250600

Kng3-e2+ 38 19 584874 79235168 60233040 2476099 1395360

Kc1-b1 38 29 18874381 79235168 60233040 20511149 14250600

Kne2-c3+ 38 19 588643 79235168 60233040 2476099 1395360

Kb1-c1 38 29 19189587 79235168 60233040 20511149 14250600

Average: 68362032 129039880 110927276 74361778 63602961

52.98 61.63 91.93 93.04

Table A.12

Depth: 5

Robert Eugene Byrne vs. Robert James Fischer, USA, 1963 (0-1)

Move SSE DSE RC SSP DSAP DSP DSAP

d2-d3 20 23 8073146 3200000 5100480 6436343 9687600

d2-d4 20 24 8879632 3200000 5100480 7962624 11793600

Kng8-f6 28 24 12906605 17210368 24165120 7962624 11793600

c2-c4 22 25 12481695 5153632 7893600 9765625 14250600

g7-g6 30 26 16882382 24300000 33390720 11881376 17100720

g2-g3 23 26 15136454 6436343 9687600 11881376 17100720

c7-c6 31 27 19477153 28629151 38955840 14348907 20389320

Bf1-g2 24 29 21709018 7962624 11793600 20511149 28480320

d7-d5 35 33 42886742 52521875 69090840 39135393 52307640

c4xd5 34 33 45027403 45435424 60233040 39135393 52307640

c6xd5 33 31 34252442 39135393 32474112 28629151 23463900

Knb1-c3 31 33 41115727 28629151 23463900 39135393 32474112

Bf8-g7 36 34 53321785 60466176 50979600 45435424 37914624

e2-e3 34 35 55619784 45435424 37914624 52521875 44060940

O-O 38 35 53439630 79235168 67420512 52521875 44060940

Kng1-e2 32 32 41678270 33554432 27676800 33554432 27676800

Knb8-c6 34 34 51216332 45435424 37914624 45435424 37914624

O-O 35 32 46423437 52521875 44060940 33554432 27676800

b7-b6 31 32 38997112 28629151 23463900 33554432 27676800

b2-b3 34 31 39874621 45435424 37914624 28629151 23463900

Bc8-a6 30 32 37462893 24300000 19780320 33554432 27676800

Bc1-a3 34 34 55974672 45435424 37914624 45435424 37914624

Rf8-e8 35 34 55844675 52521875 44060940 45435424 37914624

Qd1-d2 34 37 72989148 45435424 37914624 69343957 58741200

e7-e5 43 39 100557834 147008443 127507212 90224199 77096604

d4xe5 37 41 120519633 69343957 58741200 115856201 99777600

221

Knc6xe5 45 40 114121404 184528125 161084880 102400000 87852960

Rf1-d1 36 38 98196236 60466176 50979600 79235168 67420512

Kne5-d3 41 39 110040804 115856201 99777600 90224199 77096604

Qd2-c2 39 41 131563422 90224199 77096604 115856201 99777600

Knd3xf2 46 42 142374545 205962976 180338400 130691232 112963200

Kg1xf2 33 40 102396426 39135393 32474112 102400000 87852960

Knf6-g4+ 44 24 12972658 164916224 143511984 7962624 6144864

Kf2-g1 44 44 167436622 164916224 143511984 164916224 143511984

Kng4xe3 45 44 177981334 184528125 161084880 164916224 143511984

Qc2-d2 44 42 155820805 164916224 143511984 130691232 112963200

Kne3xg2 40 41 121633606 102400000 87852960 115856201 99777600

Kg1xg2 39 41 121263501 90224199 77096604 115856201 99777600

d5-d4 44 41 115290597 164916224 143511984 115856201 99777600

Kne2xd4 41 42 139342417 115856201 99777600 130691232 112963200

Ba6-b7+ 42 25 25684055 130691232 112963200 9765625 7617600

Kg2-f1 44 41 137404629 164916224 143511984 115856201 99777600

Qd8-d7 43 46 166150715 147008443 127507212 205962976 180338400

Average 73079581.4 77396152.3 68842033.7 66534413.4 59066095.8

Percentage 94.42 94.2 91.04 80.82

Table A.13

Depth: 5

Robert James Fischer vs. Lhamsuren Myagmarsuren, Sousse Izt, 1967 (1-0)


e2-e4 20 25 9771440 3200000 5100480 9765625 14250600

e7-e6 30 29 25765611 24300000 33390720 20511149 28480320

d2-d3 30 30 29210330 24300000 33390720 24300000 33390720

d7-d5 34 34 45831163 45435424 60233040 45435424 60233040

Knb1-d2 35 31 36743769 52521875 69090840 28629151 38955840

Kng8-f6 29 30 29707207 20511149 28480320 24300000 33390720

g2-g3 33 31 35412913 39135393 52307640 28629151 38955840

c7-c5 30 30 30444794 24300000 33390720 24300000 33390720

Bf1-g2 32 31 36778271 33554432 45239040 28629151 38955840

Knb8-c6 32 33 44314306 33554432 27676800 39135393 32474112

Kng1-f3 36 32 44623796 60466176 50979600 33554432 27676800

Bf8-e7 30 32 40196790 24300000 19780320 33554432 27676800

O-O 36 31 38297552 60466176 50979600 28629151 23463900

O-O 27 29 26980296 14348907 11407500 20511149 16574544

e4-e5 31 28 23994461 28629151 23463900 17210368 13798512

Knf6-d7 25 28 22168205 9765625 7617600 17210368 13798512

Rf1-e1 32 30 31868383 33554432 27676800 24300000 19780320

b7-b5 29 31 33823969 20511149 16574544 28629151 23463900

Knd2-f1 33 31 37219623 39135393 32474112 28629151 23463900

b5-b4 29 30 31350939 20511149 16574544 24300000 19780320

h2-h4 32 31 34923306 33554432 27676800 28629151 23463900

222

a7-a5 30 30 33595233 24300000 19780320 24300000 19780320

Bc1-f4 32 32 40798105 33554432 27676800 33554432 27676800

a5-a4 32 33 45194410 33554432 27676800 39135393 32474112

a2-a3 35 34 51315570 52521875 44060940 45435424 37914624

b4xa3 35 35 59458064 52521875 44060940 52521875 44060940

b2xa3 34 32 42823614 45435424 37914624 33554432 27676800

Knc6-a5 31 30 32983190 28629151 23463900 24300000 19780320

Knf1-e3 30 30 33180958 24300000 19780320 24300000 19780320

Bc8-a6 31 32 46160019 28629151 23463900 33554432 27676800

Bg2-h3 35 35 59170388 52521875 44060940 52521875 44060940

d5-d4 34 34 53920521 45435424 37914624 45435424 37914624

Kne3-f1 34 33 50547524 45435424 37914624 39135393 32474112

Knd7-b6 33 34 51782837 39135393 32474112 45435424 37914624

Knf3-g5 34 34 56903347 45435424 37914624 45435424 37914624

Knb6-d5 36 36 69204455 60466176 50979600 60466176 50979600

Bf4-d2 37 37 80697012 69343957 58741200 69343957 58741200

Be7xg5 35 39 80571450 52521875 44060940 90224199 77096604

Bd2xg5 38 37 74403600 79235168 67420512 69343957 58741200

Qd8-d7 37 40 87898390 69343957 58741200 102400000 87852960

Qd1-h5 42 41 99539838 130691232 112963200 115856201 99777600

Rf8-c8 41 39 91939885 115856201 99777600 90224199 77096604

Knf1-d2 40 42 109489056 102400000 87852960 130691232 112963200

Knd5-c3 43 40 101364279 147008443 127507212 102400000 87852960

Bg5-f6 40 41 95360179 102400000 87852960 115856201 99777600

Qd7-e8 43 37 74029940 147008443 127507212 69343957 58741200

Knd2-e4 34 37 59805303 45435424 37914624 69343957 58741200

g7-g6 41 35 61458965 115856201 99777600 52521875 44060940

Qh5-g5 31 35 49549865 28629151 23463900 52521875 44060940

Knc3xe4 40 35 56080036 102400000 87852960 52521875 44060940

Re1xe4 24 31 27010023 7962624 6144864 28629151 23463900

c5-c4 40 31 36332217 102400000 87852960 28629151 23463900

h4-h5 22 31 26106647 5153632 3880800 28629151 23463900

c4xd3 43 35 57120975 147008443 127507212 52521875 44060940

Re4-h4 27 32 36865333 14348907 11407500 33554432 27676800

Ra8-a7 39 35 57047724 90224199 77096604 52521875 44060940

Bh3-g2 31 37 59611335 28629151 23463900 69343957 58741200

d3xc2 41 38 78958071 115856201 99777600 79235168 67420512

Qg5-h6 36 37 64342714 60466176 50979600 69343957 58741200

Qe8-f8 42 39 85577295 130691232 112963200 90224199 77096604

Qh6xh7+ 34 17 1975677 45435424 37914624 1419857 979200

Average: 50321330.6 54331760.5 48246977.9 47123350.1 41675950.2

Percentage: 92.62 95.88 93.64 82.82

223

Table A.14

Depth: 5

Robert James Fischer vs. Pal Benko, USA, 1963


e2-e4 20 25 9771440 3200000 5100480 9765625 14250600

g7-g6 30 25 14141701 24300000 33390720 9765625 14250600

d2-d4 21 29 17428166 4084101 6375600 20511149 28480320

Bf8-g7 38 31 34897166 79235168 102080160 28629151 38955840

Knb1-c3 25 31 25877047 9765625 14250600 28629151 38955840

d7-d6 39 35 57226580 90224199 115511760 52521875 69090840

f2-f4 32 33 40273109 33554432 45239040 39135393 52307640

Kng8-f6 36 34 51228554 60466176 78960960 45435424 60233040

Kng1-f3 34 34 49527306 45435424 60233040 45435424 60233040

O-O 36 33 50256275 60466176 50979600 39135393 32474112

Bf1-d3 32 34 49265548 33554432 27676800 45435424 37914624

Bc8-g4 37 35 60349059 69343957 58741200 52521875 44060940

h2-h3 34 36 60454169 45435424 37914624 60466176 50979600

Bg4xf3 34 33 45896930 45435424 37914624 39135393 32474112

Qd1xf3 28 34 40695861 17210368 13798512 45435424 37914624

Knb8-c6 41 35 63692875 115856201 99777600 52521875 44060940

Bc1-e3 31 37 62837208 28629151 23463900 69343957 58741200

e7-e5 46 38 91971536 205962976 180338400 79235168 67420512

d4xe5 32 40 85372573 33554432 27676800 102400000 87852960

d6xe5 48 41 114644239 254803968 224363712 115856201 99777600

f4-f5 34 42 102970658 45435424 37914624 130691232 112963200

g6xf5 52 42 137035967 380204032 338130000 130691232 112963200

Qf3xf5 32 43 99139153 33554432 27676800 147008443 127507212

Knc6-d4 52 42 135635232 380204032 338130000 130691232 112963200

Qf5-f2 35 39 86375411 52521875 44060940 90224199 77096604

Knf6-e8 46 39 95776973 205962976 180338400 90224199 77096604

O-O 35 38 70455153 52521875 44060940 79235168 67420512

Kne8-d6 43 40 109002777 147008443 127507212 102400000 87852960

Qf2-g3 36 41 102102604 60466176 50979600 115856201 99777600

Kg8-h8 50 43 150174365 312500000 276595200 147008443 127507212

Qg3-g4 39 45 138597884 90224199 77096604 184528125 161084880

c7-c6 54 46 188506114 459165024 410158944 205962976 180338400

Qg4-h5 39 44 136165537 90224199 77096604 164916224 143511984

Qd8-e8 53 42 132317641 418195493 372754512 130691232 112963200

Be3xd4 27 39 58911175 14348907 11407500 90224199 77096604

e5xd4 51 40 102554979 345025251 306127500 102400000 87852960

Rf1-f6 27 39 63493451 14348907 11407500 90224199 77096604

Kh8-g8 54 40 97725059 459165024 410158944 102400000 87852960

e4-e5 26 39 53265821 11881376 9360000 90224199 77096604

h7-h6 54 38 81954383 459165024 410158944 79235168 67420512

Knc3-e2 23 35 35198355 6436343 4909212 52521875 44060940

Average: 78126000.8 129245772 117312637 83870103.6 75364705.8

Percentage: 60.45 66.6 93.15 96.47

224

Table A.15

Depth: 5

Rene Lelelier Martner vs. Robert James Fischer, Liepzig Olympiad Prelim, 1960 (0-1)


d2-d4 20 24 8879632 3200000 5100480 7962624 11793600

Kng8-f6 28 24 12906605 17210368 24165120 7962624 11793600

c2-c4 22 25 12481695 5153632 7893600 9765625 14250600

g7-g6 30 26 16882382 24300000 33390720 11881376 17100720

Knb1-c3 23 27 17069920 6436343 9687600 14348907 20389320

Bf8-g7 33 29 27200434 39135393 52307640 20511149 28480320

e2-e4 26 32 31955228 11881376 17100720 33554432 45239040

O-O 40 32 40696895 102400000 130320960 33554432 45239040

e4-e5 24 32 27886958 7962624 11793600 33554432 45239040

Knf6-e8 41 31 38279283 115856201 99777600 28629151 23463900

f2-f4 23 30 21057162 6436343 4909212 24300000 19780320

d7-d6 39 33 50079261 90224199 77096604 39135393 32474112

Bc1-e3 29 35 46801765 20511149 16574544 52521875 44060940

c7-c5 43 37 75540781 147008443 127507212 69343957 58741200

d4xc5 32 39 72178898 33554432 27676800 90224199 77096604

Knb8-c6 46 40 103621361 205962976 180338400 102400000 87852960

c5xd6 35 41 101998449 52521875 44060940 115856201 99777600

e7xd6 49 43 139276351 282475249 249387264 147008443 127507212

Knc3-e4 38 43 117133839 79235168 67420512 147008443 127507212

Bc8-f5 50 45 160414202 312500000 276595200 184528125 161084880

Kne4-g3 44 43 132581793 164916224 143511984 147008443 127507212

Bf5-e6 44 43 131745209 164916224 143511984 147008443 127507212

Kng1-f3 43 43 137248095 147008443 127507212 147008443 127507212

Qd8-c7 45 42 140130772 184528125 161084880 130691232 112963200

Qd1-b1 41 40 102003956 115856201 99777600 102400000 87852960

d6xe5 41 40 111206996 115856201 99777600 102400000 87852960

f4-f5 38 39 90833353 79235168 67420512 90224199 77096604

e5-e4 42 43 129630695 130691232 112963200 147008443 127507212

f5xe6 42 40 103927283 130691232 112963200 102400000 87852960

e4xf3 38 39 83694499 79235168 67420512 90224199 77096604

g2xf3 41 39 91035077 115856201 99777600 90224199 77096604

f7-f5 39 40 90976061 90224199 77096604 102400000 87852960

f3-f4 40 36 72107789 102400000 87852960 60466176 50979600

Kne8-f6 35 39 81489752 52521875 44060940 90224199 77096604

Bf1-e2 43 40 110280316 147008443 127507212 102400000 87852960

Rf8-e8 39 41 109083094 90224199 77096604 115856201 99777600

Ke1-f2 44 42 130818673 164916224 143511984 130691232 112963200

Re8xe6 42 45 148393851 130691232 112963200 184528125 161084880

Rh1-e1 48 42 150094236 254803968 224363712 130691232 112963200

Ra8-e8 39 43 124385214 90224199 77096604 147008443 127507212

Be2-f3 47 44 179809907 229345007 201390300 164916224 143511984

Re6xe3 38 46 139380844 79235168 67420512 205962976 180338400

Re1xe3 46 45 165102783 205962976 180338400 184528125 161084880

Re8xe3 36 41 87038855 60466176 50979600 115856201 99777600

Kf2xe3 37 34 47798524 69343957 58741200 45435424 37914624

Qc7xf4+ 38 21 4394648 79235168 67420512 4084101 3032400

225

Average: 87337682.1 105203456 93405681.7 92515166.3 81748936.2

Percentage: 83.02 93.5 94.4 93.6


All games analysed in this section were played by famous Grand Master Jose Raul

Capablanca and were analysed to a depth of 5.

Table: A.16

Depth: 6

Gossip Bernstein vs. Jose Raul Capablanca, Moscow 1914, (0-1)


d2-d4 20 24 269622072 64000000 127512000 191102976 342014400

d7-d5 27 26 514137164 387420489 652458240 308915776 530122320

c2-c4 28 28 714338648 481890304 797448960 481890304 797448960

e7-e6 30 31 1049266380 729000000 1168675200 887503681 1402410240

Knb1-c3 34 33 1432207677 1544804416 2349088560 1291467969 1987690320

Kng8-f6 33 32 1296897472 1291467969 1987690320 1073741824 1673844480

Kng1-f3 32 33 1504692601 1073741824 1673844480 1291467969 1987690320

Bf8-e7 35 33 1578275400 1838265625 2763633600 1291467969 1987690320

Bc1-g5 32 35 1972994071 1073741824 1673844480 1838265625 2763633600

O-O 39 34 1618973236 3518743761 2775477744 1544804416 1175353344

e2-e3 29 34 1797267529 594823321 430938144 1544804416 1175353344

Knb8-d7 40 33 1481768813 4096000000 3250559520 1291467969 974223360

Ra1-c1 27 32 1406063665 387420489 273780000 1073741824 802627200

b7-b6 39 33 1434672211 3518743761 2775477744 1291467969 974223360

c4xd5 28 34 1888413512 481890304 344962800 1544804416 1175353344

e6xd5 40 32 1409166606 4096000000 3250559520 1073741824 802627200

Qd1-a4 25 35 2008499194 244140625 167587200 1838265625 1409950080

Bc8-b7 47 37 3758872955 10779215329 8861173200 2565726409 1997200800

Bf1-a6 27 37 3950828318 387420489 273780000 2565726409 1997200800

Bb7xa6 41 35 4235686668 4750104241 3791548800 1838265625 1409950080

Qa4xa6 24 35 1687213572 191102976 129042144 1838265625 1409950080

c7-c5 48 34 1585535123 12230590464 10096367040 1544804416 1175353344

Bg5xf6 21 35 1391198145 85766121 54583200 1838265625 1409950080

Knd7xf6 45 34 1615165034 8303765625 6765564960 1544804416 1175353344

d4xc5 24 35 1959205409 191102976 129042144 1838265625 1409950080

b6xc5 49 36 4165303893 13841287201 11471814144 2176782336 1682326800

O-O 24 34 1772311825 191102976 129042144 1544804416 1175353344

Qd8-b6 41 37 3370920987 4750104241 3791548800 2565726409 1997200800

226

Qa6-e2 37 36 3793350599 2565726409 1997200800 2176782336 1682326800

c5-c4 35 38 3330826354 1838265625 1409950080 3010936384 2359717920

Rf1-d1 42 39 2781399410 5489031744 4405564800 3518743761 2775477744

Rf8-d8 37 39 2493806796 2565726409 1997200800 3518743761 2775477744

Knf3-d4 40 40 2200077990 4096000000 3250559520 4096000000 3250559520

Be7-b4 40 39 2295654439 4096000000 3250559520 3518743761 2775477744

b2-b3 40 39 2235258439 4096000000 3250559520 3518743761 2775477744

Ra8-c8 40 40 382695493 4096000000 3250559520 4096000000 3250559520

b3xc4 42 41 697430292 5489031744 4405564800 4750104241 3791548800

d5xc4 40 42 1395356381 4096000000 3250559520 5489031744 4405564800

Rc1-c2 43 41 1154104919 6321363049 5100288480 4750104241 3791548800

Bb4xc3 36 41 608255504 2176782336 1682326800 4750104241 3791548800

Rc2xc3 40 40 2229219555 4096000000 3250559520 4096000000 3250559520

Knf6-d5 41 42 615701572 4750104241 3791548800 5489031744 4405564800

Rc3-c2 45 40 2221259350 8303765625 6765564960 4096000000 3250559520

c4-c3 38 40 2226848861 3010936384 2359717920 4096000000 3250559520

Rd1-c1 44 39 2743280333 7256313856 5883991344 3518743761 2775477744

Rc8-c5 36 40 2352202123 2176782336 1682326800 4096000000 3250559520

Knd4-b3 43 38 2834133605 6321363049 5100288480 3010936384 2359717920

Rc5-c6 35 39 2705796088 1838265625 1409950080 3518743761 2775477744

Knb3-d4 44 39 2402166632 7256313856 5883991344 3518743761 2775477744

Rc6-c7 36 40 2279703335 2176782336 1682326800 4096000000 3250559520

Knd4-b5 43 38 3138179728 6321363049 5100288480 3010936384 2359717920

Rc7-c5 34 37 3277553292 1544804416 1175353344 2565726409 1997200800

Knb5xc3 47 40 234221911 10779215329 8861173200 4096000000 3250559520

Knd5xc3 30 43 94467620 729000000 534068640 6321363049 4389446880

Rc2xc3 50 42 629863108 15625000000 12999974400 5489031744 3776965920

Rc5xc3 31 41 3362683712 887503681 656989200 4750104241 3237399360

Rc1xc3 41 36 1891040583 4750104241 3237399360 2176782336 1402410240

Qb6-b2 34 35 1427836543 1544804416 968330880 1838265625 1168675200

Average: 1946618496 3748586329 3112961772 2736186333 2226796915

Percentage: 51.93 62.53 71.14 87.42

Table A.17

Depth: 6

Emanuel Lasker vs. Jose Raul Capablanca, World Championships, 1921 (0-1)


d2-d4 20 24 269622072 64000000 127512000 191102976 342014400

d7-d5 27 26 514137164 387420489 652458240 308915776 530122320

c2-c4 28 28 714338648 481890304 797448960 481890304 797448960

e7-e6 30 31 1049266380 729000000 1168675200 887503681 1402410240

227

Knb1-c3 34 33 1432207677 1544804416 2349088560 1291467969 1987690320

Kng8-f6 33 32 1296897472 1291467969 1987690320 1073741824 1673844480

Bc1-g5 31 34 1690632348 887503681 1402410240 1544804416 2349088560

Bf8-e7 38 34 1811435307 3010936384 4389446880 1544804416 2349088560

e2-e3 32 37 2492620204 1073741824 1673844480 2565726409 3776965920

O-O 43 35 2011507550 6321363049 5100288480 1838265625 1409950080

Kng1-f3 29 34 1797267529 594823321 430938144 1544804416 1175353344

Knb8-d7 40 33 1481768813 4096000000 3250559520 1291467969 974223360

Qd1-c2 27 37 2097809939 387420489 273780000 2565726409 1997200800

c7-c5 48 36 1899257676 12230590464 10096367040 2176782336 1682326800

Ra1-d1 25 35 1715876050 244140625 167587200 1838265625 1409950080

Qd8-a5 40 35 2154625336 4096000000 3250559520 1838265625 1409950080

Bf1-d3 32 36 2597389954 1073741824 802627200 2176782336 1682326800

h7-h6 41 36 2628813045 4750104241 3791548800 2176782336 1682326800

Bg5-h4 33 36 2460820426 1291467969 974223360 2176782336 1682326800

c5xd4 41 39 3954745206 4750104241 3791548800 3518743761 2775477744

e3xd4 37 37 3062996032 2565726409 1997200800 2565726409 1997200800

d5xc4 38 39 3758187053 3010936384 2359717920 3518743761 2775477744

Bd3xc4 42 43 5551662085 5489031744 4405564800 6321363049 5100288480

Knd7-b6 45 41 4593696719 8303765625 6765564960 4750104241 3791548800

Bc4-b3 39 37 3255280518 3518743761 2775477744 2565726409 1997200800

Bc8-d7 37 41 5010976050 2565726409 1997200800 4750104241 3791548800

O-O 47 43 6447647086 10779215329 8861173200 6321363049 5100288480

Ra8-c8 40 43 7202604500 4096000000 3250559520 6321363049 5100288480

Knf3-e5 45 45 8451304375 8303765625 6765564960 8303765625 6765564960

Bd7-b5 46 46 9922585034 9474296896 7754551200 9474296896 7754551200

Rf1-e1 48 47 11295928512 12230590464 10096367040 10779215329 8861173200

Knb6-d5 46 48 11799908101 9474296896 7754551200 12230590464 10096367040

Bb3xd5 48 50 13435081706 12230590464 10096367040 15625000000 12999974400

Knf6xd5 48 49 11885091809 12230590464 10096367040 13841287201 11471814144

Bh4xe7 45 49 10780488366 8303765625 6765564960 13841287201 11471814144

Knd5xe7 46 43 5950441802 9474296896 7754551200 6321363049 5100288480

Qc2-b3 42 41 5240587440 5489031744 4405564800 4750104241 3791548800

Bb5-c6 44 42 5464513777 7256313856 5883991344 5489031744 4405564800

Kne5xc6 40 42 4529298759 4096000000 3250559520 5489031744 4405564800

b7xc6 39 37 2595264800 3518743761 2775477744 2565726409 1997200800

Re1-e5 32 38 2849120644 1073741824 802627200 3010936384 2359717920

Qa5-b6 45 38 2728480001 8303765625 6765564960 3010936384 2359717920

Qb3-c2 31 39 2973533569 887503681 656989200 3518743761 2775477744

Rf8-d8 49 40 3879158446 13841287201 11471814144 4096000000 3250559520

Knc3-e2 33 40 3661089538 1291467969 974223360 4096000000 3250559520

Rd8-d5 44 40 4178920010 7256313856 5883991344 4096000000 3250559520

Re5xd5 34 39 2930878902 1544804416 1175353344 3518743761 2775477744

c6xd5 39 37 2149199356 3518743761 2775477744 2565726409 1997200800

Qc2-d2 40 35 1849807388 4096000000 3250559520 1838265625 1409950080

228

Kne7-f5 32 36 2092004387 1073741824 802627200 2176782336 1682326800

b2-b3 41 36 1939392475 4750104241 3791548800 2176782336 1682326800

h6-h5 32 36 2007458572 1073741824 802627200 2176782336 1682326800

h2-h3 42 36 2003435463 5489031744 4405564800 2176782336 1682326800

h5-h4 31 35 1589342350 887503681 656989200 1838265625 1409950080

Qd2-d3 40 36 1727397095 4096000000 3250559520 2176782336 1682326800

Rc8-c6 32 32 1249145437 1073741824 802627200 1073741824 802627200

Kg1-f1 34 31 1027485478 1544804416 1175353344 887503681 656989200

g7-g6 31 32 1092626676 887503681 656989200 1073741824 802627200

Qd3-b1 35 29 682831766 1838265625 1409950080 594823321 430938144

Qb6-b4 23 32 801049860 148035889 98184240 1073741824 802627200

Kf1-g1 43 33 1120464883 6321363049 5100288480 1291467969 974223360

a7-a5 25 32 932253256 244140625 167587200 1073741824 802627200

Qb1-b2 41 33 1062027111 4750104241 3791548800 1291467969 974223360

a5-a4 27 34 1108765987 387420489 273780000 1544804416 1175353344

Qb2-d2 41 35 1424940073 4750104241 3791548800 1838265625 1409950080

Qb4xd2 20 30 393318946 64000000 39767760 729000000 534068640

Rd1xd2 26 21 90288227 308915776 215280000 85766121 54583200

a4xb3 18 21 92910141 34012224 19975680 85766121 54583200

a2xb3 24 20 65921658 191102976 129042144 64000000 39767760

Rc6-b6 17 19 59342045 24137569 13708800 47045881 28465344

Rd2-d3 22 19 59690456 113379904 73735200 47045881 28465344

Rb6-a6 18 21 71380644 34012224 19975680 85766121 54583200

g2-g4 24 21 78577015 191102976 129042144 85766121 54583200

h4xg3 18 21 81180065 34012224 13366080 85766121 39070080

f2xg3 25 20 63775498 244140625 127512000 64000000 27907200

Ra6-a2 16 21 63347058 16777216 5765760 85766121 39070080

Kne2-c3 29 22 87437869 594823321 342014400 113379904 53721360

Ra2-c2 17 21 65562853 24137569 8910720 85766121 39070080

Knc3-d1 29 21 57746826 594823321 342014400 85766121 39070080

Knf5-e7 13 18 36503160 4826809 1235520 34012224 13366080

Knd1-c3 20 17 39746950 64000000 27907200 24137569 8910720

Rc2-c1+ 19 12 11469228 47045881 19535040 2985984 665280

Kg1-f2 20 18 49761271 64000000 27907200 34012224 13366080

Kne7-c6 19 22 82535771 47045881 19535040 113379904 53721360

Knc3-d1 23 19 51708610 148035889 72681840 47045881 19535040

Rc1-b1 17 19 43472650 24137569 8910720 47045881 19535040

Kf2-e2 21 18 36699088 85766121 39070080 34012224 13366080

Rb1xb3 17 21 67011370 24137569 8910720 85766121 39070080

Ke2-e3 26 19 40468007 308915776 165765600 47045881 19535040

Rb3-b4 14 19 53480800 7529536 2162160 47045881 19535040

Knd1-c3 25 20 74503324 244140625 127512000 64000000 27907200

Knc6-e7 17 19 52066418 24137569 8910720 47045881 19535040

Knc3-e2 21 17 39082875 85766121 39070080 24137569 8910720

Kne7-f5+ 25 14 14881921 244140625 127512000 7529536 2162160

229

Ke3-f2 25 21 85914235 244140625 127512000 85766121 39070080

g6-g5 18 21 85618965 34012224 13366080 85766121 39070080

g3-g4 24 21 90947566 191102976 96909120 85766121 39070080

Knf5-d6 21 22 99808347 85766121 39070080 113379904 53721360

Kne2-g1 24 20 63192412 191102976 96909120 64000000 27907200

Knd6-e4+ 24 15 15055550 191102976 96909120 11390625 3603600

Kf2-f1 24 18 40601280 191102976 96909120 34012224 13366080

Rb4-b1+ 26 14 7660163 308915776 165765600 7529536 2162160

Kf1-g2 27 20 55034223 387420489 213127200 64000000 27907200

Rb1-b2+ 26 15 12842640 308915776 165765600 11390625 3603600

Kg2-f1 28 19 38518152 481890304 271252800 47045881 19535040

Rb2-f2+ 25 13 2006433 244140625 127512000 4826809 1235520

Kf1-e1 25 18 29574021 244140625 127512000 34012224 13366080

Rf2-a2 13 20 41947081 4826809 1235520 64000000 27907200

Ke1-f1 28 19 38979962 481890304 271252800 47045881 19535040

Kg8-g7 12 21 47126598 2985984 665280 85766121 39070080

Rd3-e3 31 21 55279728 887503681 530122320 85766121 39070080

Kg7-g6 13 19 36292552 4826809 1235520 47045881 19535040

Re3-d3 28 19 37747564 481890304 271252800 47045881 19535040

f7-f6 12 18 29794719 2985984 665280 34012224 13366080

Rd3-e3 26 19 35385390 308915776 165765600 47045881 19535040

Kg6-f7 13 19 38228119 4826809 1235520 47045881 19535040

Re3-d3 28 19 39129684 481890304 271252800 47045881 19535040

Kf7-e7 12 19 36469116 2985984 665280 47045881 19535040

Rd3-e3 28 20 41954239 481890304 271252800 64000000 27907200

Ke7-d6 13 18 27485082 4826809 1235520 34012224 13366080

Re3-d3 25 18 28152759 244140625 127512000 34012224 13366080

Ra2-f2+ 21 11 1347328 85766121 39070080 1771561 332640

Kf1-e1 21 16 19391411 85766121 39070080 16777216 5765760

Rf2-g2 13 16 19673762 4826809 1235520 16777216 5765760

Ke1-f1 21 15 16924320 85766121 39070080 11390625 3603600

Rg2-a2 12 17 26337938 2985984 665280 24137569 8910720

Rd3-e3 25 18 30415863 244140625 127512000 34012224 13366080

e6-e5 14 18 34662967 7529536 2162160 34012224 13366080

Re3-d3 26 18 36868919 308915776 165765600 34012224 13366080

e5xd4 13 19 37817849 4826809 1235520 47045881 19535040

Rd3xd4 27 19 34717466 387420489 213127200 47045881 19535040

Kd6-c5 12 16 22649099 2985984 665280 16777216 5765760

Rd4-d1 27 19 31477562 387420489 213127200 47045881 19535040

d5-d4 11 17 26744432 1771561 332640 24137569 8910720

Rd1-c1+ 13 10 10662844 4826809 1235520 1000000 151200

Kc5-d5 15 19 39335307 11390625 3603600 47045881 19535040

1683375268 2094607868 1717672051 1744611907 1441664244

80.37 98 96.49 85.64

230

Table A.18

Depth: 6

Jose Raul Capablance vs. Frank James Marshall, 2ew York, 1909 (1-0)


e2-e4 20 25 309480898 64000000 127512000 244140625 427518000

e7-e5 29 28 673075454 594823321 968330880 481890304 797448960

Kng1-f3 29 27 613225379 594823321 968330880 387420489 652458240

Knb8-c6 27 28 722336094 387420489 652458240 481890304 797448960

Bf1-b5 30 30 893869214 729000000 1168675200 729000000 1168675200

d7-d6 32 29 814551869 1073741824 1673844480 594823321 968330880

O-O 27 28 611808990 387420489 652458240 481890304 797448960

a7-a6 29 28 701245182 594823321 968330880 481890304 797448960

Bb5xc6+ 27 15 59169849 387420489 652458240 11390625 27907200

b7xc6 23 25 372017531 148035889 98184240 244140625 167587200

d2-d4 29 29 840100705 594823321 430938144 594823321 430938144

e5xd4 32 30 944091597 1073741824 802627200 729000000 534068640

Knf3xd4 28 32 1253979541 481890304 344962800 1073741824 802627200

Bc8-d7 37 32 1266473080 2565726409 1997200800 1073741824 802627200

Rf1-e1 28 33 1473688189 481890304 344962800 1291467969 974223360

c6-c5 39 35 2041779646 3518743761 2775477744 1838265625 1409950080

Knd4-f3 32 33 1574264566 1073741824 802627200 1291467969 974223360

Bf8-e7 35 32 1353568789 1838265625 1409950080 1073741824 802627200

Knb1-c3 30 32 1500467925 729000000 534068640 1073741824 802627200

c7-c6 36 32 1519488196 2176782336 1682326800 1073741824 802627200

Bc1-f4 29 35 2125685693 594823321 430938144 1838265625 1409950080

Bd7-e6 42 38 3086325834 5489031744 4405564800 3010936384 2359717920

Qd1-d3 35 42 4766386937 1838265625 1409950080 5489031744 4405564800

Kng8-f6 50 43 5537704336 15625000000 12999974400 6321363049 5100288480

Ra1-d1 37 41 4723021483 2565726409 1997200800 4750104241 3791548800

d6-d5 48 41 5000127153 12230590464 10096367040 4750104241 3791548800

Knf3-g5 34 41 5009781918 1544804416 1175353344 4750104241 3791548800

d5-d4 48 43 5885803270 12230590464 10096367040 6321363049 5100288480

Kng5xe6 30 40 3685743624 729000000 534068640 4096000000 3250559520

f7xe6 45 39 3294913910 8303765625 6765564960 3518743761 2775477744

Knc3-a4 32 39 3241227352 1073741824 802627200 3518743761 2775477744

Qd8-a5 47 41 4130412937 10779215329 8861173200 4750104241 3791548800

b2-b3 36 39 3550858000 2176782336 1682326800 3518743761 2775477744

Ra8-d8 45 39 3365099998 8303765625 6765564960 3518743761 2775477744

Kna4-b2 36 39 3369988222 2176782336 1682326800 3518743761 2775477744

Knf6-h5 44 39 3157813879 7256313856 5883991344 3518743761 2775477744

Bf4-e5 34 37 2629859984 1544804416 1175353344 2565726409 1997200800

O-O 42 39 3538866798 5489031744 4405564800 3518743761 2775477744

Knb2-c4 36 38 3273395171 2176782336 1682326800 3010936384 2359717920

231

Qa5-b4 42 40 3999017350 5489031744 4405564800 4096000000 3250559520

Qd3-h3 40 40 4074099752 4096000000 3250559520 4096000000 3250559520

g7-g6 44 41 4178860707 7256313856 5883991344 4750104241 3791548800

Qh3xe6+ 48 24 115503151 12230590464 10096367040 191102976 129042144

Rf8-f7 48 40 4004331022 12230590464 10096367040 4096000000 3250559520

g2-g4 34 39 3324032444 1544804416 1175353344 3518743761 2775477744

Be7-h4 47 40 3660133203 10779215329 8861173200 4096000000 3250559520

g4xh5 31 38 2831770549 887503681 656989200 3010936384 2359717920

Bh4xf2+ 31 17 168913612 887503681 656989200 24137569 13708800

Kg1-h1 31 38 2746294155 887503681 656989200 3010936384 2359717920

Qb4-c3 47 39 3331605546 10779215329 8861173200 3518743761 2775477744

Re1-e3 31 40 3245827094 887503681 656989200 4096000000 3250559520

Qc3xc2 52 41 3902027157 19770609664 16568370000 4750104241 3791548800

Re3-d3 29 38 2732527201 594823321 430938144 3010936384 2359717920

Qc2-e2 51 41 3117785920 17596287801 14694120000 4750104241 3791548800

Knc4-d6 31 34 1928996823 887503681 656989200 1544804416 1175353344

Rd8xd6 42 34 1388776446 5489031744 4405564800 1544804416 1175353344

Be5xd6 25 29 824919710 244140625 167587200 594823321 430938144

Bf2-e1 42 35 1284020442 5489031744 4405564800 1838265625 1409950080

Qe6-e8+ 41 21 95024429 4750104241 3791548800 85766121 54583200

Kg8-g7 42 37 1689637119 5489031744 4405564800 2565726409 1997200800

h5-h6+ 40 21 85291969 4096000000 3250559520 85766121 54583200

Average: 2387558934 4163725797 3441699074 2472348577 2003523047

Percentage: 57.34 69.37 96.57 83.92

232

Appendix B

B.1 Introduction

Appendix B contains the article based on the contents of this dissertation as published in the

Proceedings of the Tools and Methods of Competitive Engineering (TMCE) 2008

Symposium, hosted in Izmir, Turkey during April 2008.

B.2 Published Article

The first page of the published article is printed on the following page.

Proceedings of the TMCE 2008, April 21–25, 2008, Izmir, Turkey, Edited by I. Horváth and Z. Rusák

Organizing Committee of TMCE 2008, ISBN 978-90-5155-044-3

1

ECONOMICMOBILE COMPUTING UTILIZING MOBILE DEVICES FORMING VIRTUAL ORGANIZATIONS

Gerard Gouws Academy for Information Technology

University of Johannesburg [email protected]

Elizabeth Ehlers Ockmer Oosthuizen

Academy for Information Technology University of Johannesburg

(emehlers, oloosthuizen)@uj.ac.za

ABSTRACT

This paper proposes an architecture MAGGIE

(Mobile Agents in Global Grid Infrastructure for

Enterprises), that allows for mobile computing

incorporating economic based grid computing,

where services and resources are contributed at a

specific price, which can be configured by the mobile

device owner. MAGGIE targets both low-end and

high-end consumer mobile devices, such as cell-

phones and PDA’s (Personal Digital Assistant) and

also makes provision for the limitations and

constraints introduced by mobile devices. MAGGIE

also provides a platform for application developers

to develop and implement services that can be used

via MAGGIE by different mobile device owners. This

paper discusses the various motivations and

challenges as to why MAGGIE incorporates mobile

devices, mobile agent technology and economic

based grid modeling to provide a grid computing

environment. The paper then discusses the

architecture of MAGGIE on both an abstract and a

detailed design level, such as its negotiations

processes, security mechanisms and service

implementation techniques. MAGGIE is also

compared to three already existing and popular grid

computing environments and technologies. MAGGIE

truly provides an architecture for mobile computing

utilizing mobile devices, incorporating economic

based models and theory, creating a competitive

environment and market.

KEYWORDS

Mobile computing, mobile devices, virtual

organizations, mobile agents.

1. INTRODUCTION

Grid computing has been an evolving approach to

solve collaborative engineering applications or

distributed applications for the last decade (Buyya,

R., 2000). With the increasing popularity of the

Internet and the World Wide Web, grid computing

technology has grown in the efficiency of harnessing

interconnected and geographically distributed

resources to satisfy distributed application

requirements. These distributed resources can range

from idle CPU cycles, memory, secondary storage,

bandwidth, specialized and scientific devices (Buyya,

R., 2000)

Grid computing has brought forth many grid

computing applications and has resulted in beneficial

results (Phan, T., 2002). Grid computing projects

have provided computational power and capabilities

to projects such as SETI (Search for Extraterrestrial

Life Project), ADIS research, Human Genome

Project and multimedia content distribution projects

(Phan, T., 2002). It is evident that grid computing

technologies can introduce many benefits on a global

scale.

Mobile computing is the concept of expanding or

integrating grid computing paradigms over mobile

devices. This is based on the fact that mobile devices

have grown exponentially in numbers, usage and

popularity (Phan, T., 2002).

Throughout this paper, the term mobile device will

refer to the range of high-end consumer devices such

as personal digital assistants (PDAs), laptops, pocket

PC’s, to low-end consumer devices such as cell

phones, pagers, etc.

ECO2OMIC MOBILE COMPUTI2G UTILIZI2G MOBILE DEVICES FORMI2G VIRTUAL

ORGA2IZATIO2S 2

This paper will discuss the architecture of MAGGIE

– Mobile Agents in Global Grid Infrastructure for

Enterprises. The MAGGIE architecture is designed

and implemented for the harvesting of idle or free

mobile device resources via wireless networks.

MAGGIE also implements mobile agent and agent

technology for various reasons that shall be discussed

later in sections 3 and 4.

The paper will be organized in the following manner:

Section 2 will discuss as to why to integrate mobile

devices into grid computing technologies and which

fundamental challenges are introduced by mobile

devices. Section 3 will discuss the benefits of

implementing mobile and agent technology into grid

computing technologies, and more specifically

mobile computing. Section 4 will provide the general

abstract overview architecture of MAGGIE. Section

5 shall provide a more in-depth discussion of

MAGGIE architecture components. Section 6 shall

provide a comparison of MAGGIE against other

related projects and architectures. In section 7 future

research work is presented and the paper is then

concluded with a summary and conclusion.

2. WHY MOBILE DEVICES?

It may seem as an unlikely approach to integrate

mobile devices into a grid computing infrastructure,

as the conventional approach is to integrate higher

performance machines such as always connected

super computers, desktop computers and even

mainframes to meet the requirements of distributed

applications (Buyya, R., 2000, Phan, T., 2002).

Mobile devices introduce many inherent

disadvantages that pose many challenges to creating

mobile grid computing solutions. These inherent

disadvantages are (Phan, T., 2002, Satyanaraynan,

M., 1993, Satyanaraynan, M., 1996):

• Resource poor: Due to the decrease of size of

mobile devices, this results into the direct

decrease of computational and secondary storage

capabilities. Even though mobile devices abide to

Moore’s law, these devices will always find

themselves inferior to more static elements such

as desktops, servers, etc.

• -etwork connectivity: Conventional grid

computing node resources can rely on reliable,

secure and high performance wired network

connectivity such as ISDN lines, ADSL lines, etc.

However, mobile devices rely on wireless, slow

and intermittent connectivity. It is thus clear that

the characteristics and topology of mobile

networks can change substantially over a period

of time.

• Battery power: Even though the battery power

and battery life of mobile devices will always

improver as technology progresses, it will remain

a critical issue to mobile devices. This can also

restrict the computational resources of mobile

devices, as more powerful computations

components require more power. This can also

hamper the motivation for users to donate

resources or services embedded on their mobile

devices, as this will consume battery power.

It is clear that mobile devices introduce many

inherent disadvantages that propose many challenges

to creating a mobile grid computing environment.

However, there too exist arguments for the utilization

of mobile devices in grid computing, and some

solutions to lift or overcome the shortcomings of

mobile devices. These arguments can be summarized

as followed (Phan, T., 2002):

• Gigantic numbers: The raw number of mobile

devices is gigantic and can provide huge

computations and storage capabilities to a grid

computing environment.

• Future technology: Mobile devices and their

corresponding battery power, computation and

storage capabilities will improve over time, thus

abiding to Moore’s Law.

• User Control: Providing mobile device owners

the appropriate mechanisms to configure policy

settings, allowing the user to reflect as to what is

perceived as over usage.

• Economic based model: Economy based grid

computing models are described as grid

computing environments, where resource and

service producers contribute resources and

services to the grid computing environment, in

exchange for some form of payment (Buyya, R.,

2000). This can aid substantially in the motivation

of mobile device owners to contribute their

mobile devices to a mobile grid computing

environment.

It is thus evident that mobile devices can provide

many substantial benefits to gird computing

environments.

3. WHY AGENT TECHNOLOGY?

It has long since been suggested that grid computing

architectures and environments can benefit from

AOSE (Agent Orientated Software Engineering)

strategies (Leong, P., 2006).


ORGA2IZATIO2S 3

AOSE can enhance or even solve some of the

complex issues that are found as common in grid

computing architectures. Such issues are (Foster, I.,

2004, Leong, P., 2006):

• Service/Resource advertisement and discovery:

There exist many efficient algorithms to search

and advertise various agents and their capabilities,

and thus grid computing architectures can benefit

from this, by advertising the various resources and

services available on the grid infrastructure

• -egotiations: Agent negotiation mechanisms can

be used to support and enhance the negotiation

processes between the resource consumer and

resource producer found in the grid environment.

• Virtual Organizations: In the context of grid

computing, Virtual Organizations (VO’s) are

viewed as a clustering of distinct entities that are

similar in the services they provide or in their

capabilities. It is in agent technology that much

research has been done in the dynamic creation of

VO’s, and thus can aid in the creation of VO’s

from a grid computing context.

It is clear to see as to how agent technology can

support and enhance a grid environment. However,

the benefits of mobile agent technology can hugely

aid both grid computing and mobile computing.

These benefits are (Kim, P.J., 2003, Lopes, R. F., et

al. 2006, Pour, G., et al., 2006):

• -etwork load: Mobile agents can greatly reduce

the network traffic load in wireless networks as

they can migrate from one grid node to another.

This is ideal for mobile devices as they contain

low bandwidth capabilities.

• Flexibility: Mobile agents can greatly increase the

flexibility of a grid computing architecture, due to

the dynamic nature of wireless networks.

• Fault tolerance: Several errors might occur

during the execution of grid computing

transactions, such as network disconnections

between grid nodes and application errors that

occurred in the execution environment of mobile

agents. Mobile agent technology and mechanisms

can be used to effectively monitor the occurrence

of such errors, and also to recover or report such

errors. This is extremely important in mobile

computing, as wireless networks are extremely

unreliable, intermittent and dynamic of nature.

It is clear to see how and why mobile agent and agent

technologies can support and enhance grid

computing paradigms, and more importantly mobile

computing.

4. MAGGIE ARCHITECTURE

The goal of Mobile Agents in Global Grid

Infrastructure for Enterprises (MAGGIE) is to

provide a general architecture for mobile computing

and distributed applications. The following sections

will discuss the appropriate mobile development

technologies that are utilized in MAGGIE, their

shortcomings, as well as give an overview of the

MAGGIE architecture.

4.1. Development Technologies

Two primary development technologies will be

utilized, as to show the harmonious integration and

utilization of such technologies by MAGGIE.

These two technologies are:

• Sun Microsystem’s Java Micro-edition Platform 2

(J2ME) using the Mobile Information Device

Profile 2.0 (MIDP 2.0).

• Microsoft’s .NET Compact Framework (.NET

CF).

The J2ME MIDP 2.0 is targeted at low-end consumer

devices that are seen as resource constraint in the

context of computational resources, memory size,

secondary storage, and display screen sizes.

The Microsoft .NET CF is targeted at more high-end

consumer devices that contains larger resource

constraint budgets. These devices can range from

PDAs, Pocket PC’s, TV-set top-boxes, etc.

Both the J2ME MIDP 2.0 and Microsoft .NET

platforms allow for the development of rich

embedded applications, that provides many libraries

and functionality to developers. Both these platforms

allow for the successful utilization and access of web

services. However, both platforms do not allow for

the development of true mobile agents, where mobile

code is transported between two different mobile

execution environments, due to the resource

constraints of mobile devices (Barnes, D., 2003,

Petrea, L. L., 2005).

4.2. General Architecture Overview

The following component and architecture overview

describes the general overview and skeleton of the

MAGGIE architecture components. The MAGGIE

architecture is an adaptation of the A4 Agent model

(Leong, P., et al. 2006). As in the A4 model,

MAGGIE contains a broker agent (See Broker Agent

this section) that acts as the root of the entire

hierarchy (Leong, P., et al., 2006). In the A4 model,


ORGA2IZATIO2S 4

the agents responsible for controlling a sub-hierarchy

are known as co-ordinaters, and each agent that

wishes to join the hierarchy can attach and register

themselves to either the broker agent or to any co-

ordinator agent (Leong, P., et al., 2006). In MAGGIE

however, any agent that wishes to join the hierarchy

can only attach themselves at leaf co-ordinator nodes,

which are known as Sub-Broker Agents (See Sub-

Broker Agent in this section). Also in the A4 model

the direction of advertisements and service

discoveries can be both upwards or downwards

(Leon, P., et al., 2006), where as in MAGGIE this

direction is only allowed upwards, as discussed in

more detail through out Section 5.2. The following

agents and components are responsible for

constructing MAGGIE:

• User Agent: The User Agent resides on the

mobile device, and acts as intermediate between

the mobile device owner and MAGGIE. The

entire interface of MAGGIE is defined as a

collection of web services, allowing any platform

to invoke these services. Thus the User Agent can

communicate with the appropriate access point

via web services.

• Client Agent: The Client Agent resides on a

Broker Domain (see figure 2) that will be defined

in this section under Local Resource Agent. The

Client Agent resides on the nearest GPRS access

point, and acts as the sole intermediate between

the entire MAGGIE system and the User Agent

on the mobile device owner and acts as a

reflection of the User Agent. The Client Agent

only exists for as long as the mobile device owner

stays logged into MAGGIE. The Client Agent can

represent either a single user, or can be seen as a

member of one or more virtual organizations that

are to be found at one single Broker Domain (see

figure 1). Virtual organizations are formed on the

following ground:

1. The services provides by distinct Client

Agents.

2. If one or more distinct group of Client Agents

belong to one company, institution and

organizations.

3. If one or more Client Agents contain the same

utilization of economic models, to perform

negotiations with.

• Trade Server: As mentioned earlier, one way to

motivate mobile device users to contribute their

services and resources to the MAGGIE system, is

allowing some form of payment transactions that

cab be executed between producer and consumer

Figure 4 UML diagram depicting how the Client

Agent can be used to represent a single client and/or

a virtual organization.

of services and resources, via economic models

and negotiations. To implement this, each User

Agent contains one Trade Server component. The

Trade Server represents one economic model with

specific conditions, as retrieved from the User

Agent. All negotiations for services and resources

represented indirectly by the Client Agent and

User Agent are done via the Trade Server, as

shown in figure 3. The economic models

supported by MAGGIE are the supply-and-

demand economic model, posted price model and

bid-or-buy model.

• Broker Agent: There exists only one Broker

Agent through the entire MAGGIE system. The

Broker Agent acts as the access point to look-up

all contributed resources and services to the

MAGGIE system (see figure 2).

• Sub-Broker Agent: There exists multiple Sub-

Broker Agents through out MAGGIE and each

acts as the head of a sub-hierarchy of Client

Agents (see figure 2). Each Sub-Broker Agent

belongs to exactly one single Sub-Broker Agent

or to the only Broker Agent. Thus when a Client

Agent is created, it resides on the nearest Sub-

Broker Agent leaf. Once the Client Agent is

registered on the appropriate Sub-Broker Agent,

the Sub-Broker Agent registers the presence of

the Client Agent and all appropriate Client Agent

attributes with its appropriate Sub-Broker Agent

parent, and the details are then finally registered

with the only Broker Agent.

• Local Resource Agent: Each Sub-Broker Agent

and the Broker Agent contain one Local Resource

Agent. Each Local Resource Agent contains the

summarized information of all available resources

in the Sub-Broker domain. The Local Resource

Agent can serve as an indicator to show if the

Sub-Broker domain can handle any more

requests, thus eliminating the process of the


ORGA2IZATIO2S 5

invoking each Client Agent for negotiation

purposes. It is the collection of Sub-Broker Agent

Figure 5 Hierarchical structure and relationships of

the Broker Agent, Sub-Broker Agent, Client Agent

and User Agent, defining Broker Domains.

Broker Agent, Client Agents and Local Resource

Agent that defines the Broker Domain (Figure 2).

• MAGGIE Portal: The MAGGIE Portal acts as the

repository point of all registered mobile device

owners, mobile devices and all registered services

that are presented by MAGGIE. The MAGGIE

Portal can also act as the storage point of all

agents that have completed their executions, and

await the harvesting of their results by the Client

Agent.

• Trade -egotiator: The Trade Negotiator Agent is

initiated by the Client once the User Agent

requests the processing of data or the invocation

of services throughout MAGGIE. The Trade

Negotiator Agent is embedded with all

negotiation conditions and variables, as provided

by the implementation of the User Agent. The

Trade Negotiator Agent is indeed an instance of a

mobile agent, and can migrate from Broker

Domain to the next (see figure 3). As the Trade

Negotiator Agent travels from one Broker

Domain to the next it first consults the Local

Resource Agent to determine if possible

negotiations exist, the Trade Negotiator Agent

will negotiate with each Client Agent’s Trade

Server. The negotiations process is determined by

the type of economic model embedded in the

Trade Server and if a successful negotiation was

agreed upon between Trade Server and Trade

Negotiator, the Trade Negotiator Agent will store

the location of the Client Agent, and the

appropriate Trade Server can make the

appropriate reservations of services and resources.

Thus the Trade Negotiator Agent can execute

long after the disappearance of the Client Agent.

Once all conditions have been met by die Trade

Negotiator Agent, it can either return to the Client

Agent or migrate to the MAGGIE Portal. If the

Client Agent is alive, the Trade Negotiator Agent

can alert the Client Agent that in turn can alert the

User Agent that successful negotiations were

achieved, and allow the mobile device owner to

accept or decline the negotiations. If the Client

Agent no longer exists throughout MAGGIE, the

Trade Negotiator Agent can then store its own

state at the storage point situated at the MAGGIE

Portal, and can later be only retrieved by its

corresponding Client Agent for interpretation. The

Trade Negotiator Agent will periodically store its

results and progress at the MAGGIE Portal

storage point that can later be retrieved by the

Client Agent, once the mobile device owner logs

into MAGGIE.

Job Handler Agent: Once all appropriate

negotiations have executed and been obtained, the

Client Agent then initiates a Job Handler Agent.

The Job Handler Agent is responsible for

executing all appropriate job processes on the

collected Client Agents and User Agents, and

harvesting all appropriate results (see figure 4).

The Job Handler Agent alerts the appropriate

Client Agent once all results have been collected.

If the Job Handler Agent cannot alert the Client

Agent, it will migrate itself to the MAGGIE

Portal storage point. The appropriate Client Agent

can thus retrieve all completed jobs or results

from the MAGGIE Portal. The Job Handler Agent

can also act as a job indicator mechanism,

indicating to the appropriate party or mobile

device owner, the progress of the completion of

all submitted requests and tasks. These results are

stored at the MAGGIE Portal storage point that

can later be retrieved by the appropriate Client

Agent. Each Job Handler Agent remains in the

same Broker Domain that it was created within,

and too registers itself with appropriate Su-Broker

Agent, which in turn registers with its parent



6

Figure 6 UML based diagram depicting the roles of the Trade Negotiator Agent and Trade Server, enabling

negotiations in MAGGIE.

Sub-Broker Agent, until the Broker Agent is

reached. This will allow the Client Agent to

discover a Job Handler Agent via the look-up

services of the Broker Agent and Sub-Broker

Agents.

• Worker Agent: The Worker Agents are all

initiated and deployed by the Job Handler Agent

once all appropriate negotiations have been

accepted, and task data are submitted. The

Worker Agents act as mobile agents and migrate

from one user Agent to the next User Agent. Each

Worker Agent will first migrate to the Broker

Domain, where the Client Agent is situated,

representing the destination User Agent (see

figure 4). It is via the Client Agent that the

Worker Agent will dock through to the User

Agent and execute its appropriate tasks. If the

Client Agent is not present at the Broker Domain

that the Worker Agent finds itself in, it will

invoke the Sub-Broker Agent look-up services

and discover the location of the Client Agent,

migrate to the appropriate Broker Domain and

follow the same procedure of docking to the User

Agent. Once the Worker Agent has successfully

executed upon the User Agent, it will either report

back to the Job Handler Agent or migrate to the

next Client Agent for further processing of

submitted tasks. During the execution of Worker

Agents, Worker Agents periodically contact the

Job Handler Agent, or via the Client Agent of the

User Agent it is residing upon. Thus if the Job

Handler Agent does not receive a heart-beat

message from any deployed Worker Agents, it

will re-deploy the Worker Agent. If possible, if

the mobile device user owner is about to close the

User Agent application, all encapsulated Worker

Agents will migrate to the appropriate Client

Agent and migrate either to the next Client Agent

if any are available, or migrate back to the Job

Handler Agent and wait the return of the Client

Agent, by invoking the Sub-Broker Agent look-up

services periodically. The technique of heart-beat

messages are also used in Lopes, R.F ., et al.

(2006)

5. DETAILED ARCHITECTURE DESIGN

The following sections will describe more detailed

design issues as well as procedures that are

incorporated and utilized by MAGGIE.

5.1. Service implementation

Due to resource constraints of mobile devices, and

due to the constraints of both .NET CF and J2ME

MIDP2.0 as mentioned earlier, it is not possible to

implement true code mobility into the Worker Agent.

This brings into effect that no User Agent can accept

any Worker Agent and execute the embedded mobile

code. This hinders the goal to implement a generic

mobile computing architecture. MAGGIE however

tries to implement a generic as possible mobile

computing platform, by providing developers a

development platform, where the creation, display

and processing of services are implemented by the



7

Figure 7 Diagram depicting the role and migration patterns of the Worker Agent to different Broker Domains

and the User Agent via the Client Agent

developers. This platform is provided by providing

developers with an underlying collection of libraries,

thus only leaving to the developer to implement

services. The underlying base and libraries of

MAGGIE thus will handle all of the following

operations:

• The docking, handling and dispatching of Worker

Agents.

• The communication and authentication between

the User Agent and Client Agent.

• The display, utilization and handling of

negotiation results, setting of Trade Server

variables and other MAGGIE specific settings.

Thus every Worker Agent shall contain MAGGIE

specific information, such as its next migration point,

the price to be billed by the User Agent, the owner of

the Worker Agent, etc. However, the actual data that

is to be processed by the User Agent can be seen as

service specific, and it is this handling and

interpretation that is to be implemented by

developers (see figure 5).

Each service is then given a unique name and version

number that can be registered at the MAGGIE Portal,

and can then be implemented over several different

mobile devices, that can be downloaded by mobile

device owners. This approach allows developers to

rapidly and easily develop a wide array of services

that can be integrated seamlessly into MAGGIE.

5.2. Service registration, discovery and invocation.

As mentioned earlier, the MAGGIE architecture

components and agents utilize Sub-Broker Agent and

Broker Agent look-up services. Each Sub-Broker

Agent has exactly one Sub-Broker Agent parent, or

has the Broker Agent as a parent. Once a Client

Agent is created in a Broker Domain, the services

and attributes that the Client Agent contain, are

registered with that specific Sub-Broker Agent. Also

the data of the Client Agent is registered as a child

service with all other upper Sub-Broker Agents in the

hierarchy until registered at the Broker Agent. A

.similar approach is used for registering Job Handler

Agents.

The discoveries of registered services follow a very

similar approach as to the registration of services.

If a service is to be discovered, the look-up service of

a Sub-Broker Agent is invoked. The Sub-Broker

Agent first consults its own collection of registered

services and if no such service was located, the

parent Sub-Broker Agent’s look-up service is

invoked. The parent Sub-Broker Agent then consults

its own collection of registered services. If the

service is not found, the same procedure is followed

with the parent Sub-Broker Agent of that Sub-Broker

Agent. In the worst case scenario, the Broker Agent

will be consulted as to search a specific service. Once

the service has been located, the location of the

appropriate Sub-Broker Agent can be retrieved, and

can then be accessed. This approach has shown to be


ORGA2IZATIO2S 8

very efficient, especially if the depth of the

hierarchical structure is 10 or less (Yanxiang, H.,

2005).

To add to the efficiency of the discovery of services,

once a client Agent or Trade Negotiator initiates a

look-up service, it will first consult the virtual

organization, if applicable, that it finds itself part of.

This can bring to effect that the discovery of services

and negotiations procedures can be accelerated, by

first consulting and negotiating with other Client

Figure 8 The layered architecture of MAGGIE-

enabled applications allowing for custom-developed

MAGGIE services.

Agents in a virtual organization that have the same

interests or same collection of contributed services to

MAGGIE.

The structure of all Sub-Broker Agents and the

Broker Agent are pre-defined and can only be

changed by users that contain appropriate

administrations privileges.

Each Sub-Broker Agent and the Broker Agent’s

interfaces are defined by a standard web service

interface, and can thus be invoked from any platform

or MAGGIE component that supports web service

invocation.

5.3. Negotiation Details

As mentioned earlier, each Trade Server utilizes an

economic model to support the negotiation between a

service/resource producer and a service/resource

consumer/. This economic approach will always

strive to produce the best price for the consumer, and

to produce the most profit for the producer. The goal

of all economic models implemented into MAGGIE

all strive to reach price equilibrium. Price

equilibrium is where the price at which the quantity

that is demanded of goods or services are equal to the

quantities supplied. It is based only on this condition

that any economic market can reach its fullest

potential and be viewed as healthy and competitive.

One such model that has been implemented into

MAGGIE is based on the commodity market model,

also know as a flat or supply-and-demand driven

price model. In this model, a consumer is charged for

the amount of resources they are planning on

consuming for the completion of their results. The

following variables are used to implement the

commodity market model that can be changed by the

mobile device owner at any time to suite the needs of

the mobile device owner.

• Peak time price: The price that is charged for the

consumption of resources during peak time hours,

that can be seen as working hours. (For example 9

am to 6 pm on business days).

• Off-peak time price: The price that is charged for

the consumption of resources after peak time

price hours.

• Lunch time price: The price that is charged during

lunch time hours for the consumption of

resources.

• Discount: The discount that is to be given if the

specific producer of some service or resource is

overloaded.

• Raise price: The increase interval of the price, if

there exist a large demand for the services of

resources contributed by some mobile device

owner.

• Holiday price: The price at which the

consumption of resources are charged on days

that are defined as public holidays. These are days

such Christmas, New Years Eve, etc.

• Peak time hours: The hours that are defined by

the user as lunch time.

It must be remembered that the peak time hours and

lunch time hours are only applicable on business

days (from Mondays to Fridays).


ORGA2IZATIO2S 9

Thus it is clear to see that MAGGIE allows users to

reflect their appropriate requirements at any time

needed. Each price that is defined by the user is

defined per task.

When the user wishes to start searching for possible

negotiations in order to complete a task, the user can

configure negotiation variables and aid in the search

for negotiations. It is also expected from developers

wishing to implement a service to provide MAGGIE

with additional negotiation variables that aids in the

negotiation between producer and consumer. These

negotiation variables are summarized as follow:

• Price per job: This is the willingness of the

consumer to pay per job that is to be processed by

MAGGIE enabled nodes. This value can only be

set by the actual mobile device owner.

• Minimum CPU: The minimum CPU speed that is

required to process the data produced by the

mobile device owner (This is measured in MHz).

This value must be provided by the developers

and implements of the MAGGIE service.

• Minimum RAM: The minimum amount of free

RAM that is needed to store and process the data

produced by the mobile device owner (this is

measured in Mb). This value must be provided by

the developers and implementers of the MAGGIE

service.

• Size of Job: This is the actual size of the job that

is produced by the mobile device owner (This is

measured in Mb). This value must be provided by

the developers and implementers of the MAGGIE

service.

• Reliability: This value determines what level of

reliability the consumer wishes the producer of

resources and service to be. This value is

described in more detail at the end of section 5.3.

This value can only be set by the actual mobile

device owner.

• Relax -egotiations Factor: This value determines

how strict or relaxed a negotiation should be. This

value is seen as a percentage value, where any

value larger than 0% can be seen as relaxing the

negotiation process by x%. For example, if

consumer Y and producer X are engaged in

negotiations where consumer Y’s willing price to

pay is w, but the end negotiation price reached is

c more (thus w + c) and the relax negotiation

factor is r%, and w + c ≤ (w * r / 100), the

negotiation price will be accepted. This value can

only be set by the actual mobile device owner.

• Maximum allowed jobs pending: This value

determines what the maximum number of jobs is

allowed to be pending on any given MAGGIE

resource producer the consumer encounter for

negotiation processes. This can give mobile

device owners the chance to specify what they

define as too busy. If this value is -1, then the

number of pending jobs at the appropriate

MAGGIE producer does not play a factor. This

value can only be set by the mobile device owner.

As mentioned earlier, the mobile device owner can

specify what the reliability of the MAGGIE producer

should be. It is only logical that any consumer would

want to only use the most reliable sources to process

their requests and tasks, and because of this fact,

every producer would like to be labeled as excellent

as to attract more consumers. Thus the level of

reliability can not be set by the producer itself, but

instead is calculated by MAGGIE. The MAGGIE

Portal storage points stores the amount of tasks that

one producer has successfully completed (c), and

also the amount of jobs that each producer has

reserved for processing (r). Thus the reliability is

calculated as c / r * 100 and this percentage value is

then used to determine the actual reliability of the

producer:

• Extremely poor (0%-10%)

• Very poor (11%-20%)

• Poor (21% - 30%)

• Below moderate (31% - 40%)

• Moderate (41% - 50%)

• Above moderate (51% - 60%)

• Good (61% - 70%)

• Very Good (71% - 80%)

• Extremely Good (81% - 90%)

• Excellent (91% - 100%)

It is evident to see as to why economic based models

introduce many benefits to both consumer and

producer.

5.4. Security Mechanism

In order for any system to be widely accepted by its

users, the security of the appropriate system must be

of an acceptable level. MAGGIES’s functionality is

mostly based on the implementation of mobile agent

technology. Mobile agent technology holds many

security concerns, regarding both the mobile agent

and the mobile agent execution environment. The

following sections will discuss the security

implementations of each execution environment and

mobile agent.


ORGA2IZATIO2S 10

5.4.1 Execution Environment Security

The greatest security risk towards an execution

environment is a malicious mobile agent that might

harm the execution environment, or try to steal any

sensitive information residing in the execution

environment.

In order to protect the execution environment, which

in this case can be the Sub-Broker Agent or the

Broker Agent, each mobile agent will contain a path

history list. This is a technique where each mobile

agent records its migrations process over different

execution environments. Thus each mobile agent

utilized in MAGGIE shall contain a history of each

visited Sub-Broker Agent and Broker Agent. It is

then required upon arrival of the mobile agent, that

each Sub-Broker Agent or Broker Agent digitally

signs the path history list. In this manner, each

execution environment can first inspect the history of

each mobile agent, and determine its own level of

trust and execution privileges for each mobile agent.

This security technique is suggested in (Borselius,

N., 2002).

5.4.2 Mobile Agent Security

The greatest security risks towards mobile agents are

the modification or theft of sensitive information via

malicious hosts and external threats as each mobile

agent travels between execution environments.

Each migrating mobile agent contains only a small

fragment of information that doesn’t necessarily raise

the question of privacy, but rather the integrity of the

data. The following example can be catastrophic to

any mobile device owner utilizing MAGGIE.

Assume some user wishes to process a request, and

the request can be met by service provider X at a

price of y, which is determined by the Trade

Negotiator Agent as it travels from site to site. A

competitor Z can intercept this Trade Negotiation

Agent and modify the value of y greatly, causing X

to lose profits or customers, as these negotiations

might be cancelled by the mobile device owner.

To solve this problem, each MAGGIE mobile agent

will implement a technique known as sliding

encryption technique (Borselius, N., 2002). Each

mobile agent’s sensitive information or data is

encrypted sing asymmetric encryption algorithms via

the execution environment, the appropriate private

key must be supplied to the mobile agent for the

decryption of its sensitive data. Using sliding

encryption allows each mobile agent to securely

travel between each Broker Domain.

6. BENCMARKING

The following sections will compare MAGGIE to

already similar and existing grid computing models.

6.1. Mobile OGSI.NET

Mobile OGSI.NET supports the hosting of different

grid services that can be utilized on the mobile

device itself (Wasson, G., 2004). Each such grid

service contains the actual application logic of the

service that resides on the mobile device. Each

mobile device that utilized Mobile OGSI.NET

registers its available grid services, and can be

discovered and invoked by other Mobile OGSI.NET

users. This all is achieved by using web services

utilizing the .NET Compact Framework foundation.

MAGGIE too follows a similar approach as used in

Mobile OGSI.NET, by allowing each mobile device

to register the collection of MAGGIE services it can

offer to the other MAGGIE mobile device users. As

in MAGGIE, Mobile OGSI.NET parses all incoming

requests, and then relays the incoming requests to the

appropriate grid service that resides on the mobile

device owner, and returns the processed requests.

MAGGIE is unique in the sense that services can be

implemented in both J2ME MIDP 2.0 and .NET CF,

allowing J2ME MIDP 2.0 and .NET CF enabled

devices to utilize MAGGIE services, where as

Mobile OGSI.NET only allows .NET CF enabled

devices to participate in Mobile OGSI.NET.

6.2. Globus Infrastructure Tool-kit

The Globus system was designed to achieve an

integration of applications, middleware and network,

creating a collection of free resources (Foster, I.,

1997). To achieve this, Globus provides a low-level

toolkit for developing grid services. The low-level

services provided by Globus include such services

as:

• Authentication

• Security

• Communications

• Network Information

• Data access

The Globus toolkit can be efficiently used to develop

higher-level grid services, and even scheduler

mechanisms on each Globus infrastructure node. In a


ORGA2IZATIO2S 11

similar approach, MAGGIE allows any developer

wishing to utilize MAGGIE, to develop an

application or domain specific services as mentioned

in Section 5.1.1 Thus each application developer

wishing to implement a MAGGIE service that is to

be implemented over several mobile devices, only

has to concern themselves with the development of

providing the service specific data, and the

appropriate processing of it. All other MAGGIE

specific services and processing are handled

automatically by the underlying MAGGIE

architecture, libraries and foundation, as discussed in

more detail in Section 5.1.1. By following this

approach, MAGGIE can contain a wide and vast

array of different services and applications that can

be utilized by different mobile device users, similarly

to that of Globus.

MAGGIE provides a much simpler means of

implementing services and doesn’t burden the user

with issues such as data communication and access,

authentication and resource allocation. Such issues

are to be implemented by application developers in

Globus, where as application developers in MAGGIE

need not to concern themselves with such issues.

6.3. Nimrod/G

The Nimrod/G grid enabled resource management

and scheduling system is built by utilizing the Globus

toolkit services, and can also be extended in the same

sense as Globus. However, Nimrod/G scheduling

schemes are based on the concept of computational

economy (Buyya, R., et al. 2000).

Nimrod/G allows different developers to produced

and manage their own computational economy

schedulers, meeting the goals and requirements of

different organizations.

MAGGIE follows a similar approach in allowing

each mobile device owner to follow an economic

based model, receiving some form of payment for the

contribution of their services and resources.

Nimrod/G too follows a very similar approach in

negotiations, such as the willing price for processing

a task, price per resource, etc. However, MAGGIE

only utilizes three economic models as mentioned in

Section 4.2 under Trade Server, and doesn’t allow for

the implementation of developer specific economic

models, providing a much more uniform and easier

process of negotiations between resource producers

and resource consumers.

However, at this present time MAGGIE doesn’t

allow developers or mobile device owners to

implement their own scheduling components. This is

due to the fact that mobile device owners may in

generally not be interested in developing such

components, or that mobile devices may not yet be

powerful enough to host such components that

demands much processing power and network

communications.

7. FUTURE RESEARCH WORK

Future research work of MAGGIE would include not

to only allow mobile devices to utilize MAGGIE, but

also allow more powerful grid components such as

desktops, supercomputers, etc. to utilize the

MAGGIE infrastructure.

Secondly, future research work of MAGGIE would

allow for the development and implementation of

management scheduling components, truly

representing the requirements and goals of some

individual organizations or mobile device owners.

This would include research to allow such goal-

specific components to be uploaded to some server

(Similar to the Nimrod/G system, as discussed in

Section 6.3). At this moment, such components

would demand too much processing power and

network communications from a single mobile

device, and can thus quickly deplete the resources

and battery power of a mobile device. This would

defy the purpose of MAGGIE, as MAGGIE is to

share resources and services of geographically

distributed devices for the processing of distributed

applications, and not for negotiations between

consumer and producer.

8. CONCLUSION

MAGGIE incorporates several different factors to

realize a global mobile computing infrastructure,

MAGGIE harnesses the advantages and approaches

of agent and more particularly mobile agent

technology, to realize, manage and enhance the

structure and management of MAGGIE components.

Secondly MAGGIE aims towards the utilization of

mobile devices, which is not near the power of more

conventional grid components, such as desktops,

mainframes, etc. However, because of the gigantic

number of MAGGIE-enabled (J2ME MIDP 2.0 and

Microsoft’s .NET CF enabled devices) devices that

exist today, MAGGIE can provide an extremely large

infrastructure for the processing of grid services and

applications.


ORGA2IZATIO2S 12

Lastly, MAGGIE incorporates economic-based grid

computing theories, as to allow mobile device

owners to reflect their needs and requirements, both

for the processing and contribution of services. It is

because of this reflection of true requirements and

goals that aids in the satisfaction between virtual

organizations. Thus different entities or mobile

device owners can compete against one another to

attract as many consumers as possible, creating a true

and healthy economy market-based environment.

With all these components merged as on functional

system, MAGGIE provides a realistic, efficient and

flexible means to allow and motivate mobile device

users to contribute their mobile devices for mobile

computing causes. Secondly this will allow mobile

device users to execute and utilize applications that

were previously impossible to execute on mobile

devices.

REFERENCES

Barnes, D., (2003), “Fundamentals of Microsoft .NET

Compact Framework Development for the Microsoft

.NET Framework developer”. Microsoft Developer

Network Technical Articles.

Borselius, N., (2002), “Mobile Agent Security”;

Electronics & Communication Engineering Journal,

Volume 14, No 5, IEEE, London.

Buyya, R., Chapin, S., and DiNucci, D., (2000),.

“Architectural Models for Resource Management in

the Grid”; Proceedings of the first IEEE/ACM

International Workshop on Grid Computing

(GRID’00), pp. 18-35

Buuy, R., Abramson, D., and Giddy, J., “An Architecture

for a Resource Management and Scheduling System in

Global Computational Grid”; In Proceedings of the

HPC ASIA ’00, the 4th

International Conference on

High Performance Computing in Asia-Pacific Region,

IEEE Computer Society Press, Beijing.

Foster, I., and Kesselman, C., 1997, “A Metacomputing

Infrastructure Toolkit”; The International Journal of

Supercomputer Applications in high Performance

Computing.

Foster, I., Jennings, N. R., and Kesselman, C., (2004)

“Brain meets brawn. Why Grid and agents need each

other”; In Proceedings of the 3rd

International

Conference on Autonomous Agents and Multi-Agent

Systems, new Your.

Kim, P. J., and Noh, Y. J., (2003), “Mobile Agent System

Architecture for supporting Mobile Market Application

Service in Mobile Computing Environment”; 2003

Proceedings of the IEEE International Conference on

Geometric Modeling and Graphics.

Leong, P., Miao, L., and Lee, B., (2006), “Agent

orientated Software Engineering for Grid Computing”;

The Proceedings of the Sixth IEEE International

Symposium on Cluster Computing and the Grid

Workshops.

Lopes, R., F., and Silva, F. J., (2006), “Fault Tolerance in

a Mobile Agent Based Computational Grid”; The

Proceedings of the Sixth IEEE International

Symposium on Cluster Computing and the Grid

Workshops.

Petrea, L. L., (2005), “Mobile code platform for ad hoc

networks”. IEEE InfoCom 2005, Student Workshop,

Miami, Florida, March 2005.

Phan, T., huan. L., and Dulan, C., (2002) “Challenge:

Integrating Mobile Wireless Devices into the

Computational Grid”; In Proceedings of the 8th

ACM

International Conference on Mobile Computing and

Networking (MobiCom’02), Atlanta.

Pour, G., and Laad, N., (2006) “Enhancing the Horizon of

Mobile Computing with mobile agent components.”;

Proceedings of the 5th

IEEE/ACIS International

Conference on Computer and Iformation Sience and 1st

IEEE/ACIST International Workshop on Components

based Software engineering, Software architecture and

re-use.

Satyanarayan, M., (1993), “Moile Computing”; Computer

magazine, pp. 81-81.

Satyanarayan, M., (1996), “Fundamental challenges in

mobile computing”; 14th

and 15th

ACM symposium on

principles of Distributed computing, Philadelphia.

Wasson, G., Beekwilder, N.,m Morgan, M., and Humprey,

M., (2004), “OGSI.NT: OGSI-compliance on the .NET

Framework”; Proceedings of the 4th

IEEE/ACM

International Symposium on Cluster Computing and

the Grid (ccGrid ’04), Chicago.

Yanxiang, H., Wen, W., Jin, H., and Liu, H., (2005)

“Agent-based Mobile Service Discovery in Grid

Computing”; The 5th

International Conference on

Computer and Information Technology, Washington.

MOBILE AGENTS FOR GLOBAL MOBILE DEVICE GRID ...

Documents

Transcript of MOBILE AGENTS FOR GLOBAL MOBILE DEVICE GRID ...