Implementation and Experimental Results of DRA4WfMS

We implemented the proposed DRA4WfMS API in order to make it easy for the programmer to write appropriate AEA software. We implemented the DRA4WfMS API in Java programming language and then constructed an AEA to conduct experiments on the operational models presented in Section 4.1.

4.5.1 DRA4WfMS API

The DRA4WfMS API is implemented in the Java programming language (it can also be extended to other programming languages). The main Java classes used include DraHandler, Participant, DraInstance, VerifyResult, and CER. The DraHandler is the core class in this API, and is responsible for parsing, verifying, decrypting, and encrypting a DRA4WfMS document, and embedding CERs. The Participant class is used to specify the related information of the user who executes AEA software. The object with class type DraInstance is an instance of a DRA4WfMS document that is bound to a participant. The VerifyResult objects are generated by the DraHandler class, and they record the result of verifying the embedded digital signatures in a DRA4WfMS document. Objects with the CER class type are generated by the DraHandler class.

Figure 36 shows the codes that use the DRA4WfMS API to construct an AEA. It consists of the following steps:

Step 1: We first have to instantiate a DraDocument object to obtain the issuer of the certificate that is used to embed digital signatures in CERs. We then instantiate a Participant object by giving the user id, the key for generating

digital signatures (cert), and a group of keys for decrypting and encrypting documents (keystore). We can then generate an instance of DraInstance.

Step 2: Before executing the activity we have to verify the embedded digital signatures in the DRA4WfMS document. Since the document may contain many digital signatures, the results are stored in a list of VerifyResult objects.

Step 3: The target DRA4WfMS document is decrypted, after which we can obtain the CERs therein.

Step 4: We now have to obtain the activities that are to be executed and check if the participant is one of the performers. currentActivities stores the activities that should be executed by the participant now.

Step 5: We start the execution of the activity. We first have to show the presentation objects to the participant.

Step 6: We obtain the execution result (some input objects) from the participant and store it in a doc object.

Step 7: We encrypt and add a digital signature to the target DRA4WfMS document.

We have now successfully embedded a CER in it.

Step 8: Finally, we produce a DRA4WfMS document and send it to the participant(s) of the subsequent activity(ies).

Figure 36. Codes to invoke the DRA4WfMS API to construct an AEA

// Codes to show the results in “VerifyResult” are placed here.

}

DraInstance decryptedDoc = DraHandler.decrypt(doc);

List<CER> obtainedCERs = decryptedDoc.getCERs();

// Codes to show CERs in “obtainedCERs” may be placed here.

Activities currentActivities = decryptedDoc.getCurrentActivities();

// We assume that there is only one activity in "currentActivities."

Presentation currentPre = act.getPresentation();

// Codes to show input and output objects in "currentPre"

// should be placed here.

DraInput myInput = new DraInput();

// Codes to get input objects specified in "currentPre" from participant // and store in “myInput” should be placed here.

myInput.add(key1, value1);

// Codes to send the generated document “doc” to // participants of subsequent activities according to // the “nextActivityUnits” are placed here.

// We assume that the path name of a DRA4WfMS document is stored in // "filename"

DraDocument DraDoc=DraHandler.getDraDocument(filename);

CertificateInfo SigIssuer=DraDoc.getSignatureIssuer();

// Codes to obtain an appropriate certificate for digital signatures according to "SigIssuer" are placed here.

// We assume that we pick up "cert" as the certificate.

Participant participant = new Participant(id, cert, keystore);

DraInstance doc = DraHandler.getDraInstance(DraDoc, participant);

Start of

Figure 37. Two workflow processes for conducting experiments

4.5.2 Experimental Results

All of the experiments were performed on a PC with a 2.4-GHz Intel Core 2 Quad processor, 4 GB of RAM, the Microsoft Windows 7 operating system, and Java Development Kit 6. Operations related to the use of digital signatures in the DRA4WfMS API employed the Java XML Digital Signature API [121], which follows the standard of XML signature syntax and processing [113]. The element-wise encryption and decryption in the DRA4WfMS API used the Apache Santuario library [123], which follows the standard of XML encryption syntax and processing [118].

We successfully conducted experiments on some workflow processes with many activities and complex flow-control mechanisms. However, because of space limitations, we only report the experimental results for a workflow process with a small number of activities. Figure 37A shows a workflow that contains five activities and representative flow-control mechanisms such as sequence, loop, split, and join. We first employed the basic operational model of the DRA4WfMS as shown in Figure 17 to execute this workflow process. We measured the following parameters: (1) the time required for the

