Ant-based interactive workflow management: a case study on RMI

INTERNATIONAL JOURNAL OF COMMUNICATION SYSTEMS Int. J. Commun. Syst. 2015; 28:1329 1339 Published online 3 March 2014 in Wiley Online Library (wileyonlinelibrary.com)..2766 Ant-based interactive workflow management: a case study on RMI Ahmet Sayar*, Department of Computer Engineering, Kocaeli University, Kocaeli, Turkey SUMMARY This paper proposes a web-based interactive workflow definition and invocation system assisting users in orchestrating a set of distributed services-activities and expressing complex dependencies between them in XML. We use Ant, which is a Java-based and freely distributed commodity tool, for workflow definitions and workflow engine. Adopting Ant as a workflow engine provides platform independence and immediate integration into the Grid services framework. Sometimes, workflow scripts need to be used repeatedly with a little change; framework enables reusable scripts to be created, stored and edited for later use. This allows sharing and dynamic modifications of workflows between multiple participants. The practicality and usefulness of the system is demonstrated through a concrete case study on Remote Method Invocation (RMI) jobs. Copyright 2014 John Wiley & Sons, Ltd. Received 14 January 2013; Revised 13 August 2013; Accepted 2 February 2014 KEY WORDS: workflow; ant; distributed processes; interactive; RMI 1. INTRODUCTION With the advent of Grid and application technologies, scientists are building more and more complex applications to manage and process large data sets, as well as to execute scientific experiments on distributed resources. Such application scenarios require means for composing and executing complex workflows [1]. Scientific workflows are becoming increasingly important as a mechanism for orchestrating distributed resources such as computational devices, data, applications and scientific instruments on the Grid environment. However, the lack of generic graphical interfaces that abstract the technical details for domain scientists has gradually become a major obstacle for them to easily master the workflow systems. Process management is very crucial in large scale science and business applications. Some processes might need to involve some other processes to fulfill their goals. These processes are called dependable processes and should run in coordination and in a synchronized way. Dependencies and orderings among those processes are defined by a user or a main process. The documents defining orderings and dependability of tasks are basically named as workflow scripts. These issues are studied in workflow research domain. Workflow management systems are mostly deployed in science portals [2] for remote experiment control and collaborative, Grid-based distributed analysis in applied sciences, using crossinstitutional integration of heterogeneous information and resources. They are also used, smoothly connecting the data producing equipment to the compute, storage and visualization center, which are usually not on the same site. Workflow systems aim at collaboration and/or integration of (i) data sources, (ii) expert scientists from various domains and (iii) super computers, which are geographically dispersed. *Correspondence to: Ahmet Sayar, Department of Computer Engineering, Kocaeli University Kocaeli, Turkey. E-mail: ahmet.sayar@kocaeli.edu.tr Copyright 2014 John Wiley & Sons, Ltd.

