Integrating the Technology Acceptance Model into a Service Oriented Analysis and Design Methodology

Integrating the Technology Acceptance Model into a Service Oriented Analysis and Design Methodology The case of Workflow System Virtual Laboratory Abstract Machine Amsterdam (WS-VLAM) Name: Boris Rottmann E-mail: boris.rottmann@student.uva.nl UvA-NetID: 10333665 27.02.2013 University of Amsterdam Faculty of Science: Master program Business Information Systems Supervisor: drs. A.W. Abcouwer Universiteit van Amsterdam Faculteit Natuurwetenschappen, Wiskunde en Informatica (FNWI; Science Faculteit) Science Park 904, 1098 XH Amsterdam mobiel +31 6 21216321 email abcouwer@uva.nl Second Reader: Patricia Lago VU University Amsterdam, FEW, Computer Science, De Boelelaan 1081a, Room: T4-22 1081 HV Amsterdam, The Netherlands. P: +31 (0) 20 59 87745 email: p.lago@vu.nl Advisors: Maryam Razavian Veije University Amsterdam, FEW, Computer Science, De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands. Telephone: +31 20 59 87788 E-mail: m.razavian@vu.nl dr. A.S.Z. (Adam) Belloum Instituut voor Informatica POSTBUS 94323 1090 GH Amsterdam Telephone 0205257514 email: A.S.Z.Belloum@uva.nl

Abstract The use of information technology (IT) in science offers great potential for improving the quality of services provided and the efficiency and effectiveness of the users, but also for reducing the organizational expenses associated with science. One of the critical success factors of any IT implementation is the users acceptance of the IT system (Amoako-Gayampah & Salam, 2003, p. 732). The Technology Acceptance Model (TAM) (Davis F. D., 1989) is widely used by researches and practitioners to predict and explain user acceptance of information technology. This research aims to understand the low acceptance of the Workflow System Virtual Laboratory Abstract Machine (WS-VLAM), by applying the Technology Acceptance Model (TAM) to scientific workflow systems. WS-VLAM is a grid-enabled workflow management system following the Open Grid Services Architecture (OGSA)/ Web Services Resource Framework (WSRF) standards. The OGSA is an extension and refinement of the service-oriented architecture (SOA). Although WS- VLAM system is a free open source software, developed for large-scale science experiments, currently the system does not garner sufficient attention from the e-science community. Furthermore, this research aims to build a bridge between the TAM research results and the design process of service based software, in particular the Service Oriented Analysis and Design Methodology (SOADM) by (Lago & Razavian, 2012). This thesis presents a two-step method to integrate the results of a TAM survey research into the design of WS-VLAM, with the objective to improve the user acceptance of the software services. Keywords: Technology acceptance model, Service oriented Analysis and Design methodology, scientific workflow management systems, Workflow System Virtual Laboratory Abstract Machine (WS-VLAM), e-science 1

1 Table of Content 2 INTRODUCTION... 8 3 RESEARCH DESIGN... 9 3.1 INTRODUCTION... 9 3.2 SURVEY RESEARCH... 9 3.2.1 Survey Design... 10 3.2.2 Survey Instrument Development... 10 3.2.3 Survey Execution... 11 3.2.4 Data Analysis and Reporting Survey Results... 11 3.3 INTEGRATING THE SURVEY RESULTS INTO A SERVICE ORIENTED DESIGN METHODOLOGY... 11 4 THEORY AND LITERATURE REVIEW... 12 4.1 SCIENTIFIC WORKFLOW MANAGEMENT SYSTEMS... 12 4.1.1 A Reference Architecture for Scientific Workflow Management Systems... 13 4.1.2 Scientific Workflow Management Systems and user acceptance research... 18 4.2 WORKFLOW SYSTEM VIRTUAL LABORATORY ABSTRACT MACHINE... 19 4.2.1 Background VLAM-G... 19 4.2.2 WS-VLAM - a new design... 20 4.2.3 WS-VLAM implementation - Reverse engineering tool... 25 4.3 SERVICE ORIENTED ANALYSIS AND DESIGN METHODOLOGY... 25 4.3.1 Terminology Overview... 28 4.3.2 Methodology and Its Supporting Models... 28 4.4 THE TECHNOLOGY ACCEPTANCE MODEL... 34 4.4.1 Perceived usefulness and perceived ease of use... 36 4.4.2 Technology acceptance model evolving... 38 4.4.3 Applying the Technology Acceptance model... 41 4.4.4 Limitations of Technology Acceptance Model... 42 5 APPLYING THE TECHNOLOGY ACCEPTANCE MODEL TO SCIENTIFIC WORKFLOW MANAGEMENT SYSTEM... 42 5.1 DEVELOPING A TECHNOLOGY ACCEPTANCE MODEL FOR SCIENTIFIC WORKFLOW SYSTEM... 43 5.1.1 Scientific Workflow System Quality... 44 5.1.2 Social Influence... 45 5.1.3 Experience... 45 5.1.4 Perceived Ease of Adoption... 46 5.1.5 Technology acceptances model variables... 47 5.2 DEVELOPING A QUESTIONNAIRE... 47 5.3 DEVELOPING HYPOTHESIS... 51 5.4 THE WORKFLOW SYSTEM TECHNOLOGY ACCEPTANCE MODEL SURVEY... 52 5.4.1 Survey questionnaire and measurements... 52 5.4.2 Descriptive characteristics of the respondents... 53 5.4.3 Results and analysis... 54 5.4.4 Interpretation of the statistical analysis... 56 5.4.5 Limitations of the statistical analysis... 58 5.4.6 Interpretation and analysis of the variables... 59 2

5.4.7 Discussion, conclusions and limitations... 66 6 INTEGRATING TECHNOLOGY ACCEPTANCE MODEL INTO THE SERVICE ORIENTED ANALYSIS AND DESIGN METHODOLOGY... 67 6.1 INTRODUCTION... 67 6.2 DEVELOPING AN INTEGRATION MODEL... 68 6.3 APPLICATION TO THE CASE OF WS-VLAM... 70 6.3.1 Service oriented Analysis and Design... 70 6.3.2 Design Space and Design Space Refinement... 72 6.3.3 Conclusion... 73 7 CONCLUSIONS... 75 7.1 INTRODUCTION... 75 7.2 REFLECTIONS... 75 7.3 OBJECTIVE OF THE THESIS PROJECT... 76 7.3.1 The Technology Acceptance Model... 76 7.3.2 Integrating the Technology Acceptance Model into the Service Oriented Analysis and Design Methodology... 77 7.4 FUTURE RESEARCH... 77 8 REFERENCES... 79 9 APPENDICES... 84 9.1 APPENDIX A: INTEGRATING THE TECHNOLOGY ACCEPTANCE MODEL INTO A SERVICE ORIENTED ANALYSIS AND DESIGN METHODOLOGY USING THE CASE OF WS-VLAM... 84 9.1.1 Service oriented Analysis... 84 9.1.2 Design space development... 102 9.1.3 Design space refinement with the Technology Acceptance Model... 105 9.1.4 Design Space Refinement... 107 9.1.5 Service oriented Design... 111 3

Figures Figure 1 Workflow Reference Model... 12 Figure 2 (a) The position of an SWFMS within a software stack and (b) zoom-in view of the reference architecture for SWFMSs (Lin C., et al., 2009).... 16 Figure 3 WS-VLAM overall architecture... 21 Figure 4 WS-VLAM - composer services... 21 Figure 5 WS-VLAM Workflow submission and monitoring... 22 Figure 6 WS-VLAM Graphical output... 23 Figure 7 WS-VLAM system overview... 24 Figure 8 Service Inventory Analysis and Design Methodology... 29 Figure 9 Examples of Analysis and Design Models (Lago & Razavian, 2012)... 31 Figure 10 SOAML Examples of Analysis and Design Models... 33 Figure 11 Conceptual model for technology acceptance (Davis F. D., 1989, p. 10)... 35 Figure 12 Original TAM proposed by Fred Davis (Davis F. D., 1989)... 35 Figure 13 Scale to measure Attitude towards a system (Chuttur, 2009, p. 7)... 37 Figure 14 New relationships formulation in TAM (Davis, F. D., 1993, p. 481)... 38 Figure 15 First modified version of TAM (Chuttur, 2009, p. 10)... 38 Figure 16 Final version of TAM (Chuttur, 2009, p. 10)... 39 Figure 17 Extending TAM to include determinates for perceived usefulness... 40 Figure 18 Extending TAM to include determinates for perceived ease of use... 41 Figure 19 Technology Acceptance model for Scientific Workflow Systems... 43 Figure 20 Technology Acceptance Model for Mobile Services... 46 Figure 21 Descriptive sample analysis... 54 Figure 22 High Correlation coefficient: H7 Perceived ease of use and Intentional behaviour to use... 57 Figure 23 Small Correlation coefficient: H9 Perceived ease of adoption and Actual use 58 Figure 24 Schematic diagram showing how study size can influence conclusions. CI: confidence interval (Hackshaw, 2008)... 58 Figure 25 Overview Supported hypothesis /Overview User Acceptance of WS-VLAM composer... 59 Figure 26 Results System Quality: Overview... 60 Figure 27 Results System Quality: R1 User interface customizability and user interaction/ R2 Reproducibility support... 61 Figure 28 Results System Quality: R3: Heterogeneous and distributed service and software tools/ R4: Heterogeneous and distributed data product management... 62 Figure 29 Results System Quality R5: High-end computing support/ R6: Workflow monitoring and failure handling... 62 Figure 30 Results System Quality: R7: Interoperability... 63 Figure 31 Results: Information Quality/ Support Quality... 63 Figure 32 Results: Social Influence and Experience... 64 Figure 33 Results: Perceived ease of adoption... 64 Figure 34 Results: Perceived Usefulness and Perceived ease of use... 65 Figure 35 Results: Behavioural Intention to use and Actual use... 65 4

Figure 36 Integrating the Technology acceptance model into a Service oriented analysis and design methodology... 69 Figure 37 Reflection on the thesis: Connecting three research fields... 76 Figure 38 Scientific experiment s life cycle (Belloum, et al., 2011)... 87 Figure 39 Scientific experiment s life cycle activity diagram... 89 Figure 40 Context Model WS-VLAM... 101 Figure 41 Data Model WS-VLAM... 102 Figure 42 QOC notation for the Concern 1... 105 Figure 43 QOC notation for the Concern 2... 111 Figure 44 Service contract identification: Problem identification... 119 Figure 45 Service contract identification: Experiment Prototyping... 120 Figure 46 Service contract identification: Experiment execution... 120 Figure 47 Service contract identification: Publication results... 121 Figure 48 Service network modelling - Problem investigation... 129 Figure 49 Service network modelling - Experiment Prototyping... 129 Figure 50 Service network modelling - Experiment execution... 130 Figure 51 Service network modelling - Publication results... 130 Figure 52 Service choreography modelling - Problem investigation... 131 Figure 53 Service choreography modelling - Experiment Prototyping... 132 Figure 54 Service choreography modelling - Experiment execution... 133 Figure 55 Service choreography modelling - Publication results... 133 5

Tables Table 1 Revised 6 items scale for perceived usefulness (Chuttur, 2009, p. 8).... 37 Table 2 Revised 6 items scale for perceived ease of use (Chuttur, 2009, p. 8).... 37 Table 3 Variation in TAM application (Chuttur, 2009, p. 13).... 42 Table 4 Developing a questionnaire for SWS-TAM... 50 Table 5 Descriptive statistics, and correlation of composite scores of constructs and significance of correlation... 56 Table 6 List of identified user acceptance issues based on SWS-TAM survey... 67 Table 7 Pros and cons overview of Integrating the Technology acceptance model into a Service oriented analysis and design methodology... 74 Table 8 Functional Requirements WS-VLAM... 93 Table 9 Quality Requirements: WS-VLAM... 95 Table 10 Business service 1: Problem investigation... 96 Table 11 Business Service 2: Experiment Prototyping... 98 Table 12 Business Service 3: Experiment Execution... 99 Table 13 Business Service 4: Results Publication... 100 Table 14 Con#1: How are workflow-modules managed?... 104 Table 15 SWS-TAM-Strategy-Customizability-to-specific-scientific-domains... 107 Table 16 Con#2: How to provide customizing options for specific scientific domains? 110 Table 17 Mapping Design Space to User acceptance strategies... 111 Table 18 All service candidates... 114 Table 19 Business Service 1: Service candidates... 115 Table 20 Business Service 2: Service candidates... 116 Table 21 Business Service 3: Service candidates... 117 Table 22 Business Service 4: Service candidates... 117 Table 23 Service based application: WS-VLAM Client... 119 Table 25 Delegation Contract... 122 Table 26 Browse repository contract... 122 Table 27 Transfer workflow contract... 123 Table 28 Allocate execution resources contract... 124 Table 29 Execute workflow contract... 125 Table 30 Workflow monitoring contract... 126 Table 31 Workflow provenance contract... 127 Table 32 Workflow output contract... 128 Table 33 Publish workflow contract... 128 6

List of abbreviations B BS - Business Service G GT4 - Globus Toolkit 4 GRAM - Globus Resource Allocation Manager GSI - Grid Security Infrastructure O OGSA - Open Grid Services Architecture S SOADM - Service Oriented Analysis and Design Methodology SO - Service oriented SOA - Service oriented Architecture SOAP - Simple Object Access Protocol SSC software service candidate SWS-TAM Scientific Workflow System Technology Acceptance Model R REST - Representational State Transfer RTSM - Run Time System Manager T TAM Technology Acceptance Model V VLAM - Virtual Laboratory Amsterdam VNC - Virtual Network Computing W WS-VLAM - Workflow System Virtual System Abstract Machine WSRF - Web service Reference Framework WS - Web service WSDL - Web service Description Language 7

2 Introduction Nowadays new IT is rapidly replacing old applications by providing more powerful tools and faster speeds for user. This adoption can be successful, however, only when users accept and effectively use the technology. Therefore, organization and developers should understand that the acceptance process is essential in making the adoption process effective. One of the key measures of IT implementation success is achieving the intended level of usage of the IT. System usage is a reflection of the acceptance of the technology by users (Amoako-Gayampah & Salam, 2003, p. 732). The Technology Acceptance Model (TAM) is an information systems theory that studies how users come to accept and use a technology (Davis F. D., 1989). Applying TAM to an information system provides the developers with information on how to improve user acceptance of the specific information system. At present, the above described adoption process is particularly a challenge in e-science, in particular Scientific Workflow Management Systems (SWfMS). The advances in Internet, e-collaboration, grid technologies and e-science technologies have greatly enhanced scientific experiments. In addition to Data- and Compute-intensive tasks, large-scale collaborations involving geographically distributed scientists and e- infrastructure are now possible. Scientific workflows, that encode the logic of experiments, are becoming valuable resources. Sharing these resources and allowing scientist s worldwide to work together on experiment is essential for promoting knowledge transfer and speeding up the development of scientific experiments. (Belloum, et al., 2011, p. 1). Several open source SWfMSs have been developed in the last years e.g. Taverna Workbench 1, Kepler 2, Triana 3, Worklfow System Virtual laboratory Abstract Machine (WS-VLAM) 4 and others. WS-VLAM is a grid-enabled workflow management system following the Open Grid Services Architecture (OGSA)/ Web Services Resource Framework (WSRF) standards defined by the Grid community. The OGSA is an extension and refinement of the service-oriented architecture (SOA). The workflow engine of the WS-VLAM is implemented as a WSRF compliant Web service making it one of the first workflow engines following the Execution Management Services described in the Open Grid Forum (OGF) documents (WSVLAM, 2012). The main problem addressed in this research relates to the user acceptance of WS- VLAM. An overview of the current usage statistic 5 (viewed December 2012) of the WS- VLAM project page indicates a low overall usage of WS-VLAM software. This research aims to understand the low acceptance and usage of the WS-VLAM. To reach the goal of 1 http://www.taverna.org.uk/ 2 https://kepler-project.org/ 3 http://www.trianacode.org/ 4 http://staff.science.uva.nl/~gvlam/wsvlam/ 5 http://s10.flagcounter.com/more/4uv 8

understanding user acceptance of WS-VLAM, this research presents an extended Technology acceptance model for scientific workflow systems, in particular for WS- VLAM/WS-VLAM client to better understand the user acceptance of WS-VLAM. Furthermore, this study claims that there is the need for a method to implement the findings of the user acceptance research to the design of software. This research proposes a two-step method to integrate the TAM survey results into the Service Oriented Analysis and Design Methodology (SOADM) by (Lago & Razavian, 2012). This approach enables the developers to implement solution for user acceptances issues directly to the software design. This study applies this approach using WS-VLAM as a practical example. 3 Research Design 3.1 Introduction This survey research aims to investigate the user acceptance of Workflow System Virtual laboratory Abstract Machine (WS-VLAM). For this purpose the Technology Acceptance Model (TAM) is applied to scientific workflow systems, in particular to WS-VLAM. The TAM is a widely used model to study user acceptance behaviour of information system (Chuttur, 2009). This leads to the first main research question of this thesis: Does the Technology Acceptance Model explain the user acceptance of scientific workflow management systems, in particular of WS-VLAM/WS-VLAM composer? Furthermore, this study claims that there is the need for a method or framework to implement the findings of the user acceptance research to the design of software. This research proposes to integrate the user acceptance findings into the SOADM by (Lago & Razavian, 2012). This leads to the second main research question of this thesis: How can the results of a Technology Acceptance Model research be integrated into the Service Oriented Analysis and Design Methodology by (Lago & Razavian, 2012)? The following section describes the research design for this thesis. 3.2 Survey Research This thesis is designed as a survey research as defined by (Kraemer, 1991) (Glasow, 2005). Kraemer (1991) identified three characteristics of survey research. These characteristics have been summarized by Glasow, (2005) as follows: First, a survey research is used to quantitatively describe aspects of a given population; these aspects often involve examining the relationships among variables. Second, the data for the survey research is collected from human beings and therefore is subjective. Third, the survey research describes a smaller part from the population which is later generalized to the whole population. In survey research, dependent and independent variables are used to define the scope of study (Glasow, 2005). Before conducting a survey, the researcher must design a 9

model that identifies the expected relationships among these variables (Glasow, 2005). The research survey is then constructed to test this model against observations of the phenomena (Glasow, 2005). This research uses the Technology acceptance model (Davis F. D., 1989), described in chapter 4.4, as a main model and foundation for the survey research. This survey research applies TAM to the scientific workflow system WS-VLAM by extending it with adapted external variables, as defined in chapter 5. 3.2.1 Survey Design According to Levy & Lemeshow, (1999) survey design includes two steps. In a first step, a sampling plan must be developed. A sampling plan describes how the sample is selected from the population, how a good sample size is determined and how the survey is distributed to the participants (Levy & Lemeshow, 1999, p. 6) (Salant & & Dillman, 1994, p. 3). The second step is related to the procedures for obtaining population estimates from the sample data and for estimating the reliability of those population estimates. This process contains the identification of the desired response rate and the preferred level of accuracy for the survey (Salant & & Dillman, 1994, p. 3). This research survey is a rather small study. The descriptive characteristics of this research survey can be found in chapter 5.4.2. The targeted population in this survey are experienced WS-VLAM users. The community around WS-VLAM is still relatively small compared to other research communities, which leads to limitations on the sample size. In his work Hackshaw, (2008) discusses the strengths and limitations of small studies. Based on his work the limitations and purpose of this research survey are outlined in chapter 5.4.5. The information from this study should be used to design larger confirming studies. The overall goal is to provide an example/trial study on how the survey results can be integrated in to the Service oriented design methodology by (Lago & Razavian, 2012). The complete survey design of this research is described in chapter 5. 3.2.2 Survey Instrument Development For most social and behavioural science surveys, the survey instrument involves a questionnaire that provides a script for presenting a set of questions and response options. The survey instrument development must be constructed according to certain steps. (Glasow, 2005) At first, the focus and scope of the study must be carefully defined. Secondly, the study objectives must be translated into measurable factors that contribute to that focus and scope (Salant & & Dillman, 1994, pp. 77-78). Thirdly, the researcher must ensure that she/he is competent in the topic (Salant & & Dillman, 1994, p. 99). Lastly, the survey must be consistently administered and ideally be developed by experts in the measurement sciences (Fowler & Floyd, 1995, p. 3). The survey instrument developed for this thesis is described in chapter 5.2. As described before the foundation for this survey research is the Technology Acceptance Model. 10

3.2.3 Survey Execution The next phase in the survey research is the survey execution, also described as the use of the survey instrument. Salant and Dillman (1994) describe the importance of keeping the confidentiality of the individual responses. It is also important to keep in mind that the participation in a survey in voluntary, this requires the researcher to encourage to participants to contribute to the research. Furthermore it s important to conduct a pilot test run of the survey to test the survey instrument before doing the actual survey (Levy & Lemeshow, 1999, p. 7). Once the test run has been completed, the survey is conducted and the data are collected and processed. The survey execution is described in chapter 5.4.1. The survey was conducted within the WS-VLAM community. 3.2.4 Data Analysis and Reporting Survey Results There are several ways to evaluate the survey. One way is to evaluate the survey questions using focus group discussions, cognitive interviews to determine how well respondents understand the questions and how they formulate their responses (Fowler & Floyd, 1995, p. 5). A goal is to analyse the responses to the survey in order to reveal expected relationships among the answers given, and to ensure consistency of respondent characteristics across questions. Surveys can also be evaluated by measuring the consistency of responses to given questions over time (Glasow, 2005). For this purpose a statistical analysis of the collected data is useful and required. This thesis presents a rather small survey sample which leads to a number of limitations, which are described in chapter 5.4.5. Hackshaw, (2008) studied the advantages and disadvantages of small surveys. According to Hackshaw, (2008), it is important to not make strong conclusions about the risk factors or trial intervention and whether the results are positive or not. Instead, the data from such studies should be used to design larger confirming studies. The statistical analysis in this thesis is kept to a minimum and the focus lays on a more qualitative approach which focuses on the answers of the participants. The survey results are reported based on the variables and the answers of the participants. This way the survey analysis uses a qualitative research approach. A similar approach has been taken in the TAM research on mobile service by (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011). A detailed description of the survey results can be found in chapter 5.4.6. 3.3 Integrating the survey results into a service oriented design methodology The main scope of this thesis lies on integrating the research survey results into the SOADM introduced by (Lago & Razavian, 2012). For this purpose a model is introduced which allows to the integration of the two methods. A detailed description of the targeted approach follows in chapter 6. An applied practical application example of this approach follows in chapter 9.1. 11

4 Theory and Literature Review This chapter introduces the theory and literature review for this thesis. Chapter 4.1 introduces the topic scientific workflow management systems. The main focus lies on a reference architecture for scientific workflow systems. Chapter 4.2 describes the Workflow System Virtual Laboratory Abstract Machine (WS-VLAM) which is the system studied in this thesis. Chapter 4.3 describes a SOADM which will be applied to WS- VLAM in this thesis. Chapter 4.4 describes the Technology Acceptance model which is the reference model for this survey research. 4.1 Scientific Workflow Management Systems Scientific workflows can be described as a new paradigm that has recently emerged for scientists to integrate, structure, and orchestrate a wide range of local and remote heterogeneous services and software tools into complex scientific processes to enable and accelerate scientific discoveries ( Tsalgatidou, et al., 2006) (Lin C., et al., 2009). A scientific workflow is the computerized implementation or automation of a scientific process, in whole or part, which usually streamlines a collection of scientific tasks with data channels and dataflow constructs to automate data computation and analysis to enable and accelerate scientific discovery (Lin C., et al., 2009). Scientific workflows encode the logic of experiments and are becoming valuable resources. Sharing these resources and letting scientists worldwide work together on one experiment is important for promoting knowledge transfer and speeding up scientific experiments. (Belloum, et al., 2011). A scientific workflow management system (SWFMS) is a system that defines, modifies, manages, monitors, and executes scientific workflows through the execution of scientific tasks. The task execution order is driven by a computerized representation of the workflow logic (Lin C., et al., 2009). The Workflow Management Coalition (WfMC) proposed areference architecture for business workflows (Hollingsworth, 1995) in 1995. Figure 1 illustrates the workflow reference model or architecture with its five interfaces. A detailed distribution of this model can be found in (Hollingsworth, 1995). This reference architecture has been widely adopted in the development of different business workflow management systems (BWFMSs) e.g. YAWL (Aalst, Aldred, Dumas, & Hofstede, 2004) and others. Figure 1 Workflow Reference Model 6 6 http://www.wfmc.org/ 12

