Kerr Daniel Thesis PDF

Space Computing with Group Key Agreement
By Daniel Robert Kerr, B.S.
A Thesis in Computer Science
Submitted to the Graduate Faculty of Texas Tech University in Partial Fulfillment of the Requirements for the Degree of
MASTER OF SCIENCES
Approved
Michael Sobolewski
Chairperson of the Committee
Phillip Smith
Yuan-Lin Zhang
Fred Hartmeister
Dean of the Graduate School
May, 2008
Copyright 2007 Daniel Robert Kerr
Texas Tech University, Daniel Robert Kerr, May 2008
Acknowledgements
I would like to thank my advisor Dr. Michael Sobolewski. His efforts and knowledge have helped me maintain a clear perspective on my goals, and accomplishments. I would also like to thank Dr. Phillip Smith, Dr. Yuan-Lin Zhang for serving on my committee, and supporting my work.
I would also like to thank my friends and family for allowing me to spend so much time away from them. As well, I would like to thank my fiance Amy Petrovich for being patient and always supporting.
ii
Table of Contents
Acknowledgements.............................................................................................................. ii Abstract ............................................................................................................................... vi List of Tables ...................................................................................................................... vii List of Figures .................................................................................................................... viii List of Diagrams................................................................................................................... ix List of Universal Modeling Language Diagrams .................................................................. xi List of Abbreviations .......................................................................................................... xii 1. Introduction .................................................................................................................... 1 Problem Statement ......................................................................................................... 2 Thesis Outline .................................................................................................................. 2 2. Background and Literature Review................................................................................. 4 Distributed Computing .................................................................................................... 4 Space Computing ......................................................................................................... 8 Encryption ..................................................................................................................... 12 Symmetric Encryption ............................................................................................... 12 Asymmetric Encryption ............................................................................................. 15 Key Agreement .......................................................................................................... 17 Packages .................................................................................................................... 19 Federated Intelligent Product Environment (FIPER) ..................................................... 20 Service Protocol Oriented Architecture (SPOA) ............................................................ 22 Service Object Oriented Architecture (SOOA) .............................................................. 22 Jini Network Technology ............................................................................................... 23 Service Oriented Computing Environment (SORCER) ................................................... 24 SGrid .......................................................................................................................... 26 3. Requirements Analysis .................................................................................................. 29 Space Environment ....................................................................................................... 29 iii
Dual Space Environment ........................................................................................... 31 Single Space Environment ......................................................................................... 31 Exertion Envelope ......................................................................................................... 32 Encryption ..................................................................................................................... 34 Symmetric Encryption ............................................................................................... 34 Asymmetric Encryption ............................................................................................. 35 4. Architecture and Design ............................................................................................... 36 Four Blocker .................................................................................................................. 36 Problem ..................................................................................................................... 36 Conclusion ................................................................................................................. 36 Objective .................................................................................................................... 36 Approach ................................................................................................................... 36 Schedule .................................................................................................................... 36 Benefits ...................................................................................................................... 37 Use Case Diagrams ........................................................................................................ 38 Component.................................................................................................................... 64 Entities ....................................................................................................................... 67 Existing Components ................................................................................................. 68 LOKI Components ...................................................................................................... 68 Component Diagrams ................................................................................................ 71 Interaction ..................................................................................................................... 80 Package.......................................................................................................................... 86 Class ............................................................................................................................... 88 Deployment ................................................................................................................... 98 Technical Architecture .................................................................................................. 99 Architectural Attributes .............................................................................................. 101 Availability ............................................................................................................... 101 Modifiability............................................................................................................. 101 iv
Performance ............................................................................................................ 101 Security .................................................................................................................... 102 Testability ................................................................................................................ 102 Usability ................................................................................................................... 103 Encryption Multi Diffie Hellman ............................................................................... 104 Data Store.................................................................................................................... 114 User Interfaces ............................................................................................................ 121 5. Validation .................................................................................................................... 129 Test Case ..................................................................................................................... 129 Verification, Validation and Accreditation .................................................................. 139 6. Conclusion ................................................................................................................... 142 7. Future Work ................................................................................................................ 144 Alternate Scalable Key Agreements ............................................................................ 144 Alternate Group Request Analysis .............................................................................. 144 Multiple Space Model ................................................................................................. 145 Replicated Group Components ................................................................................... 145 Bibliography .................................................................................................................... 146 Appendix A: Loki System Interfaces................................................................................ 150 Appendix B: Loki API Specification.................................................................................. 167
Abstract
Space computing environments, being inherently public, have an increasing need to be secured. One way of successfully implementing security in a space computing environment is through the use of groups. Although groups would successfully secure the environment, there are several complications in group creation as well as the method for encryption.
Location independent group Key Interactive management (LOKI) provides an efficient, minimal framework for implementing groups in a space computing environment, thus providing ironclad security, mobility, scalability, as well as group administration. In order to show how Loki will do this, the following questions will be answered in this thesis:
Can a secure generic method for group creation be created for all space
computing environments?
Can all space computing functionality be maintained with the implementation of

groups?
Is there an asymmetric encryption method that is scalable to larger numbers of

contributing key pairs?
vi
List of Tables
1: Linda Functions ............................................................................................................... 9 2: Javaspace Functions...................................................................................................... 10 3: Symmetric Key Algorithms ............................................................................................ 14 4: Use Case Template 1 - Create Group ............................................................................ 40 5: Use Case Template 2 - Leave Group ............................................................................. 42 6: Use Case Template 3 - Join Group ................................................................................ 44 7: Use Case Template 4 - Get Group User Agent.............................................................. 47 8: Use Case Template 5 - Pickup Exertion ........................................................................ 49 9: Use Case Template 6 - Drop Exertion ........................................................................... 51 10: Use Case Template 7 - Execute Exertion .................................................................... 53 11: Use Case Template 8 - Get Admin User Agent ........................................................... 56 12: Use Case Template 9 - Delete Worker ........................................................................ 58 13: Use Case Template 10 - Delete Exertion .................................................................... 60 14: Use Case Template 11 - Delete Group ........................................................................ 62 15: Client Mode Encryption Timings ............................................................................... 104 16: Server Mode Encryption Timings.............................................................................. 105 17: Multi Diffie Hellman Group Size Timings .................................................................. 106
vii
List of Figures
1: NASA Cluster ................................................................................................................... 6 2: Grid Computing ............................................................................................................... 6 3: Peer to Peer Computing.................................................................................................. 7 4: Pipe Cryptography ........................................................................................................ 89 5: Multi Diffie Hellman Client Mode Time Curve............................................................ 106 6: Multi Diffie Hellman Server Mode Time Curve........................................................... 107 7: Multi Diffie Hellman Compound Key Creation Algorithm .......................................... 109 8: SGrid Execution Activity .............................................................................................. 130 9: Loki SGrid Execution Activity ...................................................................................... 132 10: Sargent's Circle.......................................................................................................... 140
viii
List of Diagrams
1: Javaspace Functions...................................................................................................... 11 2: Symmetric Encryption v0.1 ........................................................................................... 13 3: Asymmetric Encryption v0.1 ......................................................................................... 16 4: Diffie-Hellman Key Exchange ........................................................................................ 18 5: FIPER Organizational Architecture ................................................................................ 21 6: Service Object-Oriented Architecture .......................................................................... 23 7: Service Oriented Architecture ...................................................................................... 25 8: SORCER Technical Architecture .................................................................................... 26 9: SGrid Component.......................................................................................................... 27 10: SGrid Technical Architecture ...................................................................................... 28 11: Dual Space Environment ............................................................................................. 31 12: Single Space Environment .......................................................................................... 31 13: Exertion Envelope v0.1 ............................................................................................... 33 14: Object to Exertion Envelope v0.1 ............................................................................... 34 15: LOKI Technical Architecture ...................................................................................... 100 16: Complementary Compound Key Protocol ................................................................ 112 17: Shared Key Generation Protocol .............................................................................. 113 18: LOKI Group Data Store v0.1 ...................................................................................... 118 19: LOKI Group Data Store v0.2 ...................................................................................... 120 20: Loki Group User Agent Group Display ...................................................................... 122 21: Loki Group User Agent Take Display ......................................................................... 123 22: Loki Group User Agent Write Display ....................................................................... 124 23: Loki Admin User Agent Main Display........................................................................ 125 24: Loki Admin User Agent Group Display ...................................................................... 126 25: Loki Admin User Agent Member Display .................................................................. 127 26: Loki Admin User Agent Exertion Display .................................................................. 128 ix
27: SGrid User Agent General Display ............................................................................ 134 28: SGrid User Agent Include Display ............................................................................. 135 29: SGrid User Agent Execution Display ......................................................................... 136 30: SGrid User Agent Context Display............................................................................. 137 31: SGrid User Agent Results Display.............................................................................. 138
List of Universal Modeling Language Diagrams

1: Four Blocker .................................................................................................................. 37 2: uc LOKI .......................................................................................................................... 38 3: uc LOKI Group Creation ................................................................................................ 39 4: uc LOKI Execution.......................................................................................................... 46 5: uc LOKI Administration ................................................................................................. 55 6: cmp LOKI ....................................................................................................................... 64 7: cmp LOKI Group Creation ............................................................................................. 71 8: cmp LOKI Administration .............................................................................................. 73 9: cmp LOKI Execution ...................................................................................................... 77 10: sd LOKI Group Creation............................................................................................... 80 11: sd LOKI Administration ............................................................................................... 82 12: sd LOKI Execution........................................................................................................ 84 13: pkg LOKI ...................................................................................................................... 86 14: pkg sorcer.core.loki.crypt ........................................................................................... 88 15: pkg sorcer.core.loki.db ............................................................................................... 91 16: pkg sorcer.core.loki.group .......................................................................................... 92 17: pkg sorcer.core.loki.key .............................................................................................. 94 18: pkg sorcer.core.loki.member ...................................................................................... 95 19: pkg sorcer.loki.admin.ui.............................................................................................. 96 20: pkg sorcer.loki.group.ui .............................................................................................. 97 21: deployment LOKI......................................................................................................... 98 22: act LOKI ..................................................................................................................... 110
xi
List of Abbreviations
API Application Programming Interface FIPER Federated Intelligent Product Environment JCE Java Cryptography Extension LOKI - Location Independent Group Key Interactive Management P2P Peer to Peer SGrid SORCER Grid SOA Service Oriented Architecture SOOA Service Object Oriented Architecture SORCER Service Oriented Computing Environment SPOAP - Service Protocol Oriented Architecture
xii
Chapter 1 Introduction
Security in networking has been a serious issue since the dawn of networked systems. With the increasing trust in computers for the use of storing sensitive data (account numbers, social security numbers, criminal records, health history, etc) security has drastically increased in order to coordinate with the importance of the information being exchanged. Along with the growth in computer networking is the growth in distributed computing. Distributed computing presents many challenges to the world of computer science.
A rather new concept in distributed computing is the concept of space computing. Space computing helps to solve several of the significant problems with distributed computing, but still leaves room for improvement. The space computing environment starts by being completely public so that all services can access objects in the publicly shared space. The space broker is also oblivious to who is a member of the space environment.
The question at hand is whether or not a minimal solution to public space encryption that implements group creation and maintenance services can be implemented in a
space computing environment. This will be done by developing a methodology and framework for all space computing environments, and then proven by coding the methodology in a particular space environment. The test case will be coded in the SORCER (Service Oriented Computing Environment) developed by Doctor Michael Sobolewski at Texas Tech University.
The Loki framework will successfully introduce group management, and exertion level encryption in an ad hoc public space computing environment.
Problem Statement
In space computing, all items in the space are inherently public, all members are ad hoc, and the service broker does not explicitly know group members. Thus, a secure communication that can be initiated by a space service broker with management of ad hoc group of service is needed.
Thesis Outline
This thesis is divided into seven chapters, each with its own intent. Chapter one gives a basic introduction to the problem the thesis is trying to solve, as well as an outline of the thesis. Chapter two provides background information and literature on the topics discussed throughout this paper. Chapter three discusses the requirements necessary to implement groups in a generic space computing environment. Chapter four gives the design and modeling of the Loki framework. Chapter five discusses the means for 2
validation, and the test case. Chapter six describes the conclusions reached through the research. Lastly chapter seven discusses future work in the implementation of groups in a generic space computing environment.
Chapter 2 Background and Literature Review Distributed Computing

Distributed computing is an area in computer science that is not only increasing in popularity but also in importance. Distributed computing is the process of dividing a task into individually computable smaller tasks and deploying them or distributing them to multiple systems, thus creating one large system. Tanenbaum defines a distributed system as a collection of independent computers that appear to the users of the system as a single computer (Tanenbaum and Van Steen 2002). The main difference between a distributed system and a series of networked computers is that a distributed system tries to hide the fact that it is a composition of individual computing units (Nadiminti, Dias de Assuncao and Buyya n.d.). Although this is the case, the process of connecting computers through networking in order to establish collaborative computation is a job that is rather complex, but increasingly important. The following paragraph from Antony Davies succinctly describes the development of distributed systems and why they are emerging as much as they are in terms of computer science theory and modern economics.
Over the past 30 years, there has been a decentralization occurring in the production of computational power. Large, stand-alone supercomputers have been overtaken by cluster computers networks of personal computers that are linked together to provide more power than traditional supercomputers at a fraction of the cost. The next step in 4
the evolution of cluster computers has been the advent of Internet distributed computing an industry in which a computational intermediary purchases idle processing power from individual personal computer owners (via Internet connection), bundles the power, and resells the power as high-performance computation.6 This industry has emerged due to a confluence of events: (1) following Moores Law, the computational power of personal computers is doubling (on average) every 18 months; (2) digital communications speed is doubling every 12 months;7 and (3) over time, the performance gap between high-performance computers (HPC) and personal computers (PC) has closed due to dramatic improvements in integrated circuit technology.8 The combination of these events creates an environment in which hardware has become so inexpensive that personal computer owners can afford to purchase levels of computational power and bandwidth that satisfy their peak demands. Because computation and bandwidth demand is extremely peaky, as PC owners purchase hardware to satisfy peak demand, the amount of idle computational power and bandwidth increases dramatically. (Davies 2004)
Some of these distributed systems include but are not limited to clusters, grids, peer to peer networks, and distributed storage systems (Nadiminti, Dias de Assuncao and Buyya n.d.). Several of these are shown in the following figures. Clusters are a form of connecting sub systems, whether they are personal computers, servers, supercomputers, etc, together via a network interface in order for them to act as a single system (Nadiminti, Dias de Assuncao and Buyya n.d.). Grids are much like clusters in that they are a connection of subsystems except that grids balance performance with task load, in order to compute the given process in the fasted amount of time. Peer to peer distribution has been used in media sharing, research, and is the process of linking terminals directly to each other via the network without central management.
Figure 1: NASA Cluster (Computational Science & Engineering Research Institute n.d.)
Figure 2: : Grid Computing (Yao 2006) 6
Figure 3: : Peer to Peer Computing (Peer-to-Peer Peer (P2P) Computing 2006)
Distributed computing has been shown to be a cost effective solution that actually saves money in most cases when compared to the alternative of purchasing new systems of equivalent computing power. Distributed computing also allows for the reuse of systems, s, which allows less to be wasted. In addition to the fact that distributed systems are both cost effective and conserve resources, they are scalable and also provide inherent redundancy (Nadiminti, Dias de Assuncao and Buyya n.d.) n.d.). Regardless of these benefits there are still pitfalls to be aware of in distributed computing. These would be based Peter Deutschs eight fallacies of computer networking. They are as follows:
1. The network is reliable. 2. Latency is zero. 3. Bandwidth is infinite. 4. The network is secure. 5. Topology doesn't change. 6. There is one administrator. 7. Transport cost is zero. 8. The network is homogeneous. (Rotem-Gal_Oz n.d.)
Several implementations of distributed systems attempt to resolve some if not all of these issues. CORBA and DCOM attempt to resolve these by implementing a software layer to moderate the use of different platforms and languages (Nadiminti, Dias de Assuncao and Buyya n.d.).
Space Computing
Space computing is a paradigm for the development of parallel and distributed computing, which originated from the language Linda. Linda was the first language to introduce a logically global associative memory structure known as a tuplespace. Multiple client-like services access the global tuplespace for the mutual exchange of tuples, Lindas object container. In order to do this, Linda requires that both the tuple and the tuplespace be public. This allows for global access but inherently causes security vulnerabilities. In Linda specifically, there are four main functions used for the exchange of objects with the space. They are as follows: 8
Table 1: Linda Functions out outputs a tuple from a process into the tuple space in removes a tuple from the tuple space and returns it to a process, blocking if a suitable tuple cannot be found rd returns a copy of a tuple from the tuple space to a process, blocking if a suitable tuple cannot be found (Wells n.d.)
The use of these four functions for tuple object manipulation eliminated several inherent problems with distributed computing. By client services requesting tuple objects when they are free to do so, the problem of load balancing is reduced out. Slower services may request less tuples per time period, but there performance will not impact or hinder the performances of faster services, who may request more tuples per time period. As well, Linda provides mutual exclusion. All client services first remove a tuple from the public domain tuplespace before making any modifications to it. This only allows for one object to access the data at a time, thus preventing invalid data without the use of semaphores, mutexes, or any other form of data blocking. JavaSpaces, being based on tuplespaces from LINDA, adopt the same functionality with different nomenclature. The idea of a tuplespace is known as an object space, a tuple is known as an object, and the functions specified above are as follows:
Table 2: Javaspace Functions write outputs an object into the object space read returns a copy of an object from the object space to a process, and blocks if desired object cannot be found take removes an object from the object space and returns it to the requesting process, and blocks if desired object cannot be found (Arnold, Freeman and Hupfer 1999)
10
Diagram 1: : Javaspace Functions (Arnold, Freeman and Hupfer 1999)
Other adaptations use the same core functions, with slightly different nomenclature. All space environments though, do maintain the core framework and benefits that Linda originated. These implementations ementations are Linda, Rinda, Tuple Spaces, TSpaces, JavaSpaces and these have been executed in C, Prolog, Smalltalk, Ruby, Python, ython, and Java. Space computing is interesting because not only does it have mutual exclusion and load balancing, but with the inc increasing reasing rate at which information can be passed, it is drastically growing in popularity. It is proving to be a beneficial low cost distributed computing solution.
11
Encryption
Encryption is the process of taking a designated segment of data, and mutating it in a standard way so the data is no longer logical. This is usually done with a standard method that may or may not use a key to do so. In modern day cryptography there are many different methods of encryption but the two most researched for the Loki platform are symmetric and asymmetric, two of the largest families of cryptography.
Symmetric Encryption
Symmetric encryption is simply the use of a single shared key for the encryption of mutually shared data. The major benefits of symmetric encryption are that it takes a relatively small key to ensure a high level of security, that both encryption and decryption are fast processes, and lastly there are many well established symmetric encryption methods native to java, c, and many other languages making development simpler. Although powerful and fast, the use of symmetric encryption creates a problem when it comes to the distribution of the shared key. Even though the encryption is secure even with a rather small key, it truly creates a problem on how to distribute the key so that the key is not accidentally leaked out.
12
Service A
Encryptor
Shared Key
Encrypted Data
Service B
Decryptor
Diagram 2: Symmetric Encryption v0.1
It is for this reason that symmetric encryption is often mixed with other forms of cryptography. A common practice is to use asymmetric encryption to encrypt the symmetric shared key. This process will be explained in greater detail later in this section. The following table shows a list of symmetric key encryption algorithms, along with their creator, and key size.
13
Table 3: Symmetric Key Algorithms Cipher Author, Year DES - Data IBM, 1970, in Encryption Standard 1977 as FIPS 46-2 standard TripleDES or IBM, 1999 as FIPS DESede 46-3 standard RC4 - Rivests Code 4 RC5 - Rivests Code 5 RC6 Ron Rivest, 1987 Key length DES 56 bits, 64bit block Comments Originally known as Lucifer. Too weak for good security 168 bits (112 DESede is three rounds effective) of DES (encryption, decryption, encryption) 1-2048 bits, A stream cipher used in typically either 40 SSL implementations or 128 bits Up to 2040 bits, Improved RC4 typically 128 or 256 bits Up to 2040 bits, A block cipher based on typically 128 or RC5 designed to meet 256 bits the requirements of the AES 128 bits, 64-bit A block cipher, patent block protection, slow
Ron Rivest, 1994
Rivest, Sidney, and Yin, 1996
IDEA -International Data Encryption Algorithm or IPES Improved Proposed Encryption Standard Blowfish
Xuejia Lai and James L. Massey, 1991
Bruce Schneier, 1993 Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, Niels Ferguson, 1998 Joan Daemen and Vincent Rijman, 2000
32 bits to 448 bits, 64-bit block Up to 256 bits, 128-bit block, typically 128, 192, or 256bit key 128, 192, and 256 bits, blocks with a length of 128, 192 or 256 bits.
Twofish
A block cipher, much faster than DES and IDEA A block cipher by Counterpane Labs. It was one of the five AES finalists
AES (Rijndael)
AES mandates a block size 128 bits and a choice of key size: 128, 192 and 256.
(Sobolewski, Secret Key Cryptography 2007)
14
In symmetric key encryption the level of security is directly related to the size of the key, so it is easy to see that algorithms like AES, Blowfish, and RC6 are more secure than say DES.
Asymmetric Encryption
Asymmetric Encryption is a more complex level encryption than that of symmetric encryption, but complexity comes with its benefits. In asymmetric encryption each party in the information exchange has a public private key pair. The public key is readily accessible to any other party who wants access to it and the private key is stored locally. The main difference between asymmetric and symmetric is that the key used for encryption and decryption is a shared key that is generated from the accessing members private key and the public keys from the other members in the transaction. This allows us to never actually pass the encryption/decryption key. We only pass components of the recipe that individually do not reveal anything. The major downfalls to using asymmetric encryption over symmetric encryption are that of computation complexity and key size. Not only do the computations take longer time, but the asymmetric keys are typically ten times larger than there equally secure symmetric encryption counterpart.
15

Locally Calculated Shared Key
Service A
Private Key As Public Key Bs Public Key
Encryptor
Encrypted Data
Locally Calculated Shared Key
Service B
Private Key
Decryptor
Diagram 3: Asymmetric Encryption v0.1
McEliece Public Key Encryption McEliece Encryption is based on the fact that solving arbitrary linear code is of NP-hard. The transform of the solving code serves as the public key whereas the linear code itself solves as the private key (Menezes, Oorschot and Vanstone 1996). The McEliece Encryption is known for being the first public key encryption to use true randomization for cryptography. Although very efficient, the McEliece Encryption public keys are very large and thus have not been given much attention. The following shows the algorithm for encryption and decryption using McEliece Encryption.
16
McEliece Public-Key Encryption Algorithm Summary: B encrypts a message m for A, which A decrypts. Encryption: B should do the following: 1) Obtain As authentic public key ( b G; t). 2) Represent the message as a binary string m of length k. 3) Choose a random binary error vector z of length n having at most t 1s. 4) Compute the binary vector c = mbG + z. 5) Send the ciphertext c to A. Decryption: To recover plaintext m from c, A should do the following: 1) Compute bc = cP1, where P1 is the inverse of the matrix P. 2) Use the decoding algorithm for the code generated by G to decode bc to bm. 3) Compute m = bmS1. Proof: Since bc = cP1 = (mbG + z)P1 = (mSGP + z)P1 = (mS)G + zP1; and zP1 is a vector with at most t 1s, the decoding algorithm for the code generated by G corrects bc to bm = mS. Finally, bmS1 = m, and, hence, decryption works. (Menezes, Oorschot and Vanstone 1996)
Key Agreement
Key agreements are a method of cryptography in which parties agree for the method in which they will share a key. Each member of a key agreement should impact the key, and any outside member to the agreement should not be able to logic, or calculate the 17
key. As well Key Agreements should not require any previously shared information between the parties in the agreement. Diffie Hellman Key Agreement Diffie Hellman is a specific implementation of asymmetric encryption that is based on prime numbers and the modulus function. Diffie Hellman in its truest for is meant to encrypt the information between two parties. The following graphic shows the communication between Alice and Bob.
Diagram 4: Diffie-Hellman Hellman Key Exchange (Diffie-Hellman Hellman Key Exchange n.d.)
As you can see in the graphic the encryption is based on the idea of function equality. Alices private key is a and her public key is ga, whereas bobs bs private key is b and his public key is gb. The exchange can happen because: 18
(g mod p) (mod p) = (gb mod p)a (mod p) It is this fact that allows the encryption to occur without passing the shared key. Expansions of Diffie Hellman attempt to add more than two parties to the key creation. This is completed by expanding on the original equation, replacing the private key with the newly created shared key from the two party key creation. This is increasingly more complex than that of the two party Diffie Hellman key creation. The three party key creation is shown below. (gab mod p)c (mod p) = (gbc mod p)a (mod p) = (gca mod p)b (mod p) gab = (ga mod p)b (mod p) = (gb mod p)a (mod p) gbc = (gb mod p)c (mod p) = (gc mod p)b (mod p) gca = (gc mod p)a (mod p) = (ga mod p)c (mod p) The complexity of adding more parties to the agreement is linear in nature. Even though this is the case, there is no standard method for asymmetric Diffie Hellman based encryption beyond two parties.
Packages
Java Cryptography Extension The Java Cryptography Extension adds security functionality to the core java language. The API includes implementations of encryption methods, decryption methods, password based encryption, ciphers, key agreements, and message authentication code. Of these, we will be most interested in the key agreements, encryption, and decryption 19
policies, including ElGamal, Diffie Hellman, Elliptic Curve Diffie Hellman, DES, RSA, and TripleDES. Bouncy Castle Bouncy Castle is a security package much like the JCE but with a larger set of security and cryptographic services. Bouncy Castle provides both a java and a C# package which supply the same services. Much like the Java Cryptography Extension we are most interested in key agreements, encryption and decryption services, which include ElGamal, Diffie Hellman, Elliptic Curve Diffie Hellman, DES, RSA, and TripleDES. In comparison to the JCE, Bouncy Castle has the same functionality but is a little slower in most implementations.
Federated Intelligent Product Environment (FIPER)

FIPER describes an environment in which everything is located on a network, and everything on the network is viewed as a service. In this environment all inter service activity utilizes a special object known as an exertion interface, and all objects that execute exertions are known as servicers. A compound group of exertions and information can be stored in a service context. A job in FIPER can then be broken down into a federation of services where federation members are linked to processes, which are in turn linked to tasks and contexts (Sobolewski, SORCER Publications 2002).
20
Diagram 5: : FIPER Organizational Architecture (Sobolewski, SORCER Publications 2002)
The organization chart of the FIPER environment shows how FIPER is scalable in nature. It uses network technologies like Jini and Rio, which will be described in greater detail, in order to manage and launch a scalable number of services. The other components in FIPER are equally as scalable and each ma maintains intains focus on their specific task. The combination of these components helps FIPER to maintain service centricity, network centricity, and web centricity. FIPER is also neutral to service location, protocol and implementation (Sobolewski, SORCER Publications 2002) 2002).
21
Service Protocol Oriented Architecture (SPOA)

In SPOA providers and requestors where a communication protocol between the two objects is fixed and known beforehand. This protocol is initiated as a generic protocol, large enough to handle any network communication, which in some cases can lead to inefficiency. A requester in SPOA can use the established protocol as well as a service description, usually the service name, to obtain a proxy for binding to the provider. Typically the requestor and provider need to know the location of the service registry, either by URL or IP address. (Sobolewski, SORCER Publications 2007)
Service Object Oriented Architecture (SOOA)

SOOA adopt the provider, requestor, and proxy network objects from SPOA with several key differences. The proxy implements the same interfaces as the provider and remains registered with the registry awaiting a requestor. Since the requestor receives the active surrogate object from the service registry, the bind operation is not needed. The protocol neutral SOOA environment requires lookup services as well as standardized interfaces do to the dynamic nature of the architecture. Providers in SOOA can really be viewed as separate network objects that find each other through a service registry, and communicate through message passing. (Sobolewski, SORCER Publications 2007)
22
Diagram 6: : Service Object Object-Oriented Architecture (Sobolewski, SORCER Publications 2007)
Jini Network Technology