1330 A. SAYAR This paper presents an interactive workflow management framework based on a build tool called Ant [3]. Ant is a build and deployment tool for the projects written in Java. It is open source, platform-independent and freely distributed by Apache Software Foundation [4]. Ant supports sequential and parallel execution containers that allow subtasks to be executed in sequence or in parallel, respectively. Ant provides a flexible mechanism to express script dependencies in a project build process. Ant tasks and dependencies are expressed in XML. The proposed system aims at collaboration and cooperation of multi-disciplinary teams located at geographically dispersed sites. Some people have more experience and knowledge for some specific jobs, and others might need their help to create a workflow script to run applications. In such collaboration, the first group of people takes over the admin role, and the second group of people takes over the user role. Admin creates template workflow scripts (which is a kind of ant build.xml file). Template defines application and workflow-specific rules and restrictions. In the template, some parts are completed by admin and some parts are left for users to fill in. Users are people defining actual workflow scripts (instances), based on their application-specific purposes. They convert template build workflow script files into actual workflow scripts. These reusable templates help users to be able to use the applications appropriately. The system provides users with the forms (templates) created with the admin-given parameters. The workflow scripts (instances) are created automatically by the system with the user-given parameters. The system also enables triggering application run and see the outcomes on the interactive screen. The proposed system has advantages regarding creation and usage of workflows collaboratively. In this respect, sometimes, workflow scripts need to be used repeatedly with a little change. Rewriting everything from the scratch and running them are time-consuming. Instead of doing repeating parts, users need to update just changing parts. Updating and editing on previously created workflow definitions are carried out by storing/fetching them to/from nonvolatile storages. Storages are located on local server s file system. Another advantage of the system is related to ease of use. Application users might not know what servers to be involved in and in what orders. They might not even know what parameters need to be fed into the system. On the other hand, admin has better knowledge on the system and help users to create satisfying workflow definitions. We have created admin and user tools enabling creation and invocation of Apache Ant build templates and corresponding instances remotely through graphical user interface. The proposed architecture gives the admin a control capability over the running parameters of the workflow instances created by the application users. During the creation of workflow instances from the script templates, some parameters can be set by the user but others cannot. These settings are carried out by the admin at the Ant build template creation stage. In order to run an application through Ant workflow script instance, application users open their interfaces on the browser, select one of the workflow script templates, fill it out, run it and get the output on the screen. The proposed system is tested in a use case scenario, which is based on Remote Method Invocation (RMI) jobs. Jobs are defined in the form of Ant s build target elements, and dependencies are defined according to the Ant s build file schema. In the scenario, admin defines the workflow, and users run the system with their application-specific parameters and get the outputs on the screen as a log file. This paper is structured as follows. Section 2 gives related works on visual workflow designs. Section 3 presents general framework of the proposed architecture. Section 4 is a case study on RMI jobs. Section 5 concludes the paper. 2. RELATED WORK Process management is an extremely important concept in both business and scientific communities. Several workflow management tools have been proposed in recent years offering advanced functionality in various domains. The idea of workflow is also used in network domain, such as sensor networks and wireless networks. However, it might take different names such as linking [5] and chaining [6]. Liu et al. [5] propose a scheme on constructing a vehicular ad hoc network

ANT-BASED INTERACTIVE WORKFLOW MANAGEMENT 1331 based on cluster chains. Xiaonan and Huanyan [6] address the joint link scheduling and multiplayer communication challenges in wireless networks. In the business, considerable amount of works has been carried out on workflows. Flower [7], Yawl [8], Staffware [9], WebSphere MQ Workflow [10], Cosa [11], SAP Workflow [12] and FileNet [13] can be given as examples of popular workflow systems developed so far. These products offer extensive functionality and support a variety of workflow patterns [14]. However, all of them are propriety software and commercially motivated, making it infeasible to use them for open-source research projects. Although a few general-purpose open-source workflow toolkits [15] are available for use, they are platform-dependent and offer limited functionality. In the scientific world, several open-source workflow management tools are freely available. However, they are directed toward service aggregation rather than distributed process management in Grid computing [16, 17] and web service environments. Business Process Execution Language (BPEL) [18] is a widely accepted and used standard in composition of web-services. It basically defines the standards for process definitions and dependence relations. However, generic graphical interfaces that abstract the technical details for domain scientists are not defined by BPEL. Some researches have been conducted to address these issues by developing BPEL-based visual scientific workflow designers. Triana [19], ChinaGrid Support Platform [20] and Jasmine [21] can be given as examples. Triana actually uses BPEL4WS to define the workflows. There are some other BPEL-based workflow designing projects in business world. Oracle s BPEL Designer [22] provides a one-to-one mapping to BPEL and a flow constructer. IBM s BPWS4J [23] editor relies on a tree-based one-to-one representation of BPEL. In addition to BPEL-based visual workflow design systems, there are some other works. Taverna [24] is aimed at developing workflows in bioinformatics domain on the Grid. It provides interactive execution and monitoring interfaces to handle workflows. It uses Simple Conceptual Unified Flow Language for workflows. Kepler [25] is another well-known workflow system enabling interactive visual interface for designing workflows. It focuses on the actor-oriented design. An actor is an encapsulated process defined with its parameters. Executions are controlled according to those actors. Workflows are modeled as compositions of actors and saved in Modeling Markup Language. The proposed system in this paper is similar to Kepler s actor-based workflow system. The system enables workflow definitions a priori and controls the clients workflow creations and executions by using those definitions. The proposed system also saves the workflows in XML-based format in accordance with Ant s build file schema. GridAnt is another related work in this context. It proposes a client-controllable workflow system and uses Ant for the pipeline processing. The Apache Ant [4] is basically a project deployment framework in Java environments. It is platform-independent, XML-based and presents certain characteristics that seem to make it suitable as a workflow language and engine. Features such as native dependence structured build targets make it easy to write declarative dependence-based workflows. One can consider workflows that can be described by an acyclic graph, where nodes of the graph represent a task to be performed and edges represent dependencies between tasks. This is harder to represent with a scripting language without a substantial additional framework behind it, but it is not at all difficult to represent with a tool like Ant [26]. GridAnt extends Ant functionalities and capabilities to decrease its deficiencies in using as a workflow tool, but we use Ant in its pure form and propose an intermediary architecture enabling creation of Ant build tools as workflow scripts. We also provide application users with the tools to run distributed chained processes remotely in accordance with the predefined workflows. We propose general tasks and focus on the creation of script-based workflow templates interactively. 3. ARCHITECTURE Tasks are rarely standalone; they often depend on each other s outcomes. Thus, for complex processes, coordinating the execution of lengthy sequences of tasks manually is counter-productive, uninteresting and error-prone. Handling such systems even becomes worse when the task runs on different machines belonging to the different administrative domains.