However, the reference architecture by the WfMC is not suitable for SWFMSs because business workflows and scientific workflows have different objectives. The aim of business workflows is to reduce human resources (and other costs) and increase revenue, while the aim of scientific workflows is to reduce both human and computation costs and accelerate the speed of turning large amounts of data into knowledge and discovery (Lin C., et al., 2009). Furthermore, business workflows are characteristically control flow oriented, while scientific workflows tend to be dataflow oriented. That difference lead to a set of requirements for system development of SWFMSs (Lin C., et al., 2009). These requirements include for example; the support of intensive user interaction and visualization, a customizable and extensible GUI, reproducibility, high-end computing, heterogeneous data management, support of heterogeneous services and software tool (Lin C., et al., 2009). Over the last years a number of SWFMSs e.g. Kepler (Ludaescher, et al., 2006), Taverna (Oinn, et al., 2004), Triana (Majithia, Shields, Taylor, & Wang, 2004), WS-VLAM (Vasyunin, et al., 2007b) and others have been developed. According to Lin, et al. (2009) an architectural reference that provides a high-level organization of subsystems and their interactions in an SWFMS is missing. The scientific workflow management system design, specification, execution, and provenance tracking, etc. are still developed in an ad hoc manner (Lin C., et al., 2009). Each SWFMS mentioned above uses a proprietary workflow language, whose semantics has not yet been fully investigated and formalized. Moreover the different SWFMS have either no explicit architectural design or the architecture is proprietary and restricted significantly by legacy system that the SWFMS is built upon e.g. Kepler (Lin C., et al., 2009). 4.1.1 A Reference Architecture for Scientific Workflow Management Systems To fill the gap of a missing reference architecture for SWFMSs Lin, et al. (2009) have developed a reference architecture for SWFMSs. The reference architecture model is based on a comprehensive study of scientific workflow literature from an architectural perspective (Lin & Lu, 2008) and the experience of developing a SOA based SWFMS (Lin C., et al., 2009). The reference architecture of SWfMS presents a foundation for understanding and improving user acceptance of WS-VLAM. The authors Lin, et al. (2009) claim that the availability of a reference architecture can provide a basis for comparison between different systems and a guidance for the architectural design of an SWFMS in a specific scientific domain. The reference architecture model is based on seven key architectural requirements which in addition to the general requirements of scalability, reliability, extensibility, availability, and security are the foundation of the reference architecture model (Lin C., et al., 2009). In the following the seven key architectural requirements for an SWFMS are briefly described. R1: User interface customizability and user interaction support 13

In SWfMS, scientists are often the end users to design, modify, run, rerun, and monitor scientific workflows. Domain-specific visualization options are often needed to support the visualization of various workflow items (Lin C., et al., 2009). User friendly graphical interfaces are crucial to increase the usability of a SWfMS. The overall goal is to speed up the exploratory process of arriving at a fitting workflow design with appropriate parameter values and input data sets (Lin C., et al., 2009). Hence, a key architectural requirement is the flexibility of customizing the user interface according to different science and engineering disciplines, scientific domains, or to an individual scientist s style, while reusing the same underlying workflow management framework. Customizing user interface should be a local matter and should not affect any other functional component of the system (Lin C., et al., 2009). R2: Reproducibility support Reproducibility is the central principle of any science method. Scientific results produced from the enactment of scientific workflows must be reproducible (Lin C., et al., 2009). Hence, sufficient provenance information, including the derivation history of a data product, needs to be maintained in order to answer the following questions (Lin C., et al., 2009): What workflows or workflow steps are executed to produce this result? Which versions of software s and OS s are used? What parameter values are used? What input data sets have contributed to this result? What scientists interactions are involved in producing this result? With the information described above, a scientific result can be reproduced in the same system or in other peer systems. Hence, a key functional component for an SWFMS is the management of provenance metadata, from collection, representation, storage, and querying, to visualization. Such a function is usually not required for a BWFMS (Lin C., et al., 2009). R3: Heterogeneous and distributed services and software tools integration Scientists often need to integrate and orchestrate a variety of heterogeneous analytical and computational services and software tools into a scientific workflows for solving a complex scientific issue (Lin C., et al., 2009). These services and software tools are usually written in numerous programming languages, invoked by different mechanisms, and run in heterogeneous and distributed computing environments (Lin C., et al., 2009). Hence, a key architectural requirement is to provide an abstraction of the services and software tools as workflow tasks. Tasks keep scientists transparent to the heterogeneity and also promote SWfMSs extensibility for the integration of future services and software tools. (Lin C., et al., 2009). R4: Heterogeneous and distributed data product management The enactment of scientific workflows often consumes and produces huge amounts of distributed data objects (Lin C., et al., 2009). These data objects can be of primitive or complex types, files in different formats and sizes, database tables, data objects and others (Lin C., et al., 2009). Scientists are often overwhelmed by the number of heterogeneous and distributed data objects. Consequently, a key architectural requirement for an SWFMS is to provide an abstraction of these data objects as data 14

products (Lin C., et al., 2009). Hence, an SWFMS needs to support the management of data products, including data product storage, archival, browsing, querying, access, movement, and visualization (Lin C., et al., 2009). R5: High-end computing support Nowadays, many scientific issues need the support of high-end computing, such as Grid computing and Cloud computing (Lin C., et al., 2009). Given the rapid advance of highend computing technology, a key architectural requirement for an SWfMS is to separate the science-focused and technology-independent problem solving environment (PSE) from the underlying often fast advanced high-end computing infrastructure (Lin C., et al., 2009). This way, domain scientists can focus on their research while utilizing stateof-the-art computing technologies in a transparent manner (Lin C., et al., 2009). R6: Workflow monitoring and failure handling The monitoring of the progress of the workflow enactment is very important, especially for long-running scientific workflows (Lin C., et al., 2009). Scientific workflows are often designed and modified by scientists in an ad hoc manner and can involve various distributed tasks that are accessed over network communications, many exceptions or failures can occur in an unforeseeable way (Lin C., et al., 2009). Moreover, the complexity and scale of data analysis and computation in scientific workflows impose additional challenges on workflow monitoring and failure handling. Hence, a key architectural requirement for an SWFMS is to offer the support for status and failure monitoring at different levels and the mechanism for catching, localizing, and handling failures automatically or with minimal human intervention (Lin C., et al., 2009). R7: Interoperability Scientific research projects become more and more collaborative in nature and involve multiple geographically distributed organizations. Many scientific workflows are distributed and collaborative, consisting of multiple subworkflows which might be managed by a different SWFMS (Lin C., et al., 2009). Hence, a key architectural requirement for SWFMSs is to promote and enable the interoperability between different SWFMSs so that one SWFMS can take advantage of the software tool libraries and features provided by other SWFMS (Lin C., et al., 2009). Overview of the reference architecture model for Scientific Workflow Management Systems The reference architecture proposed by WfMC (Hollingsworth, 1995) has been widely used for BWFMSs, but does not satisfy key requirements R1-R5 for SWFMSs identified in the previous section. Figure 2 illustrates a reference architecture for SWfMS developed by Lin C., et al., (2009). 15

Figure 2 (a) The position of an SWFMS within a software stack and (b) zoom-in view of the reference architecture for SWFMSs (Lin C., et al., 2009). As shown in Figure 2b, the reference architecture for SWfMS consists of four logical layers, seven major functional subsystems, and six interfaces (Lin C., et al., 2009). Figure 2a shows a typical software stack of a scientific workflow application (Lin C., et al., 2009): on top of an operating system, a data management system and a service management are used by an SWFMS for data management and service management, separately. A Scientific Workflow Application System (SWFAS) is developed on top of an SWFMS by supplying additional domain-specific application data and functionalities (Lin C., et al., 2009). The following sections describes the four layers illustrated Figure 2 briefly. A detailed description of the Layers, Subsystems and Interfaces can be found in (Lin C., et al., 2009). To underline the scope of this thesis, there is a special emphasis on the fourth layer by describing the subsystems Presentation & Visualization and Workflow Design and its interfaces at the end of this section. 1. Operational Layer This layer consists of a various heterogeneous and distributed data sources, software tools, services, and their operational environments, including high-end computing environments (Lin C., et al., 2009). The separation of the Operational Layer from other layers isolates data sources, software tools, services, and their associated high-end computing environments from the scope of an SWFMS, hence satisfying requirement R5 (Lin C., et al., 2009). 2. Task Management Layer Tasks are defined as the building blocks of scientific workflows and consume input data products and produce output data products (Lin C., et al., 2009). During a scientific workflow execution provenance is captured automatically to record the derivation history of a data product (Lin C., et al., 2009). The Task Management Layer satisfies requirements R2, R3, and R4 by abstracting underlying heterogeneous data into data products, services, and software tools into tasks, and by providing efficient management for data products, tasks, and provenance metadata (Lin C., et al., 2009). The separation of the Task Management Layer from the Operational Layer promotes the extensibility of 16

the Operational Layer with new services and new high-end computing facilities (Lin C., et al., 2009). 3. Workflow Management Layer This layer is responsible for the execution and monitoring of scientific workflows (Lin C., et al., 2009). The building blocks of a scientific workflow are the tasks provided by the underlying Task Management Layer. In this layer, an execution of a scientific workflow is called a workflow run. A workflow run consists of a coordinated execution of tasks, each of which is called a task run. Hence, the Workflow Management Layer addresses requirements R6 and R7 (Lin C., et al., 2009). The separation of the Workflow Management Layer from the Task Management Layer has two reasons. First it isolates the choice of a workflow model from the choice of a task model, so changes to the workflow structure do not need to affect the structures of tasks (Lin C., et al., 2009). Secondly it separates workflow scheduling from task execution which improves the performance and scalability of the whole system (Lin C., et al., 2009). The interoperability of workflows (R7) has to be addressed by standardizing workflow models, workflow run models, and workflow languages (Lin C., et al., 2009). 4. Presentation Layer This layer provides the functionality of workflow design and numerous user interfaces and visualizations for assets of the whole system (Lin C., et al., 2009). The Presentation Layer has interfaces to each lower layer (which are not illustrated in the Figure 2 for simplicity). The separation of the Presentation Layer from other layers provides the flexibility of customizing the user interfaces of the system which also promotes the reusability of the rest of system components for different scientific domains (Lin C., et al., 2009).This separation supports requirement R1 (Lin C., et al., 2009). The interoperability of workflows (requirement R7) should be addressed by standardizing the workflow layout (Lin C., et al., 2009). Subsystems and Interface The main scope of this thesis lies on user acceptance research which leads to a special attention on the Presentation Layer of the model. The layer includes the subsystems Presentation & Visualization and Workflow design which represented the communication interface to the end user. The following section focus on this two subsystems and the related interfaces. A detailed description of all the other subsystems and interfaces can be found in (Lin C., et al., 2009). The Workflow Design subsystem is used for the design and modification of scientific workflows (Lin C., et al., 2009). The Workflow Design produces workflow specifications represented in a workflow specification language (Lin C., et al., 2009). The user can design and modify a scientific workflow using a standalone or Web-based workflow designer, which supports both graphical- and scripting based design interfaces (Lin C., et al., 2009). The Presentation and Visualization subsystem is important particularly for data intensive and visualization intensive scientific workflows (Lin C., et al., 2009). The presentation of workflow and visualization of different data products and provenance metadata in multi dimensions are the key to gain and knowledge from large amount of data and metadata (Lin C., et al., 2009). These two subsystems are situated at the 17

Presentation Layer to meet requirement R1. In this subsystem, the interoperability of workflows (requirement R7: level 2) should be addressed by the standardization of scientific workflow layout (Lin C., et al., 2009). The Presentation Layer has interfaces to each lower layer (which are not all illustrated in the Figure 2 for simplicity). The shown Interface I1 provides a set of interfaces for the communications between Workflow Design subsystem and the Workflow Engine (Lin C., et al., 2009). 4.1.2 Scientific Workflow Management Systems and user acceptance research This chapter revisit one of the requirements for Scientific Workflow Management Systems described in chapter 4.1.1. R1: User interface customizability and user interaction support is highly relevant for user acceptance. Beside the definition of the requirement outlined in the previous chapters, this chapter focuses on user acceptance research related to SWfMS. User acceptance in relation to SWfMS has been addressed in a scientific paper related to Triana by (Majithia, Shields, Taylor, & Wang, 2004). The paper describes possible problems of user acceptance with current workflow frameworks and systems. For example the use of a workflow systems or framework often requires the scientist to do low-level programming. The scientist is expected to have an understanding of the component services. Furthermore it is often assumed that the scientist is aware of the services required and ensure semantic and data-type compatibility of the messages being passed between the services (Majithia, Shields, Taylor, & Wang, 2004, p. 1). The authors summarized as followed: These complexities make it imperative to provide a composition and execution framework that can make it easy for users to create and execute workflows (Majithia, Shields, Taylor, & Wang, 2004, p. 1). Motivated by the concerns mentioned above Triana project has identified the following requirement as their main concerns: The over-arching requirement is to make it possible for users to construct complex workflows graphically and transparently and thereby insulating them from the complexity of interacting with numerous heterogeneous services. (Majithia, Shields, Taylor, & Wang, 2004, p. 2). The Triana project came up with the following list of requirements for their SWfMS (Majithia, Shields, Taylor, & Wang, 2004, p. 2). Service discovery methods: there must be a mechanism by which a user, and other components, can locate relevant services on the network; Service composition methods: there must be mechanisms to allow composition of services in a simple manner; Transparent execution methods: there must be mechanisms to invoke services transparently, i.e. without requiring the user intervention; Transparent publishing of services: there must be mechanisms to allow users to publish an atomic or a composite service. 18

According to Triana project these mechanisms are the basic requirements of a framework for building complex distributed Web service based systems. By facilitating the transparent construction of Web services workflows, users can: (Majithia, Shields, Taylor, & Wang, 2004, p. 2). Focus on the design of the workflow at a conceptual level; Easily create new complex composite services which offer more functionality than available atomic services; Easily expose composite services enabling users to share and replicate experiments; Easily carry out what-if analysis by altering existing workflows; 4.2 Workflow System Virtual Laboratory Abstract Machine Workflow System Virtual Laboratory Abstract Machine (WS-VLAM) (Korkhov, et al., 2007), (Vasyunin, et al., 2007b) (Vasyunin, et al., 2007) is an open source (Apache Licences) scientific workflow management system based on Open Grid Services Architecture (OGSA) and Web Service Resource Framework (WSRF). The SWfMS has been successfully applied to a number of science fields e.g. Bio informatics (Inda, et al., 2006), Medicine (Zudilova-Seinstra, Yang, Axner, Wibisono, & Vasunin, 2008). The SWfMS consists of a workflow engine and a GUI (WSVLAM composer). The workflow engine is implemented as a WSRF compliant web service making it one of the first workflow engines following the Execution Management Services described in the Open Grid Forum (OGF) documents. The GUI is based on open source JGraph 7 library and allows the workflow creation via Drag and Drop. The GUI generates a XML description of a workflow which is transmitted via SOAP to the Workflow engine. A number of workflow modules are offered as well as a wrapper for legacy code and the creation of new workflow modules in java, python and C++ via VL Port library. For long workflow runs, the GUI can disconnected from the engine, without interrupting the workflow, and reconnect at a later point in time. 4.2.1 Background VLAM-G The Virtual Laboratory for e-science (VL-e) is a Dutch e-science project which aims to provide a generic framework for multiple scientific application domains 8. Scientific workflow management systems are considered as a core service for managing scientific experiments (Vasyunin, et al., 2007). For this purpose VL-e is recommending a number of SWfMS including G-VLAM, today known as WS-VLAM. The VLAM-G system was a prototype based on Globus Toolkit 2 (Vasyunin, et al., 2007). VLAM-G provided a synthetic environment for performing grid enabled scientific experiments. VLAM-G provided a graphical user interface for prototyping high level 7 http://jgraph.org 8 http://www.vl-e.nl/ 19

workflows and for steering computing task at runtime, and an execution engine for orchestrating experiment processes (Vasyunin, et al., 2007). On the high level a scientific experiment is described as a data driven workflow in which each component (called module in VLAM-G) represented a process of a Grid service in an experiment (Vasyunin, et al., 2007). Since the development of VLAM-G, there was a shift of paradigm in the grid community into Service Oriented Architecture. This shift was manifested with the Open Grid Service Architecture specification (OGSA) for integrating distributed and heterogeneous grid resources. Globus Toolkit 4 (GT 4) is a recent release which implements OGSA and Web Service Resource Framework (WSRF) standards, and provides services for constructing grid services, controlling security, and managing data (Vasyunin, et al., 2007). To benefit from the advantages of GT4 services, in particular, service oriented integration which provides a standard interface for interoperating with the other workflow systems, a migration of VLAM-G to GT4 was required (Vasyunin, et al., 2007). Lesson learned from VLAM-G The VLAM-G system consisted of two core components: a graphical user interface (VL- GUI) and the RUN-Time System Manager (RTSM) (GT2 based engine) (Vasyunin, et al., 2007). In the initial design, the VL-GUI and RTSM were tightly coupled, which lead to number of inconveniences (Vasyunin, et al., 2007): the user interface has to be up all the time while the workflow is executed remotely, and the RTS is thus not able to orchestrate GRID components outside the GUI. For data intensive application in VL-e, this issue becomes a bottleneck to perform long running experiments. Decoupling the GUI and workflow engine is highly demanded (Vasyunin, et al., 2007). Another lesson learned from previous design VLAM-G is related to poor the interoperability with other workflow systems (Vasyunin, et al., 2007). Applications scientists regularly require the integration between workflows developed by different systems, e.g. combining the data steaming based experiments with data statistical computation provided by R or Matlab. Including third party workflows into VLAM-G modules is time consuming; since VLAM-G uses its own defined component architecture (Vasyunin, et al., 2007). 4.2.2 WS-VLAM - a new design A new design of VLAM-G, namely WS-VLAM, has been proposed and implemented (Vasyunin, et al., 2007). WS-VLAM decouples the GUI from the engine; the old RTS has been wrapped as a Grid service, which is deployed in a GT4 container. The original GUI is design as a thin client which can talk to the RTS service (Vasyunin, et al., 2007). The overall architecture is depicted in Figure 3 WS-VLAM overall architecture Figure 3. 20

Figure 3 WS-VLAM overall architecture In Figure 3, GT4 services e.g. Delegation service and a set of WSRF compliant services developed in the VL-e project are deployed in a GT4 container (Vasyunin, et al., 2007). A repository service stores information about available components, and allows the GUI client to invoke and to obtain available resources for workflow composition (Vasyunin, et al., 2007). The original RTSM is wrapped as a Grid service: a RTSM Factory Service and a RTSM Instance Service. The factory is a persistent service which instantiates a transient RTSM Instance service when a user submits workflow (Vasyunin, et al., 2007). The WS-VLAM thin client inherits the visual interface from VLAM-G for workflow composition (Figure 4). Figure 4 WS-VLAM - composer services The GUI offers various functions: The menu bar allows the user to navigate and mange scientific workflows by offering options to start and stop workflow executions, saving and loading workflows, to detaching and reattaching to the engine and more. The 21

Workflow component palette displays the list of available workflow modules/tasks which can be used to compose workflows in the workflow composition panel by connecting their input or out ports. The workflow can be stored in XML format. The Property panel shows information about any selected workflow module, including the input and output parameters. The Monitoring console shows monitoring information about the execution of the workflow. The following sections discuss how WS-VLAM enacts and executes a workflow in particular the following issue in detail workflow execution, workflow monitoring and user interaction support. Workflow execution To execute a workflow, the RTSM of WS-VLAM has to ensure a number of steps. Before the execution, the GUI client contacts the GT4 delegation service to create delegation credential, and retrieves an End Point Reference (EPR), which is used at the execution phase to authenticate and authorize the user (Vasyunin, et al., 2007). As a next step, the GUI client contacts the RTSM Factory to submit the workflow description together with the delegation and ERP (Vasyunin, et al., 2007). After that RTSM Factory uses the GT4 GRAM to schedule the workflow components and creates an RTSM instance which monitors the execution of the workflow (Vasyunin, et al., 2007). After the job has been submitted to Grid, the RTSM Factory returns the ERP of the RTSM instance to the GUI client. The EPR will be used by the GUI client when attaching and detaching a remotely running instance of workflow (Vasyunin, et al., 2007). The basic sequence diagram of the workflow submission mechanism and execution is presented in Figure 5. By subscribing basic events generated by the RTSM, a GUI client can obtain the run status of the experiment (Vasyunin, et al., 2007). A user can subscribe different events from GRAM for monitoring the execution of each workflow (Vasyunin, et al., 2007). Figure 5 WS-VLAM Workflow submission and monitoring 22

Workflow monitoring In WS-VLAM, monitoring support is realized by using the notification mechanism provided by GT4 Toolkit (Vasyunin, et al., 2007). Via the standard interface of the notification services, the GUI client can be instantiated as multiple instances for subscribing the notification generated by RTSM Resource Property for monitoring different execution status (Vasyunin, et al., 2007). The output and the standard error stream produced by a workflow component are redirected to the RTSM (Vasyunin, et al., 2007). WSRF notifications are used to inform a client about these updates: if a user subscribes to the WSFR topic associated with these logs, an event generated from the GRAM is propagated to the subscriber (GUI client) (Vasyunin, et al., 2007). This feature will be used for realizing future provenance functionality (Gerhards, Michael; Sander, Volker; Matzerath, Torsten; Belloum, Adam; Vasunin, Dmitry; Benabdelkader, Ammar, 2011) (Vasyunin, et al., 2007). Graphical output forwarding The graphical display generated by the workflow components and the visualization of the entire workflow is crucial to support the human to interact with workflow at runtime (Vasyunin, et al., 2007). A key issue for WS-VLAM is to deliver the remote graphical output to the end user. Since the current execution environment of WS-VLAM is Linux, graphical output of a workflow component is associated with network traffic between graphical application and virtual display to be used for rendering (X-server) (Vasyunin, et al., 2007). A public X-server can cause potential security problems, the privacy of the graphical display will not be protected but each component has a private X-server instantiated at the same host with a module (Vasyunin, et al., 2007). This allows making all network connections between graphical applications (X-clients) and virtual displays (X-servers) local, and being invulnerable for network attacks (Vasyunin, et al., 2007). Figure 6 WS-VLAM Graphical output An additional technical issue in forwarding graphical output is the common security policy on a grid cluster: direct connection from outside of the cluster to a worker node is often forbidden (Vasyunin, et al., 2007). To handle this situation, a secure connection forwarding mechanism is used, as shown in Figure 6. Graphical connection from the GUI client is mediated with a port forwarding component at the service side (Vasyunin, et al., 2007). Since the service side exist in the border node, it has bidirectional access to the internal node where graphical output is produced and also access to GUI client 23

which monitors the results (Vasyunin, et al., 2007). The WS-VLAM developers have modified standard VNC X server with GSI enabled authorization in order to improve standard VNC authentication/authorization mechanism (Vasyunin, et al., 2007). This solution provides the same protection level as any other standard Globus component (Vasyunin, et al., 2007). Discussion The previous paragraph describes architectural details of the WS-VLAM. The former design VLAM-G system was review, and a number of lessons were summarized followed by a description of the new design of WS-VLAM. WS-VLAM shows that using GT4 services can facilitate the development of workflow engine (Vasyunin, et al., 2007). The following conclusions are outlined from the description above (Vasyunin, et al., 2007): 1. Decoupling the user interface from the workflow engine allows the execution of the long running experiments is independent from the user interface. More importantly, it enables workflow monitoring from different locations. 2. The GT4 release provide rich set of services for the realizing workflow engines with consideration of security control, notification, and data management 3. The standardized service oriented interface of a workflow engine promotes the interoperability between different workflow systems. WS-VLAM shows an adoption of the scientific workflow management system reference architecture described in chapter 4.1. In the following the 4 layers of the scientific workflow management system reference architecture are linked to the Figure 7 which illustrates an overview of the WS-VLAM system. Figure 7 WS-VLAM system overview The presentation layer is separated from other layers providing subsystems for the presentation and visualization and workflow design in form of the Workflow composer. As described above, WS-VLAM composer is able to disconnect from the engine without interrupting the execution of a workflow. The workflow management layer is represented by the WS-VLAM Workflow Engine, a WSRF web service. The monitoring subsystem is realized by using the notification mechanism provided by GT4 Toolkit. WS-VLAM workflows are compatible with other 24

workflow engines e.g. Kepler and Taverna which allows the communication with other scientific workflow management system. The task management layer with the subsystems data product management, provenance management and a task management exists partly. The task management allows the WS-VLAM composer user the composition of workflow modules/task of different software tools and services offered by a repository service. The implementation of a provenance data management is still under development and will be implemented in this layer. The operation layer with the subsystems for heterogeneous data sources, software tools and services exists in form of Grid middleware services which provides a data management and a process & resource management. A complete analysis of matching the reference architecture with WS- VLAM architecture could be the topic of future research. The TAM survey in chapter 5.4, in particular the external variable system quality could be used to link the reference architecture with the WS-VLAM architecture. 4.2.3 WS-VLAM implementation - Reverse engineering tool The Service oriented design methodology by (Lago & Razavian, 2012) which will be applied to WS-VLAM in chapter 9.1 requires considering the existing WS-VLAM implementation. Integrating new ideas to the design of an existing implementation may require service migration or changes to the existing implantation which makes it necessary to understand the existing code and implementation. The complete existing architecture has been described in an abstracted manner in the previous chapter. This description of on WS-VLAM is the foundation for this design document in chapter 9.1. However, to get an additional understanding of the involved services and the implementation of WS-VLAM, the reverse engineering tool agilej 9 for eclipse 10 has been used. Agilej allows to analysis existing code by providing an overview of the developed code using UML. Because of the time limitation and the complexity of WS-VLAM it is not possible to review all existing code. The reverse engineering tool was used to get a better understanding of the messages being passed between the services. This information is used in the Service oriented design methodology by (Lago & Razavian, 2012) applied to WS-VLAM in chapter 9.1. The following chapter describes the SOADM by (Lago & Razavian, 2012) in theory. 4.3 Service oriented Analysis and Design Methodology Service Orientation (SO) is having a similar impact on today s software development as Object Orientation had in the nineties (Cockburn, 1993). While Object orientation has already reached mainstream adaption, the adoption of Service Orientation is still on going (Lago & Razavian, 2012, p. 44). Service oriented Architecture (SOA) is a paradigm for effectively delivering software services in a dynamic environment. Chapter 4.2 9 http://www.agilej.com/ 10 http://www.eclipse.org/ 25