Jini is a Java based support technology for the construction of secure, distributed systems consisting nsisting of federations of well well-behaved network services and clients. (Intro to Jini 2006). . Jini is primarily designed for the building of service oriented architectures providing support for service creation, lookup services, discovery discovery, , leasing, code mobility, etc. . These concepts are implemented in the Jini Technology Starter Kit. (Jini Technology Starter Kit v2.0.1 2004) 23
Service Oriented Computing Environment (SORCER)

SORCER is developed on top of FIPER and includes design features from both SOOA and SPOA. SORCER uses dynamic discovery protocols to locate available registries (lookup services) as defined in the Jini architecture. Neither the requestor who is looking up a proxy by its interface nor the provider registering a proxy needs to know specific locations, (Sobolewski, SORCER Publications 2007). The combination of SOOA and SPOA in the SORCER environment leads to SOA, or Service Oriented Architecture. The SOA process of discovery is shown in the following diagram where the service requestor uses find discovery to get the published proxy of the desired service provider. It is passed back to the service requestor where a bind and execute is then performed by the service requestor on the service provider.
24
Diagram 7: : Service Oriented Architecture (Sobolewski, SORCER Publications 2007)
SORCER implements exertion based programming in order to handle the metasystemic distribution in the network. SORCE SORCER R does all this by adopting the Jini semantics of discover, leasing, joining, and etc to mutate Jinis focus of service management to the main focus of SORCER being exertion oriented programming and exertion execution environment. (Sobolewski, SORCER Publications 2007)
25
Diagram 8: SORCER Technical Architecture (Sobolewski, SORCER Publications 2002)
SGrid
The SORCER Grid or SGrid is a federated service metacomputing grid environment. The SGrid uses a combination of task exertions, job exertions, and service exertions, that when combined with dynamically bound service providers needed, form an exertion federation. This differs from the object oriented paradigm of the exertion space in several ways. In the object oriented paradigm the object space is the program and in SGrid the object space is the execution environment, hosted by a network of computers (Sobolewski, SORCER Publications 2007). The environment is described in the following passage, The overlay network of service providers is called the service provider grid and an exertion federation is called a virtual metacomputer. The metainstruction set of the metacomputer consists of all operations offered by all service providers in the grid. 26
Thus, a service-oriented program is composed of metainstructions with its own serviceoriented control strategy and service context representing the metaprogram parameters. (Sobolewski, SORCER Publications 2007).
The following diagram shows the component architecture of SGrid. As discussed in the previous paragraph the combination of the job exertions and providers such as the Jobber, Grider, Cataloger, Caller, File Storer, Spacer, and Transaction Manager, come together to form the SGrid exertion space.
Diagram 9: SGrid Component (Alger n.d.)
27
Diagram 10: SGrid Technical Architecture (Malladi-Venkata, Rai and Sobolewski, SORCER Publications 2004)
28
Chapter 3 Requirements Analysis Space Environment

In developing the methodology for Loki, there were two major choices for space implementation. The first being a single space environment, and the second being a dual space environment. The dual space environment consists of an exertion space and a Loki management space. The separate spaces allow group management and creation to happen in a secure environment outside that of the public exertion space. Once group creation is complete than the exertion space is used in its normal fashion, for writing reading and taking encrypted exertions. The Loki management space would at this point be used for group administration, functions like the deletion of a worker in which a new group key needs to be assembled. The Loki management space would be closed to group administrative services in order to ensure security, but would not mandate that exertions be encrypted for trusted services. In comparison, the single space environment uses the public exertion space for both group administration and exertions reading writing and taking. One of the main differences is that any administrative exertion placed into the public space environment will be encrypted asymmetrically with the key of its receiver.
Loki group key implementation utilizes the single space environment. Although there is more overhead computation in the encryption and decryption of administrative 29
exertions, the use of a single space is beneficial in many ways. The use of single space decreases coupling since all service objects will communicate with the space, regardless of environment. Using one space also allows for Loki to be used in any space computing environment including java spaces, t-spaces, tuple spaces, etc, thus aiding in the scalability of the Loki methodology. Lastly the use of a single space demands that security be enforced on the service/exertion level, as opposed to the space level security needed in the dual space environment. Although service/exertion level security demands more overhead encryption and decryption, it is inherently less vulnerable to attack. In addition, if compromised service/exertion level security only allows for access to minute components, while a breach in space level security would allow for total information access. For these three reasons, the more complex single space environment was chosen for the Loki group key solution.
30
Dual Space Environment

Services LOKI Group Services: LOKI Space LOKI User Agents
Dual Space Environment v0.1 Encryption Manager Key Generator Executor Dispatch Manager
Exertion Space
Diagram 11: Dual Space Environment
Single Space Environment

Services LOKI Group Services: Exertion Space LOKI User Agents LOKI Encryption Layer
Encryption Manager Key Generator Executor Dispatch Manager
Single Space Environment v0.1
Diagram 12: Single Space Environment
31
Exertion Envelope
Loki utilizes the idea of an exertion envelope in its message passing communication. This means that all volatile content in a message is separated from the non volatile information so that the volatile information can be encrypted with the appropriate encryption method. The unencrypted information acts as the address for the private encrypted data, forming the envelope model. This allows data to be passed more efficiently between members in the communication transaction while maintaining confidentiality of all private data.
Exertion envelopes maintain data integrity due to the fact that the raw data is only encrypted and decrypted once in a transaction. The original sender will package by sending it to the Loki Encryption Manager and addressing the envelope. All intermediary members will only need to reference the public address information in the envelope and the final receiver will unpack the data by sending it to the Loki Encryption Manager with the correct key. In comparison to the alternative method of having the address information encrypted with the raw data, exertion envelopes guarantee lossless data transfer and decreased coupling, due to the fact that the alterative would have to decrypt the entire data package with each transfer. The alternative method would have a high probability of data corruption, increased coupling, as well as the increased transfer time due to the number of times the data would have to be unencrypted.
32
Exertion Name: To: From: Encrypted Data
Diagram 13: Exertion Envelope v0.1
Exertion Envelopes are a standard data structure in the proof case space computing environment SORCER, but are easily implemented in all space computing environments. The idea of an exertion or an object is a standard structure in space computing, and the exertion envelope is simply a nested object. The original object, which is now encrypted, is placed inside of an unencrypted object with some addition address data. The only requirements necessary to implement an exertion envelope, are that the space computing environment desired support nested object structures.
33
Exertion Envelope Object Exertion Name: To: From: Encrypted Object
Original Un-Encrypted Object
Diagram 14: Object to Exertion Envelope v0.1
Encryption
The goal of Loki is to implement secure channels for group members to exchange sensitive data, and the grunt of this task falls on the ability to encrypt the groups data, and retrieve it when necessary, while maintaining the inability of outside threats being able to crack the group data. This being said it was apparent, early on in the development of Loki, that a strong and rather complex encryption method would be necessary.
Symmetric Encryption
If Loki were to use symmetric encryption it would first have to start at the group request level. The Loki Group Manager would then have to send the group information to the Loki Key Generator which would develop the symmetric key for encryption and decryption and either dispatch this key to all group members, or dispatch it to the Loki 34
Encryption Manager along with group information so the Encryption Manager would be responsible for access validation. In the first case, there is security vulnerability in the dispatching of the key, to which asymmetric encryption is needed to solve (which is talked about in the next section). In the second case, even though the information is encrypted you are not relying on the encryption for security; you are relying on the ability of the Loki Encryption Manager to authenticate the service.
Asymmetric Encryption
If Loki were to implement asymmetric encryption, the process would have to start with the service requestor requesting an exertion be executed. The exertion would be dropped to the Group Manager who would analyze and dispatch an invitation to all services that need to be in the group. The Group Manager would then receive the group invitation responses, and dispatch the combined public keys of all group members who accepted the invitation. Each service would then be able to calculate the shared key with the key generator by passing its private key and the set of public keys. This would allow services to encrypt and decrypt group data without having to pass the key, thus preventing possible corruption.
35
Chapter 4 Architecture and Design Four Blocker Problem

Shared spaces are inherently public Members in space computing can come and go (ad hoc) Space service broker doesnt explicitly know group members (workers)
Conclusion
Secure Communication that can be initiated by a space service broker with management of ad hoc group of services is needed
Objective
A group key agreement framework (Loki) for space computing environments (Loki Location independent group Key Interactive management)
Approach
Literature Review o Group Key Agreement o Space Computing Analysis of space group management Loki requirements and architecture Develop Loki methodology Loki design Loki implementation Verification and validation of Loki
Schedule
Literature Review Analysis Loki requirements and architecture Develop Loki methodology 36 August 2007 September 2007 October 2007 November 2007
Loki design Loki implementation Verification and validation of Loki Thesis Defense
December 2007 January 2008 February 2008 March 2008
Benefits
Secure ad hoc space group management Secure space exertion oriented programming model Simplified management of group keys Secure communication between inherently public object space Friendly and intuitive user agent attached to space service broker Friendly and intuitive user agent for space-oriented oriented grid computing
UML Diagram 1: : Four Blocker 37
Use Case Diagrams

The Loki use cases fall into three major components. The first is group creation, which is the most important of the three main components, and outlines the establishment and protocol of the instantiation of a group. This is followed by the administration component of the Loki framework, which outlines the management of group members and group objects. This includes deletion, addition, and persistent data storage. The last of the three major components is that of member execution, which outlines the members interaction with the space.
UML Diagram 2: uc LOKI
The first classification of use cases that we will be addressing is that of the Group Creation use cases. These are shown in UML Diagram 3.
38
UML Diagram 3: uc LOKI Group Creation
39
Table 4: Use Case Template 1 - Create Group Goal in Context Scope & Level Preconditions Successfully create a group in a space computing environment Loki, Summary Submitter must be running in a Loki secured space computing environment Successful group creation
Success End Condition Failed End Condition Primary, Secondary Actors Trigger Description
Failed group creation
Primary: Submitter Secondary: Exertion Space, Worker
Submitters request Step 1 2 3 4 5 Action Submitter dispatches a group creation exertion Future group members are invited to group Key is created based on qualified members Group key is dropped Results are generated Branching Action Worker leaves group Worker joins group
Extensions
Step 2a 3a
40
Description The group creation use case is initiated by a submitting service that will do so by dispatching an initial exertion. The Loki framework will then manage this exertion and send the appropriate invitations to the necessary group members. It will then receive the members responses and create a key agreement based on the received responses. At this point the group is created but all members need the necessary information to generate the keys for themselves. This is the key point in the security of the Loki framework; the key itself is not passed back out to member services, only superfluous public data is broadcast out to member services. Once the public keys are dispatched, the framework will then encrypt and handle the initial exertion. Analysis The group creation use case is extended by two worker use cases, leaving and joining a group, which will be described in detail in subsequent descriptions. The group creation use case is the most complex of all the use cases in the Loki framework, due to the fact that it has multiple levels of dependency. The initial submission is made, and then the actual dispatching of the initial exertion occurs after all invitations are sent, received, and processed. This means that this will be the most time intensive part of the framework, yet if completed successfully will make all other use cases and components of the framework simpler.
41
Table 5: Use Case Template 2 - Leave Group Goal in Context Scope & Level Preconditions Success End Condition Failed End Condition Primary, Secondary Actors Trigger Description Successfully leave a group Loki, Summary Must be running in a Loki secured space computing environment Worker leaves a group
Worker remains in group
Primary: Worker Secondary: Submitter
Worker chooses to leave a group Step 1 2 Action Pickup group join request exertion Drop leave exertion
Description The leave group use case is the workers response to the invitation sent in use case 1. In this case the worker does not want to be a member of the group, for some reason local to the worker. What will happen is that the worker will first pick up the group membership request from the exertion space, and then write a leave group exertion in the exertion space.
42
Analysis The original idea for the Loki framework was to have the worker be able to leave a group at any given time. Although this adds functionality, it adds unnecessary complexity to the proof that groups can be implemented in order to secure a space computing environment. It is for this reason that a worker can only leave a group in response to the initial invitation upon group creation.
43
Table 6: Use Case Template 3 - Join Group Goal in Context Scope & Level Preconditions Success End Condition Failed End Condition Primary, Secondary Actors Trigger Description Successfully join a group Loki, Summary Must be running in a Loki secured space computing environment Worker joins a group
Worker does not join group
Primary: Worker Secondary: Submitter
Worker chooses to join a group Step 1 2 Action Pickup group join request exertion Drop join exertion
Description The join group use case is the workers response to the invitation sent in use case 1. In this case the worker wants to be a member of the group. What will happen is that the worker will first pick up the group membership request from the exertion space, and then write a join group exertion in the exertion space.
44
Analysis The original idea for the Loki framework was to have the worker be able to request to join a group at any given time. Although this adds functionality, it adds unnecessary complexity to the proof that groups can be implemented in order to secure a space computing environment. It is for this reason that a worker can only join a group in response to the initial invitation upon group creation.
45
The next classification of use cases that will be discussed is those for group member execution and exertion processing. These are shown in UML Diagram 4.
UML Diagram 4: uc LOKI Execution
46
Table 7: Use Case Template 4 - Get Group User Agent Goal in Context Scope & Level Preconditions Success End Condition Failed End Condition Primary, Secondary Actors Trigger Description Successfully open group user agent Loki, Summary Must be running in a Loki secured space computing environment Group user agent is successfully retrieved
Group user agent retrieval fails
Primary: Worker Secondary: Exertion Space
Worker requests to open UA Step 1 2 Action Worker requests group user agent User agent sends back UA Branching Action Worker picks up exertion Worker drops exertion Worker executes exertion
Extensions
Step 5a 6a 7a
Description The open group user agent use case is initiated by a Loki Worker or User requesting to see the User Interface from the Loki Group User Agent. The interface is published by
47
the Loki Group Manager (which will be described in the class diagram description), and extends the functionality for group functionality monitoring. Analysis The group user agent allows for the monitoring of group services, and is helpful in validation, verification, and accreditation. It is also helpful in the viewing the progress of operations that take longer amounts of time. Even though this seems like a superficial function of the Loki framework, it is valuable to success of group creation.
48
Table 8: Use Case Template 5 - Pickup Exertion Goal in Context Successfully retrieve an exertion from a space computing environment Loki, Summary Must be running in a Loki secured space computing environment Worker successfully retrieves exertion
Scope & Level Preconditions Success End Condition Failed End Condition Primary, Secondary Actors Trigger Description
Worker does not retrieve exertion
Worker requests exertion Step 1 2 Action Worker sends take request Exertion space return encrypted exertion
Description The pickup exertion use case is executed by the Loki Worker, who picks up an exertion from the exertion space. The Loki Worker does so through the use of services provided by the group manager, which monitors and logs the exertion pickup.
49
Analysis The structure of having the Loki Group Manager monitor and log the picking up of exertions in the group allows all monitoring to be local to one component, and aids in decreasing coupling and increasing cohesion.
50
Table 9: Use Case Template 6 - Drop Exertion Goal in Context Scope & Level Preconditions Success End Condition Failed End Condition Primary, Secondary Actors Trigger Description Successfully drop an exertion from a space computing environment Loki, Summary Must be running in a Loki secured space computing environment Exertion is successfully dropped space
Exertion remains in space
Worker requests to drop exertion Step 1 2 3 Action Worker sends exertion to Loki Encryption Manager Loki Encryption Manager return encrypted exertion Worker drops encrypted exertion in Exertion Space
Description The drop exertion use case is executed by the Loki Worker, who drops an exertion into the exertion space. The Loki Worker does so through the use of services provided by the group manager, which monitors and logs the dropping of an exertion.
51
Analysis The structure of having the Loki Group Manager monitor and log the dropping of exertions in the group allows all monitoring to be local to one component, and aids in decreasing coupling and increasing cohesion.
52
Table 10: Use Case Template 7 - Execute Exertion Goal in Context Successfully execute an exertion from a space computing environment Loki, Summary Must be running in a Loki secured space computing environment Exertion is successfully executed
Exertion is no executed
Worker requests exertion execution Step 1 Action Worker sends encrypted exertion to Loki Encryption Manager Loki Encryption Manager return exertion Worker sends exertion to provider Provider executes exertion
2 3 4
Description The execute exertion use case is completed by the Loki Worker by first picking up an exertion from the space (use case 5) and then executing through the use of the Loki Workers appropriate provider. The Loki Worker notifies the Loki group manager of the execution, which in turn monitors and logs the execution. 53
Analysis The execution is the most complex of the worker services do to the fact that it incorporates an external provider for execution. The original design of the Loki framework was to have an additional component called the Loki Executor for exertion execution. In the process of minimizing components and communication, it was apparent that the only thing necessary for exertion execution was the Loki Worker, which is a wrapped generic worker. The Loki Worker adds encryption and decryption on all exertion passing with the space. Execution is inherited from the generic worker, seeing as once the worker has the exertion, the process is the same as in the generic case.
54
The last set of use cases that to be discussed is those necessary for group administration. These are shown in UML Diagram 5.
UML Diagram 5: uc LOKI Administration
55
Table 11: Use Case Template 8 - Get Admin User Agent Goal in Context Scope & Level Preconditions Success End Condition Failed End Condition Primary, Secondary Actors Trigger Description Successfully open admin user agent Loki, Summary Must be running in a Loki secured space computing environment Admin user agent is successfully retrieved
Admin user agent retrieval fails
Administrator requests to open UA Step 1 2 Action Administrator requests admin user agent Admin Agent sends back UA Branching Action Admin deletes worker from group Admin deletes exertion from group Admin deletes group
Extensions
Step 8a 10a 11a
Description The open admin user agent use case is initiated by the groups administrator requesting to see the User Interface from the Loki Admin User Agent. The interface is published by
56
the Loki Group Manager (which will be described in the class diagram description), and extends the functionality for group administration. Analysis The admin user agent allows for group administration, which consists of the deletion of exertions, workers, and the groups themselves. Although group administration is not necessary for the implementation of groups in a space computing environment, it helps with the usability of the framework. Without group administration, the group members and administrator are blind to their membership in any specific group.
57
Table 12: Use Case Template 9 - Delete Worker Goal in Context Successfully delete a worker from a group in a space computing environment Loki, Summary Must be running in a Loki secured space computing environment Worker is deleted from a specific group
Worker is still a member of a specific group
Primary: Administrator
Administrator chooses to delete worker from group Step 1 2 3 Action Delete worker request is sent to UA Delete worker request is sent to Loki Group Manager Worker's group's exertions are retrieved from Exertion Space Worker's group's exertions are decrypted Group key is recalculated Worker's group's exertions are encrypted with new group key Worker's group's exertions are written to space
4 5 6
58
Description A group administrator can choose to delete a worker from a group through the Loki Admin User Agent. This is one of the three administrative tasks that can be executed in the admin user agent; the others will be described in the next two use case descriptions. The process of deleting a worker from a group is a rather intense and costly operation and will be described in greater detail in the appropriate communication diagram. Analysis The deletion of a worker from a group is a not a critic function to the success of the Loki framework, but helps in the debugging and administration of the framework as well as validation, and is thusly included in the core implementation.
59
Table 13: Use Case Template 10 - Delete Exertion Goal in Context Successfully delete an exertion from the space computing environment Loki, Summary Must be running in a Loki secured space computing environment Exertion is deleted from space
Exertion is not deleted from space
Administrator chooses to delete an exertion Step 1 2 3 Action Delete exertion request is sent to UA Delete exertion request is sent to Loki Group Manager Loki Group Manager takes exertion from space
Description The administrator initiates the deletion of an exertion from the space which is an extension of the Admin User Agent. In this case, this selection initiates the communication necessary to simply remove the specified exertion from the space.
60
Analysis Similar to the deletion of a worker, the deletion of an exertion from the space is not a critic function to the success of the Loki framework, but helps in the debugging and administration of the framework as well as validation, and is thusly included in the core implementation.
61
Table 14: Use Case Template 11 - Delete Group Goal in Context Scope & Level Preconditions Success End Condition Failed End Condition Primary, Secondary Actors Trigger Description Successfully delete a group in a space computing environment Loki, Summary Must be running in a Loki secured space computing environment Group is deleted from space
Group is not deleted from space
Administrator chooses to delete a group Step 1 2 3 4 5 Action Delete group request is sent to UA Delete group request is sent to Loki Group Manager Group's exertions are retrieved from exertion space Group's exertions are decrypted Group's exertions are written to space
Description The administrator initiates the deletion of group from the space which is an extension of the Admin User Agent. In this case, this selection initiates the communication necessary to retrieve all exertions owned by the group, decrypt them, and then return them to the space. 62
Analysis Similar to the deletion of a worker and the deletion of an exertion, the deletion of a group is not a critic function to the success of the Loki framework, but helps in the debugging and administration of the framework as well as validation, and is thusly included in the core implementation.
63
Component
The original design of the component diagram is shown below:
UML Diagram 6: cmp LOKI
64
Group creation starts at the submitter who utilizes the javaspace interface to drops a group creation exertion in the space which the Loki Group Manager picks up. The Loki Group Manager then drops a generate group key exertion in the exertion space via the javaspace interface. The Loki Key Generator takes the generate group key exertion from the exertion space via the javaspace interface, processes the generation. The Loki Key Generator then dispatches the group keys to the exertion space so that each member has an exertion in the space containing the group key. The Loki Key Generator also dispatches a key for the Loki Group Manager, and the Loki Executor for the use of group administration. Each group member picks up their group key exertion from the exertion space through the use of the javaspace interface. Once all members have the group key information, they locally generate the shared group key. It is at this point that the Loki Group Manager takes the initial exertion and communicates to the Loki Encryptor via the encryption management provided by the Loki Encryptor to encrypt the initial exertion. The Loki Group Manager then drops the initial encrypted exertion in the Exertion Space via the javaspace.
Group administration starts with the Administrator accessing the Loki Admin User Agent. The Loki Admin User Agent interacts directly with the Loki Group Manager via the group administration, which controls and manages all administrative activity. The administrator has the ability to browse the exertion space, delete a previously created
65
group, delete a worker from a given group, or delete a groups exertion. The first activity, which is that of deleting a previously created group, communicates with the Loki Decryptor through the provided decryption management, and the exertion space through the provided javaspace. The second activity, deleting a worker from a given group, utilizes the Loki Decryptor through the provided decryption management, the Loki Encryptor through the provided encryption management, the Loki Key Generator through the provided key generation management, and the exertion space through the use of the provided javaspace. The last action available to the administrator is that of deleting an exertion from the exertion space, which obviously interacts with the exertion space itself through the provided javaspace.
The last portion of the Loki framework is that of group management, which is mainly located and handled by the Loki Group Manager and the Loki Group User Agent. The three main functions that are monitored and logged by the group management provided are that of picking up an exertion, dropping an exertion, and executing an exertion. All three upon occurrence start with the Loki Worker and are stored by the Loki Group Manager through the provided group management. Any Loki Worker can then view the management of these operations through the Loki Group User Agent. At this point in the design process, components were analyzed for validity, and efficiency with the inevitable goal of increasing cohesion and decreasing coupling. The
66
preceding communication was changed slightly in this minimization process, and will be described in further detail in the following more detailed, revised component diagrams.
Entities
Service Spacer The service spacer component describes the service spacer object utilized by the Sorcer grider, which is responsible for the creation of the group. The service spacer is by default the administrator to the group that is created by the submitted object. As the administrator to the group the service spacer has access to all of the persistent data storage via the group manager component, and can perform overhead group administration, such as deleting a member, or the group itself. In order to create a group the service spacer drops its public key for each member who is desired to be a member of the group. This object serves as the invitation to the group and the initial protocol for group creation is started from this point. Caller The caller component serves as the main execution provider to the group. Upon instantiation the caller starts up space workers, which listen to the space. Upon group creation, which the space workers are responsible for, the caller is passed the decrypted exertion for execution. Once complete the results are dropped to the space for the service requestor, in the implementation case this would be the service spacer.
67
Existing Components
Exertion Space The exertion space component is the space itself. In the Loki methodology it is used for the creation of the groups as well as the exchange of exertions as well as all standard space functionality. The Loki Group Manager, the Loki Dispatch Manager, and the Worker all communicate with the exertion space.
LOKI Components
Admin User Interface The administrative user interface component is the user agent for administrative management. It is accessible to only the administrator component and includes the functionality to delete a worker, delete an exertion, and delete a group. Exertion Dispatcher Factory The exertion dispatcher factory component, given an exertion, can dispatch tasks from the exertion to the space. The dispatch manager is used by the Loki member utility to communicate or broadcast information to the members of a group. Encryption Manager The encryption manager component is in charge of the encryption and decryption of a given exertion, based on the Loki standard encryption policy. It is passed an exertion, the shared key, and a specification as to whether to encrypt or decrypt the exertion.
68
Group Data Store The group data store is the database, local to the group manager, created for the use of storing group information. The Group Data Store will store all group information, all member information, all administrator information, all group exertion information, as well as all group action information which can include the reading, writing and taking of exertions. Group Manager The group manager component is responsible for the management of all group services, user agents, and persistent data storage. As well the group manager is responsible for maintenance of groups lifespan and deletion functionality. Group User Interface The group user interface is used by workers to monitor the activity in the group. Through the group user interface, the worker can view exertion traffic, and logging of group activity. Key Generator The key generator component given an array of the groups public keys and the services private key generates the groups shared key. The key generator component is accessed directly by all services that require it, so that the private key is not being passed across unsecure means of communication.
69
Loki Member Utility The Loki member utility is the component utilized by each individual member to produce the necessary space calls for the overhead group creation protocol, reading, taking, and writing cryptic objects to the space, as well as storage of both keys and key agreements. Space Worker Each provider within Sorcer starts multiple space worker objects, which listen to the space for objects of concern specifically to the individual provider which it was started by. The space worker in the Loki framework analyzes each received object, and decided whether or not it is an invitation. If it is not it is processed as normal, and if it is then the group creation sequence is started. Once a group is created, then the space worker will test each incoming exertion to see if it belongs to the group which the space worker belongs, and if it does then the space worker will retrieve the most current group information and decrypt the object.
70
Component Diagrams
In minimizing the components necessary for the Loki framework, it was obvious that the components break down similarly to the use cases, being in three major categories. They are Group Creation, Group Administration, and Group Management. They are described in detail as follows.
UML Diagram 7: cmp LOKI Group Creation
The first major portion is that of group creation, which is shown above. The process starts with the Service Spacer dropping the initial exertion with the Loki Member Utility component through the provided spacer interface. The Loki Member Utility then analyzes the exertion and sends the group invitation information directly to the Exertion Dispatcher Factory component through the provided dispatch management. The Exertion Dispatch Factory dispatches the group invitations in the Exertion Space through 71
the provided javaspace. The Space Worker uses the same javaspace to pick up its individual invitation, and drop either a join group response, or a leave response, back in the exertion space. The Loki Member Utility then uses the provided javaspace to pick up the worker invitations. The Loki Member Utility then uses the dispatch management to dispatch the group information back out to the worker through the Exertion Dispatcher Factory. The Exertion Dispatcher Factory then uses the javaspace to dispatch the worker information to the Exertion Space. The Loki Member Utility then takes the group information and uses the key generation management with the Key Generator to calculate the shared group key. Using the shared group key and the encryption management, the Loki Member Utility encrypts the initial exertion, and then drops it to the Exertion Space using the provided javaspace. Through the entire process the Loki Member Utility communicates with the Group Manager to record the group information with the Group Data Store using the provided storage interface.
This is drastically different than the previous description for many reasons, the first being the dependencies on the javaspace. Previously, every component would communicate directly with the Exertion Space, using the javaspace interface, and drop a specific type of exertion in order to communicate with the other components in the Loki Framework. In order to increase cohesion and decrease coupling the dependency on the javaspace needed to be reduced drastically. It is for this reason that any component that
72
communicates with only one or two other components, is now routed to directly communicate with those few components. This also aids in keeping the message passing secure and the flow of the framework logical. In addition, the minimization of direct component to component communication helps to decrease the number of types of exertions. As well, the original design of the Loki Framework did not include the Group Data Store. The implementation of the Group Data Store helps to localize the recording of group activity and helps in the object orientation of the framework design.
UML Diagram 8: cmp LOKI Administration
73
The previous diagram shows the minimized design of the Loki components necessary for group administration. As shown above all group administration is initiated by the administrator who uses the provided group administration from the Admin User Interface. The functionality of the original design is still maintained in this design but the new minimized design completes this functionality with reduced dependencies and communication. The first operation that can be performed by the administrator is that of deleting a worker from the group. This is communicated to the admin user agent via the provided group administration. This request is then passed to the Loki Member Utility via the provided group management. The Loki Member Utility is then responsible for picking up all the workers groups exertions from the exertion space via the provided javaspace. The encrypted exertions are then sent to the Encryption Manager along with the previously calculated shared group key, via the provided encryption management for the purpose of decrypting the exertions. The exertions are decrypted and then returned to the Loki Member Utility through the same interface. The Loki Member Utility then communicates with the Key Generator component through the provided key generation management in order to calculate the new group key. The Loki Member Utility then dispatches the new group information out to the members by using the Exertion Dispatcher Factory through the provided dispatch management. The dispatch manager then uses the provided javaspace to dispatch the group information to the Exertion Space. The Space Workers then use the provided javaspace to pick up the group information exertions from the Exertion Space. At this point all that is left is 74
to have the Loki Member Utility commit the group information and changed exertions. To do this the next step is to have the Loki Member Utility commit the deletion to the Group Data Store, through the provided storage. The Loki Member Utility then uses the encryption management to encrypt all the previously retrieved exertions with the new group key. The Encryption Manager then returns these encrypted exertions through the provided encryption management to the Loki Member Utility. The Loki Member Utility then returns these exertions to the Exertion Space through the provided javaspace. At this point the deletion of a worker from the group is complete.
The next administrative task to which the framework is responsible for is that of deleting an exertion from the group. This is a relatively simple task with the new minimized implementation. The Loki Member Utility receives this request from the Admin User Interface through the provided group management. The Loki Member Utility then communicates with the Exertion Space via the javaspace interface in order to take the specified exertion from the space. The Group Manager then uses the provided storage interface to communicate with the Group Data Store and stores the deletion of the exertion. This is all that is necessary to delete an exertion from the space. The last action which an administrator can perform is that of deleting a group from the space. This too starts at the Admin User Interface and send the request to the Loki Member Utility through the use of the provided group management. The Loki
75
Member Utility then communicates with the Exertion Space to take all the groups exertions, and does this through the use of the javaspace. The Loki Member Utility then uses the encryption management to send the exertions to the Encryption Manager, where they are decrypted and returned to the Loki Member Utility. The Group Manager then communicates to the Group Data Store where it stores the deletion. The Loki Member Utility then communicates with the Exertion Space through the use of the javaspace in order to drop all of the decrypted exertions thusly deleting the group. There are several major differences in the implementation previously described and the original design. Although they have the same functionality, the previously described design is better for several reasons. Firstly it is better because of the decreased dependency on both the Loki Member Utility and the Exertion Space. This allows for a more compartmentalized design with decreased coupling and increased cohesion. Secondly, several of the components whose functionalities are correlated were combined. The first of which is the Exertion Dispatcher Factory, which includes and manages the functionality of the dispatcher factory and the selected dispatcher. The next component is that of the Encryption Manager, which includes and manages both encryption and decryption since they are correlated tasks. As well the implementation of the Space Worker is a minimization of components, reducing the communication of the worker level encryption and decryption. The last improvement on the design of the administration is the implementation of the Group Data Store which allows for the management and recording of group activity. By creating a component thats sole focus 76
is to record the activity of the group, the tasks necessary to do this are localized to this component, which decreases communication and aids in increasing cohesion.
UML Diagram 9: cmp LOKI Execution
The last portion of the component diagrams is that of worker execution and functionality. Previously all worker execution was dependent on the javaspace for process success. The use of the Space Worker allows the framework to minimize the dependency on the javaspace and many other components. The Loki framework allows
77
the Space Worker to maintain the same functionality as the generic worker in space computing environment. The first operation the worker is able to perform is that of picking up and exertion. This is started at the Space Worker who uses the javaspace interface to retrieve the group encrypted exertion from the Exertion Space. The second function which the Space Worker can perform is that of dropping an exertion in the space. This is done by utilizing the javaspace to request a take on the exertion from the Exertion Space. The last action which the Loki Worker is able to perform is that of executing an exertion. The worker does this by using the provider interface to send the desired exertion for execution to the specific worker provider. Above these three functions the Space Worker is able to view the Group User Interface which allows for the viewing of the group management.
Although this framework seems to not manage the group functionality of encrypted exertions, it does by the structure of the Space Worker and its relationship to the worker which it wraps. The Space Worker is composed of the wrapped worker and the Encryption Manager, both of which are local components to the Space Worker. The way that this is designed is that the Space Worker, upon any request that will utilize the core data in the exertion envelope will communicate with the Loki Member Utility to decrypt the data, execute, and then communicate again to re-encrypt the data. This allows for
78
the data to be unencrypted for as short a time as possible, and helps to simplify the group level security.
79
Interaction
The interaction diagrams shown below outline the communication between the components in order to complete the functionality outlined in the use case diagrams.
UML Diagram 10: sd LOKI Group Creation
The Group Creation interaction diagram starts with the Service Spacer dropping the initial exertion to the Loki Member Utility much like it would to the Exertion Space without groups. The Loki Member Utility then analyzes the exertion and creates invitations for all services that need to be a part of the group necessary to process the given exertion. The Loki Member Utility then sends the group invitations to the Exertion
80
Dispatcher Factory. The Exertion Dispatcher Factory dispatches the invitations out to the Exertion Space where the Space Workers will respond with either a join group exertion or a leave group exertion. The Loki Member Utility will then be responsible for picking up these responses from the Exertion Space. The complementary compound keys are created locally to the Loki Member Utility and that group information is sent back out to the Exertion Dispatcher Factory, where it is dispatched to the Exertion Space. The Space Workers now pickup that complementary compound key information and communicate with their local Key Generator Component to create the group wide shared key. At this point in the group creation process the Loki Member Utility sends the complementary compound key information to its local Key Generator Component and generates the same group wide shared key. Once all members of the group and the Group Manager have the same shared key, the group is created. All that is left to do in the group creation process is to handle the initial exertion that sparked the group creation. The Loki Member Utility had the exertion and sends it to the local Encryptor with the shared key, in order to encrypt it. Once complete, the exertion is returned and the encrypted exertion is then dropped to the Exertion Space, where it is process by its fellow group members.
81
UML Diagram 11: sd LOKI Administration
Loki Administration requires the most complex communication of all of the use cases in the Loki Framework. The first use case is that of retrieving the Loki Admin User Agent. This is completed by the Administrator Actor sending a get request to the User Agent, which then returns the interface and allows for the functionality of all the following use cases. Through the User Agent the Administrator is able to delete a worker, delete an
82
exertion, as well as delete an exertion. The first action is that of deleting a worker from a group. This started by the Administrator communicating the deletion to the Admin User Agent. The deletion is then communicated to the Loki Member Utility, which retrieves all of the Space Workers groups exertions. Once returned to the Loki Member Utility, the exertions are sent to the Encryption Manager where they were decrypted and returned to the Loki Member Utility. At this point the Loki Member Utility internally removes the Space Worker from the group data, and computes the new complementary compound keys. New group information is then sent to the Exertion Dispatcher Factory where it is dispatched to the Exertion Space. The Space Workers will then retrieve the complementary compound key exertion from the Exertion Space and sends it to their local Loki Key Generator which will compute and return the shared key. It is at this point that the Loki Member Utility computes the shared key with its local Loki Key Generator. Once the new shared key is established the Loki Member Utility sends all the previously retrieved exertions and sends them to the Loki Encryption Manager with the group shared key. They are returned to the Loki Member Utility where they are then placed back into the Exertion Space. It is at this point that the deletion of a worker is complete. The next action that is available is that of deleting an exertion from the group. This is started by the Administrator communicating the deletion request to the Loki Admin User Agent. The User Agent then communicates this request by sending the deletion request to the Loki Member Utility, which will then take the specified exertion from the Exertion Space. The deletion 83
is then complete because the exertion is no longer available in the space. The last function available for the Administrator is that of deleting a group itself. The Administrator starts this activity by communicating this choice to the Loki Admin User Agent, which in turn communicates the choice to the Loki Member Utility. The Member Utility is responsible for taking all of the groups exertions from the Exertion Space. Once returned the Loki Member Utility communicates with the Loki Encryption Manager to decrypt the groups exertions. Once returned the Loki Member Utility returns the exertions to the Exertion Space, and the deletion is complete.
UML Diagram 12: sd LOKI Execution 84
The last set of interactions is that of the Space Worker use cases. First of these actions is that of opening the Group User Agent, which is completed simply by the Space Worker requesting the User Agent from the Agent itself. The next function the Space Worker is able to perform is that of taking an exertion from the Exertion Space. The Space Worker sends the take request to the Exertion Space, and it is responded to with the Exertion requested. The next function is that of dropping an exertion in the space. The exertion is first sent to the Loki Member Utility where it is encrypted and returned. At this point it is sent from the Space Worker to the Exertion Space. The last function that the Space Worker is able to perform is that of executing an exertion. This starts with the Space Worker sending the exertion to the Loki Member Utility for decryption before it is sent to the worker specific Provider for execution. All results are then returned to the Space Worker.
85
Package
The package diagram in the universal modeling language describes the interactions between implemented packages. This model shows the packages, classes, and interactions between these objects in the implementation case. Each package is then described in greater detail in its coordinating class diagram.
UML Diagram 13: pkg LOKI
The package diagram above show seven major packages, they are db, admin user interface, group, group user interface, crypt, member, and key. The Loki group package is one of the key packages in the Loki framework, and interacts directly with four other packages. The group is inherently the only member in the Loki framework that is able to 86
access the Loki db, and provides information from this access to other services in the framework. In addition to accessing the Loki db package, the Loki group package is responsible for publishing both user interfaces, the group user interface and the admin user interface. The two user interfaces utilize their connection to the Loki group package to display information about the groups to the administrative user and the group users. The group package also imports functionality from the Loki member utility in order to perform all group member actions. Every member of a group will import these functions from the Loki member utility. The Loki member utility itself will import functionality from both the key package and the crypt package. The key package is responsible for the creation and exchange of keys, and the crypt package is responsible for the utilization of the keys to perform cryptography actions like encrypting and decrypting.
87
Class
The class model will show more detail that the package model, and will elaborate on all of the functionality of the individual classes.
UML Diagram 14: pkg sorcer.core.loki.crypt
The Loki crypt package consists of four classes, the encryption management interface, the encryption management class, the encrypt thread class, and the decrypt thread class. The crypt package is mainly responsible for both encryption and decryption, and supplies four options for doing this. You can encrypt a String, encrypt a byte array,
88
encrypt a stream, and encrypt a pipe. The crypt package supplies the same options for decryption. Encrypting a string, a byte array, and a stream are all wrapped extensions of the basic java cipher class, but in the case of encrypting and decrypting a pipe the encryption and decryption threads are used in the following matter.
Input Pipe Encrypt / Decrypt Thread Output Pipe
Figure 4: Pipe Cryptography
89
The db package outlines the methods for connection, storing and retrieving from the database. The group manager will utilize these classes as well as restrict access to the Loki db dependent on access level. The Loki db will be created wherever the Loki Group Manager will be launched.
90
UML Diagram 15: pkg sorcer.core.loki.db
91
The Loki group package will be responsible for launching the Loki group manager provider, managing the Loki db, publishing the administrative user interface as well as the group user interface.
UML Diagram 16: pkg sorcer.core.loki.group
92
The key package will be responsible for creating key pairs, key agreements, complementary compound keys, as well as shared keys. This is done by implementing the KeyGenerationManagement interface.
93
UML Diagram 17: pkg sorcer.core.loki.key
94
The Loki member utility will be responsible for all group communication and overhead. It will provide the methods necessary to drop the creators key pair, drop the members key pair, create and drop the complementary compound key exertion, write an encrypted exertion, read an encrypted exertion, and take an encrypted exertion.
UML Diagram 18: pkg sorcer.core.loki.member
95
The administrative user interface is meant to be a tool for the group administrator to view, and control all group operations. There is the functionality to view all group activity, group information, member information, and exertion information.
UML Diagram 19: pkg sorcer.loki.admin.ui
96
The group user interface is responsible for informing group members of group activity, without sharing any critical information to the group security. There is functionality to view group information and activity information in the group. The member will not be able to see what other members belong to the group, what exertions belong to the group, or other group information.
UML Diagram 20: pkg sorcer.loki.group.ui
97
Deployment
The deployment diagram in the universal modeling language outlines what systems will provide what services. The implementation test case is distributed across seven different systems, and multiple operating systems. This distribution shows that the Loki framework solution is usable, maintaining one of the core architectural properties.
UML Diagram 21: deployment LOKI
98
Technical Architecture
The technical architecture diagram shown above outlines the major technologies involved in the implementation of the Loki Framework. At the lowest level is standard edition Java version five which is what all succeeding technologies are built in for the proof case technology. Jini service oriented technology is used to recognize and support the java based service oriented architecture, and Inca X Service Browser allows users to browses services within the environment. Rio is used to support and simplify the dynamic distribution of distributed applications in a service oriented environment (Project Rio 2007). JavaDB is used inside of Sorcer for file storage and other functions, as well as internally to the Loki Framework by the Loki Group Data Store. The Java Cryptography Extension is used in Sorcer as well as the Loki Framework for the creation and distribution of keys and key agreements. On top of these technologies is SORCER, which utilizes all of the preceding technologies to provide a service oriented environment for the implementation of services, providers, and user interfaces. One of these services is that of the SGrid application which utilizes the service oriented environment to implement a service oriented metacomputing grid framework. Lastly is the Loki Framework. The Loki Framework utilizes all of these technologies to implement and prove the correctness of the framework.
99
Diagram 15: LOKI Technical Architecture
100
Architectural Attributes Availability