1332 A. SAYAR There are some ways to put the tasks in order and chain them accordingly to achieve the systemwide goals. Using both workflow languages and corresponding workflow engines is the most efficient way of doing this. Workflows are different from the scheduling [27 30]. Scheduling is the method by which threads, processes or data flows are given access to system resources (e.g., processor time and communications bandwidth). In the workflow, the concern is the process flow and their order. Workflow engines are the heart of the workflow systems. The engines are responsible for directing the flow of control and data through multiple activities and tasks. In the proposed system, tasks are named as targets. Rather than developing the engine from scratch, we reuse an existing commodity tool called Ant. Ant is open source, written in Java and freely distributed by the Apache Software Foundation. Adopting Ant as a workflow engine provides platform independence and immediate integration into the Grid services framework. Ant tasks and dependencies can be conveniently expressed in XML, and it makes users and machines to easily read and understand the workflow scripts. Ant is designed around the concept of targets and tasks. Targets exist only as top-level entities. Dependencies between targets are specified using target names as handles. Targets in Ant are executed sequentially, without the possibility to exploit the parallelism inherent in a dependence-based specification. Targets are composed of tasks that are generally executed sequentially. In the chain, each process is defined in tag target, and flow orderings are defined by attribute depends. For example, if job A depends on job B, then job B should precede job A, and target defining job B should have attribute depends=job A. <parallel> tag element in Ant build schema enable to execute tasks in parallel. Each task in its thread runs sequentially. Conditional behaviors between the parallel tasks can be modeled at the target level according to the given target properties. The proposed framework is composed of two major parts (Figure 1). One is for creating workflow templates (Admin Tools) and another is for creating final workflow script instances (User Tools). All the templates and instances are kept in the servers local file systems as different Ant build files. Users and admin interact with the system through a browser. These two servers roles are illustrated in Figure 2. These roles are explained in Sections 3.1 and 3.2. In Figure 1, templates for the predefined workflows are listed as T-1, T-2, T-3 and T-4. These are created by admin users. When the users want to run any workflow, they need to select one of these templates and enter their own parameters for the job to execute and return the results. T1 I-1, T1 I-2 and T1 I-3 are three workflow instances created from template T-1 by the actual users. Administrators (admin users) and actual users both interact with the system through browsers. Workflow templates as shown in Figure 1 are stored in repository implemented as local file system on the server. They are actually XML-based Ant build files. Users interact (add, edit and delete) with them through visualization components of the system. Apache Ant s standard Figure 1. Proposed web-based architecture.