described the importance of a dynamic environment for SWfMS, especially for the development of OGSA/WSRF based WS-VLAM. The following section provides a brief overview of the advantages of using SOA specifically for the development of an SWFMS summarized by (Lin C., et al., 2009): 1. Service loose coupling: Service loose coupling minimizes the dependencies among subsystems of an SWFMS by the definitions of a set of language and platform independent interfaces (Lin C., et al., 2009). The functionality of subsystems is exposed as a Web services (In the case of WS-VLAM as WSRF). As a result, an SWFMS can be composed on demand from various subsystems provided by different parties as Web services (Lin C., et al., 2009). 2. Service abstraction and autonomy: A Web service provides an abstract interface that is independent from its implementation (Lin C., et al., 2009). Moreover, each Web service is autonomous in the sense that a service provider has the control over the application logic that the Web service encapsulates (Lin C., et al., 2009). As a consequence, a service provider can dynamically change the implementation and deployment environment of a Web service for a subsystem of an SWFMS with no downtime for the SWFMS as long as such changes do not affect the defined interface (Lin C., et al., 2009). The autonomy also greatly facilitates the management of the development and evolution of the whole system (Lin C., et al., 2009). 3. Service reusability: Each subsystem of an SWFMS becomes a uniform computing unit with standard interface descriptions and universal accessibility through standard communication protocols; it can be reused across different SWFMSs, even simultaneously used by both local SWFMSs and other SWFMSs across the Internet (Lin C., et al., 2009). 4. Service discoverability: As each subsystem of an SWFMS is implemented as a Web service that is developed with a semantic description, one can register the service in some public service registries (Lin C., et al., 2009). As an outcome, a subsystem becomes discoverable and can be selected and used by other SWFMSs on demand (Lin C., et al., 2009). 5. Service interoperability: Service interoperability is enabled by the open standards of messages and communication protocols for Web services, which are supported by a large body of IT industry and the Web Services Interoperability Organization (WS-I) (Lin C., et al., 2009). Many SOA methodologies have been proposed and practiced in both academia and industry (Lago & Gu, 2011). Several of these methodologies share common features (e.g. cover similar life-cycle phases). Then again these methodologies are presented for different purposes, ranging from project management to system modernization, and from business analysis to technical solutions development. Only a few do provide concrete support for the development of software that is truly service-oriented (Lago & Gu, 2011, p. 1) (Lago & Razavian, 2012, p. 44). Lago & Razavian (2012) argue that existing SOA methodologies have the same underlying assumptions as traditional software engineering methodologies. For example 26

they assume that the developer has ownership on the software or service, and has a system model in mind carrying complete definition of all functionalities that should be produced (Lago & Razavian, 2012, p. 44). Both assumptions are not true in serviceoriented (SO) development and cloud computing (CC) where services are neither owned nor always part of a monolithic system (Lago & Razavian, 2012, p. 44). According to (Bell, 2008) the introduction of the SO paradigm introduced a shift in how software systems are perceived; a shift from a large system to a set of small pluggable elements (Lago & Razavian, 2012, p. 44). Lago & Razavian (2012) therefore, argue that the subject of the architecting process should also shift from a system to the building blocks (i.e. the services); SO methodologies should be in-line with such shift. Lago & Razavian (2012) argue to support a software architecture following the service-oriented paradigm; a SO methodology should cover some essential ingredients, which are described in the following section: 1. Support Both Service- and Application Development. Developers and designers of service-oriented software can play the role of either the service provider or the service consumer (or both) (Lago & Razavian, 2012). The service provider typically develops reusable software services, by doing that, it might reuse (or not) other available services, to build its own service compositions (Lago & Razavian, 2012). In the latter case, the service provider switches to a service consumer role. In any case, the output of the development is an inventory of independent services (or service pool) meant to be published for (internal or external) reuse (Lago & Razavian, 2012). In the service provider perspective the development challenge is to identify those necessary business functions that should be added to a service inventory, without knowing the business logic of the system/sba that will reuse them (Lago & Razavian, 2012). The service consumer, instead, typically develops SBAs, in doing that; it always reuses services provided by third parties (Lago & Razavian, 2012). The outcome of the development is in this case a software system meant to be purchased to customers and directly used by end-users (Lago & Razavian, 2012). In this service consumer perspective the development challenge is to identify the characteristics of the services to be reused, and design and application that will dynamically discover and compose them, and still deliver a reliable overall system (Lago & Razavian, 2012). 2. Focus on SOA. SOA is an architectural style that supports Service Orientation (Bell, 2008). For this matter, it should (implicitly or explicitly) support (technical) mechanisms for service publication, dynamic discovery and composition (Lago & Razavian, 2012). 3. Aim at Software Services. At a conceptual level, a service can be defined as a logical representation of a repeatable (business) activity that has a specified outcome (e.g. check customer data, provide weather report, execute workflow, and monitor workflow execution). A service is self-contained (state-less and adhering to a service contract); may be composed of other services (service composition); and is a black-box to its consumers (Lago & Razavian, 2012). 27

4. Embrace the OpenWorld Assumption. Software services yield distributed ownership (Baresi,, Di Nitto, & Ghezzi, 2006). i.e. they are often owned by (other) service providers. Developing (own) SBAs or service compositions implies that reuse is planned at design time but can be actually tested only at run-time. Modern SO development must hence support a mix of design- and run-time development activities to make sure that dynamic aspects are engineered well and that the resulting software is reliable (Lago & Razavian, 2012). While all four ingredients described above are relevant, the major problem in current SOA methodologies is in the first one (Lago & Razavian, 2012). 4.3.1 Terminology Overview This section defines the different types of services as well as other basic concepts used in Service Inventory Analysis and Design Methodology (Lago & Razavian, 2012, p. 46): Conceptual Service: a conceptual service that is implementation agnostic. Considering the perspective of our methodology all services are conceptual as the methodology presented here does not address implementation of the services. Business Service: a self-contained, stateless business function that accepts one or more requests and returns one or more responses through a well-defined, standard interface. During service identification, some elicited business services become the service candidates for design. They also might become service operation candidates to be clustered in service candidates. Service Candidate: conceptual service identified during analysis that is a candidate software service. Service Operation Candidate: a service operation identified from functional requirements; it might become a service candidate itself, or be composed (i.e. aggregated) in a (more complex) service candidate. Task Service: service that mainly executes a functionality. Entity Service: service that mainly manages, and offers access to, a (complex) data resource. Hybrid Service: a mix of task service and entity service. Utility Service: Domain- or application independent service offering access to generic functions or generic data resources. Also called Infrastructure service. 4.3.2 Methodology and Its Supporting Models The following describes Lago & Razavian (2012) Service Oriented Analysis and Design Methodology (SOADM) for SO analysis and design of service inventories. The service inventories provide the building blocks for a successful service offer following a SO paradigm. The presented methodology by Lago & Razavian (2012) explicitly addresses the perspective of a service provider developing inventories of software services (i.e. 28

service provider perspective); it also supports a service consumer perspective whenever services are to be reused from other providers. According to Lago & Razavian (2012) Service orientation is shifting the focus from engineering systems to integrating existing software services. Throughout software development enterprises play service provider and service consumer roles, depending on the product they aim at producing (being a service inventory or a SBA), the methodology to be followed changes considerably (Lago & Razavian, 2012). Many service oriented approaches for design and development of services have been proposed. Some of these approaches support the entire service engineering process (e.g. (Amoako-Gayampah & Salam, 2003), (Papazoglou, 2006)), while some others cover only a few phases such as service analysis and design (e.g. (Zimmermann, 2004), (Allen, 2007)). The methodology presented by Lago & Razavian (2012) falls under the second category by specifically covering service analysis and design. A brief overview of the Service Inventory Analysis and Design Methodology is illustrated in Figure 8, Figure 8 Service Inventory Analysis and Design Methodology Service oriented (SO) analysis is defined as the process of determining how business requirements can be represented through business service candidates, while Service oriented (SO) design is the process of modelling a software service inventory and/or reusing it to compose a SBA. In these phases, for modelling purposes by Lago & Razavian (2012) reused state-of-the-practice notations like UML and SoaML, and extended them only where they revealed. The following section describes each step of the methodology introduced by Lago & Razavian (2012). Service oriented Analysis 1. Business Service identification This step aims to identify business services by the use of business process models and conceptual data models. There are two approaches for developing these models. The first approach is determined by functional models of preexisting systems (i.e. bottom-up SOA migration), while the second approach is determined by the targeted business domain, as the list of functional requirements (i.e. top-down service development) (Lago & Razavian, 2012, p. 47). Business services are identified by clustering service relevant functionality within a business process. The elements of a business process model (e.g. 29

activities and decision elements) are examined as candidate business services with the goal to identify business process elements which represent selfcontained functionality (Lago & Razavian, 2012, p. 47). Hence, business process models represent a sequence of business services, and therefore, highlight potential orchestration behavior (Lago & Razavian, 2012, p. 47). To model business processes, this methodology uses UML activity diagrams (see Figure 9, I)). The clusters of functionality representing the business services are illustrated in dashed boxes (Lago & Razavian, 2012, p. 47). By modeling clusters in this explicit way, the analyst is helped in recognizing/finding relevant candidate services. Modeling clusters also supports the analyst in comparing similar clusters for either keeping them separate, or merging them in a unified functionality (Lago & Razavian, 2012, p. 47). The second model specifically important during this step is the conceptual data model which facilitates the identification of the business services addressing the functionality of business data entities (Lago & Razavian, 2012, p. 47). The conceptual data model elements (i.e. data entities and relationships) are viewed as candidate business services (Lago & Razavian, 2012, p. 47). These business services are very reusable since they follow the principle of separation of concerns and abstract data types (as in object orientation) (Lago & Razavian, 2012, p. 47). 2. Context identification The main goal of this step is to identify a set of external elements that interact with the service inventory (i.e. external service providers, external services or SBAs, or external end users) (Lago & Razavian, 2012, p. 48). The outcome of this step is a context model that shows the inventories in their environment. To draw context models this Service Inventory Analysis and Design Methodology uses the UML use case diagram notation (Lago & Razavian, 2012, p. 48). 30

Figure 9 Examples of Analysis and Design Models (Lago & Razavian, 2012) 3. Business service decomposition This step aims to select the candidate services and their constituent service operations by choosing business services identified during the previous steps that will be (partially) automatized by means of software services (Lago & Razavian, 2012, p. 48). Each business service is modelled as a collection of candidate services. This Service Inventory Analysis and Design Methodology models the decomposition of candidate services using the UML use case diagram notation (Lago & Razavian, 2012, p. 48). Service oriented Design 4. Service candidate definition In this step, the service candidates of each business service which were identified in the previous steps are mapped on the service types (i.e. hybrid, task, entity and utility), from the perspective of a service provider (Lago & Razavian, 2012, p. 49). Figure 9, II shows the software service decomposition model. The figure illustrates the service candidates of a business service with its corresponding service types. The identification of the service types helps clarify the scope of reuse (i.e. domain-specific vs. domain generic) of the services in question. This modelling mechanism addresses an important issue in industrial practice, which is the need to reuse services developed for different purposes. Lack of support in this step leads to unnecessary duplication of services and governance problems. These are two major issues in IT service developing companies nowadays (Lago & Razavian, 2012, p. 49). 31

5. Service inventory identification Service inventory identification is about make decisions on which services are going to be provided by the inventories. The decision alternatives include the following (Lago & Razavian, 2012, p. 49): reuse an existing element (e.g. component) and transform it as a service using wrappers; develop the candidate services from scratch; outsourcing the service realization; or purchasing, leasing, or paying per use (for) a service. Figure 9, IV) illustrates the services inventory of a participant which consumes the services provided by two service provider. The result of this step is the service inventories representing the collection of software services of different types that each participant offers (Lago & Razavian, 2012, p. 49). 6. Service contract definition This step aims to identify the service contracts between participants. Crossdomain service interaction is represented by service contracts. A service contract represents how participants work together to realize the business service s goals (Lago & Razavian, 2012, p. 49). To identify the service contract each business service is modelled with service interaction diagram (see Figure 9, III)). The interactions crossing participant s domains are identified as service contracts. In a further step the service contracts are modelled using SoaML contracts diagrams (see Figure 10, I)). This procedure allows the service provider to create a holistic overview of what its service inventory is offering to potential consumers. Moreover this step gives an overview of established service level agreements with third-party service providers (Lago & Razavian, 2012, p. 49). This step supports the improvement of SO reuse and governance. 7. Service network modelling This step models how participants work together to realize each business service using their contracts. Service networks are modelled using SOAML service network architecture diagram (Lago & Razavian, 2012, p. 49). Figure 10 II.) Illustrates a service network architecture diagram with evolved participants (squares) and the service contracts (cycles). 32

I) SOAML Service Contracts II) SOAML Architecture Diagram Figure 10 SOAML Examples of Analysis and Design Models Services network architectures are usually modelled in a recursive manner. A participant providing a service in a higher level network architecture can itself have a network architecture (Lago & Razavian, 2012, p. 50). 8. Service choreography modelling This step defines the service choreography for each service contract. In particular the service choreography model represents the contract s behaviour in terms of what is transmitted between the parties and when, without defining the internal behaviour of the parties (Lago & Razavian, 2012, p. 50). The choreography models are also defined in a recursive manner. This way, each participant defines its own internal service behaviour. Service choreographies are modelled using SoaML choreography diagram. The internal behaviour of the software services are modelled using the UML sequence diagram (Lago & Razavian, 2012, p. 50). Enrichment of the service oriented design methodology The SOADM has been enriched with additional sub steps based on previous studies in different trail studies (Lago, Patricia, 2012). The methodology can be enriched with the Design space documentation (Gu, Lago, & Vliet, 2010) (Lago, Patricia, 2012). The design space includes design issues that must be addressed to develop the design solution of a software service, the related options and the decisions are described with a rationale in the design document. The components design space, the introduction of a strategy and the refinement of the design space with a strategy are highly relevant for this thesis because these components provide an interface to integrate and to address user acceptance issues to the design of a software service. There are two tools being used to implement the design space: Architectural Knowledge design Space Modelling template table (AK-SPAM) and the Question-Option- Criteria (QOC) notation. Each design issue is expressed in form of a question. This helps in focusing on the right issues, and avoids confusion between the problem to solve and its possible solutions (Lago, Patricia, 2012). Each issue description includes a motivation why this question is relevant for the software service. For each design issue several possible options are identified and evaluated. Possible relationships among options also 33

need to be considered. Decision making on which option to choose is supported by providing a set of criteria. These criteria correspond to the set of service aspects which are defined in previous steps of the methodology. For each design issue, the options and the criteria are evaluated by a relational. All these items are documented by using the Architectural Knowledge Design Space Modelling template table (AK-SPAM) and the Question-Option-Criteria (QOC) notation (Gu, Lago, & Vliet, 2010) (Lago, Patricia, 2012). Refining the Design Space becomes necessary when an additional software service strategy is introduced. For developers or other stakeholder in a software project, it can be interesting to refine the design space according to a strategy. For example it can be interesting to refine a design space according to green strategies with the goal to make the software solution environmental friendly. To include strategies in the design space, the design space needs to be edited or redefined. To do that, the identified strategies need to be mapped to the AK-SPAM and QOC notation in the design space described in the previous step. It is necessary to revisit the design space to refine and to reflect on new questions and criteria or decisions introduced by the strategy. The refinement of the design space can take two main forms (Lago, Patricia, 2012): a) Extending the design space: the strategies may lead to new design issues, options or criteria. b) Challenging the already existing design decisions: In order to enable the strategies, it might be necessary to challenge design issues describe in the previous step. In a last step the strategy needs to be mapped with the design space. The strategy usually consists of a goal and actions to achieve the goal. The goals and actions are mapped on either questions (sub-questions) or options. This means a strategic goal may be formulated as a question. An action may be formulated as an option or as a sub questions (Lago, Patricia, 2012). This chapter has introduced the service oriented design methodology which will be applied to WS-VLAM in chapter 9.1. The following chapter builds the foundation for the survey research conducted in this thesis, by introduction the Technology Acceptance Model. 4.4 The Technology Acceptance Model With increasing use of information technology in the 1970 s and an increasing number of failing system adoptions in organisations, predicting system use became an area of interest (Chuttur, 2009, p. 2). Most of the studies carried out failed to produce reliable measures that could explain system acceptance or rejection (Davis F. D., 1989). In 1985, Fred Davis introduced the Technology Acceptance Model (TAM) in his doctoral thesis at the MIT Sloan School of Management (Davis F. D., 1989). He proposed that system use is a response that can be explained or predicted by user motivation. This motivation in turn, is directly influenced by an external stimulus consisting of system features and capabilities (Figure 11). 34

Figure 11 Conceptual model for technology acceptance (Davis F. D., 1989, p. 10) By relying on prior research, e.g. Theory of Reasoned action (Fishbein & Ajzen, 1975), Theory of Planned Behaviour (Ajzen, 1991) and other related research studies, Davis further defined his conceptual model to propose the Technology Acceptance Model as shown in Figure 12. Figure 12 Original TAM proposed by Fred Davis (Davis F. D., 1989) In his work, (Davis F. D., 1989) proposed that users motivation can be explained by three factors: Perceived Usefulness, Perceived Ease of Use and Attitude toward Using the system. Davis assumed that the attitude of a user towards a system was a major determinant whether the user will use or reject the system (Chuttur, 2009, p. 2). The attitude towards using was considered to be influenced by the perceived usefulness and the perceived ease of use, with perceived ease of use directly influencing perceived usefulness. Both these beliefs were hypothesized to be directly influenced by the system design characteristics, represented by X1, X2, X3, in Figure 12 (Chuttur, 2009). During later studies, Davis refined his model to include other variables and modify the relationships that he initially formulated. Also other researchers applied, and proposed several additions to the Technology Acceptance Model (TAM). Over time, TAM evolved into a leading model for explaining and predicting system use (Chuttur, 2009, p. 2). According to (Lee, Kozar, & Larsen, 2003) TAM has become that widespread and popular that it has been cited in most of the research that deals with user acceptance of technology. Some researchers also criticise TAM for attracting more easy and quick research, such that less attention has been given to the real problem of technology acceptance (Lee, Kozar, & Larsen, 2003) (Chuttur, 2009). 35

Today s research on technology acceptance is still incomplete and therefore an understanding of the assumptions, strengths, and limitations of the Technology Acceptance Model is essential for everyone willing to study user acceptance of technology (Chuttur, 2009, p. 3). 4.4.1 Perceived usefulness and perceived ease of use Previous to the work of Davis, several studies had emphasized the importance of perceived ease of use and perceived usefulness in predicting a human s behaviour regarding an information system. An extensive review of these studies can be found in (Davis F. D., 1989). In his work, Davis assumed that people tend to use or not use system to the degree that they believe it will support them perform their job better (perceived usefulness). Furthermore Davis assumed that the belief of the efforts required to use a system can directly affect system usage behaviour (perceived ease of use) (Chuttur, 2009, p. 4). Davis defined perceived usefulness and perceived ease of use as follows (Davis F. D., 1989) (Chuttur, 2009, p. 4): Perceived usefulness: The degree to which an individual believes that using a particular system would enhance his or her job performance. Perceived ease of use: The degree to which an individual believes that using a particular system would be free of physical and mental effort. In further research Davis, proceeded to the problem of measuring the perceived usefulness and perceived ease of use of a system (Chuttur, 2009, p. 4). Developing measurement scales To measure perceived usefulness and perceived ease of use of a system Davis referred to psychometric scales used in psychology (Davis F. D., 1989). These scales usually require an individual to respond to numerous questions that relate to a given context. The responses gained from these questions can then be analysed and used as an indication of a human s internal belief for the given context. For TAM, Davis developed scales for perceived usefulness and perceived ease of use in three stages: a pretesting phase, an empirical field study, and a laboratory experiment, and each time he modified and refined the scales (Chuttur, 2009, p. 5) Davis started with a 14 item scales for each, perceived ease of use and perceived usefulness. An overview of the original 14 item questionnaire can be found in (Davis F. D., 1989, p. 324). He tested the questions in an experiment and went on in improving the quality of the 14 item scales by categorizing the items and clustering similarities such that, items that were free from uncertainty, and accurate enough to measure either perceived ease of use or perceived usefulness were identified. The result was an improved 10 item scale for each perceived ease of use and perceived usefulness. An overview of the original 10 item questionnaire can be found in (Davis F. D., 1989, p. 326). The scales were tested in several studies. The studies were evaluated using analysis method, principal component analysis, multitrait-method analysis, and factor 36

analysis. The tests showed a high reliability for the 10 item scales (Chuttur, 2009). In a last step Davis went on further to improve the 10 item scales to develop two shorter six item scales. Davis thought that shorter scales can be more practical in the real world situation. He used the Spearman-Brown prophecy formula to reduce the number of items to six (Chuttur, 2009, p. 8). The final six item scales are illustrated in Table 1 and Table 2. The tables were used in a research studying the IBM software Chart-Master. Table 1 Revised 6 items scale for perceived usefulness (Chuttur, 2009, p. 8). Table 2 Revised 6 items scale for perceived ease of use (Chuttur, 2009, p. 8). To measure the attitude towards a system, Davis used a scale developed by Ajzen and Fishbei for operationalizing attitude toward behaviour. The scale measures five different types of attitude that a person may have toward a system on a seven point scale with mid-point labelled neutral as shown in Figure 13. Figure 13 Scale to measure Attitude towards a system (Chuttur, 2009, p. 7) To measure the actual use of a system, Davis developed an actual usage scale with six labels: Don t use at all, Use less than once each week, Use about once each week, Use several times a week, Use about once each day and Use several times each day. Results of his experiments showed that, self-reported usage was significantly correlated with both perceived ease of use and perceived usefulness confirming Davis original TAM 37

model illustrated in Figure 12. Additionally, Davis used regression analysis to determine the relationship that existed in his TAM model. Along with the confirmation of his initial hypothesis, Davis also discovered other relationships that he had expected to be insignificant as shown in Figure 14. Figure 14 New relationships formulation in TAM (Davis, F. D., 1993, p. 481) Davis suggested that in contrast to what he initially predicted, perceived usefulness could also have a direct influence on actual system use. He also found that system characteristics could directly affect the attitude of a person toward using the system, without the need for the person to form an actual belief about the system as shown in Figure 14. Subsequently, other studies followed in order to investigate the relationship between the different variables in the TAM model (Chuttur, 2009). 4.4.2 Technology acceptance model evolving Later development of TAM includes behavioural intention as a new variable that is directly influenced by the perceived usefulness and the attitude towards a system (Davis, Bagozzi, & Warshaw, 1989) (Davis F. D., 1989). Davis proposed that there can be cases when, given a system which was perceived useful, an individual might form a strong behavioural intention to use the system without forming any attitude, therefore he modified the TAM model (Chuttur, 2009, p. 9) as illustrated in Figure 15. Figure 15 First modified version of TAM (Chuttur, 2009, p. 10) Davis, Bagozzi, & Warshaw used the new model, shown above, to conduct a study (Davis, Bagozzi, & Warshaw, 1989). The study results indicated a strong correlation 38

between reported intention and self-reported system usage with perceived usefulness responsible for the highest influence on people s intention. Perceived ease of use was found to have a small but significant effect on behavioural intention which later decreased over time. However the main discovery was that both perceived usefulness and perceived ease of use were found to have a direct influence on behavioural intention. This lead to the elimination of the attitude construct from the model shown in Figure 15. The resulting model is shown in Figure 16. Figure 16 Final version of TAM (Chuttur, 2009, p. 10) Hence, by eliminating the attitude towards using construct and introducing the behavioural intention constructs, the results obtained for the direct influence of perceived usefulness on actual system use as shown in Figure 14, could be explained. At the same time by removing the attitude variable eliminated unexplained direct influence from the system characteristics to the attitude variable (Chuttur, 2009, p. 10). An additional change to the original TAM model was the consideration of other factors, described as external variables that might influence the beliefs of a person towards a system. The external variables typically included system characteristics e.g. user training, user participation in design, and the nature of the implementation process (Venkatesh, V.; Davis, F.D., 1996; Chuttur, 2009). Determinants for perceived usefulness An important extension for TAM was developed by (Venkatesh, V. ; Davis, F.D., 2000). Venkatesh and Davis recognized that TAM had some limitations when it comes to explain why people perceive a system useful or not. They proposed additional variables which could be added as antecedents to the perceived usefulness variable in TAM (Chuttur, 2009, p. 14). The extended model with the variables Result Demonstrability, Output Quality, Job relevance, Image, Subjective Norm, Experience and Voluntariness is illustrated in Figure 17. 39

Figure 17 Extending TAM to include determinates for perceived usefulness Using the extended TAM model Venkatesh and Davis were able to provide more detailed explanation for the reasons why participants found a given system useful (Chuttur, 2009, p. 14). Using the extended TAM model Venkatesh and Davis were able to provide more detailed explanation for the reasons why participants found a given system useful. Their research results (Venkatesh, V. ; Davis, F.D., 2000) also showed that the extended TAM performed well in both voluntary and mandatory environments. There is one exception that subjective norm had no effect in voluntary settings but did in mandatory settings (Chuttur, 2009, p. 14). Determinants for perceived ease of use A second important extension of the TAM was made by (Venkatesh, V., 2002). He was interested in identifying the antecedents to the perceived ease of use variable in the TAM model. Figure 18 shows the extension of TAM. The extension consists of two antecedents for perceived ease of use: anchors and adjustments. 40

Figure 18 Extending TAM to include determinates for perceived ease of use The anchors group was considered as general beliefs about computers and computer usage and consists of the variables computer self-efficacy, perceptions of external control, computer anxiety and computer playfulness. The adjustment group was considered as beliefs that are shaped base on direct experience with the target system and consists of the variables perceived enjoyment and objective usability. The variables in both groups have their foundation in former research on identifying the antecedents to perceived ease of use (Davis, Bagozzi, & Warshaw, 1992) (Venkatesh, V.; Davis, F.D., 1996). Venkatesh s research (Venkatesh, V., 2002) also included tests of the new extension which showed strong support for the variables in explaining perceived ease of use for a given system (Chuttur, 2009, p. 15). 4.4.3 Applying the Technology Acceptance model TAM has been applied in numerous studies testing user acceptance of information technology (Table 3). The following table lists the different technologies which have been used in TAM research. 41