Availability is the ability of the system or framework to respond with the current status regardless of faults, errors, or crashes. The actual availability time is a calculation of the mean time of a failure divided by the mean time of a failure along with the mean time of repair (Software Architecture in Practice, Second Edition n.d.). The Loki framework addresses availability through service replication and fault tolerant programming. The abilities of the administrator aid in availability by being able to view the operations and exertions defined in the space, and manipulate them.
Modifiability
Modifiability is the ability of the framework to be modified, and at what cost this can be completed. If the specific modification is rather complex, and the modifiability of the framework is not easy, than additional time and money is required in order complete the change (Software Architecture in Practice, Second Edition n.d.). The uses of interfaces in the Loki framework allow the different components of the framework to be modified easily as long as the modification fulfills the outline of the interface.
Performance
Performance is the ability of the framework to respond to all communication in an expedient time (Software Architecture in Practice, Second Edition n.d.). The Loki framework is not particularly focused on performance, due to the fact that the Loki
101
framework is mainly focused on proving the general abilities of the framework. Performance could be increased with the implementation of more efficient methods of encryption, decryption, key generation, and etc.
Security
Security is the ability of the framework to tightly restrict access to unauthorized users, but freely permit access to authorized users. Several core components to security are nonrepudiation, confidentiality, integrity, assurance, availability, and auditing each outline security in different fashions (Software Architecture in Practice, Second Edition n.d.). Security is the main focus in the Loki framework, ensuring the appropriate privacy to members of the space. This is completed by the secure implementation of the group key and the management of groups within the space. Even though objects are still inherently public, the encryption of these objects using a shared key, provides a strong level of symmetric encryption.
Testability
Software testability refers to the ease with which software can be made to demonstrate its faults through testing (Software Architecture in Practice, Second Edition n.d.). Testing ensures that the software does what it is supposed to do, and can take almost 40% of the total process time. The Loki framework ensures testability through component based design. Each component can be tested individually, seeing as each components function is mutually exclusive.
102
Usability
Usability is how easy it is for the user to accomplish a desired task as well as the kind of user support the system provides. Usability is broken down into five different key focus areas. Learning system features, using a system efficiently, minimizing the impact of errors, adapting the system to ser needs, and increasing confidence and satisfaction (Software Architecture in Practice, Second Edition n.d.). The Loki framework maintains usability through its ability to operate without the knowledge of its operation. If operating correctly the space services should be normally operable.
103
Encryption Multi Diffie Hellman

In order to account for an unknown number of group members required for some arbitrary group, a key agreement is needed that has no restriction on the number of party members in it. It is for this reason that Multi Diffie Hellman was created. Multi Diffie Hellman is a wrapper to the standard Diffie Hellman implementation and links individual two party key agreements to allow for N-ary key agreements. Diffie Hellman is used as the core cryptographic component in the Loki Framework for several reasons. First, because it doesnt require any previously exchanged knowledge between party members, which works perfectly for the space environment since the space service broker doesnt implicitly know where group members are. As well, the Diffie Hellman Key Exchange is used because the mathematical formula involved in the exchange is scalable, and this scalability attribute is packaged into the Multi Diffie Hellman element in the Loki Framework. In addition, Diffie Hellman and Multi Diffie Hellman are used in the Loki Framework because they are both practical and timely methods of secure key creation. Several timings are shown as follows: Table 15: Client Mode Encryption Timings
Timings performed on Intel Pentium 4 3.4GHz with 2.0GB RAM Diffie Hellman Elliptic Curve Diffie Hellman El Gamal 17 milliseconds 87 milliseconds 272 milliseconds
104
Table 16: Server Mode Encryption Timings

Timings performed on Intel Pentium 4 3.4GHz with 2.0GB RAM Diffie Hellman Elliptic Curve Diffie Hellman El Gamal 14 milliseconds 90 milliseconds 243 milliseconds
The timing charts shown above outline the core time differences between Diffie Hellman, Elliptical Curve Diffie Hellman, and ElGamal, both in client and server java virtual machine modes. All three implementations were done using the same encryption package, language, and computer in order to decrease the affecting variables on the timings. It is easy to see that the fastest of these methods is that of Diffie Hellman, even though all three provide reasonably equivalent levels of security. The next information to look at is that of the Multi Diffie Hellman performance and complexity.
105
Table 17: Multi Diffie Hellman Group Size Timings

Timings performed on Intel Pentium M 1600MHz with 512MB RAM # of Party Members 10 20 30 40 50 75 100 250 500 1000 Client Mode 731 milliseconds 2854 milliseconds 6429 milliseconds 11446 milliseconds 17806 milliseconds 40088 milliseconds 71152 milliseconds 444870 milliseconds 1781211 milliseconds 7127539 milliseconds Server Mode 791 milliseconds 2013 milliseconds 4557 milliseconds 8091 milliseconds 13239 milliseconds 28261 milliseconds 53096 milliseconds 336254 milliseconds 1320289 milliseconds 5036211 milliseconds
8000000 7000000 6000000 5000000 4000000 y = 261.6e0.940x 3000000 2000000 1000000 0 10 20 30 40 50 75 100 250 500 1000
Client Mode
Expon. (Client Mode)
Figure 5: Multi Diffie Hellman Client Mode Time Curve 106

6000000 5000000 4000000 3000000 y = 170.4e0.961x 2000000 1000000 0 10 20 30 40 50 75 100 250 500 1000
Server Mode
Expon. (Server Mode)
Figure 6: Multi Diffie Hellman Server Mode Time Curve
This table shows the timings of the Multi Diffie Hellman with variable party sizes. As you can see from the table, the time is relatively small for groups of smaller sizes. This computation is only executed when the group is created or modified, so the execution time of the Multi Diffie Hellman is acceptable, especially since groups tend to be smaller than fifty party members for most multidisciplinary analysis and optimization metacomputing programs (Sobolewski, Air Force Research Lab 2007). Although the common application of the Multi Diffie Hellman is with groups of smaller size, it does have an exponential complexity, so a possible expansion of the Loki Framework is the implementation of a scalable key agreement with a better complexity. In order to fully
107
understand the exponential nature of the Multi Diffie Hellman key agreement let us look at the algorithm for the key agreement.
108
Key compoundKeys[the number of group members] for every group member { compoundKeys[member index] = the key returned by calling the GenerateRecursiveKey function with key agreement array (agrees), key pair array (pairs), calling member index (index) and index of next member (next) passed in as parameters, to the array }
GenerateRecursiveKey FunctionTakes: Key Agreement array (agrees), Key Pair array (pairs), calling member index (index), index of next member (next) Returns: Key { If (next+1 > length of pairs) { variable next = 0 } Else { variable next = next+1 } If (next equals index) { Return public key of next element of pairs array } Else { Variable tempKey = the key returned by calling the GenerateRecursiveKey function with parameters (agrees, pairs, index, next) Return the key generated by signing the next element of the agrees array with tempKey } }
Figure 7: Multi Diffie Hellman Compound Key Creation Algorithm
109
As you can see from the recursive nature of the pseudo code, the Multi Diffie Hellman process will be exponentially complex for every new group member. The benefit of the process though, is that this does not hinder the process for groups of reasonable size, so this complexity is acceptable for the proof of the Loki Framework. Another algorithm can be used if need, for example the TFAN Group Key API (Liao 2005). The following activity diagram and elaboration will show the Multi Diffie Hellman execution and encryption process used in the Loki Framework.
UML Diagram 22: act LOKI
The activity diagram shows the segment of the group creation protocol that is responsible for the creation of the shared key. It starts with the Loki Group Manager dropping the group invitations into the exertion space, enclosing its public key in the exertion. At this point the Loki Workers receiving the invitations pick them up from the space, and make a decision on whether to accept the invitation or reject the invitation. If rejected a leave exertion is created, but if accepted a join exertion is created and 110
packed with the Loki Workers public key and key agreement. In this phase the Loki Worker will also encrypt the local key agreement object with a shared key that is established through the use of a Diffie Hellman Key Exchange between the Group Manager and the Loki Worker. The Loki Worker then drops the response, either join or leave, into the exertion space. The Group Manager then retrieves the response from the exertions space, and if a join response, decrypts the exertion with the public key of the specific Loki Worker and its own private key. It is at this point that two arrays are created by the Group Manager, one contains a sequencial listing of the key agreements from all Loki Workers that accepted the invitation, and the other a sequential listing of all public keys from all Loki Workers that accepted the invitation. It is at this point that the Group Manager sends these two arrays to the Loki Key Generator in order to create the complementary compound keys neccesary for inidividual shared key creation. This creation is done as follows:
111
Public Key Array: aPublicKey Key Agreement Array: aKeyAgree bKeyAgree cKeyAgree dKeyAgree eKeyAgree bPublicKey cPublicKey dPublicKey ePublicKey
Complementary Compund Key Array:

Key bcde = bKeyAgree.doPhase(cKeyAgree.doPhase(dKeyAgree.doPhase(ePair.getPublic(),false),false),false); Key cdea = cKeyAgree.doPhase(dKeyAgree.doPhase(eKeyAgree.doPhase(aPair.getPublic(),false),false),false); Key deab = dKeyAgree.doPhase(eKeyAgree.doPhase(aKeyAgree.doPhase(bPair.getPublic(),false),false),false);
Key eabc = eKeyAgree.doPhase(aKeyAgree.doPhase(bKeyAgree.doPhase(cPair.getPublic(),false),false),false); Key abcd = aKeyAgree.doPhase(bKeyAgree.doPhase(cKeyAgree.doPhase(dPair.getPublic(),false),false),false);
Diagram 16: Complementary Compound Key Protocol
The complementary compound keys, once created, do not give away any sensitive information about the group or the key agreement. At this point in the process, the complementary compound keys are much like the public keys in a common two part key exchange. After creation, the Group Manager drops the array of complementary compound keys into the exertion space. The Loki Workers who accepted the invitation will then be responsible for picking up their specific complementary compound key and individually calculate the group wide shared key. This is done in the following manner:
112
A retrieves bcde B retrieves cdea C retrieves deab D retrieves eabc E retrieves abcd
aKeyAgree.doPhase(bcde,true); bKeyAgree.doPhase(cdea,true);
Shared Key=aKeyAgree.generateSecret()); Shared Key=aKeyAgree.generateSecret());
cKeyAgree.doPhase(deab,true); dKeyAgree.doPhase(eabc,true); eKeyAgree.doPhase(abcd,true);
Shared Key=aKeyAgree.generateSecret()); Shared Key=aKeyAgree.generateSecret()); Shared Key=aKeyAgree.generateSecret());
Diagram 17: Shared Key Generation Protocol
At this point all Loki Workers have the same shared key without having to pass any sensitive information. The Loki Group Manager will be an inherent member to all groups and will also calculate the shared key in order to securely manage the groups. Once all calculation is complete the group is created. The Loki Worker upon encryption and decryption will compare the creation time of the locally created shared key, with that of the time on the complementary compound key exertion. By doing this the Loki Worker will be aware of any updates to the group, and if there is a conflict in the times, a new shared key will be calculated locally. At no point is the shared key placed in the space.
113
Data Store
The design of the Loki framework calls for the storing of group member information and group activity information. This information is utilized functionally for key creation and encryption, as well as for group administration and monitoring. It became apparent in the design process that a method for data storage be created. This functionality is contained in the Loki Group Data Store component explained above, and is mainly utilized by the Loki Group Manager.
The Loki Group Data Store needs the functionality to store information on Groups, Members, Administrators, Exertions, as well as any interactions between these entities. Such interactions would be that of membership of members to groups, and actions that members execute on exertions in the group. As well this information needs to be securely stored, because if it is not then it is a probable security risk to the group. If an outside source were able to access this information they may be able to access sensitive group information, or even add themselves to this group. That is why this functionality is local to the Loki Group Manager, thusly decreasing excess communication and the possibility for information interruption. In order to guarantee information validity, each table in the data store also stores its creation and modification information. This allows member services (being the Loki Group Manager) to verify that data has not been modified since its previous access.
114
The first set of information that needs to be stored is that of group information. In order to avoid data duplication or modification of invalid entries, Groups are identified by a unique sequence identifier (Group_Seq_Id). All groups must have a group name (Name), expiration date and time (Exp_Date), a creation date (Creation_Date), a string containing who created the group (Created_By), the date and time of the last update (Last_Update), and a string containing the name of the last object to modify the entry (Last_Update_By). As well, a group can also have a comment attached to it (Comment), but this is not required or necessary for group storage. In order to incorporate the relationship that every group has exactly one group administrator, which is defaulted as the creator, every group entry requires the sequence identifier of the administrator which reference the administrator table (LOK_ADMIN). This group information is stored in the group table entitled LOK_GROUP. The next table of concern is the administrator table that was just mentioned (LOK_ADMIN). An administrator is uniquely identified by a sequence identifier (Admin_Seq_Id), and contains a name (Name), a string of its public key (Public_Key), a string of its key agreement (Key_Agreement), creation date and time (Creation_Date), a string containing the name of who created the entry (Created_By), the data and time of the last update (Last_Update_Date), as well as a string containing who made the last update (Last_Update_By). The next entity of concern is that of a group member, which is very similar to the group administrator except that a group can have any number of members and only one administrator. All group member entries are 115
stored in the LOK_MEMBER table, and consist of a unique member identifier Member_Seq_Id, a name (Name), public key (Public_Key), key agreement (Key_Agreement), date and time of creation (Creation_Date), string containing the creator (Created_By), date and time of the last update (Last_Update_Date), and the a string containing the name of who performed the last update (Last_Update_By). The last entity that needs to be represented in the Loki Group Data Store is that of an exertion. Every exertion that is inherent to a group is stored in the Data Store in the LOK_EXERTION table. The exertion entry consists of a unique sequence identifier (Exertion_Seq_Id), a name (Name), type (Type), creation date and time (Creation_Date), a string containing the name of who created the entry (Created_By), the data and time of the last update (Last_Update_Date), as well as a string containing who made the last update (Last_Update_By). In order to represent the relationship that every exertion can only belong to one group every exertion entry in the Data Store also contains the key of the group to which it is a member of (Group_Seq_Id) which is a reference to the LOK_GROUP table.
The next thing to discuss is that of the two relationships being, membership and execution of actions on exertions. These are critical because they are N to N relationships, or relationships that can involve entities multiple times on both sides of the relationship. First lets discuss membership. The membership relationship is tying
116
members to a group. Since a member can be a member of many groups, and every group can have more than one member, a new table needs to be created. This table is named LOK_MEMBERSHIP and contains the key of the group to which the membership entry involves (Group_Seq_Id), and the key of the member involved in the membership (Member_Seq_Id). The next relationship to discuss is that of the execution of actions on exertions. This is more complicated because it can be represented in several different ways. The initial design involved the creation of the LOK_ACTION table. This table was uniquely identified by a members key (Member_Seq_Id), and an exertions key (Exertion_Seq_Id). It also stored information in the table for the type of action being represented (Type), the date and time the action was performed and created (Creation_Date), as well as comments tied to the action (Comment). This is shown in the following diagram.
117
Diagram 18: : LOKI Group Data Store v0.1
Although this does represent the relationship of performing actions on exertions, it has several problems. The first of which is that this restricts the ability of members to perform more than one action on a given exertion, which is something that could create serious problems in the execution of the framework. This is d due ue to the fact that a
118
LOK_ACTION entry is uniquely identified by a member key, an exertion key and nothing else. A possible solution to this is to add the Creation_Date value to the key, which would allow members to perform more than one action on a given exertion as long as it was not at the same exact time and date. Although this is a valid solution, there are still problems with this design as well. In order to increase cohesion it is important to separate the action information from the information about the relationship. The relationship is actually a three way relationship between that of a member, an exertion, and an activity. The activity is the instance of an action. The activity information is stored in a table named LOK_ACTIVITY, which contains a unique sequence identifier (Activity_Seq_Id), the action being performed (Action), the date and time of execution and creation (Creation_Date), and an optional comment (Comment). The relationship is stored in a table entitled LOK_EXECUTION, which consists of the activity instance key, the member key, and the execution key. This design not only allows us to have the plurality that we need for full functionality, but it aids in the logic and cohesion of the framework design. Another issue with this design is the repetitive storage of Administrative information. Even though Administrators have separate abilities than standard group members, they can potentially be both and administrator of one group and a member of another. This creates the possibility for data corruption, seeing as information can change and only one of the entry would be changed. This is solved by making the LOK_GROUP ADMIN_SEQ_ID point to the member that is its administrator
119
rather than a separate Administrator object, thus reducing the pos possible sible data corruption out of the database.
Diagram 19: LOKI Group Data Store v0.2
120
User Interfaces
The group user interface is responsible for the monitoring and viewing of group actions, as describes in the worker use cases. It is publically accessible, but will only show the information for the groups to which the accessing member belongs. It organizes the information in a tree pane on the left hand side of the viewable area with groups at the highest level, and reads, writes, and takes to the group space in the next level. The last viewable level is the individual instances of each interaction with the space. The group instances, as well as the read, take and write instances are selectable and once selected will display the information about the instance on the right hand side of the viewable area. It will be updated upon launching the agent, but in the future could display real time information about the group. As shown in the image below, the Loki Group User Agent is launched and viewable in the IncaX Service Browser, and is published by the Loki Group Manager which handles the actions performed in the agent.
121
Diagram 20: Loki Group User Agent Group Display
122
Diagram 21: Loki Group User Agent Take Display
123
Diagram 22: Loki Group User Agent Write Display
The admin user interface is responsible for the administration of group actions and members, as shown in the administrative use cases. It organizes the information in a tree pane on the left hand side of the viewable area with groups at the highest level, and members, and exertions to the group space in the next level. The last viewable level is the individual instances of a member or exertion within the space. The group instances, as well as the member and exertion instances are selectable and once selected will display the information about the instance on the right hand side of the
124
viewable area. It is different from the Group User Agent because of the information displayed and the ability to delete any of the selectable items. This functionality is simply introduced by a delete button in the lower left hand side of the viewable area, which is enabled whenever possible. It will be updated upon launching the agent, but in the future could display real time information about the group. As shown in the image below, the Loki Admin User Agent is launched and viewable in the IncaX Service Browser, and is published by the Loki Group Manager which handles the actions performed in the agent, similar to the Group User Agent.
Diagram 23: Loki Admin User Agent Main Display 125
Diagram 24: Loki Admin User Agent Group Display
126
Diagram 25: Loki Admin User Agent Member Display
127
Diagram 26: Loki Admin User Agent Exertion Display
128
Chapter 5 Validation Test Case