ANT-BASED INTERACTIVE WORKFLOW MANAGEMENT 1333 Figure 2. A sample workflow template created with admin tools. specification for the Ant build files is used as metadata for the templates to be created and edited. It also enables us to create interactive visualization components over the templates. The aim in designing a workflow repository was to dynamically include workflow templates or provide the ability to modify the templates while a workflow is in progress. Remote access to the repository is also an important consideration in order to utilize the components of the workflow system in a collaborative environment by providing remote workflow template storage and access to distributed group members. 3.1. Admin tools Admin is provided with three capabilities, creating, editing and deleting of template files. The root element of the templates is element project. Project element might have more than one target elements. Each target element represents an independent task or job. If any task, or job, is related to any other task, this relation is expressed by using depends attributes of the target tag elements. An XML script in what follows illustrates a simple dependence scenario for the tasks ls and echo. A template might be an instance in case of that admin does not give any option for users to enter, and the entire template is filled out and all the elements are assigned by the admin. If the admin wants to give ability for users to define any tag value, then that tag value is set to a specific value ON in the template file. All the options and restrictions on template files, and indirectly on workflow instances, are defined by the admin users. SSHEXEC page of the project in Figure 2 can be given as an example. In this example, the admin frees the users to enter their host names, but job can be run only by username asayar. For the other attributes, you can have a look at the Apache Ant web site [3].

1334 A. SAYAR The possible job wrapping tags in Ant are scp, sshexec and exec. Figure 2 shows an example of job wrappings using sshexec. You can put this sshexec element inside the target named echo previously. You can also create task ls, similar to sshexec created for the previous echo, and put it in another target named ls.at the end, you will have a completed template or an instance. This example gives basic information about how to create a workflow script using Apache Ant. Figure 5 shows a sample template workflow script ready for creating a workflow instance by a user. 3.2. User tools User tools enable application users to create actual workflow scripts. The scripts are created from templates. When a user opens a browser, available templates are listed, and users select one of them to create his own custom workflow script. Figure 5 illustrates a sample scenario for a user to create his custom workflow by using user tools. Whenever user updates any value on the left-hand side of the figure, workflow script instance is updated on the right-hand side. After having finished with creating the final script, users run the applications and have the outcomes on the right-hand side of the panel shown in Figure 5. Without restarting the server or the browser, users can rerun the script with minor changes again and again. The values of the user-editable parameters and tag attributes are written in text boxes, and others are already assigned by the admin and not allowed to change. These authorization settings are defined by the administrators through admin tools presented in Section 3.1. 4. USE CASE SCENARIO ON TRACING RMI JOBS Remote Method Invocation is a type of remote procedure call that is network-independent, lightweight and totally portable, as it is written in pure Java. An RMI is essentially the same as an RPC, except that it operates on objects instead of applications. In RPC and RMI, the caller and callee both need to be up and running at the time of communication. This is called transient communication. In addition, they need to know exactly how to refer to each other. An RMI is specifically designed for Java objects. It allows remote Java objects on different JVM to communicate across the Internet. Communication is mostly achieved through process call. In this scenario, we enable clients to trace Java RMI [31] jobs and display the outcomes on the user s screen by using the proposed workflow tools. The outcome is actually a log file originated by the RMI servers and returned to the machine where network manager is located. The system consists of three different components. These are RMI server (RMIS), RMI client (RMIC) and Network Manager (NM). Workflow engine is deployed at NM. The sample scenario and the relation between the components are illustrated in Figure 3. NM database provides the workflow scripts, which are created beforehand as a separate application (Chapter 3). The scripts are called instances and created from ant template build files, according to the application purposes and by using interactive workflow tools. The whole system is developed and tested in Local Area Network. Figure 3 illustrates the sample workflow scenario for tracking the RMIC and server communications for predefined jobs. Figure 3 presents a workflow from the computational nodes point of view. The numbers over the arrows define the orders and hierarchy among the tasks in the workflow.