Table 3 Variation in TAM application (Chuttur, 2009, p. 13). Most of these studies found significant statistical prove for the influence of perceived usefulness and behavioural intention to use a specific system. These studies also found mixed results for the direct relationships between perceived ease of use and usage behaviour. Overall, all of these studies provided strong evidence to support TAM as a model for predicting system usage behaviour (Chuttur, 2009, p. 13). 4.4.4 Limitations of Technology Acceptance Model Beside the fact that several studies have confirmed the robustness of the TAM model, several others researchers have also highlighted important limitations of the model. Chuttur, (2009) categorised the criticisms for the TAM model in three categories: The methodology used for testing the TAM model The variables and relationships that exit within the TAM model The core theoretical foundation underlying the TAM model A discussion of the limitations is not part of the thesis. An outline of these limitations can be found in (Chuttur, 2009, p. 17). 5 Applying the Technology Acceptance Model to Scientific Workflow Management System Applying TAM to a new type of Information Systems, a Scientific Workflow Management System, requires an adaption or extension of the original TAM model. No study has been conducted to apply TAM to a SWFMS, yet. In addition to the description of the literature review in chapter 4.4 and the service oriented analysis of WS-VLAM in chapter 9.1.1, a number of TAM application and related research have been analysed to identify fitting and relevant external TAM variables. The following studies have been used as a foundation for the adaption: 42

1. A Reference Architecture for Scientific Workflow Management Systems and the VIEW SOA Solution (Lin C., et al., 2009) 2. An empirical examination of the acceptance behaviour of hotel front office systems: An extended technology acceptance model (Kim, Lee, & Law, 2007) 3. A comparative Study on acceptance technologies between an integrated Software (MAXIMO) and an ERP (SAP) in British Gas (BG) Tunisia (Hassairi & Ayed, 2009) 4. Technology Acceptance Model for Mobile Services as a Design Framework (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011) The overall goal of this research is to develop a TAM application which has high value for the design and development process of a SOA based scientific workflow management system. 5.1 Developing a Technology Acceptance model for Scientific Workflow System The following section introduces the developed Technology Acceptance model for scientific workflow systems (TAM-SWS) (Figure 19). TAM-SWS has been developed to study user acceptance of WS-VLAM a SWfMS based on Open Grid Services Architecture (OGSA). Figure 19 Technology Acceptance model for Scientific Workflow Systems The latest version of the TAM model (Davis F. D., 1989) has been extended with three external variables; information system quality (modified to scientific workflow management quality) consisting of 3 sub variables; System Quality, Information Quality, and Support Quality, social influence and experience. Furthermore Perceived ease of adaption has been added as a direct influence on actual use. The core TAM with the variables Perceived ease of use, Perceived Usefulness, Behavioural Intention to use and Actual system use are based on the final TAM version. The following section describes the variables used in this TAM application. To study the user acceptance of WS-VLAM a questionnaire is developed which described in chapter 5.2. Of grade influence in 43

developing the model in Figure 19 is the service oriented analysis in chapter 9.1.1. The service oriented analysis provides a detailed business domain description, business service identification and context identification. All three items help to develop the SWS-TAM by providing additional information on the technology and business domain. 5.1.1 Scientific Workflow System Quality There are several studies on the success factors of information systems where the quality of an Information System is examined in three dimensions; system, information, and service/support quality (Eldon, Y. L.;, 1997; Pitt, Watson, & Kavan, 1995; Petter, DeLone, & McLean, 2006). The system s quality signifies the operational efficiency in the function of an information system (Kim, Lee, & Law, 2007, p. 502). System quality is also described as the desirable characteristics of an information system i.e. ease of use, system flexibility, system reliability, and ease of learning, as well as system features of intuitiveness, sophistication, flexibility, and response times (Petter, DeLone, & McLean, 2006, p. 239). In prior studies, system quality is often reflected by a system s technical characteristics, including dependability, response, and other related factors (Bailey & Pearson, 1983) (Kim, Lee, & Law, 2007, p. 502). Because of the correlation between system quality and the presence of potential errors in the system, the consistency of user interaction, response rate, documentation, program code quality, and maintenance were also included (Petter, DeLone, & McLean, 2006, p. 239). Information quality is defined through the desirable characteristics of the information system outputs. For example: relevance, accuracy, conciseness, completeness, understandability, timeliness, and usability (Petter, DeLone, & McLean, 2006, p. 238). Information quality can be also very subjective from the user s perspective. That is why it is also often factored as part of user satisfaction (Bailey & Pearson, 1983). The Service or Support quality is defined as the quality of the support that system users receive from the IS department and IT support personnel i.e. responsiveness, accuracy, reliability, technical competence, and empathy of the personnel staff (Kim, Lee, & Law, 2007, p. 502). The integration of the variable Information System quality has been successful applied to TAM in a research on a hotel front office system (HFOSs) (Kim, Lee, & Law, 2007). The research found empirical evidences which indicate the significance of the variable Information System quality. The research was able to find acceptance of HFOSs from the perspective of hotel frontline employees through the external variables of information system quality (Kim, Lee, & Law, 2007). However, there are a number of differences between a hotel information system and a scientific workflow management system. This makes it necessary to redefine the definition of the Information Systems Quality variable by defining a new variable for Scientific Workflow Information System Quality (SWfMS quality). The new SWfMS quality variable is based on two foundations. Firstly it is based on the information systems quality attributes described above. The SWfMS quality variable is as well as any other information system characterised by the System quality, Information Quality and support quality as defined in the literature review above. Secondly there is a focus on SWfMS specific aspects. These SWfMS specific aspects in form of requirements have been described in chapter 4.1.1 in relation to the 44

Workflow Management System Reference model, defined by (Lin C., et al., 2009). The seven SWfMS requirements are based on an extensive literature review (Lin & Lu, 2008). In combination with the original System Quality variable the following seven SWfMS variables/requirements define the new SWfMS Quality variable. User interface customizability and user interaction support Reproducibility support Heterogeneous and distributed services and software tools integration Heterogeneous and distributed data product management High-end computing support Workflow monitoring and failure handling Interoperability The above defined SWfMS Quality variable provides insights on the quality of a scientific workflow management system, hence is highly relevant for examining user acceptance of SWfMS. Therefore the SWfMS Quality variable (consisting of SWfMS System Quality, SWfMS Information Quality and SWfMS Support quality) has been added to the SWS- TAM model. Three tables of questions have been developed, dividing the following topics SWfMS System Quality, Information Quality and SWfMS Support quality. The developed questions are attached in chapter 5.2. 5.1.2 Social Influence In their research (Hassairi & Ayed, 2009) developed an extended Technology acceptance model to compare (BG) Tunisia s user acceptance of MAXIMO and SAP enterprise resource planning systems for maintenance and planning, work orders and inventory management modules. Hassairi & Ayed, (2009) extended TAM with a number of variables; Information Accessibility, Perceived Compatibility, Personal Innovation, Social Influence. The research found empirical evidences that indicate the significance of the variables. The overall outcome of the research shows a greater support and user acceptance for the SAP ERP than for the MAXIMO ERP system. The result of the research supports British Gas (BG) Tunisia in developing their IT strategy. The social influence is an important aspect for open source SWfMS, because social influence within a scientific community could have an influence on actual user acceptance. Based on Hassairi & Ayed, (2009) research the social influence variable has been added to the SWS-TAM. The questions have been adopted from (Hassairi & Ayed, 2009) and are attached in chapter 5.2. 5.1.3 Experience The variable experience plays an important role in the user acceptance of SWfMS. The variable has been introduced by (Venkatesh, V. ; Davis, F.D., 2000) in one of the first TAM extensions described in chapter 4.4.2. Based on (Venkatesh, V. ; Davis, F.D., 2000) 45

research the Experience variable has been added to TAM-SWS. The questions have been edited from (Venkatesh, V. ; Davis, F.D., 2000) and are attached in chapter 5.2. 5.1.4 Perceived Ease of Adoption In their paper (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011) present a modified technology acceptance model customized for mobile services (TAMM). According to the authors personal mobile devices are increasingly being used as platforms for interactive services. The (TAMM) is illustrated in Figure 20. Figure 20 Technology Acceptance Model for Mobile Services Perceived Ease of Use remains as a variable from the original TAM while perceived usefulness has been removed. Perceived Value has been added to TAMM instead. The authors conducted field trials with consumers where it became evident that in the consumer market, perceived usefulness may not indicate adequate motivation to use the mobile service (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011, p. 86). Furthermore the variable Trust has been added to TAMM. The original TAM (Davis F. D., 1989) was designed for information systems at work where the users could rely on the information and services provided in terms of how their personal data was used. This is different in the mobile service environment. According to the authors research and literature review on TAM and e-commerce, trust plays an important role for user acceptance (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011, p. 86). An additional new variable is the Perceived Easy of Adoption, which is defined as taking service into use. In the original TAM settings with information systems at work, this certainly was not an issue as users typically got their applications ready installed. Field trials showed evidence that a major obstacle in adopting commercial mobile services was the users unawareness of available services, as well as problems anticipated in taking services into use (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011, p. 87). Moreover, the model differs between the intention to use and taking a service into use. The authors claim that taking a service into use may constitute a major gap hindering the transition from usage intention to actual usage (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011, p. 87). TAMM has been set up based on field trials of several mobile services with more than 200 test users. Furthermore the research presents TAMM as a design and evaluation framework. The approach is applied to four practical case studies which gives insights on how the user acceptance research could be useful for the design process of software. TAMM and the ideas related to the development of a framework for design and evaluation is of high interest for the TAM application to SWfMS because of its relation 46

service orientation. There are some intercepts between the topics service oriented information system and mobile services. In the case of open source service oriented SWfMS perceived ease of adoption plays a role in the actual use of the system. In the case of open source software the end user has to be able to setup the system him/herself and integrate it into his/her work environment. If this adoption fails the actual use is not possible. Barriers in the adoption process of service oriented software are often related to technical requirements as well as knowledge of the user and integration issues related to the IT and working environment of the end user. Based on (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011) the variable perceived ease of adoption has been added to TAM-SWS. Relevant questions have been adopted from (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011) and are attached in chapter 5.2. 5.1.5 Technology acceptances model variables The original core TAM with the variables Perceived usefulness, Perceived ease of use, Behavioural Intention to use and Actual System use has been adopted from (Davis F. D., 1989) described in chapter 4.4. The core TAM has been studied and tested in a huge number of studies and represents the foundation of this user acceptance research. Based on the TAM researches of F. D. Davis, (1989) questions related Perceived usefulness, Perceived ease of use, Behavioural Intention to use and Actual System have been attached to the TAM-SWS questionnaire in chapter 5.2. 5.2 Developing a questionnaire Table 4 shows the developed questionnaire for TAM-SWS. The developed questions can be found on the left side of the table with a literature link on the right. The questions are attached with a 5 item Like scale, (here not visible). Variables / Like Scale (1-5) Scientific Workflow Management System / System Quality R1: User interface customizability and user interaction support WS-VLAM composer provides a user-friendly interface to design, modify, run, rerun, and monitor scientific workflows. WS-VLAM composer allows me to customize the user interface according to different science and engineering disciplines, scientific domains, or to an individual customization demand. WS-VLAM composer helps me to speed up the exploratory process of arriving at a fitting workflow design with appropriate parameter values and input data sets. WS-VLAM composer colours graphics and image, animation and size are appealing. WS-VLAM composer reacts and responds quickly to my entries. Literature Support (Kim, Lee, & Law, 2007) (Lin C., et al., 2009) 47

I can easily obtain necessary information from WS-VLAM composer. R2: Reproducibility support (of scientific workflow results) WS-VLAM composer provides sufficient provenance recovery functions on executed workflows in form of a provenance database. This means I am able to answer the following questions on executed workflows: What workflows or workflow steps were executed to produce this result? Which versions of software s and OSs were used? What parameter values are used? What input data sets had contributed to this result? WS-VLAM composer supports the management of provenance metadata, from collection, representation, storage, querying, to visualization. R3: Heterogeneous and distributed services and software tools integration WS-VLAM composer provides an abstraction of various heterogeneous, distributed services and software tools as workflow tasks. This means I am able to use various services from different sources as ready to use drag and drop workflow task for my workflow e.g. RShell, Bioconductor, Matlab, Java Beanshell, Python. WS-VLAM composer allows me to reuse and manage modules, services and workflows written for WS-VLAM in a flexible and easy manner. R4: Heterogeneous and distributed data product management WS-VLAM composer supports the management of data products, including data product storage, archival, browsing, querying, access, movement, and visualization. The way input data can be managed with WS-VLAM composer fulfils my requirements. The way output data is managed and presented with WS-VLAM composer fulfils my requirements. R5: High-end computing support WS-VLAM separates the science-focused and technologyindependent problem solving environment (PSE) from the underlying computing infrastructure. I am able to focus fully on the scientific matters of my workflow rather than the technical matters. WS-VLAM offers computing features which are outstanding compared to other scientific workflow management systems. R6: Workflow monitoring and failure handling WS-VLAM composer offers the support for status and failure monitoring at different levels and the mechanism for catching, (Lin C., et al., 2009). (Kim, Lee, & Law, 2007) (Lin C., et al., 2009) (Lin C., et al., 2009) (Lin C., et al., 2009) (Lin C., et al., 2009) 48

localizing, and handling failures automatically or with minimal human intervention. WS-VLAM composer s Monitoring console allows me to track the workflow execution process in a flexible and easy manner. R7: Interoperability WS-VLAM composer enables the interoperability between different scientific workflow management systems so that I can take advantage of the software tool libraries and features provided by other scientific workflow management systems. WS-VLAM composer can exchange information easily with other systems and subsystems e.g. Kelper, Taverna, R, Matlab. Scientific Workflow Management System: Information Quality The WSV-LAM composer composition panel offers workflow design related information that satisfies my needs. The language and terminology of WS-VLAM composer menu bar are intuitive and easy to understand. The WS-VLAM composer components palette provides relevant and necessary workflow repository information (i.e. which workflow modules, service and software tools are available?). The WS-VLAM composer property panel provides useful workflow module (item) related information. The WS-VLAM composer monitoring console offers relevant and necessary workflow related information. WS-VLAM composer provides workflow results in a useful format. WS-VLAM composer provides relevant and necessary workflow provenance information. Scientific Workflow Management System / Support Quality The WS-VLAM project offers user support for issues related to WS-VLAM composer. The WS-VLAM manual and documentation allow me to solve issues related to WS-VLAM composer. User training on using WS-VLAM composer has been well established. Scientific Workflow Management System / Social Influence People who influence my behaviour would think that I should use WS-VLAM composer. People who are important to me would think that I should use WS-VLAM composer. People in my work/private community use WS-VLAM. Scientific Workflow Management System / Experience I have experience in using other scientific workflow management systems. (Kim, Lee, & Law, 2007) (Lin C., et al., 2009) (Kim, Lee, & Law, 2007) (Lin C., et al., 2009) (Kim, Lee, & Law, 2007) (Hassairi & Ayed, 2009) (Venkatesh, V. ; Davis, F.D., 2000) 49

I have experience in creating workflow items e.g. atomic task, composite task. I have IT related experience e.g. R, Matlab, Java, Python, C++. I have experience with other information systems. Perceived ease of use Learning to operate WS-VLAM composer is easy for me. (Davis F. D., 1989, p. I find it easy to get WS-VLAM composer to do what I want to do. 326). My interactions with WS-VLAM composer are clear and understandable. I find WS-VLAM composer flexible to interact with. It is easy for me to become skilful at using WS-VLAM composer. I find WS-VLAM composer easy to use. Perceived usefulness Using WS-VLAM composer in my work enables me to accomplish tasks more quickly. (Davis F. D., 1989, p. 326). Using WS-VLAM composer improves my work performance. Using WS-VLAM composer in my work increases my productivity. Using WS-VLAM composer enhances my effectiveness on the work. Using WS-VLAM composer makes it easier to do my work. I find WS-VLAM composer useful in my work. Perceived ease of adoption (Kaasinen, Mattila, It is easy to integrate WS-VLAM composer to my work Lammi, Kivinen, & environment. Vaelkkynen, 2011) WS-VLAM composer is easy to take into use. WS-VLAM composer is easy to setup. Behavioural Intention to use (User Acceptance) (Hassairi & Ayed, 2009) I have a positive opinion about using WS-VLAM composer. I am motivated about using WS-VLAM composer at my work/project. It is my wish to see the full utilization and deployment of the WS-VLAM. Actual System Use / Usage behaviour (self-report) (Davis, F. D., 1993) (Please enter your usage behaviour during your involvement with WS-VLAM/WS-VLAM composer.) Don t use at all. Use less than once each week. Use about once each week. Use several times a week. Use about once each day. Use several times each day. Table 4 Developing a questionnaire for SWS-TAM 50

5.3 Developing Hypothesis Scientific Workflow Management System Quality, perceived ease of use, and perceived usefulness According to (DeLone & McLean, 1992), (Rai, Lang, & Weiker, 2002), as well as (Kim, Lee, & Law, 2007) information quality plays a dominant role in the success of an information system. (Kim, Lee, & Law, 2007), (Igbaria, Guimaraes, & Davis, 1995), (Seddon, 1997) and (Venkatesh, V.; Davis, F.D., 1996) showed that information quality had an effect on perceived ease of use and perceived usefulness. Also, system quality is important in user beliefs (Kim, Lee, & Law, 2007), (Hong, Thong, Wong, & Tam, 2002), (Lederer, Maupin, Senza, & Zhuang, 2000) and (Ruth, 2000). (Ahn, Ryu, & Han, 2004) and (Kim, Lee, & Law, 2007) classified the quality of an Information system into system quality, information, system, and support quality. The research was found that quality affects perceived ease of use and perceived usefulness. Thus, the following hypotheses are proposed: Hypothesis 1a: System quality positively affects perceived ease of use. Hypothesis 1b: Information quality positively affects perceived ease of use. Hypothesis 1c: Support quality positively affects perceived ease of use. Hypothesis 2a: Information quality positively affects perceived usefulness. Hypothesis 2b: System quality positively affects perceived usefulness. Hypothesis 2c: Support quality positively affects perceived usefulness. Experience and perceived usefulness The influence of experience on perceived usefulness has been studied by (Venkatesh, V. ; Davis, F.D., 2000). The studies showed a high correlation between Experience and perceived usefulness. Thus, the following hypothesis is proposed: Hypothesis 3: Experience positively affects perceived usefulness. Social Influence and perceived ease of use, and perceived usefulness In their research Hassairi & Ayed, (2009) introduced the variable social influence. The research found empirical evidences that indicate that the significance of the variables on perceived ease of use and perceived usefulness. Thus, the following hypotheses are proposed: Hypothesis 4a: Social Influence positively affects perceived ease of use. Hypothesis 4b: Social Influence positively affects perceived usefulness. Perceived ease of use, perceived usefulness, and Intentional behaviour to use Most studies on technology acceptance showed that perceived ease of use directly influenced perceived usefulness and Intentional behaviour to use e.g. (Davis F. D., 1989) (Davis, Bagozzi, & Warshaw, 1989). In particular, (Davis, Bagozzi, & Warshaw, 1989) stated that through perceived usefulness and perceived ease of use Intentional behaviour to use is directly influences, which in turn clearly shows that perceived ease of use is the antecedent of perceived usefulness. Thus, the following hypotheses are proposed: Hypothesis 4: Perceived ease of use positively affects perceived usefulness. 51

Hypothesis 5: Perceived usefulness positively affects Intentional behaviour to use. Hypothesis 6: Perceived ease of use positively affects Intentional behaviour to use. Intentional behaviour to use and actual use Davis, Bagozzi, & Warshaw, (1989) showed in their research that Intentional behaviour to use had a direct effect on actual use. Thus, the following hypothesis is proposed: Hypothesis 7: Intentional behaviour to use positively affects actual use. Perceived ease of adoption and actual use Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, (2011) introduced perceived ease of adoption, which is related to taking a services into use. This variable is high relevant for open source service based information systems. Thus, the following hypothesis is proposed: Hypothesis 8: Perceived ease of adoption positively affects actual use. 5.4 The Workflow System Technology Acceptance Model survey This chapter describes the evaluation of the Workflow System Technology acceptance model survey. 5.4.1 Survey questionnaire and measurements Data to test the research hypothesis were collected via an online questionnaire developed for this study. The online questionnaire was implemented based on the questions presented in Table 4 using the website thesistools.com 11. The evaluation was conducted with Microsoft Excel. The online questionnaire was built to capture the model dimensions outlined in chapter 5.1. The model dimensions are scientific information system quality dimensions (system-, information- and service quality), perceived value, perceived ease of use, perceived usefulness, behaviour intention to use, and actual use. Most of the theoretical constructs were operationalized using validated items from prior research. As shown in Table 4, the system quality construct was measured by 20 items split into seven requirement categories (Kim, Lee, & Law, 2007) (Lin C., et al., 2009); R1: User interface customizability and user interaction support with 6 items, R2: Reproducibility support with 2 items, R3: Heterogeneous and distributed services and software tools integration with two items, R4: Heterogeneous and distributed data product management with 3 items, R5: High-end computing support 3 items, R6: Workflow monitoring and failure handling 2 items, R7: Interoperability with 2 times. The information quality construct consists of seven items (Kim, Lee, & Law, 2007) (Lin C. 11 www.thesistools.com 52

, et al., 2009). The support quality was composed into three items (Kim, Lee, & Law, 2007) (Lin C., et al., 2009). Social influence consists of three items (Hassairi & Ayed, 2009). Experience consists of four items (Venkatesh, V. ; Davis, F.D., 2000). Perceived ease of use and perceived usefulness, both consisting of six original items (Davis F. D., 1989, p. 326). Perceived ease of adoption consisting of 3 items (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011). Behavioural Intention to use, consisting of three items (Hassairi & Ayed, 2009). Finally the actual system use was measured with a seven six item like scale system (Davis, F. D., 1993). The participant could choose from the following items: Don t use at all, Use less than once each week, Use about once each week, Use several times a week, Use about once each day, Use several times each day. The survey was conducted in two stages: a pre-test run with the developers and the full study with experienced users of WS-VLAM. The questionnaire was pretested with a WS-VLAM developer to ensure the content validity. The results of pre-testing were: Reduction of questionnaire length to reduce the time needed to complete it to around 15 minutes; this was accomplished by removing less important / correlated questions, and reformatting the rating scales. Deleting items that do not appear to adequately measure the variable being analysed. Modifications in item wording The online questionnaire contains three sections: (1.) Introduction and instruction, (2.) Main questionnaire, (3.) Personal comments and feedback (optional). The respondents were asked to indicate agreement with each statement using a five-point Like-type scale (1, disagree; 2 Somewhat disagree: 3 Neither agree or disagree: 4 Somewhat agree; 5 Agree ). 5.4.2 Descriptive characteristics of the respondents Descriptive characteristics of the respondents are summarised in Figure 21. The research sample consists of WS-VLAM users mainly involved in research projects at the University of Amsterdam. The participants were chosen based on the experience with WS-VLAM. The minimum requirement for participating in the study was at least 6 month experience with WS-VLAM. The participants were contacted via e-mail and provided an online web-link to the questionnaire. The participants come from different research areas, e.g. computer science, biology, medicine, chemistry. 53

Variable Value Contacted participants 15 Received complete answers 9 Response rate 60% Gender Male 56% Female 11% Anonymous 33% Age Mean 42 Range 39-45 Nationality Dutch 11% Russian 11% Anonymous 78% Science field Bioinformatics 11% Computer Science 11% Anonymous 78% Experience with WS VLAM Less than 6 months 0% Less than 1 year 11% More than 1 year 44% Anonymous 44% Figure 21 Descriptive sample analysis A total of 15 questionnaires were distributed, and 9 questionnaires were successfully completed and returned, indicating a response rate of lower than expected, 60%. The respondents were 56% male, 11% female and 33% anonymous. The mean age was 42 while the range was between 39 and 45. The age mean does not include people who stayed anonymous. 11% of the participants are Dutch, another 11% of the participants were Russian while 78% are anonymous. 11% of the participants used WS-VLAM in a bioinformatics context, 11% in a computer science context, while 78% stayed anonymous. 44% of the participants have more than 1 year experience with WS-VLAM, 11% less the one year and 44% stayed anonymous. 5.4.3 Results and analysis The analysis of the results is divided into four main steps: 1. Calculation of the correlation of the variables of the presented hypothesis of chapter 5.3 2. Testing of the significance of these correlations to determine whether the hypothesis presented in chapter 5.3 are supported or not (accepted / rejected). 3. Interpretation of the statistical analysis. 4. Interpretation and analysis of the variables. A similar approach has been used in the papers written by (Kim, Lee, & Law, 2007) and (Chuttur, 2009). 5.4.3.1 Calculation of the correlation coefficient The correlation is one of the most common statistic measurements (Kim, Lee, & Law, 2007). A correlation is a single number that describes the degree of relationship between two variables. The Pearson correlation coefficient measures the linear association between two metric variables. It ranges from -1.00 to + 1.00, with zero representing absolutely no association. A larger coefficient means a stronger linkage, while a smaller coefficient means a weaker linkage. The correlations among the variables were calculated using composite scores similar to the work of Kim, Lee, & Law, 54