The validation test case was performed in the Texas Tech University Sorcer environment and utilizes SGrid Grider, Caller, FileStorer, and Spacer services. Before adapting Loki to this demo the basic operation started with the SGrid Grider. The Grider application would use the Grider User Interface to gain information on the desired application to execute, arguments, information to be computes, execution information, as well as job information. This information is stored into individual tasks, one for every block of data to be executed. These tasks are stored in a job and passed to the Spacer, where they are broken down and dispatched to the JavaSpace. The Caller service, upon startup, launches SpaceWorker objects that constantly listen to the space for objects that are meant for the provider which launched them. At this point the SpaceWorker objects find the dropped job from the Spacer, take it from the space and begin execution. Once execution is complete, the Caller drops the results back to the space. The spacers results collection thread, waits for these results and retrieves them. The results are then authenticated and authorized and passed back to the Grider, where they are either displayed to the screen or emailed to the job requestor.
129
Figure 8: : SGrid Execution Activity
The difference in the standard execution and the Loki execution starts with the actual launching of the services. Every service in the Sorcer environment is started with a Loki Member Utility object. This means that every service will be given a key pair, a key agreement, and the functionality to perform group activities if they are invited to a group. The SpaceWorker objects are passed this Loki Member Utility object and will analyze each object to check whether or not it is an invitation to a group, or just ju an object to be executed. So referring back to the Grider execution, the job information is passed from the Grider to the Spacer. The spacer then takes this information and sends 130
out invitations to the services required to execute the job information. Each invitation contains the Spacers public key, so that responses can be encrypted specifically for the Spacer to decrypt. The Callers SpaceWorker picks up this object, sees that it is an invitation, removes the Spacers public key, encrypts it key pair with the Spacers public key, adds its own public key object, and drops this response back to the space. The spacer receives all these responses, authorizes and authenticates the responses, and combines the decrypted key pairs in order to calculate all of the complementary compound keys. These complementary compound keys are packaged into an object which is then dropped to the space. The Spacer then begins to encrypt the initial job with the shared key, calculated by the Spacers private key and complementary compound key, and drops this to the space. The Callers SpaceWorker retrieves its complementary compound key from the retrieved complementary compound key space object. The Callers SpaceWorker then retrieves the encrypted initial exertion object from the space and decrypts it with the generated shared key. The SpaceWorker passes it up to the Caller, where it is executed, and results are generated. These results are then encrypted with the group key, and dropped to the space. The spacer picks up the results and decrypts them, and then proceeds to encrypt them with the Griders public key. Once this is complete they are passed to the Grider, via the established proxy, where they are decrypted and either displayed or email to the requestor.
131
Figure 9: : Loki SGrid Execution Activity
As you can see in the previous figure all links of communication are secured in the Loki implementation test case. The Grider to Spacer communication is secured with a two party key agreement. The S Spacer pacer to Caller communication is secured using the Loki group protocol, and scalable key agreement. Lastly the Caller to Spacer communication is secure using the same Loki group creation protocol and scalable key agreement. The received communication from the space is verified by the Authenticator and Authorizer services to ensure the security of the initial invitations.
132
From the user, or requestor level execution of each version looks the same, but under the covers, the Loki execution secures the critical information so that it cannot be viewed or compromised from the space. The following diagrams show the actual execution of the demonstration and explain step by step what is happening.
133
Diagram 27: SGrid User Agent General Display
This image shows the launching of the Grider User Interface and the initial options that are entered into the general panel of the interface.
134
Diagram 28: SGrid User Agent Include Display
This image shows the values entered into the include panel of the Grider User Interface. These values will be used in the execution that will be performed by the Caller service.
135
Diagram 29: SGrid User Agent Execution Display
This image shows the execution panel of the Grider User Interface. This basically outlines the executable that will be used on the input values entered in the previous panel.
136
Diagram 30: SGrid User Agent Context Display
This image shows the context that was created by choosing to submit this job request. This context is placed inside of an exertion that is utilized by the spacer to execute this job via the space. Once submitted from the Grider User Interface in the Loki framework the Spacer will spark the group creation protocol, and encrypt the context shown above. The Caller will utilize the groups shared key to decrypt the exertion, execute drop the encrypted results.
137
Diagram 31: SGrid User Agent Results Display
This image shows the return of the encrypted results from the Caller. The Caller encrypted the results with the group key, dropped the results to the space, where they were picked up by the Spacer. The Spacer decrypts the results with the group key, encrypts them with the Griders public key, then utilizing the established proxy returns the results. It is here that the Grider decrypts the results with its private key, and displays them.
138
Verification, Validation and Accreditation

In order to prove that the Loki Framework solves the problem of securing an ad hoc public space computing environment, the solution is compared to the Sargent circle to ensure data validity. The universal modeling language use case models are the problem entity of the framework, and outline all requirements of the framework. The conceptual model of the framework consists of the remaining models in the universal modeling language, which are derived in the analysis and modeling phase of development. In order to ensure conceptual model validity the use case models are compared to the component models and interaction models. If this portion of the Sargent circle is satisfied, than the next portion of verification is that of computerized model verification. This is done by completing the programming and implementation and comparing it to the component and interaction models, to ensure that they coincide. If they do coincide then computerized model verification is complete and the only portion of the Sargent circle left to be completed is the operational validity. Operational validity is achieved by comparing the core implementation to the use case models, to make sure that all of the original requirements have been successfully completed in the final implementation. If all three parts of the Sargent circle are completed and hold than data validity has been successfully achieved.
139
Figure 10: : Sargent's Circle (Sargent n.d.)
The Loki Framework utilizes the Sargent circle for proof by using the use case models for problem entity, the component models as the conceptual model, and lastly the SGrid implementation as the computerized model. Throughout the development of requirements, s, models, and implementation these three core objects have been compared and checked against one another to ensure that the solution still holds to be 140
valid. The final implementation secures the public ad hoc space computing environment, is member independent, scalable, and secure thusly meeting all the requirements specified by the use case models ensuring data validity.
141
Chapter 6 Conclusion
Upon successful implementation of the Loki framework, the implementation is compared to the modeling laid out in the universal modeling language diagrams. The solution is shown to be valid and therefore successfully achieves the objectives of the framework.
The first objective was to secure the inherently public space computing environment. Through the implementation it has been shown that the Loki framework successfully secures the SGrid execution environment. The encryption and decryption of objects with a securely created shared key, before any object reaches the space ensures that if objects are to stay secure.
The second objective is to maintain security in the ad hoc space computing environment. The creation of the group key accounts for the ad hoc nature of the system. The key is created and members who belong to the group can come and go, but will not be given access to the group if they establish new group characteristics like name, key, and agreement. The key agreement that is created in the framework is scalable to any number of party members, which satisfies the third objective; abstract the complexity of the N-ary key policy. 142
As well the Loki implementation provides persistent data storage, management of group services, and is inherently easy to use. The solution also maintains several important architectural characteristics such as availability, modifiability, performance, security, testability, and usability as described earlier.
Although this is the case the solution grows incrementally more complex with increasingly large groups. The framework still holds but the time complexity for groups over 1000 members will grow faster than the benefits of the framework provide. It is for this reason that I must conclude in my conclusion that the framework is complete and practical, but for groups of large amount alternate formations of groups may be explored. Such alternatives may be the concept of recursive groups, where small groups shared key is the key in another larger group. This would dissolve the issue of complex time, but allow for group of near infinite size. Other alternatives may include the replication of the group services.
In conclusion the Loki framework successfully secures the ad hoc space computing environments, with few restrictions. With little further research these few restrictions can be resolved, to produce a powerful and adaptable group key protocol for space computing environments. 143
Chapter 7 Future Work Alternate Scalable Key Agreements

The implementation for the proof case of the Loki framework utilizes Multi Diffie Hellman for its key agreement, in order to create a common shared key without passing any volatile data. Although Multi Diffie Hellman can handle all necessary actions within the Sorcer framework, it runs considerably slow for groups larger than one thousand party members. For this reason it may be required in the future to replace the scalable key agreement. It can easily be replaced because of the service oriented interface based design of the framework. This can be done by creating a class that implements the KeyGenerationManagement interface.
Alternate Group Request Analysis

Another point of future work is adding a component for the analysis of group requests. When a group is first being created it is started by the submission of an exertion to be processed. A component needs to be created that accepts this exertion and from it can analyze it to know what minimum set of group members is necessary for full functionality. To prove concept and to reduce complexity a group creation exertion is communicated initially. This allows us to avoid the analysis component while still maintaining full functionality. The analysis component is considered future work because it would allow for one less step in the communication process, and would also make the framework more cohesive. 144
Multiple Space Model

It may be beneficial to the performance of the framework to do all administrative transactions in a secure space outside of the object space or javaspace. This would allow for the administrative creation protocol to be executed without encryption, thus speeding up the creation time. Once the group is successfully created, the administrative space could be dissolved. To maintain security, this space would have to be secured or private, thus allowing vulnerable objects to be traded securely.
Replicated Group Components

In order to allow for redundancy and fault tolerance the implementation of replicated group services would be a good future addition. This would mean that there would be several group managers and group data stores working collaboratively allowing for recovery if one of them were to fail. Each of the services would also be enabled to replicate itself so that at any time if one failed, a new replicated service would be created instantaneously.
145
TexasTechUniversity,DanielRobertKerr,May2008
Bibliography
Alger,MichaelAngelo."MichaelAlger."ThesisResearch. http://www.cs.ttu.edu/~algerm/Thesis/SGridComponentDiagram.pdf (accessedOctober29,2007). Arnold,Ken,EricFreeman,andSusanneHupfer.JavaSpacesPrinciples,Patterns,and Practice.AddisonWesley,1999. Bishop,Philip,andNigelWarren.JavaSpacesinPractice.AddisonWesley,2003. "BouncyCastleCryptography."BouncyCastleCryptographyLibrary. http://www.bouncycastle.org/docs/docs1.6/index.html(accessedOctober 30,2007). Boyd,Colin,andAnishMathuria.ProtocolsforAuthenticationandKey Establishment.Springer,2003. Burnett,Steve,andStephenPaine.RSASecuritysOfficialGuidetoCryptography. McGrawHill,2001. Buyya,R,ed.HighPerformanceClusterComputing.PrenticeHall,1999. Cadenhead,Rogers.ProgrammingwithJavain24Hours.SamsPublishing,2005. Carriero,Nicholas."CoordinationLanguagesandtheirSignificance." CommunicationsoftheACM.1992. Castelluccia,Claude,HannesHartenstein,ChristofPaar,andDirkWesthoff.Security inAdHocandSensorNetworks.Springer,2005. "ComputationalScience&EngineeringResearchInstitute."MichiganTechComputer Science.www.cs.mtu.edu/~steve/CSERI/(accessedOctober13,2007). Couloris,G,JDollimore,andTKinberg.DistributedSystemsConcepts.4thEdition. AddisonWesley,2001. Davies,Antony.Computationalintermediationandtheevolutionofcomputationasa commodity.Vol.36.Pittsburgh,PA,2004. Dent,AlexanderW.,andChrisJ.Mitchell.CryptographyandStandards.Artech House,2005.
146
Deutsch,Peter.http://today.java.net/jag/Fallacies.html(accessedOctober30, 2007). DiffieHellmanKeyExchange.http://en.wikipedia.org/wiki/DiffieHellman(accessed September23,2007). Foster,I,andCKesselman,.TheGrid:BlueprintforaFutureComputing.Morgan KaufmannPublishers,1999. Garms,Jess,andDanielSomerfield.ProfessionalJavaSecurity.WroxPress,2001. Goel,Sanjay,andMichaelSobolewski."SORCERPublications."TrustandSecurityin EnterpriseGridComputingEnvironment.December2003. http://sorcer.cs.ttu.edu/conferences/2003/cnis/CNIS2003.pdf(accessed October29,2007). Hellman,MartinE."AnOverviewofPublicKeyCryptography."IEEECommunications Magazine,2002:4249. Hook,David.BeginningCryptographywithJava.WileyPublishing,2005. HowtoWriteDocCommentsfortheJavadocTool.2004. http://java.sun.com/j2se/javadoc/writingdoccomments/(accessed December4,2007). IntrotoJini.August25,2006. http://www.jini.org/wiki/Category:Introduction_to_Jini(accessedNovember 18,2007). JavaSECoreAPIDocumentation.2004.http://java.sun.com/j2se/1.5.0/docs/api/ (accessedDecember20,2007). JavaSESecurityDocumentation.2004. http://java.sun.com/j2se/1.5.0/docs/guide/security/. JiniTechnologyStarterKitv2.0.1.2004. http://java.sun.com/products/jini/2.0.1/doc/api/(accessedDecember20, 2007).
147
Kolonay,Raymond,andMichaelSobolewski."SORCERPublications."GridInteractive ServiceOrientedProgramming.July2003. http://sorcer.cs.ttu.edu/publications/papers/giso.pdf(accessedOctober29, 2007). Liao,Lijun.GroupKeyAgreementforAdHocNetworks.Bochum,2005. MalladiVenkata,RaviKiran,AbhijitRai,andMichaelSobolewski."SORCER Publications."SORCER:FederatedGridComputing.June16,2004. http://sorcer.cs.ttu.edu/publications/presentations/SORCERGUG040616.ppt (accessedOctober29,2007). MalladiVenkata,RaviKiran,MichaelSobolewski,andSekharSoorianarayanan. "SORCERPublications."SORCERProth.January2004. http://sorcer.cs.ttu.edu/publications/presentations/prothhpcc.ppt (accessedOctober29,2007). Menezes,VanOorschot,andVanstone.HandbookofAppliedCryptography.CRC Press,1996. Microsystems,Sun.BuildaComputeGridwithJiniTechnology.Sun,2004. Mir,NaderF.ComputerandCommunicationNetworks.PrenticeHall,2007. Nadiminti,Krishna,MarcosDiasdeAssuncao,andRajkumarBuyya."Distributed SystemsandRecentInnovations:ChallengesandBenefits."TheGridbus Project.http://www.gridbus.org/~raj/papers/InfoNetArticle06.pdf(accessed October13,2007). PeertoPeer(P2P)Computing.2006. http://technology.uaa.alaska.edu/News/peer2peer.cfm(accessedOctober 13,2007). ProjectRio.2007.https://rio.dev.java.net/(accessedNovember27,2007). RotemGal_Oz,Arnon."FallaciesofDistributedComputingExplained." RGOArchitects.http://www.rgoarchitects.com/Files/fallacies.pdf(accessed January25,2008). Sargent,RobertG.Verification,Validation,andAccreditationofSimulationModels. EditedbyJ.A.Joines,R.R.Barton,K.KangandP.A.Fishwick.
148
Schwarz,Heinz."SORCERPublications."ServiceOrientedArchitecturesandGrid computingANewGeneration.2005. http://sorcer.cs.ttu.edu/publications/papers/Final_CE05284.pdf(accessed October29,2007). Sobolewski,Michael."AirForceResearchLab."November15,2007. Sobolewski,Michael.FromProgrammingtoArchitectures.Lubbock,Texas, November29,2007. .SecretKeyCryptography.Lubbock,2007. ."SORCERPublications."SORCER.November2002. http://sorcer.cs.ttu.edu/publications/papers/sorcer.pdf(accessedOctober 29,2007). ."SORCERPublications."SORCER:ComputingandMetacomputingIntergrid.April 7,2007.http://sorcer.cs.ttu.edu/publications/papers/sorcerintergrid.pdf (accessedOctober29,2007). ."SORCERPublications."SORCER.March2002. http://sorcer.cs.ttu.edu/publications/papers/2420.pdf(accessedNovember 13,2007). SoftwareArchitectureinPractice,SecondEdition.http://www.softarchpract.tar.hu/ (accessedDecember2,2007). Subramanian,R,andBGoodman,.PeertoPeerComputing:Evolutionofa DisruptiveTechnology.Hershe,PA:IdeaGroupInc.,2005. Tanenbaum,A,andMVanSteen.DistributedSystems:PrinciplesandParadigms. PrenticeHall,2002. Wells,George.CoordinationLanguages:BacktotheFuturewithLinda.Rhodes University. Yao,ChaoHsu.GridComputation:theFastestSupercomputerintheWorld.2006. www.csa.com/discoveryguides/grid/reviewf.php(accessedOctober13, 2007).
149
Appendix A Loki System Interfaces Caller

package sorcer.core; public interface Caller extends Remote { public Context execute(Context context) throws RemoteException; }
150
DatabaseConnector
package sorcer.core.loki.db; /** The database connector intergaface outlines methods for the connection and deconnection to a specified database. In the loki framework this is used by the group manager object to access the group data store object. */ public interface DatabaseConnector { /** * creates a connection and connects * * @return the created connection */ public Connection getConnection(); /** * closes the created connection */ public void closeConnection(); }
151
EncryptionManagement
package sorcer.core.loki.crypt; /** The encryption management interface describes the standard methods for both encryption and decryption. It outlines both block, stream, and threaded pipe cryptography methods, and expands these to allow for both byte array and string data. @author Daniel Kerr */ public interface EncryptionManagement { /** * @param keyAgree the shared key key agreement for the creation of a common cipher */ public void init(KeyAgreement keyAgree); /** * @param plaintext string containing text to be encrypted * @return plaintext encrypted to a byte array */ public byte[] encrypt(String plaintext); /** * @param plaintext byte array containing text to be encrypted * @return plaintext encrypted to a byte array */ public byte[] encrypt(byte[] plaintext); /** * @param in input stream to be encrypted * @param out output stream containing encrypted cipher text */ public void encryptStream(InputStream in, OutputStream out); /** * @param plaintext byte array containing text to be encrypted * @return Reader to the cipher text pipe */ public Reader encryptPipe(byte[] plaintext);
152

/** * @param ciphertext string containing ciphertext to be decrypted * @return ciphertext decrypted to a byte array */ public byte[] decrypt(String ciphertext); /** * @param ciphertext byte array containing ciphertext to be decrypted * @return ciphertext decrypted to a byte array */ public byte[] decrypt(byte[] ciphertext); /** * @param in input stream to be decrypted * @param out output stream containing decrypted plain text */ public void decryptStream(InputStream in, OutputStream out); /** * @param ciphertext byte array containing ciphertext to be decrypted * @return Reader to the plain text pipe */ public Reader decryptPipe(byte[] ciphertext); }
153
FileStorer
package sorcer.core; /** The file store interface to access remote directories. */ public interface FileStorer { /** * Returns a document descriptor initialized for file read * operations. * * @param desc an initial document descriptor * @return a document descriptor initialized for read operations * @throws RemoteException * @throws IOException * @throws InvalidTransactionException */ public DocumentDescriptor getInputDescriptor(DocumentDescriptor desc) throws RemoteException, IOException, InvalidTransactionException; /** * Returns a document descriptor intialized for file appending * operations. * * @param desc an initial document descriptor * @return a document descriptor initialized for append operations * @throws RemoteException * @throws IOException * @throws InvalidTransactionException */ public DocumentDescriptor getAppendDescriptor(DocumentDescriptor desc) throws RemoteException, IOException, InvalidTransactionException;
154

/** * Returns a document descriptor intialized for file writing * operations. * * @param desc an initial document descriptor * @return a document descriptor initialized for write operation * @throws RemoteException * @throws IOException * @throws InvalidTransactionException */ public DocumentDescriptor getOutputDescriptor(DocumentDescriptor desc) throws RemoteException, IOException, InvalidTransactionException; /** * Lists all directories available on the file store. * The format is: * * # is the path separator * / is the separator between entries */ public String getDirectories(DocumentDescriptor docDesc) throws RemoteException, IOException; /** * * * * * * Returns the content of a directory. The components are separeted with a /. Only files and no directories are listed.
@param desc DocumentDescriptor. FolderPath and Principal are user. FolderPath uses # as a Path separator. * @return * @throws RemoteException * @throws IOException */ public String getDirectoryContent(DocumentDescriptor desc) throws RemoteException, IOException; public String listDirectories(DocumentDescriptor desc)
155

throws RemoteException, IOException; }
156
Grider
package sorcer.core; public interface Grider extends Remote { }
157
GroupManagement
package sorcer.core.loki.group; /** The group management interface lays the interface for database interaction, wrapping context passing to send and retrieve information to the database @author Daniel Kerr */ public interface GroupManagement extends Remote, RemotePartner { /** * get the provider identification information * * @param context information context * @return results context */ public Context getProviderID (Context context) throws RemoteException; /** * execute update * * @param context information context * @return results context */ public Context executeUpdate(Context context) throws RemoteException; /** * execute query * * @param context information context * @return results context */ public Context executeQuery(Context context) throws RemoteException; /** * add activity entry * * @param context information context * @return results context
158

*/ public Context addActivityEntry(Context context) throws RemoteException; /** * add exectuion entry * * @param context information context * @return results context */ public Context addExecutionEntry(Context context) throws RemoteException; /** * add exertion entry * * @param context information context * @return results context */ public Context addExertionEntry(Context context) throws RemoteException; /** * add group entry * * @param context information context * @return results context */ public Context addGroupEntry(Context context) throws RemoteException; /** * add member entry * * @param context information context * @return results context */ public Context addMemberEntry(Context context) throws RemoteException; /** * add membership entry * * @param context information context
159

* @return results context */ public Context addMembershipEntry(Context context) throws RemoteException; /** * get all groups * * @param context information context * @return results context */ public Context getGroups(Context context) throws RemoteException; /** * get group exertions * * @param context information context * @return results context */ public Context getGroupExertions(Context context) throws RemoteException; /** * get group members * * @param context information context * @return results context */ public Context getGroupMembers(Context context) throws RemoteException; /** * get group action * * @param context information context * @return results context */ public Context getGroupAction(Context context) throws RemoteException; /** * get action info *
160

* @param context information context * @return results context */ public Context getActionInfo(Context context) throws RemoteException; /** * get activity entry * * @param context information context * @return results context */ public Context getActivityEntry(Context context) throws RemoteException; /** * get exertion entry * * @param context information context * @return results context */ public Context getExertionEntry(Context context) throws RemoteException; /** * get group entry * * @param context information context * @return results context */ public Context getGroupEntry(Context context) throws RemoteException; /** * get member entry * * @param context information context * @return results context */ public Context getMemberEntry(Context context) throws RemoteException; /**
161

* get all activities * * @param context information context * @return results context */ public Context getActivities(Context context) throws RemoteException; /** * get all executions * * @param context information context * @return results context */ public Context getExecutions(Context context) throws RemoteException; /** * get all exertions * * @param context information context * @return results context */ public Context getExertions(Context context) throws RemoteException; /** * get all members * * @param context information context * @return results context */ public Context getMembers(Context context) throws RemoteException; /** * get all memberships * * @param context information context * @return results context */ public Context getMemberships(Context context) throws RemoteException;
162

}
163
KeyGenerationManagement
package sorcer.core.loki.key; /** The Key Generation Management provides the interface for both key and key agreement generation, as well as the framework specific implementation of the complimentary compound key and the shared key object. @author Daniel Kerr */ public interface KeyGenerationManagement { /** * Generate key pair * * @return the generated key pair * @throws InvalidAlgorithmParameterException * @throws NoSuchAlgorithmException * @see InvalidAlgorithmParameterException, NoSuchAlgorithmException */ public KeyPair genKeyPair() throws InvalidAlgorithmParameterException, NoSuchAlgorithmException; /** * Generate key agreement * * @param myKP the previously generated key pair * @return generated key agreement * @throws InvalidKeyException * @throws NoSuchAlgorithmException * @see InvalidKeyException, NoSuchAlgorithmException */ public KeyAgreement genKeyAgreement(KeyPair myKP) throws InvalidKeyException, NoSuchAlgorithmException; /** * Generate complimentary compound keys * * @param agrees
164

* @param pairs * @return * @throws InvalidKeyException; * @see InvalidKeyException; */ public Map<String,Key> genCompoundKeys( String[] ids, KeyPair[] pairs) throws InvalidKeyException, NoSuchAlgorithmException; public Map<String,Key> genCompoundKeys( Vector<String> ids, Vector<KeyPair> pairs) throws InvalidKeyException, NoSuchAlgorithmException; /** * Generate shared key based on the complimentary compound key * * @param agree * @param compKey * @return * @throws InvalidKeyException * @see InvalidKeyException */ public KeyAgreement genSharedKey(KeyAgreement agree,Key compKey) throws InvalidKeyException; }
165
Spacer
package sorcer.service; /** SORCER also extends task/job execution abilities through the use of a space rendezvous service implementing the Spacer interface. The Spacer service can drop an exertion into a shared object space implemented in SORCER using JavaSpace in which several providers can retrieve relevant exertions from the object space, execute them, and return the results back to the object space. */ public interface Spacer extends Servicer { }
166
Appendix B Loki API Specification Class sorcer.loki.admin.ui.LokiAdminUI