AEA to decrypt cipher data and verify digital signatures when it receives a DRA4WfMS document, (2) the time required for the AEA to encrypt the document and embed digital signatures after the participant finishes executing an activity, and (3) the size of the generated DRA4WfMS documents after the execution of each activity. As indicated in Table 1, it takes more time to verify all of the embedded digital signatures than to actually embed them after the participant finishes executing the activity, since only a single digital signature is embedded after executing the activity in most cases. The size of the DRA4WfMS documents and the time required to decrypt and verify signatures are both proportional to the numbers of CERs and signatures in the documents. However, encrypting and embedding signatures take a constant time. This workflow comprising five activities required less than 23 kB to record the workflow definition, security definition, activity execution results, timestamps, and digital signatures.

Table 1. Result parameters for the workflow shown in Figure 37A Number of

signatures to verify

Number of

CERs   

Initial document 7,119

X_A^′′< 0 > 1 1 0.0030 0.0156 8,667

X_B1^′′ < 0 > 2 2 0.0041 0.0167 10,184

X_B2^′′ < 0 > 2 2 0.0049 0.0145 10,184

X_C^′′< 0 > 4 4 0.0055 0.0148 13,503

X_D^′′< 0 > 5 5 0.0072 0.0147 15,015

X_A^′′< 1 > 6 6 0.0079 0.0130 16,562

X_B1^′′ < 1 > 7 7 0.0088 0.0132 18,079

X_B2^′′ < 1 > 7 7 0.0093 0.0116 18,079

X_C^′′< 1 > 9 9 0.0133 0.0118 21,398

X_D^′′< 1 > 10 10 0.0132 0.0121 22,910

: Time required to decrypt and verify signatures (in seconds)

: Time required to encrypt and embed signatures (in seconds)

: Size of the generated file (in bytes)

Figure 37B is the other workflow process investigated in our experiments. It is a workflow process that executes the process in Figure 37A according to the advanced operational model of the DRA4WfMS as shown in Figure 20. The results are presented in Table 2. Similar to the results for the basic operational model, the size of the DRA4WfMS and the time required to decrypt and verify signatures in the AEA and TFC server are both proportional to the numbers of CERs and signatures in the documents.

Encrypting and embedding signatures only need a constant time. Although the total processing times of the AEA and TFC server are very close, the TFC server does not need to make a connection-oriented session with the participant. Thus, the TFC server will not be a bottleneck in the operation of the DRA4WfMS.

The binary codes of the DRA4WfMS API, the sample codes to use it to construct an AEA, and all of the DRA4WfMS documents generated in the two workflow processes

can be downloaded at

http://www.csie.ntnu.edu.tw/~ghhwang/DRA4WfMS/DRA4WfMS_EXAMPLES.zip.

Table 2. Result parameters for the workflow shown in Figure 37B

: Time required to decrypt and verify signatures in the AEA and TFC server (in seconds)

: Time required to encrypt and embed signatures in the AEA (in seconds)

: Time required to encrypt and embed signatures in the TFC server (in seconds)

: Size of the generated file (in bytes)

4.5.3 The Pool of DRA4WfMS Documents

We employed the Apache Hadoop [119] to implement the pool of DRA4WfMS documents (shown in Figure 35), which was constructed by the HBase database.

HBase is a distributed column-oriented database built on top of HDFS (the distributed file system of Hadoop), and is the optimal Hadoop application to

use when real-time read/write random accesses to very large datasets are required. A DRA4WfMS document is stored as a cell in a row of an HBase table. An AEA connects to one of the portal servers in the DRA4WfMS cloud system. The portal server authenticates the ID of the user and then interacts with an HBase cluster (the pool of DRA4WfMS documents) to perform the following operations:

— Search DRA4WfMS documents: The user can obtain a list of links of DRA4WfMS documents where s/he is one of the participants of the subsequent activities. A very similar procedure is used to obtain the TO-DO list in a WfMS.

— Retrieve a DRA4WfMS document: According to the search result, the user can retrieve a DRA4WfMS document and then execute the activity in an AEA.

— Store a DRA4WfMS document: The resulting DRA4WfMS document produced by an AEA should be stored in the pool of DRA4WfMS documents.

— Notify the subsequent participants: After a resulting DRA4WfMS document is stored, the portal server should inform the participants of the next activities.

— Perform workflow monitoring or statistical analyses: The user can display information about the activity status of a workflow process.

Also, the MapReduce computing model supported in the HBase system can apply some statistical analyses to workflow processes or instances stored in the DRA4WfMS cloud system.