(2007). Specifically, composite scores for each variable were computed by averaging scores across items representing that variable. (E.g. The information quality variable consists of seven items. To calculate the correlation between Information quality and other variables this seven items are grouped in a composite average score per participant). A detailed overview of the grouping and the composite scores can be found in the chapter Interpretation and analysis of the variables5.4.6. 5.4.3.2 Testing the Significance of a Correlation Once the correlation has been computed, it becomes necessary to determine the probability that the observed correlation occurred by chance (Kim, Lee, & Law, 2007). This is done by a significance test. In this research, the mutually exclusive hypothesis is tested (Null Hypothesis: r = 0, Alternative Hypothesis: r <> 0). The goal is to determine the probability that the correlation is a real one and not a chance occurrence. In hypotheses testing, it is necessary to determine the significance level. In this research a significance level of alpha =.10 is used. This means that when conducting a test, the probabilities that the correlation is a chance occurrence is no more than 10 out of 100. To test a hypothesis, it is necessary to define the critical value of r. In this research the table of critical values for Pearson s r 12 has been used to determine the critical value for r. Before it is possible to calculate or look up the critical value for r, it is necessary to also compute the degrees of freedom (df). The df is equal to N-2 or, in this research, 9-2 = 7 (9 participants). Additionally, it is necessary to decide whether a one-tailed or two-tailed test is required. In this research, since there is no strong prior theory to suggest whether the relationship between variables in question would be positive or negative, this research opt for the two-tailed test. With these information: the significance level (alpha =.10)), degrees of freedom (df = 7), and type of test (two-tailed), it is now possible to test the significance of the correlation found. According to the table of critical values for Pearson s r a critical value of 0.58 has been identified for this research. This means that if the correlation is greater than.58 or less than -.58 it can be concluded that the result occurs by chance is less than 10 out of 100. In other words it can be concluded that the correlation is "statistically significant, given the parameters of the test. Therefore, the null hypothesis is rejected, and the alternative is accepted it. R-Squared is a statistical term explaining how good one variable is at predicting another (Kim, Lee, & Law, 2007). If R-Squared is 1.0, then given the value of one variable, it is possible to perfectly predict the value of another variable. When R-Squared is 0.0, one variable does not help to predict another variable. The R-Square values of the variables in question are shown in Table 5. The values support the significant test. All supported hypothesis show a high R-squared value, which means the variables are good in predicting another variable. In the next part of the analysis the focus lies on the different external variables which explain the user acceptance process. 12 http://www.radford.edu/~jaspelme/statsbook/chapter%20files/table_of_critical_values_for_r.pdf 55

5.4.4 Interpretation of the statistical analysis Table 5 indicates the correlations among the composite scores representing the hypothesis variables. As shown in Table 5, hypothesises related to the original TAM variables are supported while some hypothesises related to newly added external variables are not supported. The following section describes this observation in more details. Evaluation Hypothesis Independent variable Dependent variable Hypothesis Correlation Critical value of r alpha = 0.10 Hypothesis support R2 Perceived ease of use H1a 0.22 0.58 no 0.05 System quality Perceived usefulness H2a 0.58 0.58 yes 0.34 Perceived ease of use H1b 0.44 0.58 no 0.19 Information quality Perceived usefulness H2b 0.60 0.58 yes 0.36 Perceived ease of use H1c 0.05 0.58 no 0.00 Support Quality Perceived usefulness H2c 0.61 0.58 yes 0.37 Experience Perceived usefulness H3 0.40 0.58 no 0.16 Perceived ease of use H4a 0.19 0.58 no 0.04 Social Influence Perceived usefulness H4b 0.29 0.58 no 0.08 Perceived ease of use Perceived usefulness H5 0.66 0.58 yes 0.43 Perceived usefulness Intentional behaviour to use H6 0.64 0.58 yes 0.40 Perceived ease of use Intentional behaviour to use H7 0.70 0.58 yes 0.49 Intentional behaviour Actual use H8 0.77 0.58 yes 0.59 Perceived ease of adoption Actual use H9 0.17 0.58 no 0.03 Table 5 Descriptive statistics, and correlation of composite scores of constructs and significance of correlation The correlation between SWfMS/System quality and Perceived Ease of Use is small positive correlated. This means an increase in system quality causes increase in perceived ease of use by 22%. However the significance is below the critical value of r, thus H1a is not supported. This is also true for the relationships SWfMS Information quality to perceived ease of use with 44% and SWfMS Support quality to perceived ease of use with 5%. Both relationships are below the critical value of r, thus H1b and H1c are also not supported. Perceived ease of use means that people, in this case the participants of this survey, believe that using WS-VLAM would be free from effort. The hypothesis are not supported which leads to the assumption that the variables are not applicable to explain the perceived ease of use at WS-VLAM. This is an unexpected finding considering prior research by (Kim, Lee, & Law, 2007). In the research by Kim, Lee, & Law, (2007) the relationships between System quality, Information quality and Support quality was mainly highly correlated and significant, except the relationship Information quality and Perceived Ease of Use. The correlation of SWfMS/System quality, SWfMS/Information quality and SWfMS/Support quality to Perceived usefulness is higher, 58%, 60% and 61% and significant because those values are above the critical value of r. Thus H2a, H2b and H2c are supported. This leads to the assumption, that the described three quality variables are closely correlated to the Perceived usefulness of WS-VLAM. Perceived usefulness means that people, in this case the participants of this survey, would use WS-VLAM to enhance his/her job performance. This finding fits the expectation considering prior research by (Kim, Lee, & Law, 2007). The correlation between the external variable 56

Experience and Perceived usefulness is small with 40% and not significant. Thus H3 is not supported. The external variable Social influence and Perceived ease of use as well as perceived usefulness are small positively correlated with 19% and 29% and not significant. Thus H4a and H4b are also not supported. This leads to the assumption that the variables Experience and Social influence are not applicable to explain the perceived ease of use and Perceived usefulness of WS-VLAM. This is an unexpected finding, since it was expected by this study that the WS-VLAM composer requires some IT experience to be used and that this IT Experience would lead to a higher perceived usefulness. Furthermore, the external variable Experience has been successfully tested, and found to be highly relevant in other studies (Venkatesh, V. ; Davis, F.D., 2000). The external variable social influence has been also studied in a research focusing on ERP systems, which showed a high correlation between social influence and perceived ease of use and perceived usefulness of ERP systems (Hassairi & Ayed, 2009). The original TAM variables show a high correlation and support the TAM introduced by (Davis F. D., 1989). Perceived ease of use is highly positively correlated to perceived usefulness by 66% and significant, Perceived usefulness is highly positively correlated to Intentional behaviour to use by 64% and significant, Perceived ease of use is highly correlated to Intentional behaviour to use by 70% and significant (see Figure 22, example of high correlation), Intentional behaviour to use is positively and highly correlated to affects actual use by 77% and significant, thus H5, H6, H7 and H8 are supported. Independent variable Dependent variable Perceived ease of use Intentional behaviour to use 2,33 3,33 4,17 4,67 5,00 5,00 3,17 4,33 3,00 4,00 3,67 4,00 3,00 3,00 3,00 4,00 2,50 4,33 Correlation coefficient 0,70 Rsquare 0,49 Figure 22 High Correlation coefficient: H7 Perceived ease of use and Intentional behaviour to use The external variable Perceived Ease of Adoption is slight positively correlated to actual use with 17% and not significant, thus H9 is supported (see Figure 23, example small correlation). 57

Independent variable Dependent variable Perceived ease of adoption Actual use 1,33 1,00 5,00 4,00 4,33 4,00 1,33 4,00 4,00 4,00 4,00 2,00 3,00 2,00 4,33 2,00 1,67 4,00 Correlation coefficient 0,17 Rsquare 0,03 Figure 23 Small Correlation coefficient: H9 Perceived ease of adoption and Actual use Perceived ease of adoption describes the perceived ease of how to take WS-VLAM into use, to set it up and to integrate it into a job. Because the hypothesis is not supported it can be assumed to the variable perceived ease of adoption does not explain actual use of WS-VLAM. This is an unexpected finding, since the variable has been successfully applied and was found significant to mobile services in a research by Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, (2011). 5.4.5 Limitations of the statistical analysis The small sample size leads to limitations in the statistical evaluation of this survey. The chosen sample group for this survey are experienced users of WS-VLAM who have at least 6 month experience with the system. Doing the survey with experienced users was found essential during the study preparation simply because the opinion of an experienced user is more trustworthy than the opinion of inexperienced new users. The decision to focus on experienced users limits the amount of possible participants to 15 while 9 responded (response rate 60%). Hackshaw, (2008) published a paper on the strengths and limitations of small studies. According to that study there is nothing wrong about conducting a well-designed small study, however the sample size reached in this survey is extremely small. Small studies can provide results quickly however they do not normally yield reliable or precise estimates (Hackshaw, 2008). One of the main disadvantages of small studies is related to the variability. The variability is determined by the standard deviation. The standard deviation obtained by sampling a distribution is itself not absolutely accurate. This is particularly true if the sampler is small. This effect is described by the confidence interval (CI) (Hackshaw, 2008). Figure 24 illustrates how the size of the sample influences the conclusion. Figure 24 Schematic diagram showing how study size can influence conclusions. CI: confidence interval (Hackshaw, 2008) 58

In this WS-VLAM study a confidence interval of 90% has been used. According to Hackshaw, (2008), it is important to not make strong conclusions about the risk factors or trial intervention and whether the results are positive or not. Instead, the data from such studies should be used to design larger confirming studies. If the aim is to provide reliable evidence on a risk factor or new intervention, the study should be large enough to do that (Hackshaw, 2008). For reasons described above the statistical analysis of this survey is kept to a minimum. This survey study should be understood as a foundation for future research on WS- VLAM and other scientific workflow management systems. The following chapter analyses the different variables and focuses on the answers of the participants. This way the survey analysis uses a qualitative research approach. A similar approach has been taken in the TAM research on mobile service by (Kaasinen, Mattila, Lammi, Kivinen, & Vaelkkynen, 2011). 5.4.6 Interpretation and analysis of the variables The statistical analysis of the questionnaire provides evidence for reliability of the original TAM constructs (Perceived ease of use, perceived usefulness, Behavioural Intention to use and Actual system use). Even the sample size was small the correlation between the original Tam constructs was high and significant. The chosen external variables are positively correlated however partly not significant, possible reasons for this are outlined in the previous chapter. Figure 25 illustrates the developed SWS-TAM model presented in chapter 5. The lines indicate the supported (green) and not supported (red) hypothesis as also described in the previous chapter. To explain and understand the user acceptance of WS-VLAM composer it is useful to have a closer look at the variables. The following section analyses the different variables and highlights the findings. Figure 25 Overview Supported hypothesis /Overview User Acceptance of WS-VLAM composer Figure 25 (right side) shows the overview of the user acceptance of WS-VLAM composer. The figure shows the total average scores of the variables. The average scores are based on the five-point Like-type scale (1, disagree; 2 Somewhat disagree: 3 Neither agree or disagree: 4 Somewhat agree; 5 Agree ). Variables with weaker average scores may indicate user acceptance issues of WS-VLAM/WS-VLAM composer. 59

5.4.6.1 System quality As described in chapter 5.1.1 the system quality variable consists of essential requirements for a scientific workflow management system introduced in the scientific workflow management reference architecture. Figure 26 illustrates an overview of the system quality variables average values for R1- R7. The figure gives an overview of the strengths and the weakness of WS-VLAM system. The lowest scores are reached by R2: Reproducibility support and R7: Interoperability. The highest scores are reached by: R5 High-end computing support, R6 Workflow monitoring and failure handling. The following sections describe the system quality requirements R1-R7. Figure 26 Results System Quality: Overview Figure 27 (left) illustrates the system quality requirement one (R1): User interface customizability support and user interaction support. The overall interface is rated moderate user friendly. However the customizability options of WS-VLAM composer are rated rather low. WS-VLAM composer does not support the adaption and customization to specific scientific domains. Customization options for specific scientific domains could be a useful feature for WS-VLAM users and might lead to a higher user acceptance. Another aspect of improving the user interface and customizability could be the use of portal solutions. This means that the scientist is able to manage his workflows through a customizable portal. An example for such portal solution has been introduced by Taverna project; Enactment of Taverna Workflows via a Portal 13. Taverna project uses the REST or SOAP interface of the Taverna Engine to provide basic functions to a portal using portlets. The portal does not offer the same range of functions as the Taverna Editor, for example it does not provide design tools for the creation of workflows. However, such a portal solution could increase the user acceptance of WS-VLAM and could be a feature for future development. 13 http://dev.mygrid.org.uk/wiki/display/portals/deliverable+2.1.1+- +Enactment+of+Taverna+Workflows+via+a+Portal 60

Figure 27 Results System Quality: R1 User interface customizability and user interaction/ R2 Reproducibility support Figure 27 (right) illustrates the system quality requirement two (R2) Reproducibility support of WS-VLAM composer which is rated moderate low. Reproducibility support or provenance management is a feature which is currently not supported by the WS-VLAM composer. However WS-VLAM project is investing methods to implement such features to WS-VLAM (Gerhards, Skorupa, Sander, Belloum, Vasunin, & Benabdelkader, 2011) (Gerhards, Michael; Sander, Volker; Matzerath, Torsten; Belloum, Adam; Vasunin, Dmitry; Benabdelkader, Ammar, 2011). Integrating a provenance management feature into WS-VLAM composer is essential according to the scientific workflow management reference model (Lin C., et al., 2009). Figure 28 (left) illustrates the system quality variable requirement three (R3) Heterogeneous and distributed services and software tools. The overall rating is moderate positive. WS-VLAM supports a number of disputed services and software tools such as R, java and python; however the scientist is required to do low level programming or is required to use a wrapper to create workflow modules based on this services and software tools. To allow the scientist to fully focus on the scientific aspects of the experiment, it could be helpful to make the workflow modules creation easier. This could be achieved by offering workflow module service templates. Such features are available in the scientific workflow management system Taverna. Often required services are integrated into Taverna and allow the direct configuration of a workflow module within the GUI of Taverna. Examples for such service are the Beanshell 14, Rshell 15 RESTshell 16 in Taveran. The scientist is able to create a Java or R or REST based workflow task within the GUI without doing low level programming or wrapping. The Beanshell and Rshell as well as the RESTshell are completely integrated into the GUI of Taverna. Integrating such service templates could be a feature which could bring additional value and user acceptance to WS-VLAM/WS-VLAM composer. 14 http://dev.mygrid.org.uk/wiki/display/taverna/beanshell 15 http://dev.mygrid.org.uk/wiki/display/taverna/rshell 16 http://dev.mygrid.org.uk/wiki/display/taverna/rest 61

Figure 28 Results System Quality: R3: Heterogeneous and distributed service and software tools/ R4: Heterogeneous and distributed data product management Figure 28 (right) also illustrates the system quality variable requirement four (R4): Heterogeneous and distributed data product management. The management of data products and the output management are relatively low rated. Finding ways to improve the data management could improve the user acceptance of WS-VLAM. The reference architecture for SWfMSs described in chapter 4.1.1 addresses this topic with an approach called data product management. The SWfMS should offer one data product format which allow users to export the workflow results into other a range of common formats. By providing one data product format users do not need to think about what type of data format they use during the experiments. Figure 29 presents the ratings for the system quality variable requirement five (R5) Highend computing support (left) and the system quality variable requirement six (R6) Workflow monitoring and failure handling (right). Both requirements are positively rated and seem to be strong features of WS-VLAM/WS-VLAM composer. WS-VLAM is one of the first GRID based Workflow Management Systems which makes it interesting for scientific experiments which require high scaling and computing features. Furthermore it is possible to detach/reattach the WS-VLAM composer from the WS- VLAM Engine which also supports long running experiments. Figure 29 Results System Quality R5: High-end computing support/ R6: Workflow monitoring and failure handling Figure 30 illustrates the system quality variable requirement seven (R7) Interoperability. Interoperability with other workflow management systems is rate rather low. 62

Figure 30 Results System Quality: R7: Interoperability The weak interoperability seems to be one of the weaknesses of WS-VLAM. The interoperability to other workflow management systems is essential according to the scientific workflow management reference model (Lin C., et al., 2009). Currently WS- VLAM is supporting a limited export function to other Workflow Management System (Vasyunin, et al., 2007). More integration features to existing established scientific workflow management systems could increase the user acceptance of WS-VLAM. 5.4.6.2 Information Quality and Support Quality Figure 31 illustrates the Information Quality (left) and Support Quality (right) of WS- VLAM\WS-VLAM composer. Both variables are rated positively. The information quality of the provenance management is rated low, which supports the low rated system quality variable: reproducibility support and the fact that WS-VLAM composer does offer a provenance feature yet. WS-VLAM provides provenance features which are not yet accessible with the WS-VLAM composer. Figure 31 Results: Information Quality/ Support Quality The support from the WS-VLAM project is rated positively while the documentation is moderate positively rated. An improvement of the WS-VLAM documentation could lead to a higher user acceptance. The project Taverna offers a very useful Wiki documentation. A Wiki could allow the WS-VLAM project to improve the current documentation with the help of a community. 63

5.4.6.3 Social Influence and Experience Figure 32 illustrates the WS-VLAM composer variables social influence (left) and experience (right). The statistical analysis of these variables has shown a rather weak correlation to Perceived Ease of Use and perceived usefulness however these variables provide some interesting information. Figure 32 (right) shows that WS-VLAM users who have participated in the questionnaire have good IT experience. All of them have experience with workflow management systems. Figure 32 Results: Social Influence and Experience The social influence to use WS-VLAM is rated mixed. Building up a community around WS-VLAM and advertise for it could improve the user acceptance and the actual use of WS-VLAM. 5.4.6.4 Perceived of adoption Figure 33 illustrates the perceived ease of adoption of WS-VLAM composer. There is a difference in using a ready to use installed WS-VLAM and setting up the system from the scratch. In the case of the University of Amsterdam, most of the participants did use an installed ready to use WS-VLAM. This means the participants main adoption challenge was to start the web service based WS-VLAM composer which can be started from the WS-VLAM project page. Figure 33 Results: Perceived ease of adoption Barriers in the adoption process of service oriented software are often related to technical requirements as well as knowledge of the user and integration issues related to the IT and working environment of the user. The perceived ease of adoption is rated 64

rather mixed. A number of people seem to find the current web application difficult to adopt. 5.4.6.5 Perceived Usefulness and Perceived ease of use Figure 34 illustrates the perceived usefulness (left) and the perceived ease of use (right) of WS-VLAM composer. Figure 34 Results: Perceived Usefulness and Perceived ease of use The figures show that perceived usefulness is rated higher than perceived ease of use. By improving the Perceived Ease of Use the overall user acceptance of WS-VLAM composer could be improved. However none of the tested variables is strongly correlated to perceived ease of use. Finding variables which are related to the Perceived Ease of Use could be subject of future research. 5.4.6.6 Behavioural Intention to use and actual use Figure 35 illustrates the Behavioural intention to use (left) and the actual use (right) of WS-VLAM composer. The behavioural intention to use is rated positively. The majority of the participants are motivated and wish to use WS-VLAM composer. Figure 35 Results: Behavioural Intention to use and Actual use The actual use variable gives some insights on how often WS-VLAM composer is used when the participant is involved in a research project which utilises WS-VLAM. Most of the participants use WS-VLAM composer several times a week. These numbers seem rather low compared to other information systems e.g. hotel information system (Kim, 65

Lee, & Law, 2007). However the usage behaviour/pattern of a scientific workflow management system might be different to the usage behaviour of for example a hotel front ends information systems. This topic might be interesting for future research in this area. 5.4.7 Discussion, conclusions and limitations The analysis of the SWS-TAM variables has identified strength and weakness of WS- VLAM/WS-VLAM composer. This allows addressing one of the research questions raised chapter 3, which is: Does the Technology Acceptance Model explain the user acceptance of scientific workflow management systems, in particular of WS-VLAM/WS-VLAM composer? The analysis provides a range of insights on the user acceptance of WS- VLAM. In this perspective the question can be positively answered. The following list summarizes the findings related to the weaknesses of WS-VLAM. The following table lists the issues, a description and a possible solution to the problem. User acceptances issues R1: User interface customizability and user interaction support - R1-Q2 customizability R2: Reproducibility support/ Information Quality: Provenance information R3: Heterogeneous and distributed services and software tools ID Description Possible solution uai-01- userinterface uai-02- provenan ce uai-03- distribut edservices The SWS-TAM analysis indicates a low support of customizability options of the user interface to scientific domains. The SWS-TAM analysis indicates a low support of reproducibility/ provenance management features of WS- VLAM composer. The SWS-TAM analysis indicates a low support of distributed services and software tools. The scientist is required to do low level programming or is required 66 -Modify WS-VLAM composer and implement customizability features for specific scientific domains -Implement a portal based solution for WS-VLAM, offer a range of portlets -Provide provenance management features and integrate them to WS-VLAM composer. The issue has been addressed by WS-VLAM composer (Gerhards, Skorupa, Sander, Belloum, Vasunin, & Benabdelkader, 2011) (Gerhards, Michael; Sander, Volker; Matzerath, Torsten; Belloum, Adam; Vasunin, Dmitry; Benabdelkader, Ammar, 2011).: -Provide service template features for WS-VLAM composer. (A concrete solution needs to be provided by future research on this topic)

R4: Heterogeneous and distributed data product management/ Information Quality: Workflow results R7: Interoperability uai-04- datamanage ment uai-05- interoper ability to use a wrapper to create workflow modules in WS- VLAM composer. To allow the scientist to fully focus on the scientific aspects of the experiment it could be helpful to make it easier to create the workflow modules using distributed services and software tools. The SWS-TAM analysis indicates a low support for distributed data product management of WS-VLAM composer. The SWS-TAM analysis indicates a low support of the interoperability of WS-VLAM to other scientific workflow management systems Table 6 List of identified user acceptance issues based on SWS-TAM survey -Improve data management of WS-VLAM by introducing a data product management. (A concrete solution needs to be provided by future research on this topic) -Improve interoperability features of WS-VLAM. (A concrete solution needs to be provided by future research on this topic) A limitation of the TAM is that the identified issues are left with no method to address them. This thesis claims that there is a need for a method which allows addressing these issues in the design of a software or service. The following chapter presents a possible solution for this issue by integrating the TAM survey results into the SOADM. A complete exemplified application of SOADM to WS-VLAM and the exemplified integration of the TAM survey research results can be found in the chapter 9.1 of the appendices. 6 Integrating Technology Acceptance Model into the Service Oriented Analysis and Design Methodology 6.1 Introduction The previous chapters 4.3 and 4.4 introduced the concepts; SOADM (Lago & Razavian, 2012) and the TAM (Davis F. D., 1989). The SOADM by (Lago & Razavian, 2012) is a methodology to design SOA based software solutions. SOA is a paradigm for effectively delivering software services in a dynamic 67

environment. Nowadays SOA is an important and increasingly used paradigm in software engineering (Lago & Razavian, 2012). Many service oriented approaches for design and development of services have been proposed. Some of these approaches support the entire service engineering process (e.g. (Amoako-Gayampah & Salam, 2003), (Papazoglou, 2006)), while some others cover only a few phases such as service analysis and design (e.g. (Zimmermann, 2004), (Allen, 2007)). The methodology presented by Lago & Razavian (2012) falls under the second category by specifically covering service analysis and design. The TAM (Davis F. D., 1989) is a widely used information systems theory that studies how users come to accept and use a technology. Applying TAM to an information system provides the developers with information on how to improve user acceptance of the specific information system. This study claims that it is useful to develop a method to implement the findings of the TAM research to the design of software. Most of the studies which applied TAM to a specific system (see, chapter 4.4.3) identify user acceptance issues; however they do not provide a method to implement them into the design of the system in question. For these reasons this chapter describes a method to integrate TAM into the Service oriented design methodology. 6.2 Developing an integration model Figure 36, illustrates the combination of the TAM (Davis F. D., 1989) with the SOADM (Lago & Razavian, 2012). The SOADM consists of two main steps, illustrated in two boxes: the service oriented analysis (bottom left) and the service oriented design (bottom right). The TAM is illustrated with one box (centre top). All three boxes are interdependent and influence each other. In the centre of this interdependency is Design space. The Design space describes design issues that must be addressed to develop the design solution of a software service. The Design space, the introduction of a user acceptance strategy and the refinement of the design space with the strategy are highly relevant for this thesis because these steps provide an interface to integrate user acceptance issues to the design of a software service. The following section describes several important interdependencies between the different steps. 68

Figure 36 Integrating the Technology acceptance model into a Service oriented analysis and design methodology This research discovered that the Service oriented analysis can be used to design and apply the TAM to a specific technology (see chapter 5.1). To be able to apply the TAM to a technology or a system, the technology, the system and business domain needs to be analysed and studied. This step can be partly provided by the SO Analysis, Figure 36 (bottom left). The integration step can be summarized as follows: The SO Analysis helps to define the domain and the variables for the TAM. The SO Analysis provides the domain description, the business service identification, the list of quality and functional requirements, the context and the data model. All these steps provide a foundation to design the TAM to a specific Technology. (This step has been applied in chapter 5.1). After applying the TAM, the results of the survey research are integrated into the SO Analysis and the SO design of the software service. The relationships between the steps are interdependent. This means that the results of the TAM research have influence on the SO Analysis and the SO Design. The following two steps have been identified to integrate the TAM survey research results into the SOADM: Implementing a User Acceptance Strategy for the Service Oriented Analysis and Design Methodology. The SOADM by (Lago & Razavian, 2012) provides a step to integrate a strategy into the design of a software service (see, Figure 36 (centre)). In previous studies this step has been used to various strategies, for example to integrate a green strategy to a software service (Lago, Patricia, 2012), with the aim to implement an environmentally friendly software service. In this study, the focus lies on introducing a User Acceptance Strategy. The strategy needs to be described in detail in this step. (This step has been applied in chapter 9.1.3.1 of the appendix). 69