java.lang.Object java.awt.Component java.awt.Container javax.swing.JComponent javax.swing.JPanel sorcer.loki.admin.ui.LokiAdminUI
All Implemented Interfaces: java.awt.image.ImageObserver, java.awt.MenuContainer, java.io.Serializable, javax.accessibility.Accessible, sorcer.core.SORCER
public class LokiAdminUI extends javax.swing.JPanel implements sorcer.core.SORCER
The Administrative User Interface is the accessible agent for the expanded functionality of the administrator in a group. The administrator is able to delete a worker from a group, delete an exertion from a group, and delete a group itself. In addition the adminstrator is able to browse the group, members, and exertions See Also: Serialized Form
Nested Class Summary
Nested classes/interfaces inherited from class javax.swing.JPanel
167

javax.swing.JPanel.AccessibleJPanel
Nested classes/interfaces inherited from class javax.swing.JComponent

javax.swing.JComponent.AccessibleJComponent
Nested classes/interfaces inherited from class java.awt.Container

java.awt.Container.AccessibleAWTContainer
Nested classes/interfaces inherited from class java.awt.Component

java.awt.Component.AccessibleAWTComponent, java.awt.Component.BltBufferStrategy, java.awt.Component.FlipBufferStrategy
Field Summary
private GroupManagement gm_mgt
group manager
private item net.jini.core.lookup.ServiceItem
service item
private logger static java.util.logging.Logger class logger
168

private javax.swing.JButton myButton
private myModel javax.swing.tree.DefaultTreeModel javax.swing.JPanel myPanel
private
private
javax.swing.JSeparator mySeparator
private
javax.swing.JSplitPane mySplitPane
private
javax.swing.JLabel myStatusLabel
private
javax.swing.JToolBar myToolBar
private
javax.swing.JTextPane myTPane
private
javax.swing.JScrollPane myTPaneSPane
private
javax.swing.JTree myTree
private
javax.swing.JScrollPane myTreeSPane
Fields inherited from class javax.swing.JComponent

accessibleContext, listenerList, TOOL_TIP_TEXT_KEY, ui,
169

UNDEFINED_CONDITION, WHEN_ANCESTOR_OF_FOCUSED_COMPONENT, WHEN_FOCUSED, WHEN_IN_FOCUSED_WINDOW
Fields inherited from class java.awt.Component

BOTTOM_ALIGNMENT, CENTER_ALIGNMENT, LEFT_ALIGNMENT, RIGHT_ALIGNMENT, TOP_ALIGNMENT
Fields inherited from interface sorcer.core.SORCER

ADD_DATANODE, ADD_DOMAIN, ADD_JOB_TO_SESSION, ADD_LEAFNODE, ADD_SUBDOMAIN, ADD_TASK, ADD_TASK_TO_JOB_SAVEAS, ADD_TASK_TO_JOB_SAVEAS_RUNTIME, ANY, APPEND, APS, AS_PROPS, AS_SESSION, ATTRIBUTE_MODIFIED, BGCOLOR, BROKEN_LINK, C_DECREMENT, C_INCREMENT, CATALOG_CONTENT, CATALOGER_EVENT, CLEANUP_SESSION, Command, CONTEXT_ATTRIBUTE_VALUES, CONTEXT_ATTRIBUTES, CONTEXT_RESULT, CPS, CREATION_TIME, DATANODE_FLAG, DELETE_CONTEXT_EVT, DELETE_JOB_EVT, DELETE_NOTIFICATIONS, DELETE_SESSION, DELETE_TASK, DELETE_TASK_EVT, DROP_EXERTION, EXCEPTION_IND, EXCEPTIONS, EXERTION_PROVIDER, FALSE, GET, GET_CONTEXT, GET_CONTEXT_NAMES, GET_FT, GET_JOB, GET_JOB_NAME_BY_JOB_ID, GET_JOBDOMAIN, GET_JOBNAMES, GET_NEW_SERVLET_MESSAGES, GET_NOTIFICATIONS_FOR_SESSION, GET_RUNTIME_JOB, GET_RUNTIME_JOBNAMES, GET_SESSIONS_FOR_USER, GET_TASK, GET_TASK_NAME_BY_TASK_ID, GET_TASK_NAMES, GETALL_DOMAIN_SUB, IGRID_HOME, IN_FILE, IN_PATH, IN_SCRIPT, IN_VALUE, IND, IS_NEW, J_DATA_DIR, J_DATA_ROOT_DIR, J_DATA_SERVER, J_DATA_SERVER_PORT, J_DELAY_TIME, J_DESCRIPTION, J_GROUPS, J_ICON_NAME, J_INTERFACE_ONLY, J_INTERFACES, J_LOCATION, J_LOCATORS, J_MONITORABLE, J_NOTIFIABLE, J_POOL_SIZE, J_PORTAL_HOST, J_PORTAL_PORT, J_PROVIDER_JINIFIED, J_PROVIDER_NAME, J_PROVIDR_HOST, J_PROXY_CLASS, J_SERVICE_ID_PERSISTENT, J_SPACE_ENABLED, J_SPACE_GROUPS, J_TEMPLATE_MATCH, J_WEBSTER, J_WEBSTER_PORT, J_WORKER_TRANSACTION_LEASE_TIME, J_WORKERS_MAX, J_WORKERS_TRANSACTIONAL, JOB_ID, JOB_NAME, JOB_STATE, JOB_TASK, LOOKUP_CACHE_ENABLED, LOOKUP_MAX_MATCHES, LOOKUP_MIN_MATCHES, LOOKUP_WAIT, MAIL_SEP, MAX_LOOKUP_WAIT, MAX_PRIORITY, META_MODIFIED, MIN_PRIORITY, MODIFY_LEAFNODE, MSG_CONTENT, MSG_ID, MSG_SOURCE, MSG_TYPE, MULTICAST_ENABLED, NEW_CONTEXT_EVT, NEW_JOB_EVT,
170

NEW_TASK_EVT, NONE, NORMAL_PRIORITY, NOTIFY_EXCEPTION, NOTIFY_FAILURE, NOTIFY_INFORMATION, NOTIFY_WARNING, NOTRUNTIME, NULL, OBJECT_DOMAIN, OBJECT_NAME, OBJECT_OWNER, OBJECT_SCOPE, OBJECT_SUBDOMAIN, Order, OUT_COMMENT, OUT_FILE, OUT_PATH, OUT_SCRIPT, OUT_VALUE, P_DATA_DIR, P_DATA_ROOT_DIR, P_DATA_SERVER, P_DATA_SERVER_PORT, P_DELAY_TIME, P_DESCRIPTION, P_GROUPS, P_ICON_NAME, P_INTERFACE_ONLY, P_INTERFACES, P_LOCATION, P_LOCATORS, P_MONITORABLE, P_NOTIFIABLE, P_POOL_SIZE, P_PORTAL_HOST, P_PORTAL_PORT, P_PROVIDER_CONFIG, P_PROVIDER_JINIFIED, P_PROVIDER_NAME, P_PROVIDR_HOST, P_PROXY_CLASS, P_SERVICE_ID_PERSISTENT, P_SPACE_ENABLED, P_SPACE_GROUPS, P_TEMPLATE_MATCH, P_UNDEFINED, P_WEBSTER, P_WEBSTER_PORT, P_WORKER_TRANSACTION_LEASE_TIME, P_WORKERS_MAX, P_WORKERS_TRANSACTIONAL, PERSIST_CONTEXT, PERSIST_JOB, PERSIST_SORCER_NAME, PERSIST_SORCER_TYPES, PERSISTENCE_EVENT, POSTPROCESS, PREPROCESS, PRIVATE, PRIVATE_SCOPE, PROCESS, PROVIDER, PROVIDER_CONTEXT, PUBLIC_SCOPE, REGISTER_FOR_NOTIFICATIONS, REMOVE_CONTEXT, REMOVE_DATANODE, REMOVE_JOB, REMOVE_TASK, RENAME_CONTEXT, RENAME_SORCER_NAME, RESUME_JOB, RUNTIME, S_CATALOGER_NAME, S_COMMANDER_NAME, S_COMMUNITY, S_DEFAULT_COMMUNITY, S_ENV_FIENAME, S_HOME, S_IS_DB_ORACLE, S_JOBBER_NAME, S_LOCALHOST, S_PERSISTER_IS_DB_TYPE, S_PERSISTER_NAME, S_RMI_HOST, S_RMI_PORT, S_SERVICE_ACCESSOR_PROVIDER_NAME, S_SERVICE_ID_FILENAME, SAPPEND, SAVE_TASK_AS, SAVEJOB_AS, SAVEJOB_AS_RUNTIME, SCRATCH_CONTEXTIDS, SCRATCH_JOBEXERTIONIDS, SCRATCH_METHODIDS, SCRATCH_TASKEXERTIONIDS, Script, SCRIPT, SELECT, SELF, SERVICE_EXERTION, SOC_BOOLEAN, SOC_CONTEXT_LINK, SOC_DATANODE, SOC_DB_OBJECT, SOC_DOUBLE, SOC_FLOAT, SOC_INTEGER, SOC_LONG, SOC_PRIMITIVE, SOC_SERIALIZABLE, SOC_STRING, SORCER_FOOTER, SORCER_HEADER, SORCER_HOME, SORCER_INTRO, SORCER_TMP_DIR, SPOSTPROCESS, SPREPROCESS, SPROCESS, STEP_JOB, STOP_JOB, STOP_TASK, SUBCONTEXT_CONTROL_CONTEXT_STR, SUSPEND_JOB, SYSTEM_SCOPE, TABLE_NAME, TASK_COMMAND, TASK_ID, TASK_JOB, TASK_NAME, TASK_PROVIDER, TASK_SCRIPT, TRUE, UPDATE_CONTEXT, UPDATE_CONTEXT_EVT, UPDATE_DATANODE, UPDATE_EXERTION, UPDATE_JOB, UPDATE_JOB_EVT, UPDATE_TASK, UPDATE_TASK_EVT, VALUE
Fields inherited from interface java.awt.image.ImageObserver

ABORT, ALLBITS, ERROR, FRAMEBITS, HEIGHT, PROPERTIES, SOMEBITS, WIDTH
171
Constructor Summary
LokiAdminUI(java.lang.Object obj)
Class Constructor
Method Summary
private void createUI()
The function to create the user interface components and tie them to the neccesary listeners for data manipulation.
private getSelectedNode() javax.swing.tree.DefaultMutableT reeNode private getTree() javax.swing.tree.DefaultMutableT Creates the tree to be viewed in the reeNode
user interface by requesting the neccesary information from the publisher, the Group Manager
static net.jini.lookup.entry.UIDe getUIDescriptor() scriptor java.lang.String listDB()
private
Test function to debug the contents of the Group Data Store

private java.lang.String showExertionInfo(java.lang.String nod estring)
returns the information from the selected exertion string
172

private java.lang.String showGroupInfo(java.lang.String nodest ring)
returns the group information based on the selected node string

private java.lang.String showMemberInfo(java.lang.String nodes tring)
returns the information from the selected member node
Methods inherited from class javax.swing.JPanel

getAccessibleContext, getUI, getUIClassID, paramString, setUI, updateUI
Methods inherited from class javax.swing.JComponent

addAncestorListener, addNotify, addVetoableChangeListener, computeVisibleRect, contains, createToolTip, disable, enable, firePropertyChange, firePropertyChange, firePropertyChange, fireVetoableChange, getActionForKeyStroke, getActionMap, getAlignmentX, getAlignmentY, getAncestorListeners, getAutoscrolls, getBorder, getBounds, getClientProperty, getComponentGraphics, getComponentPopupMenu, getConditionForKeyStroke, getDebugGraphicsOptions, getDefaultLocale, getFontMetrics, getGraphics, getHeight, getInheritsPopupMenu, getInputMap, getInputMap, getInputVerifier, getInsets, getInsets, getListeners, getLocation, getMaximumSize, getMinimumSize, getNextFocusableComponent, getPopupLocation, getPreferredSize, getRegisteredKeyStrokes, getRootPane, getSize, getToolTipLocation, getToolTipText, getToolTipText, getTopLevelAncestor, getTransferHandler, getVerifyInputWhenFocusTarget, getVetoableChangeListeners, getVisibleRect, getWidth, getX, getY, grabFocus, isDoubleBuffered, isLightweightComponent, isManagingFocus, isOpaque, isOptimizedDrawingEnabled, isPaintingTile, isRequestFocusEnabled, isValidateRoot, paint, paintBorder, paintChildren, paintComponent, paintImmediately, paintImmediately, print, printAll, printBorder,
173

printChildren, printComponent, processComponentKeyEvent, processKeyBinding, processKeyEvent, processMouseEvent, processMouseMotionEvent, putClientProperty, registerKeyboardAction, registerKeyboardAction, removeAncestorListener, removeNotify, removeVetoableChangeListener, repaint, repaint, requestDefaultFocus, requestFocus, requestFocus, requestFocusInWindow, requestFocusInWindow, resetKeyboardActions, reshape, revalidate, scrollRectToVisible, setActionMap, setAlignmentX, setAlignmentY, setAutoscrolls, setBackground, setBorder, setComponentPopupMenu, setDebugGraphicsOptions, setDefaultLocale, setDoubleBuffered, setEnabled, setFocusTraversalKeys, setFont, setForeground, setInheritsPopupMenu, setInputMap, setInputVerifier, setMaximumSize, setMinimumSize, setNextFocusableComponent, setOpaque, setPreferredSize, setRequestFocusEnabled, setToolTipText, setTransferHandler, setUI, setVerifyInputWhenFocusTarget, setVisible, unregisterKeyboardAction, update
Methods inherited from class java.awt.Container

add, add, add, add, add, addContainerListener, addImpl, addPropertyChangeListener, addPropertyChangeListener, applyComponentOrientation, areFocusTraversalKeysSet, countComponents, deliverEvent, doLayout, findComponentAt, findComponentAt, getComponent, getComponentAt, getComponentAt, getComponentCount, getComponents, getComponentZOrder, getContainerListeners, getFocusTraversalKeys, getFocusTraversalPolicy, getLayout, getMousePosition, insets, invalidate, isAncestorOf, isFocusCycleRoot, isFocusCycleRoot, isFocusTraversalPolicyProvider, isFocusTraversalPolicySet, layout, list, list, locate, minimumSize, paintComponents, preferredSize, printComponents, processContainerEvent, processEvent, remove, remove, removeAll, removeContainerListener, setComponentZOrder, setFocusCycleRoot, setFocusTraversalPolicy, setFocusTraversalPolicyProvider, setLayout, transferFocusBackward, transferFocusDownCycle, validate, validateTree
Methods inherited from class java.awt.Component

action, add, addComponentListener, addFocusListener,
174

addHierarchyBoundsListener, addHierarchyListener, addInputMethodListener, addKeyListener, addMouseListener, addMouseMotionListener, addMouseWheelListener, bounds, checkImage, checkImage, coalesceEvents, contains, createImage, createImage, createVolatileImage, createVolatileImage, disableEvents, dispatchEvent, enable, enableEvents, enableInputMethods, firePropertyChange, firePropertyChange, firePropertyChange, firePropertyChange, firePropertyChange, firePropertyChange, getBackground, getBounds, getColorModel, getComponentListeners, getComponentOrientation, getCursor, getDropTarget, getFocusCycleRootAncestor, getFocusListeners, getFocusTraversalKeysEnabled, getFont, getForeground, getGraphicsConfiguration, getHierarchyBoundsListeners, getHierarchyListeners, getIgnoreRepaint, getInputContext, getInputMethodListeners, getInputMethodRequests, getKeyListeners, getLocale, getLocation, getLocationOnScreen, getMouseListeners, getMouseMotionListeners, getMousePosition, getMouseWheelListeners, getName, getParent, getPeer, getPropertyChangeListeners, getPropertyChangeListeners, getSize, getToolkit, getTreeLock, gotFocus, handleEvent, hasFocus, hide, imageUpdate, inside, isBackgroundSet, isCursorSet, isDisplayable, isEnabled, isFocusable, isFocusOwner, isFocusTraversable, isFontSet, isForegroundSet, isLightweight, isMaximumSizeSet, isMinimumSizeSet, isPreferredSizeSet, isShowing, isValid, isVisible, keyDown, keyUp, list, list, list, location, lostFocus, mouseDown, mouseDrag, mouseEnter, mouseExit, mouseMove, mouseUp, move, nextFocus, paintAll, postEvent, prepareImage, prepareImage, processComponentEvent, processFocusEvent, processHierarchyBoundsEvent, processHierarchyEvent, processInputMethodEvent, processMouseWheelEvent, remove, removeComponentListener, removeFocusListener, removeHierarchyBoundsListener, removeHierarchyListener, removeInputMethodListener, removeKeyListener, removeMouseListener, removeMouseMotionListener, removeMouseWheelListener, removePropertyChangeListener, removePropertyChangeListener, repaint, repaint, repaint, resize, resize, setBounds, setBounds, setComponentOrientation, setCursor, setDropTarget, setFocusable, setFocusTraversalKeysEnabled, setIgnoreRepaint, setLocale, setLocation, setLocation, setName, setSize, setSize, show, show, size, toString, transferFocus, transferFocusUpCycle
Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait,
175

wait, wait
Field Detail
gm_mgt
group manager
item
private net.jini.core.lookup.ServiceItem item
service item
logger
private static final java.util.logging.Logger logger
class logger
myButton
private javax.swing.JButton myButton
myModel
private javax.swing.tree.DefaultTreeModel myModel
myPanel
private javax.swing.JPanel myPanel
176
mySeparator
private javax.swing.JSeparator mySeparator
mySplitPane
private javax.swing.JSplitPane mySplitPane
myStatusLabel
private javax.swing.JLabel myStatusLabel
myToolBar
private javax.swing.JToolBar myToolBar
myTPane
private javax.swing.JTextPane myTPane
myTPaneSPane
private javax.swing.JScrollPane myTPaneSPane
myTree
private javax.swing.JTree myTree
myTreeSPane
private javax.swing.JScrollPane myTreeSPane
Constructor Detail
LokiAdminUI
public LokiAdminUI(java.lang.Object obj)
177
Class Constructor Parameters:

obj - the service item object passed in invocation
Method Detail
createUI
getSelectedNode
private javax.swing.tree.DefaultMutableTreeNode getSelectedNode()
Returns: the selected DefaultMutableTreeNode from the tree pane See Also:
DefaultMutableTreeNode
getTree
private javax.swing.tree.DefaultMutableTreeNode getTree()
Creates the tree to be viewed in the user interface by requesting the neccesary information from the publisher, the Group Manager Returns: the root of the created tree See Also:
DefaultMutableTreeNode, GroupManager
getUIDescriptor
public static net.jini.lookup.entry.UIDescriptor getUIDescriptor()
178
Returns: the descriptor for the user interface See Also:

UIDescriptor
listDB
private java.lang.String listDB()
Test function to debug the contents of the Group Data Store Returns: the string value of the database contents See Also:
Image
showExertionInfo
private java.lang.String showExertionInfo(java.lang.String nodestring)
returns the information from the selected exertion string Parameters:

nodestring - name of selected exertion node
Returns: information in string form
showGroupInfo
private java.lang.String showGroupInfo(java.lang.String nodestring)
returns the group information based on the selected node string Parameters:
nodestring - name of selected group node
Returns: information in string form 179
showMemberInfo
private java.lang.String showMemberInfo(java.lang.String nodestring)
returns the information from the selected member node Parameters:

nodestring - name of selected member node
180
Class sorcer.loki.group.ui.LokiGroupUI
java.lang.Object java.awt.Component java.awt.Container javax.swing.JComponent javax.swing.JPanel sorcer.loki.group.ui.LokiGroupUI
All Implemented Interfaces: java.awt.image.ImageObserver, java.awt.MenuContainer, java.io.Serializable, javax.accessibility.Accessible, sorcer.core.SORCER
public class LokiGroupUI extends javax.swing.JPanel implements sorcer.core.SORCER
The Group User Interface is the read only agent for all members in a group. It allows a member to browse reads, writes, and takes to group to which they belong. See Also: Serialized Form
Nested classes/interfaces inherited from class javax.swing.JPanel

javax.swing.JPanel.AccessibleJPanel
Nested classes/interfaces inherited from class javax.swing.JComponent

javax.swing.JComponent.AccessibleJComponent
181
Nested classes/interfaces inherited from class java.awt.Container

java.awt.Container.AccessibleAWTContainer
Nested classes/interfaces inherited from class java.awt.Component

java.awt.Component.AccessibleAWTComponent, java.awt.Component.BltBufferStrategy, java.awt.Component.FlipBufferStrategy
Field Summary
group manger
private item net.jini.core.lookup.ServiceItem
service item
private logger static java.util.logging.Logger class logger private myModel javax.swing.tree.DefaultTreeModel javax.swing.JSplitPane mySplitPane
private
private
javax.swing.JLabel myStatusLabel
182

private
javax.swing.JTextPane myTPane
private
javax.swing.JScrollPane myTPaneSPane
private
javax.swing.JTree myTree
private
javax.swing.JScrollPane myTreeSPane
Fields inherited from class javax.swing.JComponent

accessibleContext, listenerList, TOOL_TIP_TEXT_KEY, ui, UNDEFINED_CONDITION, WHEN_ANCESTOR_OF_FOCUSED_COMPONENT, WHEN_FOCUSED, WHEN_IN_FOCUSED_WINDOW
Fields inherited from class java.awt.Component

BOTTOM_ALIGNMENT, CENTER_ALIGNMENT, LEFT_ALIGNMENT, RIGHT_ALIGNMENT, TOP_ALIGNMENT

ADD_DATANODE, ADD_DOMAIN, ADD_JOB_TO_SESSION, ADD_LEAFNODE, ADD_SUBDOMAIN, ADD_TASK, ADD_TASK_TO_JOB_SAVEAS, ADD_TASK_TO_JOB_SAVEAS_RUNTIME, ANY, APPEND, APS, AS_PROPS, AS_SESSION,
183

ATTRIBUTE_MODIFIED, BGCOLOR, BROKEN_LINK, C_DECREMENT, C_INCREMENT, CATALOG_CONTENT, CATALOGER_EVENT, CLEANUP_SESSION, Command, CONTEXT_ATTRIBUTE_VALUES, CONTEXT_ATTRIBUTES, CONTEXT_RESULT, CPS, CREATION_TIME, DATANODE_FLAG, DELETE_CONTEXT_EVT, DELETE_JOB_EVT, DELETE_NOTIFICATIONS, DELETE_SESSION, DELETE_TASK, DELETE_TASK_EVT, DROP_EXERTION, EXCEPTION_IND, EXCEPTIONS, EXERTION_PROVIDER, FALSE, GET, GET_CONTEXT, GET_CONTEXT_NAMES, GET_FT, GET_JOB, GET_JOB_NAME_BY_JOB_ID, GET_JOBDOMAIN, GET_JOBNAMES, GET_NEW_SERVLET_MESSAGES, GET_NOTIFICATIONS_FOR_SESSION, GET_RUNTIME_JOB, GET_RUNTIME_JOBNAMES, GET_SESSIONS_FOR_USER, GET_TASK, GET_TASK_NAME_BY_TASK_ID, GET_TASK_NAMES, GETALL_DOMAIN_SUB, IGRID_HOME, IN_FILE, IN_PATH, IN_SCRIPT, IN_VALUE, IND, IS_NEW, J_DATA_DIR, J_DATA_ROOT_DIR, J_DATA_SERVER, J_DATA_SERVER_PORT, J_DELAY_TIME, J_DESCRIPTION, J_GROUPS, J_ICON_NAME, J_INTERFACE_ONLY, J_INTERFACES, J_LOCATION, J_LOCATORS, J_MONITORABLE, J_NOTIFIABLE, J_POOL_SIZE, J_PORTAL_HOST, J_PORTAL_PORT, J_PROVIDER_JINIFIED, J_PROVIDER_NAME, J_PROVIDR_HOST, J_PROXY_CLASS, J_SERVICE_ID_PERSISTENT, J_SPACE_ENABLED, J_SPACE_GROUPS, J_TEMPLATE_MATCH, J_WEBSTER, J_WEBSTER_PORT, J_WORKER_TRANSACTION_LEASE_TIME, J_WORKERS_MAX, J_WORKERS_TRANSACTIONAL, JOB_ID, JOB_NAME, JOB_STATE, JOB_TASK, LOOKUP_CACHE_ENABLED, LOOKUP_MAX_MATCHES, LOOKUP_MIN_MATCHES, LOOKUP_WAIT, MAIL_SEP, MAX_LOOKUP_WAIT, MAX_PRIORITY, META_MODIFIED, MIN_PRIORITY, MODIFY_LEAFNODE, MSG_CONTENT, MSG_ID, MSG_SOURCE, MSG_TYPE, MULTICAST_ENABLED, NEW_CONTEXT_EVT, NEW_JOB_EVT, NEW_TASK_EVT, NONE, NORMAL_PRIORITY, NOTIFY_EXCEPTION, NOTIFY_FAILURE, NOTIFY_INFORMATION, NOTIFY_WARNING, NOTRUNTIME, NULL, OBJECT_DOMAIN, OBJECT_NAME, OBJECT_OWNER, OBJECT_SCOPE, OBJECT_SUBDOMAIN, Order, OUT_COMMENT, OUT_FILE, OUT_PATH, OUT_SCRIPT, OUT_VALUE, P_DATA_DIR, P_DATA_ROOT_DIR, P_DATA_SERVER, P_DATA_SERVER_PORT, P_DELAY_TIME, P_DESCRIPTION, P_GROUPS, P_ICON_NAME, P_INTERFACE_ONLY, P_INTERFACES, P_LOCATION, P_LOCATORS, P_MONITORABLE, P_NOTIFIABLE, P_POOL_SIZE, P_PORTAL_HOST, P_PORTAL_PORT, P_PROVIDER_CONFIG, P_PROVIDER_JINIFIED, P_PROVIDER_NAME, P_PROVIDR_HOST, P_PROXY_CLASS, P_SERVICE_ID_PERSISTENT, P_SPACE_ENABLED, P_SPACE_GROUPS, P_TEMPLATE_MATCH, P_UNDEFINED, P_WEBSTER, P_WEBSTER_PORT, P_WORKER_TRANSACTION_LEASE_TIME, P_WORKERS_MAX, P_WORKERS_TRANSACTIONAL, PERSIST_CONTEXT, PERSIST_JOB, PERSIST_SORCER_NAME, PERSIST_SORCER_TYPES, PERSISTENCE_EVENT, POSTPROCESS, PREPROCESS, PRIVATE, PRIVATE_SCOPE, PROCESS, PROVIDER, PROVIDER_CONTEXT, PUBLIC_SCOPE, REGISTER_FOR_NOTIFICATIONS, REMOVE_CONTEXT, REMOVE_DATANODE, REMOVE_JOB, REMOVE_TASK, RENAME_CONTEXT, RENAME_SORCER_NAME, RESUME_JOB, RUNTIME, S_CATALOGER_NAME, S_COMMANDER_NAME, S_COMMUNITY, S_DEFAULT_COMMUNITY, S_ENV_FIENAME, S_HOME, S_IS_DB_ORACLE, S_JOBBER_NAME, S_LOCALHOST, S_PERSISTER_IS_DB_TYPE, S_PERSISTER_NAME, S_RMI_HOST, S_RMI_PORT,
184