ANT-BASED INTERACTIVE WORKFLOW MANAGEMENT 1335 Figure 3. Sample workflow scenario. Figure 4 represents same scenario from a different point of view, that is, from process communication point of view. The sample workflow is shown as an acyclic graph in Figure 4 in terms of ant s target-task compositions. Figure 4 is target-based, or task-based, representation of the sample scenario given in Figure 3. The corresponding build file, which is a workflow script, is given in APPENDIX. The build file explains the targets and orders among them to achieve the expected results. The arrows in Figure 4 represent dependence relations between the tasks. Ant uses the term target for the tasks. The terms task and target are used interchangeably throughout the paper. Table I illustrates the machines (NM, RMIS and RMIC) and their assigned tasks in the proposed system. The tasks to be assigned are compiling (compile), creating executable jar packages for RMIC and servers (jar), starting up Figure 4. Task hierarchies, dependence relations. Tasks Table I. Machines and their tasks in the system. Machines NM RMIC RMIS Compile X Jar X RMI-Server-Client-Run X X GetClientLog Run X NM, Network Manager; RMIC, Remote Method Invocation client; RMIS, Remote Method Invocation server.

1336 A. SAYAR the client and server machines (RMI-Server-Client-Run), sending the log files to the network manager (GetClientLog) and showing the log files on the user interface at user-client side (run). Target-6 is called RMI-Server-Client-Run, and starts up RMIS and RMIC. It is represented with the arrows numbered 1 in Figure 3. Target-6 runs both client and server at the same time; there is no order among them. This is achieved by using ant s standard tags called <parallel> and <sshexec>. <sshexec> is used to run remote jobs packed as jars, and <parallel> is used to notify the ant engine to run all the jobs defined in <sshexec> to run parallel. The tasks (or jobs) are already put into the servers RMIS and RMIC as executable jar packages beforehand. They are placed under the folder C:/ of the corresponding machines local file systems (see command parameter in target-6 in the Appendix). These packages are run through <sshexec>, and the parameter <timeout> is set to 0. Zero means there is no timeout set for the task, in other words, server needs to be carried out with the first task to go on to the next one. The arrows numbered 1 and 2 in Figure 3 represent client-server paradigm in distributed computing, which is RMI in this case. The arrow 2 is request and arrow 3 is response. The API level communication details are not given here. Target-7 is called GetClientLog. It aims at sending the communication logs are created at the end of application run. Log file is provided by RMIS and sent to the user through the network manager. This is represented with arrows numbered 4 and 5 in Figure 3. Logs are text-based files created once and updated over the time in which server and clients are up and running. A log file contains details such as creation times of servers, exceptions thrown or failures. In the proposed framework, log files are sent to the network manager through secure copy sub task <scp>. <scp> is ant s built-in task definition. Its standard properties and their values for the sample scenario are given in what follows. Figure 5. (User tool) A sample template is edited, and a workflow script is created.