Refinement of Design space using Architectural Knowledge design Space Modelling template table (AK-SPAM) and the Question-Option-Criteria (QOC) notation. The SOADM by (Lago & Razavian, 2012) provides a step to refine the Design space based on a strategy (see, Figure 36 (centre)). In this study, the Design space is refined based on User Acceptance Strategy. (This step has been applied in chapter 9.1.4 of the appendix). The steps summarized above addressed one of the research questions raised in chapter 3, which is: How can the results of a Technology Acceptance Model research be integrated into the SOADM by (Lago & Razavian, 2012)? The presented steps allow an integration of the survey research results into the SOADM by (Lago & Razavian, 2012); hence the research question can be answered positively. The following chapter describes the application process for the developed integration model in more detail. 6.3 Application to the case of WS-VLAM This chapter describes and documents the application process of SOADM to the case of WS-VLAM and the integration of the TAM survey results into the SOADM as illustrated in Figure 36. This chapter should be understood as evaluation of the application process. The exemplified application of SOADM to WS-VLAM and the exemplified integration of the TAM survey research results can be found in the chapter 9.1 of the appendices. The application of SOADM to WS-VLAM is a special case, because WS-VLAM is a fully implemented SWfMS with an existing design documentation. However, the existing WS- VLAM design documentation does not follow a design methodology and can be described as ad-hoc design documentation. A goal of this project is to supply WS-VLAM with a structured design documentation and to present improvement ideas based on the TAM survey. To create the UML and SOAML diagrams for the SOADM the software MagicDraw 17 has been used. The major guideline for applying the SOADM to WS-VLAM was the existing documentation summarized and described in chapter 4.2. 6.3.1 Service oriented Analysis and Design The SOADM consist of two core steps as illustrated in Figure 36, the SO Analysis and the SO Design. The SO Analysis consists of three sub-steps: Business service identification, context identification and business service decomposition. To execute these steps the extensive literature review described in chapter 4 was very useful. A good orientation for developing these steps was the paper: Collaborative e-science - Experiments and Scientific Workflows (Belloum, et al., 2011). The paper is co-authored by one of the developers of WS-VLAM and presents among other things the scientific experiment s life cycle which was used to devise and develop the business services related to scientific experiments and WS-VLAM in this project. The overall process of applying the sub-steps: 17 http://www.nomagic.com/ 70

Business service identification, context identification and business service decomposition can be described as structured and successful in this project. However, there were some issues regarding the definition of the participants involved in the business services. During the application of the first sub-steps, in particular the business service identification, it is necessary to define the participants involved in the business services and the context of the business services. The paper on the SOADM (Lago & Razavian, 2012) does not provide a definition for the term participant which leaves room for interpretation, as experienced in this case study. In a first application of the case study, some of the participants had similar names as the software service candidates (e.g. the participant Delegation service had the same name as the software service candidate Delegation service, a better description of for the participant would be Security provider. The Security provider provides the delegation service). This issue lead to problems over the entire case study. Defining the right participants at the beginning is key, because the participants are influencing almost every other step of the methodology. This issue illustrates the interdependency of the SO Analysis and the SO Design negatively. The correction of such a mistake requires a manual correction in all previous generated diagrams. The wrong definition of the participants might have been caused by the existing documentation of WS-VLAM (compare, Figure 5 and Figure 54). As described before a major guideline for applying the SOADM to WS-VLAM is the existing documentation of WS-VLAM. Figure 5 illustrates a sequence diagram which uses the service names as participants. Figure 54 illustrates a similar sequence diagram assembled according to the participant definition of the SOADM. The issues relate to the participant s definition, provide evidence that in the case of reengineering or revisiting existing implementations additional attention needs to be paid to match the existing documentation and SOADM. This leads to one of the major challenges for the particular case study on WS-VLAM, which was to review the existing design documentation and the existing architecture of WS-VLAM. To achieve an understanding of the WS-VLAM architecture the following steps were completed; interviewing the developers, studying published papers on WS- VLAM and studying the WS-VLAM design documentation (WS-VLAM wish list 18 ). One of the most useful papers for this matter is: WS-VLAM: A GT4 Based Workflow Management System by (Vasyunin, et al., 2007) which allows the reader to get a comprehensive overview of the existing WS-VLAM architecture. The summary of the paper review in chapter 4.2 is the bases for several steps of the SO Analysis and the SO Design. Some of the existing documentation was directly integrated into the SOADM. The WS-VLAM wish-list for example is integrated into the SO Analysis by mapping the wish-list items to functional requirements (see chapter 9.1.1.2.1). The existing architecture documentation was mapped to the SO design; the steps Service candidate definition, Service inventory identification (Service identification for WS-VLAM client), Service contract definition, Service network modelling, and Service choreography modelling were developed based on the literature review of the existing architecture and by interview with the developers. The main scope of this study is the service based 18 http://staff.science.uva.nl/~gvlam/wsvlam/presentations/ws-vlam-wishlist.ppt 71

application WS-VLAM client. In their paper Lago & Razavian, (2012) clearly distinguish between service base application and service inventories. This is the reason why the Service inventory identification has been renamed to Service identification for WS- VLAM. The WS-VLAM client can be described as a service based application and therefore it is not described as a service inventory. The step is documented in the example in chapter 9.1.5.1.2 of the appendices. The previous paragraph leads again to the conclusion that an extensive literature review is key to apply these steps successfully. The literature review helped to discover the WS- VLAM wishlist, a list of functional requirements of WS-VLAM, which could be directly mapped to the functional requirements of the SOADM. The direct mapping helps to build a bridge between the former design documentation and the new documentation. Another important conclusion made during the application process is that a successful application of SOADM is only possible when relevant stakeholders of WS-VLAM project are directly involved in the design process. The most useful ideas and the best process were made by talking directly to the developers. This is why several interviews with the developers were conducted. This approach also assures that the design documentation is of help for the developers. 6.3.2 Design Space and Design Space Refinement As shown in Figure 36, the Design space is a central aspect of integrating the TAM results into the SOADM. The Design space describes design issues that are addressed to develop the design solution. The Design space, the introduction of a strategy and the Refinement of the Design space with a strategy are highly relevant for this case study on WS-VLAM because they provide an interface to integrate and to address user acceptance issues to the design of a software service in this case WS-VLAM client. Each design issue is expressed in form of a question. This helps to focus on the right issues, and avoid confusion between the problems and its possible solutions (Lago, Patricia, 2012). Each issue description includes a motivation on why this question is relevant for the software service. For each design issue several possible options are identified and evaluated. Possible relationships among options also need to be considered. The decision making on which option to choose is supported by providing a set of criteria. These criteria correspond to the set of service aspects (quality requirements) which are defined in previous steps of the methodology. The process of formulating design issues as questions was perceived helpful in this case study. However, giving a rational on the decisions was often perceived as very difficult for the WS-VLAM case. By addressing design issues the existing architecture needs to be considered which requires a full understanding of the existing architecture and/or collaboration with the developers. An example of a design issue can be found in chapter 9.1.2. There are two tools being used to implement the Design space: the Architectural Knowledge design Space Modelling template table (AK-SPAM) and the Question-Option- Criteria (QOC) notation. Both tools are very helpful to structure the Design space. After the Design space has been defined, all design aspects concerning the software solution should be decided. 72

In a next step, a strategy is applied to the Design space. This requires editing or redefining the Design space. In the WS-VLAM case a User Acceptance Strategy was applied to Design space. To define a User Acceptance Strategy it is useful to study the TAM survey results described in chapter 5.4.7. Chapter 5.4.7 presents a table of all identified user acceptance issues. Based on this table it is possible to develop strategies to address these issues. One of the issues discovered in the TAM survey research on WS- VLAM indicated that the WS-VLAM client customizability features are rated low by the participants of the survey. The participants of the TAM survey were asked whether WS- VLAM client allows the user to customize the user-interface according to different science and engineering disciplines, scientific domains, or to an individual customization requirement. Customizing options for the user interface are a requirement described by the scientific workflow management reference architecture, described in chapter 4.1.1. A more detailed definition of customizing features for WS-VLAM client can be found in chapter 9.1.3 of the appendices. After defining a User Acceptance Strategy, it is necessary to revisit the Design space to refine and to reflect on new and existing criteria. The refinement of the Design space can take two main forms according to (Lago, Patricia, 2012): a) Extending the Design space: the strategies may lead to new design issues, options or criteria. b) Challenging the already existing design decisions: In order to enable the strategies, it might be necessary to challenge design issues describe in the design space. In the next step the strategy needs to be applied to the Design space. The strategy usually consists of a goal and actions to achieve the goal. The goals and actions are mapped to either questions (sub-questions) or options. This means a strategic goal may be formulated as question. An action may be formulated as an option or as sub question (Lago, Patricia, 2012). The Customizability strategy led to a new concern, which was added to the Design space (see, chapter 9.1.4.1). The new concern on how to add customizability features to WS- VLAM client is again documented with the two tools: Architectural Knowledge design Space Modelling template table (AK-SPAM) and the Question-Option-Criteria (QOC) notation. In a last step the changes in the Design space based on the User Acceptance Strategy need to be documented in a table. This step can be found in chapter 9.1.4.3. The new concern on customizability influenced the SO design in the following aspects. It was decided to provide and alternative customizable user interface in form of a Web Portal with portlets representing the different services of WS-VLAM. The new web portal solution had to be integrated into the steps Service candidate definition, Service inventory identification (Service identification for WS-VLAM), Service contract definition, Service network modelling, and Service choreography modelling. This shows again the interdependencies of the process. The overall process of integrating the TAM survey results to the Design space in this project can be described as structured and successful. 6.3.3 Conclusion The example of the User Acceptance Strategy focusing on Customizability features for WS-VLAM client shows how the results of a TAM survey can be integrated into the 73

SOADM. The two tools; the Architectural Knowledge design Space Modelling template table (AK-SPAM) and the Question-Option-Criteria (QOC) notation provide a solid structure for the integration process. However, applying new aspects to the Design space is a time consuming and difficult procedure, because changes in the Design space have an influence on the SO Analysis as well as on the SO Design. This interdependency requires the software designer to constantly revisit all other steps and check for dependencies. An example is above described issue of renaming the participants, which requires manual change to all other steps of the methodology. This can be extremely time consuming and prone to errors considering that the methodology uses different UML and SOAML diagram types. The research related to SOAML should investigate more agile and flexible methods for changes in the design document in order to make the process less sensitive to errors and less time consuming. The following table summarizes the identified strengths and issues of integrating the TAM survey results into a SOADM as illustrated in Figure 36. Strength This thesis presents a simple two step method to integrate TAM survey results into the design of service oriented software. SOADM provides a structured and tested foundation to implement a strategy into the Design space of software. Issues The interdependency between the TAM survey results, the SO Analysis and the SO Design requires the software designer to constantly revisit all steps of the SOADM and to check for dependencies. The SOADM does not provide an agile method to track changes in the Design space and in other steps. 74 The integration of existing implantations like WS-VLAM is not directly supported by SOADM. This case study indicated some issues related to integration and migration of existing software services. It might be useful to adapt/change the steps of the SOADM when applying it to existing software. Two tested tools to describe design issues are used: Architectural Knowledge design Space Modelling template table (AK- SPAM) and the Question-Option-Criteria (QOC) notation Table 7 Pros and cons overview of Integrating the Technology acceptance model into a Service oriented analysis and design methodology A major issue in this case study was the complexity of WS-VLAM. The literature review and study of WS-VLAM took longer than expected. This thesis project was planned for three months, a rather short time frame to address such a complex system like WS- VLAM. During the case study it was necessary to reduce the examples addressed with SOADM. This thesis provides opportunites for future research on WS-VLAM, SOADM

and SWS-TAM as well as on the presented integration model. An overview of future research topics follows in chapter 7.4. 7 Conclusions 7.1 Introduction This research aims to investigate the user acceptance of Workflow System Virtual laboratory Abstract Machine (WS-VLAM) (Vasyunin, et al., 2007). For this purpose the Technology Acceptance Model (TAM) (Davis F. D., 1989) has been applied to scientific workflow systems, in particular to WS-VLAM. The TAM survey results have indicated several user acceptance issues of WS-VLAM. To address the user acceptance issues, this thesis presents a two-step method to integrate the results of the TAM survey into the design of WS-VLAM using Service Oriented Analysis and Design Methodology (SOADM) (Lago & Razavian, 2012). This thesis applies the two step method using WS-VLAM as a case study. 7.2 Reflections This thesis connects three research fields as illustrated in Figure 37. The research field Computer Science/GRID Computing is addressed by studying the scientific workflow system WS-VLAM developed by the WS-VLAM project, a project of the GRID computing department of the University of Amsterdam. The WS-VLAM study has three components: review scientific papers about WS-VLAM, interview the developers and reverse engineer the WS-VLAM composer code. The complexity of the system was obviously a challenge for this thesis project. The right level of abstraction needed to be identified. The research field Information Systems is addressed with the information system theory: TAM. The TAM study had two components: study and review scientific papers on TAM and application of TAM to WS-VLAM. The number of published studies on TAM is huge. Another challenge was applying TAM to WS-VLAM. The literature review has shown that TAM has not yet been applied to workflow management systems. To apply TAM to a new technology, the external variables of the model have to be adjusted and modified. The new TAM model is called Scientific Workflow System Technology Acceptance Model (SWS-TAM) and has been tested in a small research survey. 75

Figure 37 Reflection on the thesis: Connecting three research fields The research field Software Engineering is addressed by utilizing the SOADM by (Lago & Razavian, 2012). The SOADM study has three components: studying and reviewing the SOADM literature, applying the SOADM to WS-VLAM to analyse the current WS-VLAM service architecture, integrating the TAM survey results into the SOADM to improve the design of WS-VLAM and to improve the user acceptance of WS-VLAM. This thesis presents a two-step method to integrate the TAM survey results into the SOADM. The application of the SOADM to WS-VLAM as well as the integration of the TAM survey results is exemplified in a case study on WS-VLAM. This last step was the most challenging and time consuming aspect of the thesis because it requires a combination of all three research fields. 7.3 Objective of the thesis project This thesis presents a two-step method to integrate the results of a TAM survey research into the design of WS-VLAM, with the objective to improve the user acceptance of the WS-VLAM. A test of this method was conducted successfully. This chapter focuses on the objectives of the thesis by elaborating on the two research questions raised in chapter 3. 7.3.1 The Technology Acceptance Model The first research question addressed in this thesis is: Does the TAM explain the user acceptance of scientific workflow management systems, in particular of WS-VLAM/WS- VLAM composer? This thesis delivers an answer for this question by providing an application of the TAM to SWfMS, which resulted in the development of SWS-TAM. The newly developed SWS- TAM was applied to WS-VLAM and tested in a small research survey case study with experienced WS-VLAM users. The evaluation of the survey research has provided evidence for the reliability of the original TAM construct. Furthermore the survey research provided evidence that some of the newly developed TAM variables are highly relevant for user acceptance of SWfMSs. The newly developed variables are SWfMS Quality, SWfMS Information quality and SWfMS Support quality. The analysis of the survey results also provides a list of user acceptance issues of WS-VLAM. The identified 76

user acceptance issues relate to the following topics: User interface customizability and user interaction support, Reproducibility support, Heterogeneous and distributed services and software tools, Heterogeneous and distributed data product management, Interoperability. These issues need to be addressed to improve the user acceptance of WS-VLAM. 7.3.2 Integrating the Technology Acceptance Model into the Service Oriented Analysis and Design Methodology The second research question addressed in this thesis is: How can the results of a TAM research be integrated into the SOADM by (Lago & Razavian, 2012)? This research introduces a two-step method to integrate the results of the survey research into the SOADM (Lago & Razavian, 2012), which can be summarized as follows: Implementing a user acceptance strategy The SOADM by (Lago & Razavian, 2012) provides a phase to integrate a strategy into the design of a software service. This phase can be used to introduce a user acceptance strategy based on the TAM survey research. Refinement of design space based on the user acceptance strategy. The SOADM by (Lago & Razavian, 2012) provides a phase to refine the design space based on a strategy. This way the design space can be refined based on user acceptance strategy. This two-step method has been successfully applied to an exemplified case study on WS-VLAM. The overall objective to integrate the TAM survey results into the SOADM has been achieved. This thesis also addressed some issues related to SOADM which were identified during the case study on WS-VLAM. SOADM is not optimized to be applied to implemented existing software services. Integrating an implemented software service and an existing documentation is challenging and difficult with SOADM. The interdependency between the TAM survey results, the SO Analysis and the SO Design requires the software designer to constantly revisit all steps of the SOADM and to check for dependencies. The SOADM does not provide an agile method to track changes in the Design space and in other steps. 7.4 Future research The Scientific Workflow System Technology Acceptance Model (SWS-TAM) has been tested within a small research survey study. There are three propositions for future research related to SWS-TAM: 1. To test the statistical validity of the model, a larger survey research needs to be conducted. The statistical analysis of this survey showed strong support of the original TAM model, however some of the external variables were not statistically supported as described in chapter 5.4.4. However, due to the small sample size, the statistical analysis was reduced to a minimum and the analysis of the variables and the answers of the participants was the main focus. For 77

future research, it could be interesting to conduct the survey in a larger scale to provide a statistical proof for the model and to improve it. 2. The here develop SWS-TAM model could be applied to other Scientific workflow management Systems e.g. Taverna, Kepler. This way it would be possible to compare the workflow systems. Furthermore, it would be possible to identify the features which improve the user acceptance. 3. This study presented a number of steps to integrate the SWS-TAM survey results into the service oriented design methodology (Lago & Razavian, 2012). For future research it could be interesting to identify further studies to improve the integration of the two models. 4. The exemplified application of WS-VLAM to SOADM needs to be improved and completed to be of value to the WS-VLAM project. The exemplified application of SOADM and the exemplified integration of the TAM survey results presented in the appendix A of this thesis can be seen as a trail study to fully apply the SOADM in a future research. 78

8 References Tsalgatidou, A., Athanasopoulos, G., Pantazoglou, M., Pautasso, C., Heinis, T., Grønmo, R., et al. (2006). Developing Scientific Workflows from Heterogeneous Services.SIGMOD Record, vol. 35, no. 2, pp. 22-28. Aalst, W., Aldred, L., Dumas, M., & Hofstede, A. (2004). Design and Implementation of the YAWL System. Proc. Center for Advancement of Informal Science Education Conf. (CAiSE 04), pp. 142-159. Ahn, T., Ryu, S., & Han, I. (2004). The impact of online and offline features on the user acceptance of Internet shopping malls. Electronic Commerce Research and Applications, 3(4), 405 420. Ajzen, I. (1991). The theory of planned behavior. Organizational Behavior and Human Decision Processes 50(2), 179 211. Allen, P. (2007). SOA best practice report: the service oriented process. Technical report, CBDi Journal. Amoako-Gayampah, K., & Salam, A. (2003). An extension of the technology acceptance model in an ERP implementation environment. University of North Carolina at Greensboro, USA: Science Direct Elsevier B.V. Arsanjani, A. G. (2008). SOMA: a method for developing service-oriented solutions IBM Syst. J. 47, 377 396. Bailey, J., & Pearson, S. (1983). Development of a tool measuring and analyzing computer user satisfaction. Management Sciences, 29(5), 530 545. Bandura, A. (1982). Self Efficancy Mechanism in Human Agency - American Psychologist 37(2) 122-147. Baresi,, L., Di Nitto, E., & Ghezzi, C. (2006). Toward open-world software: Issue and challenges. Computer 39, 36 43. Bell, M. (2008). Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley Publishing. Belloum, A., Inda, M., Vasunin, D., Zhao, Z., Rauwerda, H., Breit, T. M., et al. (2011, August). Collaborative e-science Experiments and Scientific Workflows. University of Amsterdam, Netherlands: IEEE Computer Society. Chuttur, M. (2009). Overview of the Technology Acceptance Model: Origins, Developments and Future Directions. Indiana University, USA: Sprouts: Working Papers on Information Systems 9(37) http://sprouts.aisnet.org/9-37. Cockburn, A. (1993). The impact of object-orientation on application development. IBM Syst. J. 32, 420 444. Dasgupta, S., Granger, M., & Mcgarry, N. (2002). User Acceptance of E-Collaboration Technology: An Extension of the Technology Acceptance Model. USA: Group Decision and Negotiation, 11, 87-100. Davis, F. D. (1989). A technology acceptance model for empirically testing new end-user information systems: Theory and results. Wayne State University, USA. Davis, F. D. (1993). User acceptance of computer technology: system characteristics, user perceptions. 79

Davis, F., Bagozzi, R. P., & Warshaw, P. R. (1989). User acceptance of computer technology: a comparison of two theoretical models. Management Science, 35(8), 982-1003. Davis, F., Bagozzi, R., & Warshaw, P. (1992). Extrinsic and intrinsic motivation to use computers in the workplace. DeLone, W., & McLean, E. (1992). Information systems success: The quest for the dependent variable. Information Systems Research, 3(1), 60 95. Doherty, N., & Perry, I. (2001). The Cultural Impact of Workflow Management Systems in the Financial Services Sector. The Service Industries Journal, 21:4, 147-166. Eldon, Y. L.;. (1997). Perceived importance of information system success factors: A meta analysis of group difference. Information & Management 32(1), 15 28. Feller, M., Foster, I., & Martin, S. (2007). GT4 GRAM: A Functionality and Performance Study. USA. Fishbein, M., & Ajzen, I. (1975). Belief, attittude, intention and behavior: an introduction of theory and research. MA, USA: Addison-Wesley. Fowler, J., & Floyd, J. (1995). Improving survey questions: Design and evaluation. (Vol. 38). Thousand Oaks, CA: Sage Publications. Gerhards, M., Sander, V., Matzerath, T., Belloum, A., Vasunin, D., & Benabdelkader, A. (2011). Provenance opportunities for WS-VLAM: an exploration of an e-science and an e-business approach, WORKS '11 Proceedings of the 6th workshop on Workflows in support of large-scale science. USA. Gerhards, M., Skorupa, S., Sander, V., Belloum, A., Vasunin, D., & Benabdelkader, A. (2011, September 22). HisT/PLIER: A two-fold Provenance Approach for Gridenabled Scientific Workflows using WS-VLAM,, Grid 2011: 12th IEEE/ACM International Conference on Grid Computing, Lyon. Gerhards, Michael; Sander, Volker; Matzerath, Torsten; Belloum, Adam; Vasunin, Dmitry; Benabdelkader, Ammar. (2011). Provenance opportunities for WS-VLAM: an exploration of an e-science and an e-business approach. Glasow, P. A. (2005). Fundamentals of Survey Research Methodology. Washington C3 Center McLean, Virginia. Gu, Q., Lago, P., & Vliet, H. v. (2010). A Template for SOA Design Decision Making in an Educational Setting. seaa, pp.175-182, 2010 36th EUROMICRO Conference on Software Engineering and Advanced Applications. Hackshaw, A. (2008). Small studies: strengths and limitations; University College London, Cancer Research UK & UCL Cancer Trials Centre, University College London, 90 Tottenham Court Road, London W1T 4TJ, UK. Fax: 44 2076799899. E-mail: ah@ctc.ucl.ac.uk. Hassairi, A. F., & Ayed, T. L. (2009). A comparative Study on acceptance technologies between an integrated Software (MAXIMO) and an ERP (SAP) in British Gas (BG) Tunisia. High Business School, Tunesia. Hollingsworth, D. (1995). Workflow Management Coalition Specification: The Workflow Reference Model. Document Number TC00-1003, v. 1.1. 80

Hong, W., Thong, J., Wong, W., & Tam, K. (2002). Determinants of user acceptance of digital libraries: An empirical examination of individual differences and system characteristics. Journal of Management Information Systems, 18(3), 97 124. Igbaria, M., Guimaraes, T., & Davis, G. (1995). Testing the determinants of microcomputer usage via a structural equation model. Journal of Management Information Systems, 11(4), 87 114. Inda, M., Belloum, A., Roos, M., Vasunin, D., Laat, C. d., Hertzberger, L., et al. (2006). Interactive Workflows in a Virtual Laboratory for e-bioscience: The SigWin- Detector Tool for Gene Expression Analysis. In Second IEEE International Conference on e-science and Grid Computing (pp. 19). Kaasinen, E., Mattila, E., Lammi, H., Kivinen, T., & Vaelkkynen, P. (2011). Technology Acceptance Model for Mobile Services as a Design Framework. Kim, T. G., Lee, J. H., & Law, R. (2007). An empirical examination of the acceptance behaviour of hotel front office system: An extended technology acceptance model. Cheju National University, Korea: ScienceDirect Tourism Management 29(2008) 500-513. Korkhov, V., Vasyunin, D., Wibisono, A., Belloum, A. S., Inda, M. A., Roos, M., et al. (2007). VLAM-G: Interactive data driven workflow engine for Grid-enabled resources. Scientific Programming, Volume 15 Issue 3, August 2007, Pages 173-188. Koufaris, M. (2002). Applying the technology acceptance model and flow theory to online consumer behavior. USA: Information System Research, 13(2), 205-223. Kraemer, K. L. (1991). Introduction. Paper presented at The Information Systems Research Challenge: Survey Research Methods. Lago, P., & Gu, Q. (2011). Guiding the selection of service-oriented software engineering methodologies. Service Oriented Computing and Applications, 1 21. Lago, P., & Razavian, M. (2012). A Pragmatic Approach for Analysis and Design of Service Inventories. Amsterdam, Netherlands. Lago, Patricia. (2012). Service Oriented Design 405061 - Lecture slides. Landry, B., Griffith, R., & Hartman, S. (2006). Measuring student perceptions of blackboard using the technology acceptance model. USA: Decision Science, 4(1), 87-99. Lederer, A., Maupin, D., Senza, M., & Zhuang, Y. (2000). The technology acceptance model and the World Wide Web. Decision Support Systems, 29(3), 269 282. Lee, Y., Kozar, K., & Larsen, K. (2003). The technology acceptance model: past, present, and future. Levy, P. S., & Lemeshow, S. (1999). Sampling of populations: Methods and applications. (3rd ed.). New York: John Wiley and Sons. Lin, C., Lu, S., Fei, X., Chebotko, A., Pai, D., Lai, Z., et al. (2009). A Reference Architecture for Scientific Workflow Management Systems and the VIEW SOA Solution. IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 2, NO. 1,. Lin, C., & Lu, S. (2008). Architectures of Workflow Management Systems: A Survey. Technical Report TR-SWR-01-2008. 81