S_SERVICE_ACCESSOR_PROVIDER_NAME, S_SERVICE_ID_FILENAME, SAPPEND, SAVE_TASK_AS, SAVEJOB_AS, SAVEJOB_AS_RUNTIME, SCRATCH_CONTEXTIDS, SCRATCH_JOBEXERTIONIDS, SCRATCH_METHODIDS, SCRATCH_TASKEXERTIONIDS, Script, SCRIPT, SELECT, SELF, SERVICE_EXERTION, SOC_BOOLEAN, SOC_CONTEXT_LINK, SOC_DATANODE, SOC_DB_OBJECT, SOC_DOUBLE, SOC_FLOAT, SOC_INTEGER, SOC_LONG, SOC_PRIMITIVE, SOC_SERIALIZABLE, SOC_STRING, SORCER_FOOTER, SORCER_HEADER, SORCER_HOME, SORCER_INTRO, SORCER_TMP_DIR, SPOSTPROCESS, SPREPROCESS, SPROCESS, STEP_JOB, STOP_JOB, STOP_TASK, SUBCONTEXT_CONTROL_CONTEXT_STR, SUSPEND_JOB, SYSTEM_SCOPE, TABLE_NAME, TASK_COMMAND, TASK_ID, TASK_JOB, TASK_NAME, TASK_PROVIDER, TASK_SCRIPT, TRUE, UPDATE_CONTEXT, UPDATE_CONTEXT_EVT, UPDATE_DATANODE, UPDATE_EXERTION, UPDATE_JOB, UPDATE_JOB_EVT, UPDATE_TASK, UPDATE_TASK_EVT, VALUE
Fields inherited from interface java.awt.image.ImageObserver

ABORT, ALLBITS, ERROR, FRAMEBITS, HEIGHT, PROPERTIES, SOMEBITS, WIDTH
Constructor Summary
LokiGroupUI(java.lang.Object obj)
Class Constructor
Method Summary
private getSelectedNode()
185

javax.swing.tree.DefaultMutableTr eeNode private getTree() javax.swing.tree.DefaultMutableTr Creates the tree to be viewed in the eeNode
user interface by requesting the neccesary information from the publisher, the Group Manager
static net.jini.lookup.entry.UIDes getUIDescriptor() criptor java.lang.String showActionInfo(java.lang.String node string)
private
returns the information from the selected action node

private java.lang.String showGroupInfo(java.lang.String nodes tring)
returns the group information based on the selected node string
Methods inherited from class javax.swing.JPanel

getAccessibleContext, getUI, getUIClassID, paramString, setUI, updateUI
Methods inherited from class javax.swing.JComponent

addAncestorListener, addNotify, addVetoableChangeListener, computeVisibleRect, contains, createToolTip, disable, enable, firePropertyChange, firePropertyChange, firePropertyChange, fireVetoableChange, getActionForKeyStroke, getActionMap, getAlignmentX, getAlignmentY, getAncestorListeners, getAutoscrolls, getBorder, getBounds, getClientProperty, getComponentGraphics,
186

getComponentPopupMenu, getConditionForKeyStroke, getDebugGraphicsOptions, getDefaultLocale, getFontMetrics, getGraphics, getHeight, getInheritsPopupMenu, getInputMap, getInputMap, getInputVerifier, getInsets, getInsets, getListeners, getLocation, getMaximumSize, getMinimumSize, getNextFocusableComponent, getPopupLocation, getPreferredSize, getRegisteredKeyStrokes, getRootPane, getSize, getToolTipLocation, getToolTipText, getToolTipText, getTopLevelAncestor, getTransferHandler, getVerifyInputWhenFocusTarget, getVetoableChangeListeners, getVisibleRect, getWidth, getX, getY, grabFocus, isDoubleBuffered, isLightweightComponent, isManagingFocus, isOpaque, isOptimizedDrawingEnabled, isPaintingTile, isRequestFocusEnabled, isValidateRoot, paint, paintBorder, paintChildren, paintComponent, paintImmediately, paintImmediately, print, printAll, printBorder, printChildren, printComponent, processComponentKeyEvent, processKeyBinding, processKeyEvent, processMouseEvent, processMouseMotionEvent, putClientProperty, registerKeyboardAction, registerKeyboardAction, removeAncestorListener, removeNotify, removeVetoableChangeListener, repaint, repaint, requestDefaultFocus, requestFocus, requestFocus, requestFocusInWindow, requestFocusInWindow, resetKeyboardActions, reshape, revalidate, scrollRectToVisible, setActionMap, setAlignmentX, setAlignmentY, setAutoscrolls, setBackground, setBorder, setComponentPopupMenu, setDebugGraphicsOptions, setDefaultLocale, setDoubleBuffered, setEnabled, setFocusTraversalKeys, setFont, setForeground, setInheritsPopupMenu, setInputMap, setInputVerifier, setMaximumSize, setMinimumSize, setNextFocusableComponent, setOpaque, setPreferredSize, setRequestFocusEnabled, setToolTipText, setTransferHandler, setUI, setVerifyInputWhenFocusTarget, setVisible, unregisterKeyboardAction, update
Methods inherited from class java.awt.Container

add, add, add, add, add, addContainerListener, addImpl, addPropertyChangeListener, addPropertyChangeListener, applyComponentOrientation, areFocusTraversalKeysSet, countComponents, deliverEvent, doLayout, findComponentAt, findComponentAt, getComponent, getComponentAt, getComponentAt, getComponentCount, getComponents, getComponentZOrder, getContainerListeners, getFocusTraversalKeys, getFocusTraversalPolicy, getLayout, getMousePosition, insets, invalidate, isAncestorOf, isFocusCycleRoot, isFocusCycleRoot, isFocusTraversalPolicyProvider, isFocusTraversalPolicySet, layout,
187

list, list, locate, minimumSize, paintComponents, preferredSize, printComponents, processContainerEvent, processEvent, remove, remove, removeAll, removeContainerListener, setComponentZOrder, setFocusCycleRoot, setFocusTraversalPolicy, setFocusTraversalPolicyProvider, setLayout, transferFocusBackward, transferFocusDownCycle, validate, validateTree
Methods inherited from class java.awt.Component

action, add, addComponentListener, addFocusListener, addHierarchyBoundsListener, addHierarchyListener, addInputMethodListener, addKeyListener, addMouseListener, addMouseMotionListener, addMouseWheelListener, bounds, checkImage, checkImage, coalesceEvents, contains, createImage, createImage, createVolatileImage, createVolatileImage, disableEvents, dispatchEvent, enable, enableEvents, enableInputMethods, firePropertyChange, firePropertyChange, firePropertyChange, firePropertyChange, firePropertyChange, firePropertyChange, getBackground, getBounds, getColorModel, getComponentListeners, getComponentOrientation, getCursor, getDropTarget, getFocusCycleRootAncestor, getFocusListeners, getFocusTraversalKeysEnabled, getFont, getForeground, getGraphicsConfiguration, getHierarchyBoundsListeners, getHierarchyListeners, getIgnoreRepaint, getInputContext, getInputMethodListeners, getInputMethodRequests, getKeyListeners, getLocale, getLocation, getLocationOnScreen, getMouseListeners, getMouseMotionListeners, getMousePosition, getMouseWheelListeners, getName, getParent, getPeer, getPropertyChangeListeners, getPropertyChangeListeners, getSize, getToolkit, getTreeLock, gotFocus, handleEvent, hasFocus, hide, imageUpdate, inside, isBackgroundSet, isCursorSet, isDisplayable, isEnabled, isFocusable, isFocusOwner, isFocusTraversable, isFontSet, isForegroundSet, isLightweight, isMaximumSizeSet, isMinimumSizeSet, isPreferredSizeSet, isShowing, isValid, isVisible, keyDown, keyUp, list, list, list, location, lostFocus, mouseDown, mouseDrag, mouseEnter, mouseExit, mouseMove, mouseUp, move, nextFocus, paintAll, postEvent, prepareImage, prepareImage, processComponentEvent, processFocusEvent, processHierarchyBoundsEvent, processHierarchyEvent, processInputMethodEvent, processMouseWheelEvent, remove, removeComponentListener, removeFocusListener, removeHierarchyBoundsListener, removeHierarchyListener, removeInputMethodListener, removeKeyListener, removeMouseListener, removeMouseMotionListener, removeMouseWheelListener,
188

removePropertyChangeListener, removePropertyChangeListener, repaint, repaint, repaint, resize, resize, setBounds, setBounds, setComponentOrientation, setCursor, setDropTarget, setFocusable, setFocusTraversalKeysEnabled, setIgnoreRepaint, setLocale, setLocation, setLocation, setName, setSize, setSize, show, show, size, toString, transferFocus, transferFocusUpCycle

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
Field Detail
gm_mgt
group manger
item
private net.jini.core.lookup.ServiceItem item
service item
logger
class logger
myModel
private javax.swing.tree.DefaultTreeModel myModel
189
mySplitPane
private javax.swing.JSplitPane mySplitPane
myStatusLabel
private javax.swing.JLabel myStatusLabel
myToolBar
myTPane
private javax.swing.JTextPane myTPane
myTPaneSPane
private javax.swing.JScrollPane myTPaneSPane
myTree
private javax.swing.JTree myTree
myTreeSPane
private javax.swing.JScrollPane myTreeSPane
Constructor Detail
LokiGroupUI
public LokiGroupUI(java.lang.Object obj)
Class Constructor Parameters: 190

obj - the service item object passed in invocation
Method Detail
createUI
getSelectedNode
private javax.swing.tree.DefaultMutableTreeNode getSelectedNode()
Returns: the selected DefaultMutableTreeNode from the tree pane See Also:
DefaultMutableTreeNode
getTree
private javax.swing.tree.DefaultMutableTreeNode getTree()
Creates the tree to be viewed in the user interface by requesting the neccesary information from the publisher, the Group Manager Returns: the root of the created tree See Also:
DefaultMutableTreeNode, GroupManager
getUIDescriptor
public static net.jini.lookup.entry.UIDescriptor getUIDescriptor()
Returns: the descriptor for the user interface 191
See Also:
UIDescriptor
showActionInfo
private java.lang.String showActionInfo(java.lang.String nodestring)
returns the information from the selected action node Parameters:

nodestring - name of selected action node
showGroupInfo
private java.lang.String showGroupInfo(java.lang.String nodestring)
returns the group information based on the selected node string Parameters:
nodestring - name of selected group node
192
Interface sorcer.core.loki.crypt.EncryptionManagement
All Known Implementing Classes: EncryptionManager
public interface EncryptionManagement
The encryption management interface describes the standard methods for both encryption and decryption. It outlines both block, stream, and threaded pipe cryptography methods, and expands these to allow for both byte array and string data.
Method Summary
byte[] decrypt(byte[] ciphertext)
byte[] decrypt(java.lang.String ciphertext)
java.io.Reader decryptPipe(byte[] ciphertext)
void decryptStream(java.io.InputStream in, java.io.OutputStream out)
byte[] encrypt(byte[] plaintext)
byte[] encrypt(java.lang.String plaintext)
java.io.Reader encryptPipe(byte[] plaintext)
void encryptStream(java.io.InputStream in, java.io.OutputStream out)
193
void init(javax.crypto.KeyAgreement keyAgree)
Method Detail
decrypt
Parameters:
ciphertext - byte array containing ciphertext to be decrypted
Returns:
ciphertext decrypted to a byte array
decrypt
Parameters:
ciphertext - string containing ciphertext to be decrypted
Returns:
decryptPipe
Parameters:
Returns: Reader to the plain text pipe 194
decryptStream
Parameters:
in - input stream to be decrypted out - output stream containing decrypted plain text
encrypt
Parameters:
plaintext - byte array containing text to be encrypted
Returns:
plaintext encrypted to a byte array
encrypt
Parameters:
plaintext - string containing text to be encrypted
Returns:
encryptPipe
Parameters:
Returns: Reader to the cipher text pipe 195
encryptStream
Parameters:
in - input stream to be encrypted out - output stream containing encrypted cipher text
init
Parameters:
keyAgree - the shared key key agreement for the creation of a common cipher
196
Class sorcer.core.loki.crypt.EncryptionManager
java.lang.Object sorcer.core.loki.crypt.EncryptionManager
All Implemented Interfaces: EncryptionManagement
public class EncryptionManager extends java.lang.Object implements EncryptionManagement
The encryption manager class implements block, stream, and threaded pipe encryption using DES, and AES encryption.
Field Summary
private byte[] buf
buffer
private javax.crypto.Cipher decryptionCipher
cipher for decryption

private javax.crypto.Cipher encryptionCipher
cipher for encryption

private logger static java.util.logging.Logger class logger
Constructor Summary
EncryptionManager()
197
Method Summary
Uses the keyAgree Key Agreement to create and initialize both the encryption and decryption ciphers.
Methods inherited from class java.lang.Object 198

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Field Detail
buf
private byte[] buf
buffer
decryptionCipher
private javax.crypto.Cipher decryptionCipher
cipher for decryption
encryptionCipher
private javax.crypto.Cipher encryptionCipher
cipher for encryption
logger
class logger
Constructor Detail
EncryptionManager
public EncryptionManager()
Method Detail
199
decrypt
public byte[] decrypt(byte[] ciphertext)
Specified by:
decrypt in interface EncryptionManagement
Parameters:
Returns:
decrypt
public byte[] decrypt(java.lang.String ciphertext)
Specified by:
decrypt in interface EncryptionManagement
Parameters:
ciphertext - string containing ciphertext to be decrypted
Returns:
decryptPipe
public java.io.Reader decryptPipe(byte[] ciphertext)
Specified by:
decryptPipe in interface EncryptionManagement
Parameters:
Returns: Reader to the plain text pipe
200
decryptStream
public void decryptStream(java.io.InputStream in, java.io.OutputStream out)
Specified by:
decryptStream in interface EncryptionManagement
Parameters:
in - input stream to be decrypted out - output stream containing decrypted plain text
encrypt
public byte[] encrypt(byte[] plaintext)
Specified by:
encrypt in interface EncryptionManagement
Parameters:
Returns:
encrypt
public byte[] encrypt(java.lang.String plaintext)
Specified by:
encrypt in interface EncryptionManagement
Parameters:
plaintext - string containing text to be encrypted
Returns:
201
encryptPipe
public java.io.Reader encryptPipe(byte[] plaintext)
Specified by:
encryptPipe in interface EncryptionManagement
Parameters:
Returns: Reader to the cipher text pipe
encryptStream
public void encryptStream(java.io.InputStream in, java.io.OutputStream out)
Specified by:
encryptStream in interface EncryptionManagement
Parameters:
in - input stream to be encrypted out - output stream containing encrypted cipher text
init
public void init(javax.crypto.KeyAgreement keyAgree)
Uses the keyAgree Key Agreement to create and initialize both the encryption and decryption ciphers. Specified by:
init in interface EncryptionManagement
Parameters:
keyAgree - the shared key key agreement for the creation of a common cipher
202
Class sorcer.core.loki.crypt.DecryptThread
java.lang.Object java.lang.Thread sorcer.core.loki.crypt.DecryptThread
All Implemented Interfaces: java.lang.Runnable
class DecryptThread extends java.lang.Thread
The decryption thread is sparked by an encryption manager for the processing of cipher text which is written back to the manager via an output pipe
Nested classes/interfaces inherited from class java.lang.Thread

java.lang.Thread.State, java.lang.Thread.UncaughtExceptionHandler
Field Summary
private myCipher javax.crypto.Cipher cipher private myOut java.io.PrintWriter writer private myScan java.util.Scanner reader
203
Fields inherited from class java.lang.Thread

MAX_PRIORITY, MIN_PRIORITY, NORM_PRIORITY
Constructor Summary
DecryptThread(java.io.Writer out, javax.crypto.Cipher decryptCipher, byte[] data)
DecryptThread(java.io.Writer out, javax.crypto.Cipher decryptCipher, java.lang.String data)
Method Summary
private init(java.io.Writer out, javax.crypto.Cipher decryptCipher, void java.io.Reader in)
void run() data is processed and decrypted by the local cipher object (myCipher)
and is written to the local writer object (myOut)
Methods inherited from class java.lang.Thread

activeCount, checkAccess, countStackFrames, currentThread, destroy,
204

dumpStack, enumerate, getAllStackTraces, getContextClassLoader, getDefaultUncaughtExceptionHandler, getId, getName, getPriority, getStackTrace, getState, getThreadGroup, getUncaughtExceptionHandler, holdsLock, interrupt, interrupted, isAlive, isDaemon, isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon, setDefaultUncaughtExceptionHandler, setName, setPriority, setUncaughtExceptionHandler, sleep, sleep, start, stop, stop, suspend, toString, yield

Field Detail
myCipher
private javax.crypto.Cipher myCipher
cipher
myOut
private java.io.PrintWriter myOut
writer
myScan
private java.util.Scanner myScan
reader
205
Constructor Detail
DecryptThread
public DecryptThread(java.io.Writer out, javax.crypto.Cipher decryptCipher, byte[] data)
Parameters:
out - output pipe for writing decryptCipher - cipher to use for decryption data - cipher text byte array to decrypt
DecryptThread
public DecryptThread(java.io.Writer out, javax.crypto.Cipher decryptCipher, java.lang.String data)
Parameters:
out - output pipe for writing decryptCipher - cipher to use for decryption data - cipher text string to decrypt
Method Detail
init
private void init(java.io.Writer out, javax.crypto.Cipher decryptCipher, java.io.Reader in)
Parameters:
out - output pipe for writing decryptCipher - cipher to use for decryption in - input pipe for reading
206
run
public void run() data is processed and decrypted by the local cipher object (myCipher) and is
written to the local writer object (myOut) Once complete the thread closes Specified by:
run in interface java.lang.Runnable
Overrides:
run in class java.lang.Thread
207
Class sorcer.core.loki.crypt.EncryptThread
java.lang.Object java.lang.Thread sorcer.core.loki.crypt.EncryptThread
All Implemented Interfaces: java.lang.Runnable
class EncryptThread extends java.lang.Thread
The encryption thread is sparked by an encryption manager for the processing of cipher text which is written back to the manager via an output pipe
Nested classes/interfaces inherited from class java.lang.Thread

java.lang.Thread.State, java.lang.Thread.UncaughtExceptionHandler
Field Summary
private myCipher javax.crypto.Cipher cipher private myOut java.io.PrintWriter writer private myScan java.util.Scanner reader
208
Fields inherited from class java.lang.Thread

MAX_PRIORITY, MIN_PRIORITY, NORM_PRIORITY
Constructor Summary
EncryptThread(java.io.Writer out, javax.crypto.Cipher encryptCipher, byte[] data)
EncryptThread(java.io.Writer out, javax.crypto.Cipher encryptCipher, java.lang.String data)
Method Summary
private init(java.io.Writer out, javax.crypto.Cipher encryptCipher, void java.io.Reader in)
void run() data is processed and encrypted by the local cipher object (myCipher)
and is written to the local writer object (myOut)
Methods inherited from class java.lang.Thread

activeCount, checkAccess, countStackFrames, currentThread, destroy,
209

dumpStack, enumerate, getAllStackTraces, getContextClassLoader, getDefaultUncaughtExceptionHandler, getId, getName, getPriority, getStackTrace, getState, getThreadGroup, getUncaughtExceptionHandler, holdsLock, interrupt, interrupted, isAlive, isDaemon, isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon, setDefaultUncaughtExceptionHandler, setName, setPriority, setUncaughtExceptionHandler, sleep, sleep, start, stop, stop, suspend, toString, yield

Field Detail
myCipher
private javax.crypto.Cipher myCipher
cipher
myOut
private java.io.PrintWriter myOut
writer
myScan
private java.util.Scanner myScan
reader
210
Constructor Detail
EncryptThread
public EncryptThread(java.io.Writer out, javax.crypto.Cipher encryptCipher, byte[] data)
Parameters:
out - output pipe for writing encryptCipher - cipher to use for encryption data - cipher text byte array to encrypt
EncryptThread
public EncryptThread(java.io.Writer out, javax.crypto.Cipher encryptCipher, java.lang.String data)
Parameters:
out - output pipe for writing encryptCipher - cipher to use for encryption data - cipher text string to encrypt
Method Detail
init
private void init(java.io.Writer out, javax.crypto.Cipher encryptCipher, java.io.Reader in)
Parameters:
out - output pipe for writing encryptCipher - cipher to use for encryption in - input pipe for reading
211
run
public void run() data is processed and encrypted by the local cipher object (myCipher) and is
written to the local writer object (myOut) Once complete the thread closes Specified by:
run in interface java.lang.Runnable
Overrides:
run in class java.lang.Thread
212
Interface sorcer.core.loki.db.DatabaseConnector
All Known Implementing Classes: DerbyConnector
public interface DatabaseConnector
The database connector intergaface outlines methods for the connection and deconnection to a specified database. In the loki framework this is used by the group manager object to access the group data store object.
Method Summary
void closeConnection()
closes the created connection

java.sql.Connection getConnection()
creates a connection and connects
Method Detail
closeConnection
closes the created connection
getConnection
creates a connection and connects 213
Returns: the created connection
214
Class sorcer.core.loki.db.DerbyConnector
java.lang.Object sorcer.core.loki.db.DerbyConnector
All Implemented Interfaces: DatabaseConnector
public class DerbyConnector extends java.lang.Object implements DatabaseConnector
Derby Database specific DatabaseConnector
Field Summary
private connection java.sql.Connection connection object private java.lang.String driver
derby driver name

private logger java.util.logging.Logger logger object private java.lang.String protocol
name of derby protocol
Constructor Summary
DerbyConnector(java.lang.String databaseDir)
initializes variables and creates database connection
215
Method Summary
closes the created connection, and shutsdown the derby protocol

creates a connection and connects

Field Detail
connection
private final java.sql.Connection connection
connection object
driver
private final java.lang.String driver
derby driver name See Also: Constant Field Values
216
logger
private final java.util.logging.Logger logger
logger object
protocol
private final java.lang.String protocol
name of derby protocol See Also: Constant Field Values
Constructor Detail
DerbyConnector
public DerbyConnector(java.lang.String databaseDir) throws java.sql.SQLException
initializes variables and creates database connection Parameters:

databaseDir - directory of database
Throws:
java.sql.SQLException
Method Detail
closeConnection
public void closeConnection()
closes the created connection, and shutsdown the derby protocol Specified by:
closeConnection in interface DatabaseConnector
217
getConnection
public java.sql.Connection getConnection()
Description copied from interface: DatabaseConnector creates a connection and connects Specified by:
getConnection in interface DatabaseConnector
Returns: the created connection
218
Class sorcer.core.loki.db.DatabaseInitializer
java.lang.Object sorcer.core.loki.db.DatabaseInitializer
public class DatabaseInitializer extends java.lang.Object
initialize the database as a GStoreDB
Field Summary
private groupstoreDB GStoreDB database object
Constructor Summary
DatabaseInitializer(DatabaseConnector connector)
initializes the local database object as a GStoreSB

DatabaseInitializer(java.lang.String url, java.lang.String username, java.lang.String password)
initializes the local database object as a GStoreSB
Method Summary
GStoreDB getDatabase()
returns database object
219

Field Detail
groupstoreDB
private final GStoreDB groupstoreDB
database object
Constructor Detail
DatabaseInitializer
public DatabaseInitializer(DatabaseConnector connector) throws java.sql.SQLException
initializes the local database object as a GStoreSB Parameters:

connector - the connection to the database
Throws:
See Also:
GStoreDB, SQLException
DatabaseInitializer
public DatabaseInitializer(java.lang.String url, java.lang.String username, java.lang.String password) throws java.sql.SQLException
initializes the local database object as a GStoreSB 220
Parameters:
url username password -
Throws:
See Also:
GStoreDB, SQLException
Method Detail
getDatabase
public GStoreDB getDatabase()
returns database object
221
Class sorcer.core.loki.db.GStoreDB
java.lang.Object sorcer.core.loki.db.GStoreDB
public class GStoreDB extends java.lang.Object
Field Summary
private addNewActivityEntry java.sql.PreparedStatement insert new activity entry private addNewExecutionEntry java.sql.PreparedStatement insert new execution entry private addNewExertionEntry java.sql.PreparedStatement insert new exertion entry private addNewGroupEntry java.sql.PreparedStatement insert new group entry private addNewMemberEntry java.sql.PreparedStatement insert new member entry private addNewMembershipEntry java.sql.PreparedStatement insert new membership entry private java.sql.Connection connection
connection object
private listActionInfo java.sql.PreparedStatement select action information private listActivities java.sql.PreparedStatement select all activities entries private listActivityInfo
222

java.sql.PreparedStatement
select activity entry
private listExecutions java.sql.PreparedStatement select all execution entries private listExertionInfo java.sql.PreparedStatement select exertion entry private listExertions java.sql.PreparedStatement select all exertion entries private listGroupAction java.sql.PreparedStatement select group action private listGroupExertions java.sql.PreparedStatement select group exertions private listGroupInfo java.sql.PreparedStatement select group entry private listGroupMembers java.sql.PreparedStatement select group members private listGroups java.sql.PreparedStatement select all groups entries private listMemberInfo java.sql.PreparedStatement select member entry private listMembers java.sql.PreparedStatement select all member entries private listMemberships java.sql.PreparedStatement select all membership entries private logger static java.util.logging.Logger logger object
223
Constructor Summary
protected GStoreDB(java.sql.Connection connection)
initialize all statements and database
Method Summary
sorcer.service.Contex addActivityEntry(sorcer.service.Context context) t add activity entry sorcer.service.Contex addExecutionEntry(sorcer.service.Context context t )
add execution entry

sorcer.service.Contex addExertionEntry(sorcer.service.Context context) t add exertion entry sorcer.service.Contex addGroupEntry(sorcer.service.Context context) t add group entry sorcer.service.Contex addMemberEntry(sorcer.service.Context context) t add member entry sorcer.service.Contex addMembershipEntry(sorcer.service.Context contex t t)
add membership entry

protected void createTables()
create the following tables if the do not exist:

activity execution exertion group member membership sorcer.service.Contex executeQuery(sorcer.service.Context context) t sorcer.service.Contex executeUpdate(sorcer.service.Context context)
224

t sorcer.service.Contex getActionInfo(sorcer.service.Context context) t get group action sorcer.service.Contex getActivities(sorcer.service.Context context) t get all activity entries sorcer.service.Contex getActivityEntry(sorcer.service.Context context) t get activity entry sorcer.service.Contex getExecutions(sorcer.service.Context context) t get all executions sorcer.service.Contex getExertionEntry(sorcer.service.Context context) t get exertion entry sorcer.service.Contex getExertions(sorcer.service.Context context) t get all exertions sorcer.service.Contex getGroupAction(sorcer.service.Context context) t get group action sorcer.service.Contex getGroupEntry(sorcer.service.Context context) t get group entry sorcer.service.Contex getGroupExertions(sorcer.service.Context context t )
get group exertions