ANT-BASED INTERACTIVE WORKFLOW MANAGEMENT 1337 For the client interaction with the system, defining the client and server names, giving the userdefined parameters and showing the results of the tracking system, we have also developed user interface tools. These are separated from the ant build template and instance creation tools. Targets 1, 2 and 3 explain that part of the system. These are all carried out at the network manager site. Target-1 is called Compile. It aims at compiling the required classes and packages for the application. This is carried out through Ant s built-in subtask called <javac>. It has some attributes such as srcdir and destdir. Srcdir defines the location of source codes to be compiled, and destdir defines the location in which the compiled source codes to be placed. The following task is jar, which is defined in target-2. It creates executable jar packages from the target code in destdir created by target-1. Target-3 is called run. It runs the jar package coming from target-2 and opens up user interface interactive tools for the users to provide the required parameters for the application to run appropriately. It also shows the results on the user screen. This is carried out by Ant s built-in subtask called <exec> (see Appendix for the details). 5. CONCLUSION AND FUTURE WORK The work presented in this paper is an interactive and visual workflow system assisting users in orchestrating a set of distributed services-activities and expressing complex dependencies between them in XML. Interactive visual tools hide the complexity of the system and make it easy to handle the distributed services. Implementation and design of the proposed framework is demonstrated. We also demonstrated the proposed workflow system s feasibility and effectiveness through a case study on RMI jobs. Rather than developing the engine from scratch, we reuse an existing commodity tool called Ant. Ant is open source, written in Java and freely distributed by the Apache Software Foundation. Adopting Ant as a workflow engine provides platform independence and immediate integration into the Grid services framework. Ant tasks and dependencies can be conveniently expressed in XML, and it makes users and machines to easily read and understand the workflow scripts. The proposed system enables separation of configuration and run-time stages. Templates are created at configuration time by admin users. Actual workflow scripts are created at run-time by the application users. The system also enables sharing and replicating workflow scripts with other users. This increases the number and types of the users of Grids. That is, any user can use the system without having deep knowledge of application science domains. Eliminating the rewriting of repetitive parts of a workflow definition is the most important future of the proposed workflow system. Multiple uses of abstract models for a given process are possible without having to redefine it. Admin defines the abstract model (in XML schema) for a given process, and then, users create workflow scripts in accordance with those abstract models through GUI. This enables controllable and easy to use system. Abstract models and user scripts can be changed dynamically and stored in local file system by admin and users, respectively (Figure 5). Because of its main targeted usage area, Ant lacks several aspects in supporting sophisticated workflow requirements. Workflows created by using Apache Ant are not powerful enough for most distributed applications. Ant lacks the functionality to support workflow compositions. Ant provides mechanisms only to direct the flow of control. It lacks the infrastructure to support workflow composition allowing the output of one activity to become the input to another and defining the number of iteration for any process execution. In the future, we are going to enhance the proposed architecture by eliminating these drawbacks through some extension to the XML-based Ant build schema files. The system presented in this paper is a work in progress. Although an initial prototype is available for evaluation, it will undergo significant extensions based on users feedbacks. Regarding user interfaces, we plan to use XSL [32] and XSLT [32] for creating graphical user interfaces from the template files created by admin. However, Ant schema is too large; creating XSLT file for conversion might not help for the performance issues, but it is worth to try. We also plan to test and apply our proposed admin and user interactive tools to real geophysics applications such as Pattern Informatics [33] and Virtual California (VC) [34].

1338 A. SAYAR APPENDIX A. ANT BUILD.XML FOR A SAMPLE SCENARIO GIVEN IN FIGURES 3 AND 4