Ludaescher, B., Altintas, I., Berkley, C., Higgins, D., Jaeger, E., Jones, M., et al. (2006). Scientific Workflow Management and the Kepler System. Concurrency and Computation: Practice and Experience, vol. 18, no. 10, pp. 1039-1065. Majithia, S., Shields, M., Taylor, I., & Wang, I. (2004). Triana: A Graphical Web Service Composition and Execution Toolkit. Cardiff School of Computer Science, Cardiff University, UK. Masrom, M. (2007). Technology Acceptance Model and E-learning. University of Teknologi Malaysia City Campus, Malaysia. Mathieson, K. (1991). Predicting user intentions: comparng the technology acceptance model with theory of planned behavior. USA: Information Systems Research, 2(3), 173-191. Morris, M. G., & Dillion, A. (1997). The influence of user perceptions on software utilization: application and evaluation of the theoretical model of technology acceptance. IEEE Software, 14(4), 56-75. O'Brien, L., Merson, P., & Bass, L. (2007). Quality attributes for service-oriented architectures. Proceedings of the international Workshop on Systems Development in SOA Environments. Oinn, T., Addis, M., Ferris, J., Marvin, D., Senger, M., Greenwood, R., et al. (2004). Taverna: A Tool for the Composition and Enactment of Bioinformatics Workflows, Bioinformatics, vol. 20, no. 17, pp. 3045-3054. Papazoglou, M. H. (2006). Service Oriented design and development methodology Int. J. Web Eng. Technol. 2, 412 442. Petter, S., DeLone, W., & McLean, E. (2006). Measuring information systems success: models, dimensions, measures, and interrelationships. European Journal of Information Systems (2008) 17, 236 263. Pitt, F., Watson, T., & Kavan, C. (1995). Service quality: A measure of information system effectiveness. MIS Quarterly, 19(2) 173 187. Rai, A., Lang, S. S., & Weiker, R. B. (2002). Assessing the validity of IS success model: An empirical test and theoretical analysis. Information Systems Research, 13(1), 50 69. Riemenschneider, C. K., & Hardgrave, B. C. (2001). Explaining Software Development Tool use with the Technology Acceptance Model. Ruth, C. (2000). Applying a modified technology acceptance model to determine factors affecting behavioral intention to adopt electronic shopping on the world wide web: A structural equation modeling approach. Doctoral dissertation, Drexel University. Salant, P., & & Dillman, D. A. (1994). How to conduct your own survey. New York: John Wiley and Sons. Seddon, P. (1997). A respecification and extension of the DeLone and McLean model of IS Success. Information Systems Research, 8(3), 240 253. Szajna, B. (1996). Empirical evaluation of the revised technology acceptance model. USA: Management Science, 42(1), 85-92. Vasyunin, D., Korkhov, V., Wibisono, A., Guevara-Masis, V., Belloum, A., de Laat, C., et al. (2007b). WS-VLAM: towards a scalable workflow system on the grid, WORKS '07 82

Proceedings of the 2nd workshop on Workflows in support of large-scale science, Pages 63-68, ACM New York, NY, USA. Vasyunin, D., Korkhov, V., Zhao, Z., Belloum, A., de Laat, C., Adriaans, P., et al. (2007). WS-VLAM: A GT4 Based Workflow Management System, Computational Science ICCS 2007, Lecture Notes in Computer Science Volume 4489, 2007, pp 191-198. Venkatesh, V. ; Davis, F.D. (2000). A theoretical extension of the technology acceptance model: for longitudinal field studies. Management Science, 46(2), pp. 186-204. Venkatesh, V. (2002). Determinants of perceived ease of use: Integrating control, intrinsic motivation, and emotion into the technology acceptance model. Venkatesh, V., & Brown, S. (2001). A longitudinal investigation of personal computers in homes: Adoption determinants and emerging challengers. USA: MIS Quarterly, 25(1), 71 102. Venkatesh, V.; Davis, F.D. (1996). A model of the antecedents of perceived ease of use - development and test. Decision Sciences, 27(3), 451-481. Virtual Laboratory for e-science. (2007). The WS-VLAM Users Guide (Version 0.1). Willis, T. J. (2008). An evaluation of the Technology Acceptance Model as a means of understanding online social networking behavior. University of South Florida. WSVLAM, U. o. (2012). WSVLAM Project. Retrieved from http://staff.science.uva.nl/~gvlam/wsvlam/ Yousafzai, S., Foxall, G., & Pallister, G. (2007). Technology acceptance: a meta-analysis of the TAM: Part 1. Yu, J., & Buyya, R. (2005). A Taxonomy of Scientific Workflow Systems for Grid Computing. SIGMOD Record, Vol. 34, No. 3. Zimmermann, O. K. (2004). Elements of Service-Oriented Analysis and Design. Zudilova-Seinstra, E., Yang, N., Axner, L., Wibisono, A., & Vasunin, D. (2008). Serviceoriented visualization applied to medical data analysis. Service Oriented Computing and Applications December 2008, Volume 2, Issue 4, pp 187-201. 83

9 Appendices 9.1 Appendix A: Integrating the technology acceptance model into a Service oriented Analysis and Design Methodology using the case of WS-VLAM The following chapter follows the Service oriented Design methodology proposed by (Lago & Razavian, 2012) described and outlined in the previous chapter 4.3 and extends it with the TAM. The methodology described in chapter 4.3 focuses on a pragmatic approach for the analysis and design of service inventories; however WS-VLAM composer can be described as a service based application which requires modifying the methodology. The service inventory identification has been changed to the service identification for WS-VLAM composer. A detailed description of these changes follows in chapter 9.1.5.1.2. This chapter should be seen as an applied example of how to integrate results of TAM survey research into a SOADM. Due to the complexity of WS-VLAM and WS-VLAM composer a number of limitations had to be applied. Not all results from the TAM research are addressed in this chapter, but only a few selected. Also the main scope of this chapter lies on WS-VLAM composer, rather than on the whole WS-VLAM system. 9.1.1 Service oriented Analysis 9.1.1.1 Introduction 9.1.1.1.1 Purpose The purpose of this chapter is to provide the developers of WS-VLAM with a service oriented analysis and design documentation for WS-VLAM/WS-VLAM composer. WS- VLAM composer was implemented with an ad-hoc based on a requirement list developed in 2007. This service oriented analysis and design document intends to improve the WS-VLAM documentation and support future development of WS-VLAM. Furthermore this document should be seen as an example of how TAM described in chapter 5 can be integrated in to a SOADM as described in chapter 4.3. 9.1.1.1.2 Targeted Readers The target readers are the developers of WS-VLAM. The document supposes to improve the quality of documentation of WS-VLAM and WS-WVLAM composer. Furthermore, this document should be seen as an applied example for researchers interested in TAM research. This document describes how to integrate the TAM into the service oriented and design methodology. 9.1.1.1.3 Definitions and Acronyms 84

This chapter contains a list of definitions and acronyms which are used in this Service inventory and design methodology. WS-VLAM: Workflow System Virtual System Abstract Machine Grid middleware Acronyms o GT4:Golbus Toolkit 4 (www.globus.org) o GRAM: Globus Resource Allocation Manager o GSI: Grid Security Infrastructure Web service Acronyms o WSRF: Web service Reference Framework (http://www.globus.org/wsrf/) o WS: Web service o WSDL: Web service Description Language o SOAP: Simple Object Access Protocol VL-e (http://www.vl-e.nl) Acronyms o VLAM: Virtual Laboratory Amsterdam o RTSM: Run Time System Manager o PoC: Proof of concept environment (http://poc.vl-e.nl/) o SPX.Y: VL-e research Sub-program Other Acronyms o VNC: Virtual Network Computing (http://www.realvnc.com/what.html) o R: Statistical programming Framework (http://www.r-project.org/) SOA Acronyms o Conceptual Service: a conceptual service that is implementation agnostic. Considering the perspective of our methodology all services are conceptual as the methodology presented here does not address implementation of the services. o Business Service: a self-contained, stateless business function that accepts one or more requests and returns one or more responses through a well-defined, standard interface. During service identification, some elicited business services become the service candidates for design. They also might become service operation candidates to be clustered in service candidates. o Service Candidate: conceptual service identified during analysis that is a candidate software service. o Service Operation Candidate: a service operation identified from functional requirements; it might become a service candidate itself, or be composed (i.e. aggregated) in a (more complex) service candidate. o Task Service: service that mainly executes a functionality. o Entity Service: service that mainly manages, and offers access to, a (complex) data resource. o Hybrid Service: a mix of task service and entity service. 85

o Utility Service: Domain- or application independent service offering access to generic functions or generic data resources. Also called Infrastructure service 9.1.1.1.4 Business Domain Description Complex scientific experiments contain distributed data and computing resources and require collaboration among scientists with various backgrounds. Lately, workflows have become a popular approach to modelling and organizing such experiments (Belloum, et al., 2011). A scientific workflow management system explicitly models the dependencies between processes within an experiment and orchestrates resources runtime behaviour. Over the past few years, various research groups have developed workflow management systems e.g. Taverna Workbench 19, Kepler 20, Triana 21, Worklfow System Virtual laboratory Abstract Machine (WSVLAM) 22 and others. Successful scientific workflows are evolving into commodity tools that are used to build and run more complex and challenging experiments (Belloum, et al., 2011). A new generation of social networking and sharing sites has emerged e.g. myexperiment 23 site, which makes it easy to find, use, and share scientific workflows and build communities. In his article Science 2.0, Ben Shneiderman claims that traditional scientific methods need to be extended to deal with the complex issues that arise as social systems meet technological innovation. This idea extends the e-science concept, introduced a decade ago, which focuses mainly on computationally intensive science and how to solve it using highly distributed environments (Belloum, et al., 2011). Complex scientific experiments involve not only access to geographically distributed data and computer resources but also require methods for sharing the acquired knowledge among scientists (Belloum, et al., 2011). Grids and clouds, are virtual infrastructures that support data- and compute- intensive experiments and provide solutions to the inherent scaling problem (Belloum, et al., 2011). However, these technologies offer little to support the sharing of experiments or allow new findings by integrating various data sources, such as publications and scientific results across different scientific domains (Belloum, et al., 2011). Worklfow System Virtual laboratory Abstract Machine (WS-VLAM) is part of Virtual Laboratory for e-science (VL-e) a framework which supports the entire life cycle of e- science experiments. WS-VLAM is a tool which supports various aspects of life cycle of e-science experiments. Life cycle of e-science experiments Setting up scientific experiments contains various activities performed at different times (Belloum, et al., 2011). These activities belong to the experiment s life cycle, which 19 http://www.taverna.org.uk/ 20 https://kepler-project.org/ 21 http://www.trianacode.org/ 22 http://staff.science.uva.nl/~gvlam/wsvlam/ 23 www.myexperiment.org 86

consist of four phases: problem investigation, experiment prototyping, experiment execution, and results publication (see Figure 38). Figure 38 Scientific experiment s life cycle (Belloum, et al., 2011) Every phase of the life cycle requires support for collaboration and interactions. Integrating the data produced throughout this life cycle can be challenging, and it becomes even more challenging when considering that scientists are continuously defining hypotheses, collecting data, running experiments, revising hypotheses, and publishing results. Multidisciplinary and geographically distributed teams of scientists must be able to locate, construct, execute, and maintain such scientific experiments (Belloum, et al., 2011). As described above the main scope of this document the WS-VLAM composer and its role in the life cycle of e-science experiments in the e-vl framework. A detailed description of WS-VLAM architecture can be found in chapter 4.2. The following section describes the participants of WS-VLAM. A participant either uses a service or provides a service. The participants in WS-VLAM are defined as follows: Client/Portal Application Provider (The client/portal Application Provider provides access to the WS-VLAM services. In this case study the provider is the WS-VLAM project homepage at the University of Amsterdam) Workflow System Provider (The Workflow System Provider provides the WS- VLAM services. In this case study on WS-VLAM the provider is the University of Amsterdam) Security Provider (The security provider provides the authentication and delegation for WS-VLAM services. In this case study the security provider is the University of Amsterdam). GRID/Computing Resources Provider (GRID/Computing Resources provider provides the GRID hardware infrastructure for the workflow management system. In this case study the GRID/Computing resource provider is the University of Amsterdam Super Computer). 87

Virtual Laboratory for e-science Framework (Virtual Laboratory for e-science, a generic framework that supports a wide class of specific e-science application. WS-VLAM is part of this framework). The following activity diagram, Figure 39, describes the typical activities related to a scientific e-science life cycle which need to be covered by WS-VLAM and e-vl. The activity diagram illustrates the activities related to the Problem Investigation (green), Experiment Prototyping (yellow), Experiment Execution(red) and Results Publication(Result publication). The dashed boxes present software service candidates which will be described in the following chapters. 88

Figure 39 Scientific experiment s life cycle activity diagram 89

The following list describes the different phases of the scientific experiment s life cycle and the evolved participants. These actives are the foundation for developing WS-VLAM business services. Business services Problem Investigation Experiment Prototyping Experiment Execution Results Publication Description Before designing a new experiment, scientists review and study related research and identify existing methods and tools that they might reuse in the experiment (Belloum, et al., 2011). At this stage, scientists have two main requirements: access to existing knowledge within a scientific field, e.g. scientific publications, books, software components, etc. and the possibility of interaction with peers, e.g. to brainstorm and share live documents. When performing these activities, scientists create new valuable knowledge, which should be recorded and shared (Belloum, et al., 2011). Prototyping a new experiment is an iterative process where the experiment is designed and modelled as a workflow. The implementation of the workflow is the main goal of this business service. In e-science, using workflows supports the scientists to abstract a complex experiment (Belloum, et al., 2011). Experiment execution or workflow execution focuses on scaling the prototypes designed in the earlier phase. Scientific workflows are datacentric and may have special requirements for both computing and network resources (Belloum, et al., 2011). Executing such workflows includes staging the components that make up the experiment, efficiently executing them on available computing resources, monitoring the experiment s progress and collecting provenance information (Belloum, et al., 2011). The publication of the experiment results should contain a clear description of the experiment steps, execution conditions, input data, interactions required to control the execution, and workflow output information (Belloum, et al., 2011). Most of this information is generated by the workflow management system for example through the workflow provenance recovery and the workflow monitoring. Publishing this information in public repositories requires careful annotation. Environments that let scientists annotate data and compose documents jointly are key components in supporting large-scale, multicentre scientific experiments (Belloum, et al., 2011). 90

9.1.1.2 Business service identification 9.1.1.2.1 Functional Requirements The following functional requirements are based on the WS-VLAM wish list 24 (partly implemented). This links this design document directly to the pervious design documentation of WS-VLAM. This document aims to structure the pervious design documentation with the SOADM by (Lago & Razavian, 2012). Short Name Unique ID Description Workflow Composition panel fr-01- workflow_compositi on panel Workflow Components palette Workflow Property panel Display Workflow Monitor console Workflow menu bar/workflow navigator Generate the XML description of the workflow Submit xml description of a workflow to the engine Attach and detach from engine Monitors the workflow execution Supports hierarchical fr-02- workflowcomponents-palette fr-03- workflowproperty-panel fr-04-diplayworkflow-monitorconsole fr-05-diplayworkflow-navigator fr-06-generate-xmldescription-ofworkflow fr-07-submit-xmldescription-toengine fr-09-allowe-guiattach-and-detachfrom-engine fr-10-monitorworkflow-execution Monitors the workflow execution using WSRFnotifications. fr-11-hierachicalworkflow Allows the graphical composition of workflow modules (via Drag and Drop) to compose a scientific workflows. Offers an overview of workflow modules provided by the workflow repository. Retrieves the description of workflow components from Repository Services. Provides information monitoring information on the workflow execution (log files). Provides workflow management functions. E.g. start/stop workflow execution. Generates the XML description of the workflow which is readable for the WS-VLAM factory engine. Submits the description of the workflow using SOAP protocol to the workflow engine. Allows to attach and detach to/from workflow engine in the case of long running workflows. Supports hierarchical workflow composition (creates composite workflow components). 24 http://staff.science.uva.nl/~gvlam/wsvlam/presentations/ws-vlam-wishlist.ppt 91

workflow composition Encapsulate complex procedures Access to DBMS Access to databases Workflow provenance Controlled execution of workflow Distributed execution Dynamic workflow execution composition Integration of 3rd party software Access to existing 3rd party webservices Typing mechanism for input/output data Allowed multiple input output entities Encapsulation fr-12-encapsulatecomplexprocedures fr-13-provide-datamanagement-forworkflows fr-14-providedatabase-accessfor-workflows fr-15-integrate-3 rd - party-softwaretools-in-workflows fr-16-provideaccess-to-3 rd -partyservices-forworkflows fr-17-typingmeachisum-forinput-outputdata fr-18-allowedmuliple-inputoutput-enteties fr-19-allowedhierachies-ofworkflows fr-20-ceputureworkflowprovenance fr-21-controlledworkflow execution fr-22-supportdestribuedexecution-acrossgrid fr-23-dynamicworkflow-execution Encapsulate complex procedures/in-house developed software for novice users. Access to DBMS; a service on(/from) which a workflow entity can store(/retrieve) data. Access to databases from workflow. (storage/retrieval/querying) Integration of 3rd party software in a workflow (R, Matlab, VTK, ITK, FSL, etc.). Access to existing 3rd party web-services. Typing mechanism for input/output data. Fan-in (the input data can come from multiple entities) & fan-out (the output can be passed to multiple entities). Encapsulation; the ability to create hierarchies of workflow). Capture workflow, provenance ; Maintain history of executed workflow for later inspection and reproduction of experiment. Controlled execution of workflow, (e.g. stepwise; useful in debugging). Distributed execution (e.g. across a Grid of systems). Interactive, dynamic execution of workflow, Dynamic workflow. 92