sorcer.service.Contex getGroupMembers(sorcer.service.Context context) t get group members sorcer.service.Contex getGroups(sorcer.service.Context context) t get all groups sorcer.service.Contex getMemberEntry(sorcer.service.Context context) t get member entry
225

sorcer.service.Contex getMembers(sorcer.service.Context context) t get all members sorcer.service.Contex getMemberships(sorcer.service.Context context) t get all memberships

Field Detail
addNewActivityEntry
private final java.sql.PreparedStatement addNewActivityEntry
insert new activity entry
addNewExecutionEntry
private final java.sql.PreparedStatement addNewExecutionEntry
insert new execution entry
addNewExertionEntry
private final java.sql.PreparedStatement addNewExertionEntry
insert new exertion entry
addNewGroupEntry
private final java.sql.PreparedStatement addNewGroupEntry
226
insert new group entry
addNewMemberEntry
private final java.sql.PreparedStatement addNewMemberEntry
insert new member entry
addNewMembershipEntry
private final java.sql.PreparedStatement addNewMembershipEntry
insert new membership entry
connection
private final java.sql.Connection connection
connection object
listActionInfo
private final java.sql.PreparedStatement listActionInfo
select action information
listActivities
private final java.sql.PreparedStatement listActivities
select all activities entries
listActivityInfo
private final java.sql.PreparedStatement listActivityInfo
select activity entry
227
listExecutions
private final java.sql.PreparedStatement listExecutions
select all execution entries
listExertionInfo
private final java.sql.PreparedStatement listExertionInfo
select exertion entry
listExertions
private final java.sql.PreparedStatement listExertions
select all exertion entries
listGroupAction
private final java.sql.PreparedStatement listGroupAction
select group action
listGroupExertions
private final java.sql.PreparedStatement listGroupExertions
select group exertions
listGroupInfo
private final java.sql.PreparedStatement listGroupInfo
select group entry
listGroupMembers
private final java.sql.PreparedStatement listGroupMembers
select group members
228
listGroups
private final java.sql.PreparedStatement listGroups
select all groups entries
listMemberInfo
private final java.sql.PreparedStatement listMemberInfo
select member entry
listMembers
private final java.sql.PreparedStatement listMembers
select all member entries
listMemberships
private final java.sql.PreparedStatement listMemberships
select all membership entries
logger
logger object
Constructor Detail
GStoreDB
protected GStoreDB(java.sql.Connection connection) throws java.sql.SQLException
initialize all statements and database Parameters:

connection -
229
Throws:
Method Detail
addActivityEntry
public sorcer.service.Context addActivityEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add activity entry Parameters:

context -
Returns: Throws:
java.rmi.RemoteException
addExecutionEntry
public sorcer.service.Context addExecutionEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add execution entry Parameters:

context -
Returns: Throws:
addExertionEntry
public sorcer.service.Context addExertionEntry(sorcer.service.Context context) throws java.rmi.RemoteException
230
add exertion entry Parameters:

context -
Returns: Throws:
addGroupEntry
public sorcer.service.Context addGroupEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add group entry Parameters:

context -
Returns: Throws:
addMemberEntry
public sorcer.service.Context addMemberEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add member entry Parameters:

context -
Returns: Throws:
231
addMembershipEntry
public sorcer.service.Context addMembershipEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add membership entry Parameters:

context -
Returns: Throws:
createTables
protected void createTables() throws java.sql.SQLException
create the following tables if the do not exist: activity execution exertion
group member membership
Throws:
executeQuery
public sorcer.service.Context executeQuery(sorcer.service.Context context) throws java.rmi.RemoteException
Throws:
executeUpdate
public sorcer.service.Context executeUpdate(sorcer.service.Context context) throws java.rmi.RemoteException
Throws:
232
getActionInfo
public sorcer.service.Context getActionInfo(sorcer.service.Context context) throws java.rmi.RemoteException
get group action Parameters:

context -
Returns: Throws:
getActivities
public sorcer.service.Context getActivities(sorcer.service.Context context) throws java.rmi.RemoteException
get all activity entries Parameters:

context -
Returns: Throws:
getActivityEntry
public sorcer.service.Context getActivityEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get activity entry Parameters:

context -
Returns: 233
Throws:
getExecutions
public sorcer.service.Context getExecutions(sorcer.service.Context context) throws java.rmi.RemoteException
get all executions Parameters:

context -
Returns: Throws:
getExertionEntry
public sorcer.service.Context getExertionEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get exertion entry Parameters:

context -
Returns: Throws:
getExertions
public sorcer.service.Context getExertions(sorcer.service.Context context) throws java.rmi.RemoteException
get all exertions Parameters: 234

context -
Returns: Throws:
getGroupAction
public sorcer.service.Context getGroupAction(sorcer.service.Context context) throws java.rmi.RemoteException

context -
Returns: Throws:
getGroupEntry
public sorcer.service.Context getGroupEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get group entry Parameters:

context -
Returns: Throws:
getGroupExertions
public sorcer.service.Context getGroupExertions(sorcer.service.Context context)
235

throws java.rmi.RemoteException
get group exertions Parameters:

context -
Returns: Throws:
getGroupMembers
public sorcer.service.Context getGroupMembers(sorcer.service.Context context) throws java.rmi.RemoteException
get group members Parameters:

context -
Returns: Throws:
getGroups
public sorcer.service.Context getGroups(sorcer.service.Context context) throws java.rmi.RemoteException
get all groups Parameters:

context -
Returns: Throws:
236
getMemberEntry
public sorcer.service.Context getMemberEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get member entry Parameters:

context -
Returns: Throws:
getMembers
public sorcer.service.Context getMembers(sorcer.service.Context context) throws java.rmi.RemoteException
get all members Parameters:

context -
Returns: Throws:
getMemberships
public sorcer.service.Context getMemberships(sorcer.service.Context context) throws java.rmi.RemoteException
get all memberships Parameters:

context -
Returns: Throws: 237

238
Class sorcer.core.loki.exertion.CCKExertion
java.lang.Object sorcer.core.loki.exertion.CCKExertion
All Implemented Interfaces: java.io.Serializable, sorcer.service.Exertion
public class CCKExertion extends java.lang.Object implements sorcer.service.Exertion
See Also: Serialized Form
Field Summary
java.util.Map<java.lang.String,java.security.Key> ccKeys
Fields inherited from interface sorcer.service.Exertion

STANDARD, THIN
Constructor Summary
CCKExertion()
239
Method Summary
sorcer.service.Exertion exert(net.jini.core.transaction.Transacti on txn)
Sends this exertion to the assigned service provider if set.

static CCKExertion get(java.util.Map<java.lang.String,java.s ecurity.Key> keys)
sorcer.service.Context getContext()
Returns a service context (service data) of this exertion to be processed by its methods as specified by exertion's signatures.
sorcer.service.FlowType getFlowType()
Returns a flow type for this exertion execution.

java.lang.String getName()
Returns a name of this exertion.

sorcer.service.Signature getProcessSignature()
Returns a signature of the PROCESS type for this exertion.

java.util.List<sorcer.servic getSignatures() e.Signature> Returns a process signature, all pre-
processing, post-processing, and append signatures.

boolean isJob()
Returns true if this exertion requires execution by a Jobber, otherwise false if this exertion requires its execution by a Tasker.
240

boolean isTree()
Return true if this exertion is atop an acyclic graph in which no node has two parents (two references to it).
void setFlowType(sorcer.service.FlowType flowT ype)
Sets a flow type for this exertion execution.

void setServicer(sorcer.service.Servicer provi der)
Sets the explicit Servicer for this exertion that normally is not required.

Field Detail
ccKeys
public java.util.Map<java.lang.String,java.security.Key> ccKeys
Constructor Detail
CCKExertion
public CCKExertion()
Method Detail
241
exert
public sorcer.service.Exertion exert(net.jini.core.transaction.Transaction txn) throws net.jini.core.transaction.TransactionException, sorcer.service.ExertionException, java.rmi.RemoteException
Description copied from interface: sorcer.service.Exertion Sends this exertion to the assigned service provider if set. If a service provider is not set then in runtime it bounds to any available provider that matches this exersion's signature of the PROCESS type. Specified by:
exert in interface sorcer.service.Exertion
Parameters:
txn - The transaction (if any) under which to exert.
Returns: a resulting exertion Throws:

net.jini.core.transaction.TransactionException - if a transaction error
occurs
sorcer.service.ExertionException - if processing this exertion causes an
error
See Also:
Exertion.setServicer(sorcer.service.Servicer)
get
public static CCKExertion get(java.util.Map<java.lang.String,java.security.Key> keys)
getContext
public sorcer.service.Context getContext()
242
Description copied from interface: sorcer.service.Exertion Returns a service context (service data) of this exertion to be processed by its methods as specified by exertion's signatures. Specified by:
getContext in interface sorcer.service.Exertion
Returns: a service context See Also:

Exertion.getSignatures()
getFlowType
public sorcer.service.FlowType getFlowType()
Description copied from interface: sorcer.service.Exertion Returns a flow type for this exertion execution. A flow type indicates if this exertion can be executed sequentially, in parallel, or concurrently with other component exertions within this exertion. The concurrent execution requires all mapped inputs in the exertion context to be assigned before this exertion can be executed. Specified by:
getFlowType in interface sorcer.service.Exertion
Returns: a flow type See Also:

FlowType}.
getName
public java.lang.String getName()
Description copied from interface: sorcer.service.Exertion Returns a name of this exertion. 243
Specified by:
getName in interface sorcer.service.Exertion
Returns: a name
getProcessSignature
public sorcer.service.Signature getProcessSignature()
Description copied from interface: sorcer.service.Exertion Returns a signature of the PROCESS type for this exertion. Specified by:
getProcessSignature in interface sorcer.service.Exertion
Returns: a process service signature See Also:

getSignatures
public java.util.List<sorcer.service.Signature> getSignatures()
Description copied from interface: sorcer.service.Exertion Returns a process signature, all pre-processing, post-processing, and append signatures. There is only one process signature defining late binding to the service provider processing this exertion. Specified by:
getSignatures in interface sorcer.service.Exertion
Returns: a collection of all service signatures See Also:

Exertion.getProcessSignature()
244
isJob
public boolean isJob()
Description copied from interface: sorcer.service.Exertion Returns true if this exertion requires execution by a Jobber, otherwise false if this exertion requires its execution by a Tasker. Note that control folow exerton can be processed by either a Tasker or a Jobber. Specified by:
isJob in interface sorcer.service.Exertion
Returns:
true if this exertion requires execution by a Jobber.
isTree
public boolean isTree()
Description copied from interface: sorcer.service.Exertion Return true if this exertion is atop an acyclic graph in which no node has two parents (two references to it). Specified by:
isTree in interface sorcer.service.Exertion
Returns: true if this exertion is atop an acyclic graph in which no node has two parents (two references to it).
setFlowType
public void setFlowType(sorcer.service.FlowType flowType)
Description copied from interface: sorcer.service.Exertion Sets a flow type for this exertion execution. A flow type indicates if this exertion can be executed sequentially, in parallel, or concurrently with other operations within this underlying Exertion. The concurrent execution requires all mapped 245
inputs in the related service contexts of component exertions to be assigned before this exertion can be executed. Specified by:
setFlowType in interface sorcer.service.Exertion
Parameters:
flowType - the flow type of this exertion
See Also:
FlowType}.
setServicer
public void setServicer(sorcer.service.Servicer provider)
Description copied from interface: sorcer.service.Exertion Sets the explicit Servicer for this exertion that normally is not required. Specified by:
setServicer in interface sorcer.service.Exertion
Parameters:
provider - a service provider
246
Class sorcer.core.loki.exertion.KPExertion
java.lang.Object sorcer.core.loki.exertion.KPExertion
All Implemented Interfaces: java.io.Serializable, sorcer.service.Exertion
public class KPExertion extends java.lang.Object implements sorcer.service.Exertion
See Also: Serialized Form
Field Summary
java.lang.String GroupSeqId
java.lang.Boolean isCreator
byte[] keyPair
java.security.PublicKey publicKey
Fields inherited from interface sorcer.service.Exertion

STANDARD, THIN
247
Constructor Summary
KPExertion()
Method Summary
sorcer.service.Exertion exert(net.jini.core.transaction.Transa ction txn)
Sends this exertion to the assigned service provider if set.

static KPExertion get(java.lang.Boolean iscreator, byte[] keypair, java.security.PublicKey pk, java.lang.String GSUID)
sorcer.service.Context getContext()
Returns a service context (service data) of this exertion to be processed by its methods as specified by exertion's signatures.
sorcer.service.FlowType getFlowType()
Returns a flow type for this exertion execution.

java.lang.String getName()
Returns a name of this exertion.

sorcer.service.Signature getProcessSignature()
Returns a signature of the PROCESS type for this exertion.

java.util.List<sorcer.service.S getSignatures()
248

ignature>
Returns a process signature, all preprocessing, post-processing, and append signatures.
boolean isJob()
Returns true if this exertion requires execution by a Jobber, otherwise false if this exertion requires its execution by a Tasker.
boolean isTree()
Return true if this exertion is atop an acyclic graph in which no node has two parents (two references to it).
void setFlowType(sorcer.service.FlowType fl owType)
Sets a flow type for this exertion execution.

void setServicer(sorcer.service.Servicer pr ovider)
Sets the explicit Servicer for this exertion that normally is not required.

Field Detail
249
GroupSeqId
public java.lang.String GroupSeqId
isCreator
public java.lang.Boolean isCreator
keyPair
public byte[] keyPair
publicKey
public java.security.PublicKey publicKey
Constructor Detail
KPExertion
public KPExertion()
Method Detail
exert
public sorcer.service.Exertion exert(net.jini.core.transaction.Transaction txn) throws net.jini.core.transaction.TransactionException, sorcer.service.ExertionException, java.rmi.RemoteException
Description copied from interface: sorcer.service.Exertion Sends this exertion to the assigned service provider if set. If a service provider is not set then in runtime it bounds to any available provider that matches this exersion's signature of the PROCESS type. Specified by:
exert in interface sorcer.service.Exertion
Parameters: 250

txn - The transaction (if any) under which to exert.
Returns: a resulting exertion Throws:

net.jini.core.transaction.TransactionException - if a transaction error
occurs
sorcer.service.ExertionException - if processing this exertion causes an
error
See Also:
Exertion.setServicer(sorcer.service.Servicer)
get
public static KPExertion get(java.lang.Boolean iscreator, byte[] keypair, java.security.PublicKey pk, java.lang.String GSUID)
getContext
public sorcer.service.Context getContext()
Description copied from interface: sorcer.service.Exertion Returns a service context (service data) of this exertion to be processed by its methods as specified by exertion's signatures. Specified by:
getContext in interface sorcer.service.Exertion
Returns: a service context See Also:

251
getFlowType
public sorcer.service.FlowType getFlowType()
Description copied from interface: sorcer.service.Exertion Returns a flow type for this exertion execution. A flow type indicates if this exertion can be executed sequentially, in parallel, or concurrently with other component exertions within this exertion. The concurrent execution requires all mapped inputs in the exertion context to be assigned before this exertion can be executed. Specified by:
getFlowType in interface sorcer.service.Exertion
Returns: a flow type See Also:

FlowType}.
getName
public java.lang.String getName()
Description copied from interface: sorcer.service.Exertion Returns a name of this exertion. Specified by:
getName in interface sorcer.service.Exertion
Returns: a name
getProcessSignature
public sorcer.service.Signature getProcessSignature()
Description copied from interface: sorcer.service.Exertion Returns a signature of the PROCESS type for this exertion. Specified by: 252

getProcessSignature in interface sorcer.service.Exertion
Returns: a process service signature See Also:

getSignatures
public java.util.List<sorcer.service.Signature> getSignatures()
Description copied from interface: sorcer.service.Exertion Returns a process signature, all pre-processing, post-processing, and append signatures. There is only one process signature defining late binding to the service provider processing this exertion. Specified by:
getSignatures in interface sorcer.service.Exertion
Returns: a collection of all service signatures See Also:

Exertion.getProcessSignature()
isJob
public boolean isJob()
Description copied from interface: sorcer.service.Exertion Returns true if this exertion requires execution by a Jobber, otherwise false if this exertion requires its execution by a Tasker. Note that control folow exerton can be processed by either a Tasker or a Jobber. Specified by:
isJob in interface sorcer.service.Exertion
Returns:
true if this exertion requires execution by a Jobber.
253
isTree
public boolean isTree()
Description copied from interface: sorcer.service.Exertion Return true if this exertion is atop an acyclic graph in which no node has two parents (two references to it). Specified by:
isTree in interface sorcer.service.Exertion
Returns: true if this exertion is atop an acyclic graph in which no node has two parents (two references to it).
setFlowType
public void setFlowType(sorcer.service.FlowType flowType)
Description copied from interface: sorcer.service.Exertion Sets a flow type for this exertion execution. A flow type indicates if this exertion can be executed sequentially, in parallel, or concurrently with other operations within this underlying Exertion. The concurrent execution requires all mapped inputs in the related service contexts of component exertions to be assigned before this exertion can be executed. Specified by:
setFlowType in interface sorcer.service.Exertion
Parameters:
flowType - the flow type of this exertion
See Also:
FlowType}.
setServicer
public void setServicer(sorcer.service.Servicer provider)
254
Description copied from interface: sorcer.service.Exertion Sets the explicit Servicer for this exertion that normally is not required. Specified by:
setServicer in interface sorcer.service.Exertion
Parameters:
provider - a service provider
255
Interface sorcer.core.loki.group.GroupManagement
All Superinterfaces: net.jini.admin.Administrable, sorcer.core.provider.proxy.Outer, sorcer.core.provider.proxy.Partner, java.rmi.Remote, sorcer.core.provider.proxy.RemotePartner, sorcer.service.Servicer All Known Implementing Classes: GroupManager
public interface GroupManagement extends java.rmi.Remote, sorcer.core.provider.proxy.RemotePartner
The group management interface lays the interface for database interaction, wrapping context passing to send and retrieve information to the database
Method Summary
sorcer.service.Contex addActivityEntry(sorcer.service.Context context) t add activity entry sorcer.service.Contex addExecutionEntry(sorcer.service.Context context t )
add exectuion entry

sorcer.service.Contex addExertionEntry(sorcer.service.Context context) t add exertion entry sorcer.service.Contex addGroupEntry(sorcer.service.Context context) t add group entry sorcer.service.Contex addMemberEntry(sorcer.service.Context context) t add member entry sorcer.service.Contex addMembershipEntry(sorcer.service.Context contex t t)
256

sorcer.service.Contex executeQuery(sorcer.service.Context context) t execute query sorcer.service.Contex executeUpdate(sorcer.service.Context context) t execute update sorcer.service.Contex getActionInfo(sorcer.service.Context context) t get action info sorcer.service.Contex getActivities(sorcer.service.Context context) t get all activities sorcer.service.Contex getActivityEntry(sorcer.service.Context context) t get activity entry sorcer.service.Contex getExecutions(sorcer.service.Context context) t get all executions sorcer.service.Contex getExertionEntry(sorcer.service.Context context) t get exertion entry sorcer.service.Contex getExertions(sorcer.service.Context context) t get all exertions sorcer.service.Contex getGroupAction(sorcer.service.Context context) t get group action sorcer.service.Contex getGroupEntry(sorcer.service.Context context) t get group entry sorcer.service.Contex getGroupExertions(sorcer.service.Context context t )
get group exertions

sorcer.service.Contex getGroupMembers(sorcer.service.Context context) t get group members
257

sorcer.service.Contex getGroups(sorcer.service.Context context) t get all groups sorcer.service.Contex getMemberEntry(sorcer.service.Context context) t get member entry sorcer.service.Contex getMembers(sorcer.service.Context context) t get all members sorcer.service.Contex getMemberships(sorcer.service.Context context) t get all memberships sorcer.service.Contex getProviderID(sorcer.service.Context context) t get the provider identification information
Methods inherited from interface sorcer.core.provider.proxy.Outer

getInner
Methods inherited from interface net.jini.admin.Administrable

getAdmin
Methods inherited from interface sorcer.service.Servicer

service
258
Method Detail
addActivityEntry
sorcer.service.Context addActivityEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add activity entry Parameters:

context - information context
Returns: results context Throws:

addExecutionEntry
sorcer.service.Context addExecutionEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add exectuion entry Parameters:


addExertionEntry
sorcer.service.Context addExertionEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add exertion entry 259
Parameters:

addGroupEntry
sorcer.service.Context addGroupEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add group entry Parameters:


addMemberEntry
sorcer.service.Context addMemberEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add member entry Parameters:


260
addMembershipEntry
sorcer.service.Context addMembershipEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add membership entry Parameters:


executeQuery
sorcer.service.Context executeQuery(sorcer.service.Context context) throws java.rmi.RemoteException
execute query Parameters:


executeUpdate
sorcer.service.Context executeUpdate(sorcer.service.Context context) throws java.rmi.RemoteException
execute update Parameters:

Returns: 261
results context Throws:

getActionInfo
sorcer.service.Context getActionInfo(sorcer.service.Context context) throws java.rmi.RemoteException
get action info Parameters:


getActivities
sorcer.service.Context getActivities(sorcer.service.Context context) throws java.rmi.RemoteException
get all activities Parameters:


getActivityEntry
sorcer.service.Context getActivityEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get activity entry 262
Parameters:

getExecutions
sorcer.service.Context getExecutions(sorcer.service.Context context) throws java.rmi.RemoteException
get all executions Parameters:


getExertionEntry
sorcer.service.Context getExertionEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get exertion entry Parameters:


263
getExertions
sorcer.service.Context getExertions(sorcer.service.Context context) throws java.rmi.RemoteException
get all exertions Parameters:


getGroupAction
sorcer.service.Context getGroupAction(sorcer.service.Context context) throws java.rmi.RemoteException


getGroupEntry
sorcer.service.Context getGroupEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get group entry Parameters:

Returns: results context 264
Throws:
getGroupExertions
sorcer.service.Context getGroupExertions(sorcer.service.Context context) throws java.rmi.RemoteException
get group exertions Parameters:


getGroupMembers
sorcer.service.Context getGroupMembers(sorcer.service.Context context) throws java.rmi.RemoteException
get group members Parameters:


getGroups
sorcer.service.Context getGroups(sorcer.service.Context context) throws java.rmi.RemoteException
265
get all groups Parameters:


getMemberEntry
sorcer.service.Context getMemberEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get member entry Parameters:


getMembers
sorcer.service.Context getMembers(sorcer.service.Context context) throws java.rmi.RemoteException
get all members Parameters:


266
getMemberships
sorcer.service.Context getMemberships(sorcer.service.Context context) throws java.rmi.RemoteException
get all memberships Parameters:


getProviderID
sorcer.service.Context getProviderID(sorcer.service.Context context) throws java.rmi.RemoteException
get the provider identification information Parameters:


267
Class sorcer.core.loki.group.GroupManager
java.lang.Object sorcer.core.loki.group.GroupManager
All Implemented Interfaces: java.io.Serializable, java.rmi.Remote, net.jini.admin.Administrable, GroupManagement, sorcer.core.provider.proxy.Outer, sorcer.core.provider.proxy.Partner, sorcer.core.provider.proxy.Partnership, sorcer.core.provider.proxy.RemotePartner, sorcer.core.SORCER, sorcer.service.Servicer
public class GroupManager extends java.lang.Object implements GroupManagement, sorcer.core.provider.proxy.RemotePartner, sorcer.core.provider.proxy.Partnership, java.io.Serializable, sorcer.core.SORCER
Group Manger implements the Group Management interface in order to connect and interact with the See Also: Serialized Form
Field Summary
private admin net.jini.admin.Administrable administrative object private GStoreDB database
database object
private java.lang.String databaseDir
location of database
private logger static java.util.logging.Logger logging object
268

private sorcer.core.Provider partner
provider object
private static long serialVersionUID
serializable UID
private serviceID net.jini.core.lookup.ServiceID service id

ADD_DATANODE, ADD_DOMAIN, ADD_JOB_TO_SESSION, ADD_LEAFNODE, ADD_SUBDOMAIN, ADD_TASK, ADD_TASK_TO_JOB_SAVEAS, ADD_TASK_TO_JOB_SAVEAS_RUNTIME, ANY, APPEND, APS, AS_PROPS, AS_SESSION, ATTRIBUTE_MODIFIED, BGCOLOR, BROKEN_LINK, C_DECREMENT, C_INCREMENT, CATALOG_CONTENT, CATALOGER_EVENT, CLEANUP_SESSION, Command, CONTEXT_ATTRIBUTE_VALUES, CONTEXT_ATTRIBUTES, CONTEXT_RESULT, CPS, CREATION_TIME, DATANODE_FLAG, DELETE_CONTEXT_EVT, DELETE_JOB_EVT, DELETE_NOTIFICATIONS, DELETE_SESSION, DELETE_TASK, DELETE_TASK_EVT, DROP_EXERTION, EXCEPTION_IND, EXCEPTIONS, EXERTION_PROVIDER, FALSE, GET, GET_CONTEXT, GET_CONTEXT_NAMES, GET_FT, GET_JOB, GET_JOB_NAME_BY_JOB_ID, GET_JOBDOMAIN, GET_JOBNAMES, GET_NEW_SERVLET_MESSAGES, GET_NOTIFICATIONS_FOR_SESSION, GET_RUNTIME_JOB, GET_RUNTIME_JOBNAMES, GET_SESSIONS_FOR_USER, GET_TASK, GET_TASK_NAME_BY_TASK_ID, GET_TASK_NAMES, GETALL_DOMAIN_SUB, IGRID_HOME, IN_FILE, IN_PATH, IN_SCRIPT, IN_VALUE, IND, IS_NEW, J_DATA_DIR, J_DATA_ROOT_DIR, J_DATA_SERVER, J_DATA_SERVER_PORT, J_DELAY_TIME, J_DESCRIPTION, J_GROUPS, J_ICON_NAME, J_INTERFACE_ONLY, J_INTERFACES, J_LOCATION, J_LOCATORS, J_MONITORABLE, J_NOTIFIABLE, J_POOL_SIZE, J_PORTAL_HOST, J_PORTAL_PORT, J_PROVIDER_JINIFIED, J_PROVIDER_NAME, J_PROVIDR_HOST, J_PROXY_CLASS, J_SERVICE_ID_PERSISTENT, J_SPACE_ENABLED, J_SPACE_GROUPS, J_TEMPLATE_MATCH, J_WEBSTER, J_WEBSTER_PORT, J_WORKER_TRANSACTION_LEASE_TIME, J_WORKERS_MAX, J_WORKERS_TRANSACTIONAL, JOB_ID, JOB_NAME, JOB_STATE, JOB_TASK, LOOKUP_CACHE_ENABLED, LOOKUP_MAX_MATCHES, LOOKUP_MIN_MATCHES, LOOKUP_WAIT, MAIL_SEP, MAX_LOOKUP_WAIT, MAX_PRIORITY, META_MODIFIED, MIN_PRIORITY, MODIFY_LEAFNODE, MSG_CONTENT, MSG_ID, MSG_SOURCE, MSG_TYPE, MULTICAST_ENABLED, NEW_CONTEXT_EVT, NEW_JOB_EVT, NEW_TASK_EVT, NONE, NORMAL_PRIORITY, NOTIFY_EXCEPTION, NOTIFY_FAILURE,
269