ANT-BASED INTERACTIVE WORKFLOW MANAGEMENT 1339 REFERENCES 1. Yu J, Buyya R. A taxonomy of workflow management systems for grid computing. Journal of Grid Computing 2005; 3(3-4):171 200. 2. Wilkins DN Special issue: Science gateways common community interfaces to grid resources. Concurrency and Computation: Practice and Experience 2007; 19(6):743 749. 3. Apache Ant. Apache Ant Project 2010 02/09/2010. Available from: http://ant.apache.org/ (Accessed May 12, 2010). 4. The Apache Software Foundation. The Apache Software Foundation 2010. Available from: http://www.apache.org/ (Accessed May 2, 2010). 5. Liu K-H, Li J-S, Wang C-Y, Chilamkurti N, Vasilakos AV. Minimizing multiplayer interactive delay in multihop wireless networks. International Journal of Communication Systems 2012; 25(10):1330 1349. 6. Xiaonan W, Huanyan Q. Constructing a VANET based on cluster chains. International Journal of Communication Systems 2012.2484. 7. Flower. Workflow framework. 2012. Available from: http://flower.codeplex.com/ (Accessed July 12, 2012). 8. Van Der Aalst WMP, Ter Hofstede AHM. YAWL: yet another workflow language. Information Systems 2005; 30(4):245 275. 9. Staffware. Workflow system. 2012. Available from: http://www.amrein.com/eworld/flow006.htm (Accessed June 19, 2012). 10. MQ. Websphere MQ workflow. 2012. Available from: http://www-01.ibm.com/software/integration/wmqwf/ (September 15, 2012). 11. COSA. The Cosa BPM suite. 2012. Available from: http://www.cosa.nl/ (November 25, 2012). 12. SAP. Business workflow system. 2012. Available from: http://help.sap.com/saphelp_46c/helpdata/en/c5/ e4a930453d11d189430000e829fbbd/content.htm (August 12, 2012). 13. FileNet. Content manager. 2012. Available from: http://www-01.ibm.com/software/data/content-management/filenetcontent-manager/ (Accessed August 12, 2012). 14. Aalst WMP, et al. Advanced workflow patterns. Journal of Distributed and Parallel Databases 2003; 14(1):5 51. 15. WFTK. Open source workflow toolkit. 2012. Available from: http://www.vivtek.com/wftk/ (Accessed October 10, 2012). 16. Berman F, Fox G, Hey T. Grid Computing: Making the Global Infrastructure a Reality. John Wiley & Sons: Chichester, England, 2003. 17. Atkinson MP, De Roure D, Dunlop AN, Fox G, Henderson P, Hey AJG, Paton NW, Newhouse S, Parastatidis S, Trefethen AE, Watson P, Webber J. Web service grids: an evolutionary approach. Concurrency and Computation: Practice and Experience 2005; 17(2-4):377 389. 18. Emmerich W, Butchart B, Chen L, Wassermann B, Price SL. Grid Service Orchestration using the Business Process Execution Language (BPEL). Journal of Grid Computing 2005; 3(3-4):283 304. 19. Taylor I, Matthew S, Wang I, Harrison A. (Part III) The Triana Workflow Environment: Architecture and Applications. Workflows for e-science. Springer: London, 2007; 320 339. 20. Chen Y, et al. A visual scientific workflow designer for chemists in grid environment. The Third China Grid Annual Conference, China, 2008. 21. Bendoukha H, Benyettou A, Slimani Y. JASMIN: a visual framework for managing applications in service-oriented grid systems. in ICIW 2012: The Seventh International Conference on Internet and Web Applications and Services. 2012. Stuttgart, Germany. 22. Designer OB. Oracle s BPEL designer. 2012. Available from: http://www.oracle.com/technetwork/middleware/ bpel/overview/index.html (Accessed September 12, 2012). 23. BPWS4J. IBM s BPWS4J. 2012. Available from: http://www.ibm.com/developerworks/webservices/library/wsbpelcol4/ (Accessed September 12, 2012). 24. Turi D, et al. Taverna Workflows: Syntax and Semantics in 3rd IEEE International Conference on e-science and Grid Computing (e-science 07). IEEE Computer Society: Bangalore, India, 2007. 25. Ludäscher B, Altintas I, Berkley C, Higgins D, Jaeger E, Jones M, Lee EA, Tao J, Zhao Y. Scientific workflow management and the Kepler system. Concurrency and Computation: Practice and Experience 2006; 18(10):1039 1065. 26. Fox G,Gannon D.Workflow in grid systems. Concurrency and Computation: Practice and Experience 2006; 18(10):11. 27. Berlinska J, Drozdowski M. Scheduling divisible MapReduce computations. Journal of Parallel and Distributed Computing 2011; 71(3):450 459. 28. Papazachos ZC, Karatza HD. Scheduling of frequently communicating tasks. International Journal of Communication Systems 2012; 25(2):146 157. 29. Chen Y-S, Deng D-J, Hsu Y-M, Wang S-D. Efficient uplink scheduling policy for variable bit rate traffic in IEEE 802.16 BWA systems. International Journal of Communication Systems 2012; 25(6):734 748. 30. Jang K-W. Meta-heuristic algorithms for channel scheduling problem in wireless sensor networks. International Journal of Communication Systems 2012; 25(4):427 446. 31. RMI. Java Remote Method Invocation Specification Volume, 2004. 32. Clark J. XSL Transformations (XSLT). 1999, W3C. 33. Holliday JR, Chen C-c, Tiampo KF, Rundle JB, Turcotte DL, Donnellan A. A RELM earthquake forecast based on pattern informatics. Seismological Research Letters 2007; 78(1):87 93. 34. Tiampo KF, Rundle JB, McGinnis SA, Gross SJ, Klein W. Eigenpatterns in southern California seismicity. Journal of Geophysical Research 2002; 107(B12):2354.