Maintain intermediate Maintain intermediate results, Checkpointing; both data and process nohup execution (being able to execute a workflow in the background, without having to be logged in all the time. Control flow Resource brokering Compliance to standards fr-24-providecheckpointing fr-25-providecontrol-flowconstructs fr-27-provideresource-brokering fr-28-complicanceto-standards-on-alllevels Control flow (while/for/if-then-else, parallel/sequential/recursion). Resource brokering; given the description of resources required by a workflow entity and the description of abilities provided by a resource: the (automatic) brokering of and entity onto a resource. Compliance to standards on all levels Implementation on well-established standards (i.e. Grid software, easy to install, maintain) Quality-of-Service: fault tolerant, stable, high availability, dependable. Software engineering: maintainability of dependency on 3rd party software OWL/Ontology, semantic annotation Table 8 Functional Requirements WS-VLAM 9.1.1.2.2 Quality Requirements The following list illustrates some of the quality requirements associated to a SOA-based design, which are believed to be mostly relevant for WS-VLAM. The list contains the name, an ID and a description of the chosen quality requirement. Short Name Unique ID Description Usability qr-01-usability "Usability is a measure of the quality of a user's experience in interacting with information or services (O'Brien, Merson, & Bass, 2007). In the case of WSVLAM client, this means the client needs to provide a user friendly, customizable, domain independent, easy to learn user interface. This topic has been addressed in chapter 4.1.1 and 4.1.2. Availability qr-02- Availability is the proportion of time a system or 93

Interoperability Performance availability qr-03- interoperability qr-04- performance component is operational and accessible when required for use. Availability of services both from the user s and provider s perspectives is a concern for the success of an SOA. From the service user s perspective, if the service is not available (even transiently), then the system cannot successfully meet its functional requirements. From the service provider s perspective, in order for the service to be used (for which the provider may receive compensation), it must be available when needed. Otherwise, the downtime could affect the provider s finances and reputation. (O'Brien, Merson, & Bass, 2007). In the case of WS-VLAM client this means to insure the availability of the client tools as well as the GRID resources. WS-VLAM needs to provide: fault tolerates stability and high availability. "Interoperability refers to the ability of a collection of communicating entities to share specific information and operate on it according to an agreed-upon operational semantics" (O'Brien, Merson, & Bass, 2007). In the case of WS-VLAM, this means that WS-VLAM needs to support the integration with other scientific workflow management systems. WS-VLAM needs to support the interaction with different distributed services and software tools e.g. R, Python, C, C++, Java, etc. Performance can mean different things in different contexts. In general, it is related to response time (how long does it take to process a request), throughput (how many requests overall can be processed per unit of time), or timeliness (ability to meet deadlines, i.e., to process a request in a deterministic and acceptable amount of time) (O'Brien, Merson, & Bass, 2007). One of the main strength is related to the scalability and the performance of workflow executions (Belloum, et al., 2011). The performance is strongly related to the GRID resources WS-VLAM is using. Security qr-05-security Although security denotes different things with respect to software systems, in general, it is associated with four principles: (a) confidentiality, which ensures that access to information/services is granted only to authorized subjects; (b) authenticity, which is related to trust that the indicated 94

User acceptance qr-06-useracceptance author/sender is the one responsible for the information; (c) integrity, which guarantees that information is not corrupted; and (d) availability, which ensures that the service is available in a timely manner. Security is a major concern for SOA and Web services (O'Brien, Merson, & Bass, 2007). Security is a main concern for WS-VLAM. Security aspects of WS-VLAM have been described in chapter 4.2. The user acceptance has been added as a quality requirement to link the TAM research results to WS- VLAM. User acceptance is often tested in software engineering to reduce change requests and to reduce costs in the on-going development. The TAM provides a theoretical foundation to test user acceptance of a technology or system. User acceptance is closely related to the quality of a user's experience and the acceptance of the user to use the WS-VLAM, the flexibility of WS-VLAM and the functionality of WS-VLAM. A high user acceptance is reflected in a high Perceived Ease of Use and a high Perceived Usefulness of WS-VLAM. Table 9 Quality Requirements: WS-VLAM 9.1.1.2.3 Business Services This chapter describes the identified business services. Field Unique ID Short Name Involved Participants Detailed Operational Description Description bs_01_problem_investigation Problem investigation Client/Portal Application, Workflow System Provider, Security Provider Before designing a new experiment, scientists study and review related research and identify existing methods and tools that they might reuse in the experiment (Belloum, et al., 2011). At this stage, scientists have two main requirements: access to existing knowledge within a scientific field, that is for example scientific publications, books, software components, and so on and the possibility of interaction with others to brainstorm and share live knowledge. When carrying out these activities, scientists create new valuable knowledge, which should be recorded and shared (Belloum, et al., 2011). Support for collaboratively investigating a problem must address two main challenges: information integration (in 95

Service Behaviour heterogeneous formats) and access to collaborative tools. The second challenge is in the scope of WS-VLAM client. WS-VLAM client provides access to a repository with existing to workflow modules. The scientist is able to browse through this workflow modules and is able to decide whether she/he wants to reuse use of implement new tools/workflow modules. Service Decomposition Table 10 Business service 1: Problem investigation Field Description 96

Unique ID Short Name Involved Participants Detailed Operational Description Service Behaviour bs_02_experiment_prototyping Experiment Prototyping Client/Portal Application, Workflow System Provider, Security Provider Prototyping a new experiment is an iterative process where the experiment is designed and modelled as a workflow. The implementation of the workflow is the main goal of this business service. The scientist chooses from a range of workflow modules and control flow elements to compose a complete workflow. The workflow modules are connecting via input and output ports. In a data flow driven workflow management system, a workflow module is executed when data is received at the input port. control flow elements such as loops, OR, XOR etc. allow the scientist to control the workflow execution. In e-science, using workflows supports the scientists to abstract a complex experiment (Belloum, et al., 2011). 97

Service Decomposition Table 11 Business Service 2: Experiment Prototyping Field Unique ID Short Name Involved Participants Detailed Operational Description Description bs_03_experiment_execution Experiment Execution Client/Portal Application, Workflow System Provider, Security Provider, GRID/Computing Resource Provider Experiment execution or workflow execution focuses on scaling the prototypes designed in the earlier phase. Scientific workflows are data-centric and may have special requirements for both computing and network resources (Belloum, et al., 2011). Executing such workflows includes staging the components that make up the experiment, efficiently executing them on available computing resources, monitoring the experiment s progress and collecting provenance information (Belloum, et al., 2011) Service Behaviour 98

Service Decomposition Table 12 Business Service 3: Experiment Execution Field Unique ID Short Name Involved Participants Detailed Operational Description Service Behaviour Description bs_04_results_publication Results Publication Client/Portal Application, Workflow System Provider, Security Provider, VL-e The publication of the experiment results should contain a clear description of the experiment steps, execution conditions, input data, interactions required to control the execution, and workflow output information (Belloum, et al., 2011). Most of this information are generated by the workflow management system for example through the workflow provenance recovery and the workflow monitoring. Publishing this information in public repositories requires careful annotation. Environments that let scientists annotate data and compose documents jointly are key components in supporting largescale, multicenter scientific experiments (Belloum, et al., 2011). 99

Service Decompositio n Table 13 Business Service 4: Results Publication Similarities, Redundancies and Reused sub-services To conclude this chapter, this section points out the result of the services decomposition carried above. By analysing all candidate services, the analysis showed some of them are reused in different services, for example the candidate Security/delegation Service of the Problem investigation service is used also in the Experiment prototyping, the Experiment execution and the result publication. Such a case the candidate services is label reused. The following list of the services and the relative operational services that compose the WS-VLAM System so far in the design: 1. Problem Investigation a. Provide security/delegation (reused) b. Share problem investigation process and ideas with others c. Provide access to workflow module repository (reused) 2. Experiment prototyping a. Provide Security/delegation (reused) b. Provide access to workflow module repository (reused) c. Provide workflow design tools d. Provide workflow notification(reused) e. Provide workflow provenance(reused) 3. Experiment execution a. Provide security/delegation (reused) b. Provide workflow engine c. Allocate network and computing resources d. Control and mange workflow execution 100

e. Provide workflow notification (reused) f. Provide provenance information (reused) g. Provide/Forward workflow output (reused) 4. Results publication a. Provide security/delegation (reused) b. Provide/ Forward workflow output (reused) c. Provide provenance information (reused) d. Provide workflow notification(reused) 9.1.1.2.4 Context Model This chapter describes the business services of WS-VLAM, the interacting participants and the WS-VLAM system boundaries. The context model in Figure 40 shapes the design concerns addressed in this document, with the actors involved. The participants are described in chapter 9.1.1.1.4. A participant rather provides a service or uses a service. 9.1.1.2.5 Data Model Figure 40 Context Model WS-VLAM In this section provides the description of the static structure of the system, by means of a data model. Figure 41 illustrates a diagram depicting all the entities involved in the business services analysed before. 101

Figure 41 Data Model WS-VLAM 9.1.2 Design space development This chapter documents the design space for the WS-VLAM. The design space includes design issues that must be addressed to develop the design solution for WS-VLAM. The design options and the design decisions are outlined with a rationale in this design chapter. There are two tools being used to implement the design space: Architectural Knowledge design Space Modelling template table (AK-SPAM) and the Question-Option- Criteria (QOC) notation (Lago, Patricia, 2012). Given the business services identified in chapter 9.1.1.2.3 and the selected service aspects in chapter 9.1.1.2.2 this chapter identifies a set of design issues. Each design issue is expressed in the form of a question. This helps in focusing on the right issues, and avoids confusion between the problem to solve and its possible solutions. Each issue description includes a motivation why this question is relevant to WS-VLAM. For each design issue several possible options are identified and evaluated. Possible relationships among options also need to be considered. Moreover, a set of relevant criteria s is provided to be able to make a decision on one of the options. These criteria correspond to the set of service aspects which were selected in chapter 9.1.1.2.2. For each design issue, the decision is presented by giving a relational. 102

All these items are documented by using the Architectural Knowledge Design Space Modelling template table (AK-SPAM) and the Question-Option-Criteria (QOC) notation. 9.1.2.1 How are workflow-modules managed? The following table illustrates a concern: How are workflow modules managed? Concern (Identifier: Description) Ranking criteria (Identifier: Name) Con#1: How are workflow-modules managed? This concern aims at the design decision on how the user can manage existing workflow modules. Workflow modules are the components of a workflow and are essential for designing and building a scientific workflow. Cr#1: qr-01-usability Cr#2: qr-02-availability Cr#3: qr-05-security Options Identifier: Name Con#1-Opt#1: Via a workflow module repository service Description Workflow modules are provided through a workflow module repository accessible from any internet location. The user can browse the repository to view and to use existing workflow modules. The repository is accessible and integrated with a client service which requires a user authentication. Status This option is decided. Relationship(s) A relationship might exist to authentication and verification concerns. However because of the time limitation for this thesis, other design concerns are not addressed and left for future work on this design document. Evaluation Cr#1: By using a repository service for the workflow modules the quality requirement usability is supported because the user is able to easily access and manage the required workflow modules. Cr#2: By using a repository service for the workflow modules the quality requirement availability is supported. By means of service level agreements for the uptime of the repository service, the availability of workflow modules can be guaranteed. Cr#3: By using a repository service for the workflow modules, the quality requirement security is supported. By means of service level agreements for the security of the repository service the security of 103

Rationale of decision Identifier: Name Description Status Relationship(s) Evaluation Rationale of decision workflow modules can be guaranteed. This option is decided because a repository service solution supports both rating criteria: usability, availability. Con#1-Opt#2: local file system The workflow modules are stored on the local file system of the client. The user has to select a local storage folder for the workflow modules, the workflow modules access does not require authentication. This option is rejected. No relationship. Cr#1: By using the local file system to manage workflow modules the quality requirement usability is supported because the user is able to easily access and manage the required workflow modules. Cr#2: By using the local file system to manage the workflow modules the quality requirement availability is not supported. The WS-VLAM client can be accessed from any internet location. When the user uses different computers to access the WS- VLAM client, the workflow modules are not available thus the availability of all workflow modules cannot be guaranteed. Cr#3: By using the local file system for the workflow modules the quality requirement security is not supported. The workflow modules are accessible to unauthorized parties which might cause a security issue. This option is rejected because (Cr#2) and (Cr#3) are not supported by this option sufficiently. Table 14 Con#1: How are workflow-modules managed? 104

Via a workflow module repository service Usability Con#1: How are workflow-modules managed? Availability Via the local file system Security Figure 42 QOC notation for the Concern 1 9.1.2.2 More example of design issues Because of the limited time for this thesis not all design issues can be address in this work. The following list gives an overview of design issues which could be address in future research on WS-VLAM. 1 What type of identification should be supported? 2 How to ensure the data exchange security between services? 3 How provide an optimal monitoring of the workflow execution? 4 What data is stored for provenance support? 5 How to display/present workflow results? 6 How to provide the right level of security? 7 How to decrease the request and response time during retrieving and storing data to data storage? 8 How is the workflow execution managed? 9 How can the workflow execution be managed? 10 How is workflow input data managed? 11 How is workflow output data managed? 9.1.3 Design space refinement with the Technology Acceptance Model This chapter presents a refinement of the design space based on results of the TAM research presented in chapter 5.4. By analysing the TAM research results it is possible to identify and define a set of user acceptance strategies to improve the user acceptance of WS-VLAM. The results of the user acceptances research have been outlined in chapter 5.4.7. This chapter presents strategies to address this user acceptance issues. Because of the time limitation for this thesis, only one issue has been address with a strategy as an example. The chosen issue is uai-01-user-interface described in chapter 5.4.7. The issue is addressed with the TAM strategy 01 Customizability for specific scientific domains described in the following chapter. 105

To include the user acceptance strategies in the design, the design space needs to be edited or redefined. To do that, the identified strategies need to be mapped to the AK- SPAM and QOC notation in the design space from the previous chapter 9.1.2. It is necessary to revisit the design space of chapter 9.1.2 to refine and to reflect on new questions and criteria or decisions introduced by the TAM strategies. The refinement of the design space can take two main forms: a) Extending the design space: the strategies may lead to new design issues, options or criteria. b) Challenging the already existing design decisions: In order to enable the strategies, it might be necessary to challenge design issues describe in the previous step. Lago, Patricia, (2012) has presented a method to map a strategy to the design space. The strategy usually consists of a goal and actions to achieve the goal. The goals and actions are mapped on either questions (sub-questions) or options. This means a strategic goal may be formulated as a question. An action may be formulated as an option or as a sub questions. 9.1.3.1 Description of Technology Acceptance Model Strategies 1. TAM-ST-01-Customizability-to-specific-scientific-domains Field Unique ID Short Name Description Description TAM-ST-01-Customizability-to-specific-scientific-domains TAM Strategy 01 Customizability for specific scientific domains A scientific workflow management systems needs to provide an interface which is user friendly and customizable to different scientific domains. A scientist from the biology domain has different demands and requirements than a scientist from astrology domain. This makes it necessary to provide customizability feature which allow the scientist to adapt the scientific workflow system to her/his specific domain. This feature could for example require the following actions: 1. Choice for specific workflow modules templates (The scientist can choose from a range of specifically for his domain customized workflow modules templates) 2. Choice for specific workflow monitoring and provenance information. ( The scientist can choose 106

Type of strategy Relevance for Business domain Diagram from monitoring and provenance filers, which allowed him to focus on domain specific information). 3. Choice for different layout setting. (The scientist can choose from layout settings which allow her/him to adapt the layout to specific domain needs.) User acceptance/ TAM A strategy to provide customizability features for different scientific domains to improve the user acceptance is of interest for WS-VLAM. Provide customized workflow module list Improve user acceptance Provide specific workflow monitoring and provenance information Customizabilityfor-specificscientificdomains Provide layout settings and options Table 15 SWS-TAM-Strategy-Customizability-to-specific-scientific-domains Other strategies Other TAM strategies can be derived from the survey results in chapter 5.4.7. For example, the following user acceptance issues can be addressed with a strategy: uai-02- provenance, uai-03- distributed-services, uai-04-data-management, uai-05- interoperability. This could be relevant for future research. 9.1.4 Design Space Refinement 9.1.4.1 New concerns Concern (Identifier: Description) Con#2: How to provide customizing options for specific scientific domains? The TAM research described in chapter 5.4 has identified several user acceptance issues. The participants of the survey have rated the customizability of WS-VLAM low. This means improvement of this feature could lead to a higher user acceptance of WS-VLAM composer. 107

Ranking criteria (Identifier: Name) Customizability features could be added by modifying the current WS-VLAM composer or by implementing a new open source portal solution with portlets. Such portal solutions have been implement by other scientific workflow system e.g. Taverna 25, Kepler - IceCore 26. Customizing options for this document are defined as follows: 1. The choice for specific workflow modules templates. E.g. a scientist from the biology domain can chose to see only workflow module templates for biology. 2. The choice for specific workflow monitoring and provenance information. E.g. a scientist from the biology domain can chose to filter the monitoring for domain specific requirement. 3. The choice for different layout settings. E.g. a scientist from the biology domain can adapt the layout of the interface to domain specific requirements. Cr#1: qr-01-usability Cr#2: qr-02-security Cr#3: qr-06-user-acceptance Options Identifier: Name Con#1-Opt#1: Modify WS-VLAM composer in order to offer customisability features to the user. Description WS-VLAM composer implementation has to be modified in order to address the user acceptance issue of missing customizing features. This means the current user interface needs to be edited or changed. Status Relationship(s) Evaluation This option is decided. There is a relationship to Con#1: How are workflowmodules managed? Cr#1: By adding customizability features to WS- VLAM composer the quality requirement usability is supported because the user will be able to customize WS-VLAM composer to her/his needs which increase the usability. Cr#2: By adding customizability features to WS- 25 http://dev.mygrid.org.uk/wiki/display/portals/deliverable+2.1.1+- +Enactment+of+Taverna+Workflows+via+a+Portal 26 ftp://ftp.eso.org/projects/adass/posters/p088.pdf 108

Rationale of decision Identifier: Name Description VLAM composer the quality requirement security is supported because the new customizability features will be implemented within the secure WS-VLAM environment. Cr#3: By adding customizability features to WS- VLAM composer the quality requirement user acceptance might be positively increased because new customizability features would make the WS- VLAM client more flexible and changeable. However, there might be limitations in terms what features can be added to the current WS-VLAM client application. Furthermore the implementation of such features could be costly. This option has been decided because the overall impact on the usability, security and user acceptance is positive. The implementation of such changes might be connected with high implementation efforts and costs. Furthermore Op#2 might have a higher influence on the user acceptance of WS-VLAM because it provides more flexibility and changeability for the user. Con#1-Opt#2: Implement a flexible open source workflow management portal solution with portlets (Portlets are user interface components that are managed and displayed in a web portal). There are several free open source web portals solutions available. These portal solutions, often use an integrated a Content Management System (CMS) as a foundation. Examples for such open source portals projects are the Liferay, uportal and Sakai and others. The focus of the development work should lay on developing different portlets for WS- VLAM. The goal is that the user can choose from a wide number of portlets to use WS-VLAM services e.g. The scientist can choose to use a portlet which provides monitoring information on the execution of a workflow. The following portlets should be available: Portlet for delegation management Portlet for workflow module repository Portlet for workflow monitoring Portlet for provenance information Portlet for workflow execution management 109

Portlet for workflow design By being able to choose the portlets, the user can customize the portals to her/his requirements. Status This option is decided. Relationship(s) There is a relationship to Con#1: How are workflowmodules managed? Evaluation Cr#1: By implementing new WS-VLAM portlets for different features within a web portal solution could improve significantly the usability of WS-VLAM. User will be able to customize and choose the features she/he needs and wishes to use. The portlets are organised within an open source web portal. Cr#3: By implementing new WS-VLAM portlets for different features within a web portal solution the quality requirement security is supported. The portlets are organised within an open source web portal which offers security features. Cr#4: By implementing new WS-VLAM portlets for different features within a web portal solution the quality requirement user acceptance might be positively influenced. The described open source portals solution in the form of a Content Management System (CMS) provide additional features to improve the user acceptance e.g. Content management option etc. Rationale of The option has been decided because a portal decision solution could bring additional value to WS-VLAM and the overall user acceptance. Other workflow systems have successfully implemented portlets for such portals. Overall rational on this concern The presented ideas on customizability need to be evaluated and further investigated. The ideas presented above could be used for future research on WS-VLAM. A final decision on this concern needs to be discussed with the WS-VLAM project. Table 16 Con#2: How to provide customizing options for specific scientific domains? 110

Related to Con#2: How to provide customizing options for specific scientific domain? Con#1: How are workflow-modules managed? Implement a flexible open source workflow management portal solution with portlets Modify WS-VLAM composer in order to offer customisability features to the user. Usability Security User acceptance Figure 43 QOC notation for the Concern 2 9.1.4.2 Challenge of the old concerns In this example, no existing concerns are challenged. 9.1.4.3 Mapping Design Space to User acceptance strategies To make the influence of the strategy on the design space traceable, it is necessary to document the changes in design space. To show how the design space has been extended, the goals and actions of each of strategy have been mapped on the QOC elements (i.e. questions, option and criteria) (See Figure 43). This way it becomes clear how the strategies are addressed in the design space. The following table describes the influence from the strategy on the design space. Strategy Name Strategy ID Description Customizability-to-specificscientific-domains TAM-S-01- Customizability-tospecific-scientificdomains Table 17 Mapping Design Space to User acceptance strategies The new concern Con#2: How to provide customizing options for specific scientific domain? is related to Con#1: How are workflowmodules managed? Because the customizability features might influence the implementation and function of the repository service. 9.1.5 Service oriented Design 111

9.1.5.1 Solution Space 9.1.5.1.1 Service candidate definition This chapter presents the identified software service candidates. The software service candidates are elicited from the business services which are defined in chapter Fehler! Verweisquelle konnte nicht gefunden werden.. The following list has been used to create Table 5. ss-01-provide-security-delegation ss-02-provide-access-to-workflow-module-repository ss-03-provide-workflow-design-tools (client)/ ss-03-control-and-manageworkflow-execution (client) ss-04-provide-workflow-notification ss-05-provide-workflow-provenance ss-06-provide-workflow-engine ss-07-allocate-network-and-computing-resources ss-08-provide-workflow-output ss-09-provide-portal The list has been slightly modified for readability reasons. 1. WS-VLAM Provenance: Provides access to provenance workflow database. Service candidate name Delegation Service Workflow module repository service Composer / Client service ID ssc-01- securitydelegation ssc-02-workflowmodulerepository ssc-03-clientservice Description WS-VLAM Delegation service: Provides authentication and delegation features for the user and the workflow engine. WS-VLAM repository service: Provides access to a workflow modules database. A repository of existing workflow task which can be used to compose a workflow. The repository also provides access to existing complete workflows. WS-VLAM Client service (also composer or GUI): Primarily a service based application, providing a graphical interface which allows the user to interact with WS-VLAM service including: requesting authentication and delegation, design and composing workflows, to manage the existing workflows, to manage and control the workflow execution, view the workflow notification (monitoring) and provenance 112

Workflow notification service Workflow provenance service Workflow engine service Allocate resources service Workflow output service ssc-06- workflow-engine information and to view the workflow output. The WS-VLAM client generates the XML description of the workflow. It also submits the description of the workflow using SOAP protocol to the workflow engine. It retrieves the description of workflow components from repository services. It allows attaching and detaching to/from workflow engine in the case of long running workflows. It also allows monitoring the workflow execution using WSRFnotifications. WS-VLAM Notification producer service: Provides notifications for monitoring the execution. WS-VLAM Provenance: Provides access to provenance workflow database. Provenance information can be used to reproduce a scientific result. WS-VLAM Runtime System Manager Workflow Factory Engine: In Globus Toolkit version 4 (GT4), RTSM provides remote job execution functions. It can be detached/reattached from the workflow composer (GUI). Creates an instance when a workflow is submitted and executes it. WS-VLAM Grid Resource Allocation and Management: In Globus Toolkit version 4 (GT4), remote job execution is supported by the Grid Resource Allocation and Management (GRAM) service, which defines mechanisms for submitting requests to execute jobs (defined in a job description language and for monitoring and controlling the resulting job executions (Feller, Foster, & Martin, 2007) ssc-04-workflownotification ssc-05-workflowprovenance ssc-07-allocatenetwork-andcomputingresources ssc-08- workflow-output WS-VLAM Output Forwarder service: Uses Grid Security Infrastructure (GSI) enabled, private Virtual Network Computing (VNC) for graphical modules to provide the WS-VLAM client with output data from the workflow execution. Workflow Portal ssc-09-portal WS-VLAM Portal (NOT IMPLEMENTED) Alternative user interface to WS-VLAM client. Provides a graphical interface based on portlets which allows the user to interact with WS-VLAM 113

service. This service resulted from TAM research. More information in chapter 7.2.2. Table 18 All service candidates The following service candidate might contain one or more business service activities. The service candidates are illustrated as dashed boxes in the following diagrams. This dashed boxes group the elements of the activity diagram into possible service candidate. Furthermore, the service candidate are mapped to the service types that represent the type of service candidate such as Task service, Utility service, Hybrid service, and Entity service. The following tables group the identified software service candidates according to the business services. Field ID Name Business Service Behaviour Description bs_01_problem_investigation Problem investigation Software Service Candidate Delegation Service: ss-01- security-delegation, Workflow module repository service: ss-02-workflow-modulerepository Workflow composer / client service: ssc-03-client 114

Diagram Table 19 Business Service 1: Service candidates Field ID Name Business Service Behaviour Description bs_02_experiment_prototyping Experiment Prototyping Software Service Candidate Delegation Service: ssc-01- security-delegation Workflow module repository service: ssc-02-workflow-modulerepository Workflow composer / client service: ssc-03-client Workflow notification service: ssc-04-workflow-notification Workflow provenance service: ssc-05-workflow-provenance 115

Diagram Table 20 Business Service 2: Service candidates Field ID Name Business Service Behaviour Description bs_03_experiment_execution Experiment Execution Software Service Candidate Delegation Service: ssc-01- security-delegation Workflow module repository service: ssc-02-workflow-modulerepository Workflow composer / client: ssc-03-client, Workflow notification: ssc-04-workflow-notification Workflow provenance: ssc-05-workflow-provenance Workflow engine service: ssc-06- workflow-engine Allocate resources service: ssc-07-allocate-network-and-computingresources Workflow output service: ssc-08- workflow-output 116

Diagram Table 21 Business Service 3: Service candidates Field ID Name Business Service Behaviour Description bs_04_results_publication Results Publication Software Service Candidate Diagram Delegation Service: ssc-01- security-delegation Workflow composer / client service: ssc-03-client Workflow notification service: ssc-04-workflow-notification Workflow provenance service: ssc-05-workflow-provenance Workflow output service: ssc-08- workflow-output Table 22 Business Service 4: Service candidates 117

9.1.5.1.2 Service identification for WS-VLAM This step has been renamed from Participant's service inventory identification to service identification for WS-VLAM. The focus of this work is the WS-VLAM client, a service based application which does not require a service inventory. Table 23 describes the service based application Client/Portal Application. The client application provides a graphical interface to use the WS-VLAM services. The client can be also used as workflow design composer and workflow management tool. In this description the client service becomes a hybrid service which not only provides a services task but also provides access to all other WS-VLAM services. The term portal has been added as a resulted from the user acceptance strategy described in chapter 9.1.3. The portal provides the same functions as the WS-VLAM client but in a more flexible and customizable manner. The portal consists of several portlets. The idea is to provide a number portlets (Portlets are user interface components that are managed and displayed in a web portal) which represent WS-VLAM services. The user can choose which portlets she/he wants to use. In this description the portal service becomes a hybrid service which not only provides a service tasks but also provides access to all other WS-VLAM services. Field ID Name Participant Provider: Constituent Software Service Candidates Consumer: Constituent Software Service Candidates Description sba-01-ws-vlam-client Client/Portal Client/Portal Application Workflow composer / client: ssc-03-client Delegation Service: ssc-01- security-delegation Workflow module repository service: ssc-02-workflow-module-repository Workflow notification: ssc-04-workflow-notification Workflow provenance: ssc-05-workflow-provenance Workflow engine: ssc-06- workflow-engine Workflow output service: ssc-08- workflow-output 118

Diagrams Table 23 Service based application: WS-VLAM Client 9.1.5.1.3 Service contract identification In this chapter describes all contracts among participants and related services for each business service. The identified contract and involved participants are illustrated and described. Figure 44 illustrates the business service: Problem identification. Two service contracts have been identified: Delegation contact and Browse repository contact. Figure 44 Service contract identification: Problem identification 119

Figure 45 illustrates the business service Experiment prototyping. Four service contracts have been identified: Delegation contract, browse repository, workflow monitoring contact and workflow provenance contact. Figure 45 Service contract identification: Experiment Prototyping Figure 46 illustrates the business service Experiment execution. Sven service contracts have been identified: Delegation contacts, transfer workflow file contract, provide notification contact, provide, provenance information, allocate recourses contact and provide workflow output. Figure 46 Service contract identification: Experiment execution Figure 47 illustrates business service Publication results. Four service contracts have been identified: Delegation contract, provenance contract, notification contract, workflow output contract. 120

Figure 47 Service contract identification: Publication results 9.1.5.1.4 Service contract definition This chapter describes the identified contracts from the previous chapter using SOAML service structure diagram and SOAML chorography diagram. Field ID Name Involved Participants Service Structure Diagram Description cn-01-delegation Delegation contract Provider: Security Provider Consumer: Client/Portal Application 121

Service Choreography diagram Table 24 Delegation Contract Field ID Name Involved Participants Service Structure Diagram Description cn-02-browse-repository Browse repository contract Provider: Workflow System Provider Consumer: Client/Portal Application Service Choreography diagram Table 25 Browse repository contract Field ID Name Involved Participants Description cn-03-transfer-workflow-file Transfer workflow contract Provider: Client/Portal Application Consumer: Workflow System Provider 122

Service Structure Diagram Service Choreography diagram Table 26 Transfer workflow contract Field ID Name Involved Participants Description cn-04-allocate-execution-resources Allocate execution resources contract Provider: GRID/Computing Resource Provider Consumer: Workflow System Provider 123

Service Structure Diagram Service Choreography diagram Table 27 Allocate execution resources contract Field ID Name Involved Participants Service Structure Diagram Description cn-05-execute-workflow Execute workflow contract Provider: Workflow System Provider Consumer: Client/Portal Application Provider 124

Service Choreography diagram Table 28 Execute workflow contract Field ID Name Involved Participants Service Structure Diagram Description cn-06-workflow-monitoring Workflow monitoring contract Provider: Workflow System Provider Consumer: Client/Portal Application 125

Service Choreography diagram Table 29 Workflow monitoring contract Field ID Name Involved Participants Service Structure Diagram Description cn-07-workflow-provenance Workflow provenance contract Provider: Workflow System Provider Consumer: Client/Portal Application 126

Service Choreography diagram Table 30 Workflow provenance contract Field ID Name Involved Participants Service Structure Diagram Description cn-08-workflow-output Workflow output contract Provider: Workflow System Provider Consumer: Client/Portal Application 127

Service Choreography diagram Table 31 Workflow output contract Field ID Name Involved Participants Service Structure Diagram Description cn-09-publish-data Publish workflow contract Provider: Client/Portal Application Consumer: VL-e Framework Service Choreography diagram Table 32 Publish workflow contract 128

9.1.5.2 Service network modelling This chapter illustrates the service networks of each business service. To illustrate the service network, SOMAL service architecture diagrams are used. Figure 48 illustrates the service architecture of the business service problem investigation. Figure 48 Service network modelling - Problem investigation Figure 49 illustrates the service architecture of the business services Experiment prototyping. Figure 49 Service network modelling - Experiment Prototyping 129

Figure 50 illustrates the service architecture of the business service experiment execution. Figure 50 Service network modelling - Experiment execution Figure 51 illustrates the Business service Publication results. Figure 51 Service network modelling - Publication results 130

9.1.5.2.1 Service choreography modelling In this section shows UML sequence diagrams related to each business service of the domain. A detailed description of the sequence diagram can be found in chapter 4.2. The user can use the WS-VLAM client or the WS-VLAM portal. Because the diagrams would look the same only the WS-VLAM client is illustrated here. Figure 52 illustrates the service choreography of the business service problem investigation. Figure 52 Service choreography modelling - Problem investigation Figure 53 illustrates the service choreography of the business service experiment prototyping. 131

Figure 53 Service choreography modelling - Experiment Prototyping Figure 54 illustrates the service choreography of the business service experiment execution. 132

Figure 54 Service choreography modelling - Experiment execution Figure 55 illustrates the service choreography of the business service Publication results. Figure 55 Service choreography modelling - Publication results 133