NOTIFY_INFORMATION, NOTIFY_WARNING, NOTRUNTIME, NULL, OBJECT_DOMAIN, OBJECT_NAME, OBJECT_OWNER, OBJECT_SCOPE, OBJECT_SUBDOMAIN, Order, OUT_COMMENT, OUT_FILE, OUT_PATH, OUT_SCRIPT, OUT_VALUE, P_DATA_DIR, P_DATA_ROOT_DIR, P_DATA_SERVER, P_DATA_SERVER_PORT, P_DELAY_TIME, P_DESCRIPTION, P_GROUPS, P_ICON_NAME, P_INTERFACE_ONLY, P_INTERFACES, P_LOCATION, P_LOCATORS, P_MONITORABLE, P_NOTIFIABLE, P_POOL_SIZE, P_PORTAL_HOST, P_PORTAL_PORT, P_PROVIDER_CONFIG, P_PROVIDER_JINIFIED, P_PROVIDER_NAME, P_PROVIDR_HOST, P_PROXY_CLASS, P_SERVICE_ID_PERSISTENT, P_SPACE_ENABLED, P_SPACE_GROUPS, P_TEMPLATE_MATCH, P_UNDEFINED, P_WEBSTER, P_WEBSTER_PORT, P_WORKER_TRANSACTION_LEASE_TIME, P_WORKERS_MAX, P_WORKERS_TRANSACTIONAL, PERSIST_CONTEXT, PERSIST_JOB, PERSIST_SORCER_NAME, PERSIST_SORCER_TYPES, PERSISTENCE_EVENT, POSTPROCESS, PREPROCESS, PRIVATE, PRIVATE_SCOPE, PROCESS, PROVIDER, PROVIDER_CONTEXT, PUBLIC_SCOPE, REGISTER_FOR_NOTIFICATIONS, REMOVE_CONTEXT, REMOVE_DATANODE, REMOVE_JOB, REMOVE_TASK, RENAME_CONTEXT, RENAME_SORCER_NAME, RESUME_JOB, RUNTIME, S_CATALOGER_NAME, S_COMMANDER_NAME, S_COMMUNITY, S_DEFAULT_COMMUNITY, S_ENV_FIENAME, S_HOME, S_IS_DB_ORACLE, S_JOBBER_NAME, S_LOCALHOST, S_PERSISTER_IS_DB_TYPE, S_PERSISTER_NAME, S_RMI_HOST, S_RMI_PORT, S_SERVICE_ACCESSOR_PROVIDER_NAME, S_SERVICE_ID_FILENAME, SAPPEND, SAVE_TASK_AS, SAVEJOB_AS, SAVEJOB_AS_RUNTIME, SCRATCH_CONTEXTIDS, SCRATCH_JOBEXERTIONIDS, SCRATCH_METHODIDS, SCRATCH_TASKEXERTIONIDS, Script, SCRIPT, SELECT, SELF, SERVICE_EXERTION, SOC_BOOLEAN, SOC_CONTEXT_LINK, SOC_DATANODE, SOC_DB_OBJECT, SOC_DOUBLE, SOC_FLOAT, SOC_INTEGER, SOC_LONG, SOC_PRIMITIVE, SOC_SERIALIZABLE, SOC_STRING, SORCER_FOOTER, SORCER_HEADER, SORCER_HOME, SORCER_INTRO, SORCER_TMP_DIR, SPOSTPROCESS, SPREPROCESS, SPROCESS, STEP_JOB, STOP_JOB, STOP_TASK, SUBCONTEXT_CONTROL_CONTEXT_STR, SUSPEND_JOB, SYSTEM_SCOPE, TABLE_NAME, TASK_COMMAND, TASK_ID, TASK_JOB, TASK_NAME, TASK_PROVIDER, TASK_SCRIPT, TRUE, UPDATE_CONTEXT, UPDATE_CONTEXT_EVT, UPDATE_DATANODE, UPDATE_EXERTION, UPDATE_JOB, UPDATE_JOB_EVT, UPDATE_TASK, UPDATE_TASK_EVT, VALUE
Constructor Summary
GroupManager()
constructor for initializing the database and logger
270
Method Summary
sorcer.service.Context addActivityEntry(sorcer.service.Context context )
add activity entry

sorcer.service.Context addExecutionEntry(sorcer.service.Context contex t)
add execution entry

sorcer.service.Context addExertionEntry(sorcer.service.Context context )
add exertion entry

sorcer.service.Context addGroupEntry(sorcer.service.Context context)
add group entry

sorcer.service.Context addMemberEntry(sorcer.service.Context context)
add member entry

sorcer.service.Context addMembershipEntry(sorcer.service.Context conte xt)

sorcer.service.Context executeQuery(sorcer.service.Context context)
execute query
sorcer.service.Context executeUpdate(sorcer.service.Context context)
execute update
sorcer.service.Context getActionInfo(sorcer.service.Context context)
get action info

sorcer.service.Context getActivities(sorcer.service.Context context)
get all activities

sorcer.service.Context getActivityEntry(sorcer.service.Context context )
271
get activity entry

java.lang.Object getAdmin()
get administrative object

sorcer.service.Context getExecutions(sorcer.service.Context context)
get all executions

sorcer.service.Context getExertionEntry(sorcer.service.Context context )
get exertion entry

sorcer.service.Context getExertions(sorcer.service.Context context)
get all exertions

sorcer.service.Context getGroupAction(sorcer.service.Context context)
get group actions

sorcer.service.Context getGroupEntry(sorcer.service.Context context)
get group entry

sorcer.service.Context getGroupExertions(sorcer.service.Context contex t)
get group exertions

sorcer.service.Context getGroupMembers(sorcer.service.Context context)
get group members

sorcer.service.Context getGroups(sorcer.service.Context context)
get all groups

java.rmi.Remote getInner()
get inner provider

sorcer.service.Context getMemberEntry(sorcer.service.Context context)
get member entry

sorcer.service.Context getMembers(sorcer.service.Context context)
get all members 272

sorcer.service.Context getMemberships(sorcer.service.Context context)
get all memberships

sorcer.service.Context getProviderID(sorcer.service.Context context)
retrieves provider id
private void initDB()
initialize the database, and create if not existent

sorcer.service.Exertio service(sorcer.service.Exertion exertion, n net.jini.core.transaction.Transaction transacti on)
return service object

void setAdmin(java.lang.Object admin)
set administrative object

void setInner(java.lang.Object provider)
set inner provider

Field Detail
admin
private net.jini.admin.Administrable admin
administrative object
273
database
private GStoreDB database
database object
databaseDir
private java.lang.String databaseDir
location of database
logger
logging object
partner
private sorcer.core.Provider partner
provider object
serialVersionUID
private static final long serialVersionUID
serializable UID See Also: Constant Field Values
serviceID
private net.jini.core.lookup.ServiceID serviceID
service id
Constructor Detail
274
GroupManager
public GroupManager()
constructor for initializing the database and logger
Method Detail
addActivityEntry
public sorcer.service.Context addActivityEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add activity entry Specified by:

addActivityEntry in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
addExecutionEntry
public sorcer.service.Context addExecutionEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add execution entry Specified by:

addExecutionEntry in interface GroupManagement
Parameters:
context -
275
Returns: Throws:
See Also:
RemoteException
addExertionEntry
public sorcer.service.Context addExertionEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add exertion entry Specified by:

addExertionEntry in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
addGroupEntry
public sorcer.service.Context addGroupEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add group entry Specified by:

addGroupEntry in interface GroupManagement
Parameters:
context -
276
Returns: Throws:
See Also:
RemoteException
addMemberEntry
public sorcer.service.Context addMemberEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add member entry Specified by:

addMemberEntry in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
addMembershipEntry
public sorcer.service.Context addMembershipEntry(sorcer.service.Context context) throws java.rmi.RemoteException
add membership entry Specified by:

addMembershipEntry in interface GroupManagement
Parameters:
context -
277
Returns: Throws:
See Also:
RemoteException
executeQuery
public sorcer.service.Context executeQuery(sorcer.service.Context context) throws java.rmi.RemoteException
execute query Specified by:

executeQuery in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
executeUpdate
public sorcer.service.Context executeUpdate(sorcer.service.Context context) throws java.rmi.RemoteException
execute update Specified by:

executeUpdate in interface GroupManagement
Parameters:
context -
278
Returns: Throws:
See Also:
RemoteException
getActionInfo
public sorcer.service.Context getActionInfo(sorcer.service.Context context) throws java.rmi.RemoteException
get action info Specified by:

getActionInfo in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
getActivities
public sorcer.service.Context getActivities(sorcer.service.Context context) throws java.rmi.RemoteException
get all activities Specified by:

getActivities in interface GroupManagement
Parameters:
context -
279
Returns: Throws:
See Also:
RemoteException
getActivityEntry
public sorcer.service.Context getActivityEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get activity entry Specified by:

getActivityEntry in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
getAdmin
public java.lang.Object getAdmin() throws java.rmi.RemoteException
get administrative object Specified by:

getAdmin in interface net.jini.admin.Administrable
Returns: Throws:
280
getExecutions
public sorcer.service.Context getExecutions(sorcer.service.Context context) throws java.rmi.RemoteException
get all executions Specified by:

getExecutions in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
getExertionEntry
public sorcer.service.Context getExertionEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get exertion entry Specified by:

getExertionEntry in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
281
getExertions
public sorcer.service.Context getExertions(sorcer.service.Context context) throws java.rmi.RemoteException
get all exertions Specified by:

getExertions in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
getGroupAction
public sorcer.service.Context getGroupAction(sorcer.service.Context context) throws java.rmi.RemoteException
get group actions Specified by:

getGroupAction in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
282
getGroupEntry
public sorcer.service.Context getGroupEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get group entry Specified by:

getGroupEntry in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
getGroupExertions
public sorcer.service.Context getGroupExertions(sorcer.service.Context context) throws java.rmi.RemoteException
get group exertions Specified by:

getGroupExertions in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
283
getGroupMembers
public sorcer.service.Context getGroupMembers(sorcer.service.Context context) throws java.rmi.RemoteException
get group members Specified by:

getGroupMembers in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
getGroups
public sorcer.service.Context getGroups(sorcer.service.Context context) throws java.rmi.RemoteException
get all groups Specified by:

getGroups in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
284
getInner
public java.rmi.Remote getInner() throws java.rmi.RemoteException
get inner provider Specified by:

getInner in interface sorcer.core.provider.proxy.Outer
Returns: remote provider object Throws:

getMemberEntry
public sorcer.service.Context getMemberEntry(sorcer.service.Context context) throws java.rmi.RemoteException
get member entry Specified by:

getMemberEntry in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
getMembers
public sorcer.service.Context getMembers(sorcer.service.Context context) throws java.rmi.RemoteException
get all members 285
Specified by:
getMembers in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
getMemberships
public sorcer.service.Context getMemberships(sorcer.service.Context context) throws java.rmi.RemoteException
get all memberships Specified by:

getMemberships in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
getProviderID
public sorcer.service.Context getProviderID(sorcer.service.Context context) throws java.rmi.RemoteException
retrieves provider id 286
Specified by:
getProviderID in interface GroupManagement
Parameters:
context -
Returns: Throws:
See Also:
RemoteException
initDB
private void initDB()
initialize the database, and create if not existent
service
public sorcer.service.Exertion service(sorcer.service.Exertion exertion, net.jini.core.transaction.Transaction transaction) throws java.rmi.RemoteException
return service object Specified by:

service in interface sorcer.service.Servicer
Parameters:
exertion transaction -
Returns: Throws:
See Also: 287

RemoteException
setAdmin
public void setAdmin(java.lang.Object admin)
set administrative object Specified by:

setAdmin in interface sorcer.core.provider.proxy.Partnership
Parameters:
admin -
setInner
public void setInner(java.lang.Object provider)
set inner provider Specified by:

setInner in interface sorcer.core.provider.proxy.Partnership
Parameters:
provider -
288
Interface sorcer.core.loki.key.KeyGenerationManagement
All Known Implementing Classes: KeyGenerator
public interface KeyGenerationManagement
The Key Generation Management provides the interface for both key and key agremment generation, as well as the framework specific implementation of the complimentary compound key and the shared key object.
Method Summary
java.util.Map<java.lang.String,j genCompoundKeys(java.lang.String[] id ava.security.Key> s, java.security.KeyPair[] pairs)
Generate complimentary compound keys

java.util.Map<java.lang.String,j genCompoundKeys(java.util.Vector<java ava.security.Key> .lang.String> ids, java.util.Vector<java.security.KeyPai r> pairs)
javax.crypto.KeyAgreement genKeyAgreement(java.security.KeyPair myKP)
Generate key agreement

java.security.KeyPair genKeyPair()
Generate key pair

javax.crypto.KeyAgreement genSharedKey(javax.crypto.KeyAgreemen t agree, java.security.Key compKey)
Generate shared key based on the complimentary compound key
289
Method Detail
genCompoundKeys
java.util.Map<java.lang.String,java.security.Key> genCompoundKeys(java.lang.String[] ids, java.security.KeyPair[] pairs) throws java.security.InvalidKeyException, java.security.NoSuchAlgorithmException
Generate complimentary compound keys Parameters:

agrees pairs -
Returns: Throws:
InvalidKeyException; java.security.InvalidKeyException java.security.NoSuchAlgorithmException
See Also:
InvalidKeyException;
genCompoundKeys
java.util.Map<java.lang.String,java.security.Key> genCompoundKeys(java.util.Vector<java.lang.String> ids, java.util.Vector<java.security.KeyPair> pairs) throws java.security.InvalidKeyException, java.security.NoSuchAlgorithmException
Throws:
java.security.InvalidKeyException java.security.NoSuchAlgorithmException
290
genKeyAgreement
javax.crypto.KeyAgreement genKeyAgreement(java.security.KeyPair myKP) throws java.security.InvalidKeyException, java.security.NoSuchAlgorithmException
Generate key agreement Parameters:

myKP - the previously generated key pair
Returns: generated key agreement Throws:

See Also:
InvalidKeyException, NoSuchAlgorithmException
genKeyPair
java.security.KeyPair genKeyPair() throws java.security.InvalidAlgorithmParameterException, java.security.NoSuchAlgorithmException
Generate key pair Returns: the generated key pair Throws:

java.security.InvalidAlgorithmParameterException java.security.NoSuchAlgorithmException
See Also:
InvalidAlgorithmParameterException, NoSuchAlgorithmException
291
genSharedKey
javax.crypto.KeyAgreement genSharedKey(javax.crypto.KeyAgreement agree, java.security.Key compKey) throws java.security.InvalidKeyException
Generate shared key based on the complimentary compound key Parameters:

agree compKey -
Returns: Throws:
java.security.InvalidKeyException
See Also:
InvalidKeyException
292
Class sorcer.core.loki.key.KeyGenerator
java.lang.Object sorcer.core.loki.key.KeyGenerator
All Implemented Interfaces: KeyGenerationManagement
public class KeyGenerator extends java.lang.Object implements KeyGenerationManagement
key generator for the implementation and operation of the multi diffie hellman key exhange protocol in order to implement groups in an ad hoc space computing environment
Field Summary
private g512 static java.math.BigInteger
g component of multi diffie hellman key exchange
private p512 static java.math.BigInteger
p component of multi diffie hellman key exchange
Constructor Summary
KeyGenerator()
293
Method Summary
java.util.Map<java.lang.String, genCompoundKeys(java.lang.String[] ids java.security.Key> , java.security.KeyPair[] pairs)
generate complimentary compound key array for multi diffie hellman key exchange
java.util.Map<java.lang.String, genCompoundKeys(java.util.Vector<java. java.security.Key> lang.String> ids, java.util.Vector<java.security.KeyPair > pairs)
generate complimentary compound key array for multi diffie hellman key exchange
javax.crypto.KeyAgreement genKeyAgreement(java.security.KeyPair myKP)
generate key agreement based on key pair for multi diffie hellman key exchange
java.security.KeyPair genKeyPair()
generate key pair for multi diffie hellman key exchange

javax.crypto.KeyAgreement genSharedKey(javax.crypto.KeyAgreement agree, java.security.Key compKey)
generate shared key for multi diffie hellman key exchange based on specific complimentary compound key
private static java.security.Key recKey(javax.crypto.KeyAgreement[] agr ees, java.security.KeyPair[] pairs, int index, int cur)
recursive function neccesary for complimentary compound key creation

private static java.security.Key recKey(java.util.Vector<javax.crypto.K eyAgreement> agrees, java.util.Vector<java.security.KeyPair > pairs, int index, int cur)
294

Field Detail
g512
private static java.math.BigInteger g512
g component of multi diffie hellman key exchange
p512
private static java.math.BigInteger p512
p component of multi diffie hellman key exchange
Constructor Detail
KeyGenerator
public KeyGenerator()
Method Detail
genCompoundKeys
public java.util.Map<java.lang.String,java.security.Key> genCompoundKeys(java.lang.String[] ids, java.security.KeyPair[] pairs) throws java.security.InvalidKeyException, java.security.NoSuchAlgorithmException
295
generate complimentary compound key array for multi diffie hellman key exchange Specified by:
genCompoundKeys in interface KeyGenerationManagement
Parameters:
ids pairs -
Returns: Throws:
See Also:
InvalidKeyException
genCompoundKeys
public java.util.Map<java.lang.String,java.security.Key> genCompoundKeys(java.util.Vector<java.lang.String> ids, java.util.Vector<java.security.KeyPair> pairs) throws java.security.InvalidKeyException, java.security.NoSuchAlgorithmException
generate complimentary compound key array for multi diffie hellman key exchange Specified by:
genCompoundKeys in interface KeyGenerationManagement
Parameters:
ids pairs -
Returns: Throws: 296

See Also:
InvalidKeyException
genKeyAgreement
public javax.crypto.KeyAgreement genKeyAgreement(java.security.KeyPair myKP) throws java.security.InvalidKeyException, java.security.NoSuchAlgorithmException
generate key agreement based on key pair for multi diffie hellman key exchange Specified by:
genKeyAgreement in interface KeyGenerationManagement
Parameters:
mkKP -
Returns: Throws:
See Also:
InvalidKeyException, NoSuchAlgorithmException
genKeyPair
public java.security.KeyPair genKeyPair() throws java.security.InvalidAlgorithmParameterException, java.security.NoSuchAlgorithmException
generate key pair for multi diffie hellman key exchange Specified by:
genKeyPair in interface KeyGenerationManagement
297
Returns: Throws:
java.security.InvalidAlgorithmParameterException java.security.NoSuchAlgorithmException
See Also:
InvalidAlgorithmParameterException, NoSuchAlgorithmException
genSharedKey
public javax.crypto.KeyAgreement genSharedKey(javax.crypto.KeyAgreement agree, java.security.Key compKey) throws java.security.InvalidKeyException
generate shared key for multi diffie hellman key exchange based on specific complimentary compound key Specified by:
genSharedKey in interface KeyGenerationManagement
Parameters:
agree compKey -
Returns: Throws:
See Also:
InvalidKeyException
recKey
private static java.security.Key recKey(javax.crypto.KeyAgreement[] agrees, java.security.KeyPair[] pairs, int index, int cur)
298

throws java.security.InvalidKeyException
recursive function neccesary for complimentary compound key creation Parameters:

agrees pairs index cur -
Returns: Throws:
recKey
private static java.security.Key recKey(java.util.Vector<javax.crypto.KeyAgreement> agrees, java.util.Vector<java.security.KeyPair> pairs, int index, int cur) throws java.security.InvalidKeyException
Throws:
299
Class sorcer.core.loki.key.FixedRandom
java.lang.Object java.util.Random java.security.SecureRandom sorcer.core.loki.key.FixedRandom
All Implemented Interfaces: java.io.Serializable
public class FixedRandom extends java.security.SecureRandom
Is used in generating a random component for cryptographic functions, ciphering, and key component creation See Also: Serialized Form
Field Summary
(package private) sha java.security.MessageDigest
message digest
(package private)
byte[] state
state byte object generated from digest
Constructor Summary
FixedRandom()
constructor initializes all local objects
300
Method Summary
void nextBytes(byte[] bytes)
inherited method modified to fix length of randomization
Methods inherited from class java.security.SecureRandom

generateSeed, getAlgorithm, getInstance, getInstance, getInstance, getProvider, getSeed, next, setSeed, setSeed
Methods inherited from class java.util.Random

nextBoolean, nextDouble, nextFloat, nextGaussian, nextInt, nextInt, nextLong

Field Detail
sha
java.security.MessageDigest sha
message digest 301
state
byte[] state
state byte object generated from digest
Constructor Detail
FixedRandom
FixedRandom()
constructor initializes all local objects
Method Detail
nextBytes
public void nextBytes(byte[] bytes)
inherited method modified to fix length of randomization Overrides:

nextBytes in class java.security.SecureRandom
Parameters:
bytes -
302
Class sorcer.core.loki.member.LokiMemberUtil
java.lang.Object sorcer.core.loki.member.LokiMemberUtil
public class LokiMemberUtil extends java.lang.Object
Field Summary
private boolean debug
debug switch
private boolean debugdb
debug db switch
private java.lang.String groupName
Group Name
private java.lang.String groupSeqId
Group sequence identifier

protected logger static java.util.logging.Logger Logger object private java.lang.String memberSeqId
unique sequence identifier

private EncryptionManagement myCryptMan
encryption manager
private myKeyAgreement javax.crypto.KeyAgreement key agreement private myKeyGen KeyGenerationManagement key generation manager
303

private java.security.KeyPair myKeyPair
key pair
private java.lang.String myName
name identifier
private java.lang.String myUID
unique identifier
Constructor Summary
LokiMemberUtil(java.lang.String name)
initializes all local variables and retrieves the compound key, and utilizes it to compute the shared key
Method Summary
private java.lang.String printEE(java.lang.String header, sorcer.core.exertion.ExertionEnvelop ee)
CCKExertion readCCK(java.lang.String serviceType)
sorcer.core.exertion.Exerti readEnEE(sorcer.core.exertion.ExertionEnve onEnvelop lop template, net.jini.core.transaction.Transaction txn)
KPExertion readKP(java.lang.String serviceType, java.util.Vector<java.lang.String> ids, java.util.Vector<java.security.KeyPair> r_
304

pairs)
void setGroupName(java.lang.String gname)
void setGroupSeqId(java.lang.String GSUID)
CCKExertion takeCCK(java.lang.String serviceType)
sorcer.core.exertion.Exerti takeEnEE(sorcer.core.exertion.ExertionEnve onEnvelop lop template, net.jini.core.transaction.Transaction txn)
KPExertion takeKP(java.lang.String serviceType, java.util.Vector<java.lang.String> ids, java.util.Vector<java.security.KeyPair> r_ pairs)
sorcer.core.exertion.Exerti takewriteCCKExertion(java.lang.String serv onEnvelop iceType)
sorcer.core.exertion.Exerti takewriteCKPExertion(java.lang.String serv onEnvelop iceType)
sorcer.core.exertion.Exerti takewriteKPExertion(java.security.Key crea onEnvelop torPublicKey, java.lang.String serviceType)
sorcer.core.exertion.Exerti writeEnEE(sorcer.core.exertion.ExertionEnv onEnvelop elop template)
305

Field Detail
debug
private boolean debug
debug switch
debugdb
private boolean debugdb
debug db switch
groupName
private java.lang.String groupName
Group Name
groupSeqId
private java.lang.String groupSeqId
Group sequence identifier
logger
protected static java.util.logging.Logger logger
Logger object 306
memberSeqId
private java.lang.String memberSeqId
unique sequence identifier
myCryptMan
private EncryptionManagement myCryptMan
encryption manager
myKeyAgreement
private javax.crypto.KeyAgreement myKeyAgreement
key agreement
myKeyGen
private KeyGenerationManagement myKeyGen
key generation manager
myKeyPair
private java.security.KeyPair myKeyPair
key pair
myName
private java.lang.String myName
name identifier
myUID
private java.lang.String myUID
307
unique identifier
Constructor Detail
LokiMemberUtil
public LokiMemberUtil(java.lang.String name)
initializes all local variables and retrieves the compound key, and utilizes it to compute the shared key
Method Detail
printEE
private java.lang.String printEE(java.lang.String header, sorcer.core.exertion.ExertionEnvelop ee)
readCCK
public CCKExertion readCCK(java.lang.String serviceType)
readEnEE
public sorcer.core.exertion.ExertionEnvelop readEnEE(sorcer.core.exertion.ExertionEnvelop template, net.jini.core.transaction.Transaction txn)
readKP
public KPExertion readKP(java.lang.String serviceType, java.util.Vector<java.lang.String> ids, java.util.Vector<java.security.KeyPair> r_pairs)
setGroupName
public void setGroupName(java.lang.String gname)
308
setGroupSeqId
public void setGroupSeqId(java.lang.String GSUID)
takeCCK
public CCKExertion takeCCK(java.lang.String serviceType)
takeEnEE
public sorcer.core.exertion.ExertionEnvelop takeEnEE(sorcer.core.exertion.ExertionEnvelop template, net.jini.core.transaction.Transaction txn)
takeKP
public KPExertion takeKP(java.lang.String serviceType, java.util.Vector<java.lang.String> ids, java.util.Vector<java.security.KeyPair> r_pairs)
takewriteCCKExertion
public sorcer.core.exertion.ExertionEnvelop takewriteCCKExertion(java.lang.String serviceType)
takewriteCKPExertion
public sorcer.core.exertion.ExertionEnvelop takewriteCKPExertion(java.lang.String serviceType)
takewriteKPExertion
public sorcer.core.exertion.ExertionEnvelop takewriteKPExertion(java.security.Key creatorPublicKey, java.lang.String serviceType)
309
writeEnEE
public sorcer.core.exertion.ExertionEnvelop writeEnEE(sorcer.core.exertion.ExertionEnvelop template)
310
Permission To Copy
In presenting this thesis in partial fulfillment of the requirements for a masters degree at Texas Tech University or Texas Tech University Health Sciences Center, I agree that the Library and my major department shall make it freely available for research purposes. Permission to copy this thesis for scholarly purposes may be granted by the Director of the Library or my major professor. It is understood that any copying or publication of this thesis for financial gain shall not be allowed without my further written permission and that any user may be liable for copyright infringement.
Agree (Permission is granted.) ______________________________ Student Signature ________________ Date
Disagree (Permission is not granted.) Daniel Robert Kerr_______________ Student Signature March 17th, 2008___ Date

Kerr Daniel Thesis PDF

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Kerr Daniel Thesis PDF

Transféré par

Droits d'auteur :

Formats disponibles

Space Computing with Group Key Agreement

By Daniel Robert Kerr, B.S.

A Thesis in Computer Science

Copyright 2007 Daniel Robert Kerr

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Can all space computing functionality be maintained with the implementation of

Is there an asymmetric encryption method that is scalable to larger numbers of

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

List of Universal Modeling Language Diagrams

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Chapter 2 Background and Literature Review Distributed Computing

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Figure 2: : Grid Computing (Yao 2006) 6

Texas Tech University, Daniel Robert Kerr, May 2008

Figure 3: : Peer to Peer Computing (Peer-to-Peer Peer (P2P) Computing 2006)

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Diagram 1: : Javaspace Functions (Arnold, Freeman and Hupfer 1999)

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Diagram 2: Symmetric Encryption v0.1

Texas Tech University, Daniel Robert Kerr, May 2008

Ron Rivest, 1994

Rivest, Sidney, and Yin, 1996

Xuejia Lai and James L. Massey, 1991

(Sobolewski, Secret Key Cryptography 2007)

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Diagram 3: Asymmetric Encryption v0.1

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Texas Tech University, Daniel Robert Kerr, May 2008

Federated Intelligent Product Environment (FIPER)

Texas Tech University, Daniel Robert Kerr, May 2008

Diagram 5: : FIPER Organizational Architecture (Sobolewski, SORCER Publications 2002)

Texas Tech University, Daniel Robert Kerr, May 2008

Service Protocol Oriented Architecture (SPOA)

Service Object Oriented Architecture (SOOA)

Texas Tech University, Daniel Robert Kerr, May 2008

Diagram 6: : Service Object Object-Oriented Architecture (Sobolewski, SORCER Publications 2007)

Jini Network Technology

Texas Tech University, Daniel Robert Kerr, May 2008

Service Oriented Computing Environment (SORCER)

Texas Tech University, Daniel Robert Kerr, May 2008

Diagram 7: : Service Oriented Architecture (Sobolewski, SORCER Publications 2007)

Texas Tech University, Daniel Robert Kerr, May 2008