Contextualized Scientific Workflows in the Cloud (PDF Download ...

Chapter 12

Contextualized Scientific Workflows in the Cloud Xiaoliang Fan

Abstract Scientific workflow allows automating the workflow procedure through a compilation of known sequences of actions in distributed environments such as the cloud. Preliminary benefits have been seen in realizing scientific workflows on the cloud. However, there is a notable absence of a holistic view in current scientific workflow systems that, on one hand, capture the evolving context when designing workflow models; and on the other hand, help a specific user interact with the system during QoS prediction and dynamic selection of the relevant cloud services. In this chapter, recent works on designing scientific workflows are first reviewed by discussing the opportunities and challenges respectively. The author then proposes a contextualized approach and research directions to improve the designing of scientific workflows in the user-oriented paradigm. Finally, a case study in drug design process is presented to evaluate the contextualized methodology. The contextualized approach could be considered as an effective way of addressing the socio-technical issues in designing scientific workflows in the cloud.

12.1

Introduction

Scientific workflow technology has merged over the last decade to automate the composition and execution of complex computational and data analyses tasks in science domain. With the paradigm-shifting technology, especially cloud computing (Buyya et al. 2008), more and more scientists are migrating their scientific workflows in the cloud. Such migration is advanced to enable a utility-oriented computing model in terms of elastic size of data center on-demand resource provisioning mechanism. Cloud projects (Buyya et al. 2008) are widely applied in genome informatics, nano science, drug discovery process, etc. Preliminary benefits have been seen in realizing scientific workflows on the cloud (Fan et al. 2013). The scientific workflow implemented in the cloud is supposed to enable the dynamic choice of datasets, parameters and workflow components in X. Fan () Lanzhou University, Lanzhou, China e-mail: [email protected] © Springer Science+Business Media New York 2014 P. Brézillon, A. J. Gonzalez (eds.), Context in Computing, DOI 10.1007/978-1-4939-1887-4_12

173

174

X. Fan

the cloud. Thus it is not possible to design it in advance. Furthermore, the explorative nature of scientific results in a large number of alternative scientific workflow components (i.e., cloud services) which could provide equivalent functionalities but with different service quality. Thus, scientists who are about to adopt the usage of scientific workflow systems begin to take into account the differences in quality of services (QoS) when selecting cloud services with similar functionality (Kuang et al. 2012). This issue is extremely challenging in the cloud computing environment, because the elastic nature of cloud further boosts the increase of alternative services. To address this problem, early research works mainly deal with the QoS constraints (Liu et al. 2012), such as time, cost, fidelity, reliability and security. More recently, the QoS-aware methodology has been used in dealing with the issue of dynamic service selection in scientific workflows. Furthermore, when manipulating contextual constraints for QoS prediction and service recommendation, those works above (Kuang et al. 2012; Liu et al. 2012) only take into account the contextual information about the physical world (such as network bandwidth and IP address which indicate the location of the user), while neglecting the user-oriented context constraints (such as user preference, user behavior and user mood). With such limitation, we could foresee potential failures of the system where a cloud workflow recommended with services of good quality will not satisfy the individual scientist who may not know how to manipulate the service at all. We believe that it is worthy of presenting a novel paradigm to design scientific workflows in a socio-technical perspective. We coin the term “contextualized scientific workflows in the cloud”, featuring: (1) a user-/context-oriented approach in the center of the system to allow making contexts explicit in designing workflows with the dynamic selection of cloud services; (2) the abstract model of cloud workflows, contextualized to a set of concrete models by the user who faces the workflow execution in a specific context; (3) the special focus on the social and human factors of designing scientific workflows. Hereafter, this chapter is organized as follows. Section 12.2 introduces the possibilities of migrating context to cloud workflows. Section 12.3 discusses potential opportunities in the design of contextualized workflows in the cloud. Section 12.4 presents a group of major challenges when designing scientific workflows with contextual constraints. Section 12.5 proposes suggestions on research directions to which we could put our research efforts. A case study is presented in Sect. 12.6. Finally, the general conclusion and perspective in Sect. 12.7 closes this paper.

12.2

Making Context Explicit in Cloud Workflows

Context has long played a well acknowledged role in a number of domains, such as natural language processing, problem solving, machine learning, knowledge acquisition, and databases and ontology. In this chapter, we use the definition of context

12

Contextualized Scientific Workflows in the Cloud

175

Fig. 12.1 Our framework for modeling context in cloud workflow

described in (Brézillon and Pomerol 1999). They declared that context is “what constrains the resolution of a problem without explicit intervention in it”. In order to introduce the context methodology in scientific workflows, we first propose our working definition of context, which is divided into two parts (see Fig. 12.1): (1) the conceptual view of context uses the view in (Brézillon and Pomerol 1999); and (2) the implementation view of context is inherited from (Vieira et al. 2007) applied in cloud workflows. In general, the representation in Fig. 12.1 illustrates the relationship among task, contextual element, rule and cloud workflow. The major differences between our definition and Vieira et al. (2007) embrace the following two extended concepts (see Fig. 12.1): (1) we use the concept of “task” instead of “entity” in a broader view of context that does not appear explicitly in the task, not limited to the context of which depends on static attributes from pre-defined entities, as mentioned in context-aware applications (Henricksen and Indulska 2006); and (2) we introduce the concept of “cloud workflow” in order to describe the relationship among context-related concepts and information in scientific workflows in the cloud. Furthermore, we propose that the usual approach for scientific workflow lifecycle is to consider explicitly three contextualized processes (see Fig. 12.2): • Contextualization process identifies the published cloud workflow from the repository in a context close to the context at hand (Point A & B in Fig. 12.2); • Decontextualization process extracts the part of published cloud workflow—the abstract model—to be reused for the problem at hand (Point C in Fig. 12.2); and • Recontextualization process designs the cloud workflow concrete model before the cloud workflow is executed to adapt to the current context (Point D in Fig. 12.2). Compared with (Fan et al. 2011), the major characteristics of cloud workflow lifecycle is that after the execute phase (see Fig. 12.2), the lifecycle enters the result

176

X. Fan

Fig. 12.2 The contextualized scientific workflow lifecycle in the cloud

analysis process, after which the scientist potentially re-designs the current cloud workflow concrete model (Point F in Fig. 12.2). In this evolving cloud workflow lifecycle, scientists cycle through this process until they are satisfied with the result. Finally, the new cloud workflow concrete model has proved its worth and is to be published to the repository for the purpose of sharing (Point G & H in Fig. 12.2).

12.3

Opportunities

The roles of context during the design phase of scientific workflows in the cloud are: (i) context is considered as the key component of cloud workflow design; (ii) context is capable of managing constraints to validate the cloud workflow design model before execution; and (iii) context enables the solution to drive programmable-level specification when the use of workflow specification or language presents an interest for users. We believe that context could bring potential benefits between the scientific workflow design and the user-oriented need. More specifically, context modeling would be the ideal tool for recording provenance information. Using context-based provenance information, scientists could debug workflow execution, validate scientific results, and guide the workflow design and execution with explicit contextual cues. It is in harnessing this possibility, by encouraging scientists to collaborate with the cloud workflow system through interactivity, that contextualized approach could act as one of possible solutions to leverage this gap. In the implementation level, we aim to utilize the Contextual Graphs, or CxGs (Brézillon 2005), for representing the assembling of a cloud workflow in context at the conceptual level. A contextual graph is a directed graph, acyclic with one input and one output and a general structure of a spindle. A path in a contextual graph is

12


177

Fig. 12.3 Elements of a contextual graph [22]

composed of elements of reasoning and contexts, which corresponds to a specific way for problem solving. Figure 12.3 provides the definition of the elements in a contextual graph (actions, contextual elements, sub-graphs, activities and parallel actions grouping). A CxG can improve the process by proposing the known practices (i.e., ways to build the specific cloud service) to explore. Thus it could be assimilated to a simulation leading to the best specific workflow component (i.e., a cloud service) in the user’s query context. The role of CxG could be considered as: (1) the production of workflow models according to the quality of service constraints (time, cost, fidelity, reliability and security) and contextual constraints (i.e., type of contextual elements); (2) the translation of workflow candidates according to both contextual clues (i.e., instantiations of contextual elements). The Contextual Graphs (CxGs) software is available at http://www.cxg.fr.

12.4

Challenges

Contextualized workflow system is a novel type of workflow management system implemented in the cloud, thus its system architecture is consistent with the cloud computing paradigm and its functionalities contain the general workflow functionalities and new components extended for cloud computing. Additionally, because of the market-oriented and the dynamic nature of cloud computing, quality of service (QoS) management plays an important role in cloud workflow systems. Therefore, we consider the main challenges of designing contextualized workflow systems in the dimension of architecture, functionality and QoS management.

12.4.1 Architectural Challenges The system architecture decides how the system components are organized and how they communicate with each other. For contextualized cloud workflow systems, the architecture should not only follow the general architecture of cloud computing

178

X. Fan

Fig. 12.4 The conceptual architecture of contextualized cloud workflow

paradigm, but also should be adapted according to the contextual requirements of the users. As discussed before, the real use of cloud workflow systems requires the introduction of the concept of “context”. Current failures are mainly attributed to the lack of explicitness of contexts in cloud workflow design and its contextualization process (Fan et al. 2013). We propose a conceptual architecture of contextualized cloud workflow in Fig. 12.4 to make contexts explicit in three layers of cloud workflow models, as a trade-off between the global (workflow-level recommendation) and local (service-level selection) optimization to enable a “Workflow as a Service”. The conceptual architecture in Fig. 12.4 features in the abstraction of a highlevel layer, called Cloud workflow Metamodel (the upper layer in Fig. 12.4), from the underlying layers. We propose that the metamodel should represent: (1) general steps of the experiment; (2) initial descriptions of scientists’ requests for the experiment, such as requirements for the generation of cloud workflow; (3) constraints that must be satisfied by a cloud workflow model in order for it to be validated. For example, dataflow is consistent with the software constraints. Otherwise, it provides suggestion to make other software substituted to achieve the similar function while complying with the constraints; and finally (4) the contextual correlation between cloud workflow abstract model and its corresponding cloud workflow concrete models. Point A in Fig. 12.4 shows the first instantiation in the conceptual framework. The contextualized cloud workflow metamodel is instantiated to an abstract one in a specific domain to address the particular focus and requirement in this domain. The first instantiation leads to defining the domain that is relevant for the current focus. For example in Fig. 12.4, the cloud workflow metamodel class is instantiated in the domain of docking preparation. The cloud workflow abstract model (the intermediate layer in Fig. 12.4) corresponds to the cloud workflow abstract model. This model is specified without identifying the specific resource or service for cloud workflow execution. The scientist makes a simulation before running the cloud workflow concrete model without paying attention to the instances of contextual elements for the current problem. For

12


179

example, it is shown in Fig. 12.4 that the class of “Docking Preparation” implements a “Task” activity. Point B in Fig. 12.4 highlights the second instantiation that cloud workflow abstract model is instantiated to address a given situation and the scientist’s current understanding of the experiment, combining with the scientist’s focus and services or resources available for cloud workflow execution. The cloud workflow concrete model (the lowest layer of Fig. 12.4) describes the concrete model, which combines the abstract model with specific resources or services. In this layer, the instances of contextual information are chosen to address the specific situation at a given context. Each abstract model represents a separate thread of execution of activities and actions to be controlled independently to the individual enactment. For example in Fig. 12.4, the “docking software” is instantiated to “an instantiation of Dock 6.2 software”. Similarly, “actor’s preference” will be instantiated to “familiarity of the software”, “skill” could be instantiated to “expertise”, and “user’s mood” is expected to instantiate as “normal”.

12.4.2

Functionality Challenges

System functionality is the set of system functional components that are designed and developed to meet the system functional requirements. The major challenge to system functionality of contextualized cloud workflow systems can be classified to two categories (Liu et al. 2012): (1) functional components to realize the basic functionalities of cloud workflow systems (integration of cloud services, such as cloud resource management and QoS management); (2) functional components to enable the management of context and system reasoning (modeling and representation of contextual information in cloud workflows, dynamic selection of cloud services, etc.).

12.4.3

QoS Management Challenges

QoS management focuses on non-functional requirements which are the constraints on the system functionality such as time, cost, reliability and security (Liu et al. 2012). The main challenge here is how to combine the traditional QoS constraints with user-oriented contextual constraints (user preference, user behavior, etc.). A user may ask for a specific scientific workflow model, and then the subsequent steps would be: • The system recommends the cloud services corresponding to the demand; • The system builts a contextual process by assembling elementary services according to both QoS constraints (time, cost, fidelity, reliability, security, etc.) and contextual elements (size of the problem, estimated time for the building of the service, cost estimation of this building, etc.);

180

X. Fan

• QoS constraints and contextual elements constitute the contextualized workflows for the specific user. • The contextual constraints mentioned above may come from several sources (Fan 2011): • Task at hand (i.e., urgency of the task, and the budget for computation): If it is a urgent task and the budget is adequate, scientist could choose a more powerful and expensive cloud services; • Situation in which the task is realized (i.e., availability of resources): such as availability of virtual machines, cloud services, storage and instruments; • User’s preference, skill and familiarity of the service: when a scientist is going to choose one cloud service from multiple candidates with similar functionality, he might choose the secondary choice instead, in order to escape the long-time learning curve of manipulating the first-choice method that he doesn’t know how to use at all.

12.5

Research Directions

As mentioned in the previous section, various challenges are foreseen in designing cloud workflows with context constraints. However, those are also prospective areas to which we can put our research efforts and make breakthroughs towards contextualized workflows. We aim to discuss the research directions of contextualized workflows in the socio-technical dimension, such as user-system interaction, decision supporting system, context-based intelligent assistant system, etc. However, we are not recommending designing a contextualized workflow from ground up. Middleware technologies that can bridge existing workflow systems with the cloud would seem more cost effective. Plus, to better utilize the mutual approach of designing workflows, we will put contextualized and user-oriented approach as top priority by discussing the research interests within the framework of workflow reference model (WfMC 1995) and well-known taxonomy of workflow management systems (Yu and Buyya 2005). By implementing the building blocks in the workflow reference architecture, we could also leverage existing cloud technologies, such as data management, resource provisioning, etc. There are many existing cloud workflow systems, but it is difficult to involve the user in the design process, because of the lack of making context explicitly and exposing the system’s reasoning to a specific user. However, transitioning into the cloud gives an opportunity for scientists to implement the various key components of workflow that need to be designed in portions. Thus, looking at the actual results of a portion helps decide how that portion should be and once it is settled, then the next portion can be designed. Context-aware Workflow QoS prediction has been identified as promising research directions in real-world web services (Zheng et al. 2012) and cloud workflows (Kuang et al. 2012), especially when choosing a certain cloud workflow component (i.e., a cloud service) according to contextual information. QoS predication aims at

12


181

providing personalized QoS value prediction for service users, employing the historical QoS values. Recent works mainly consider two kinds of QoS properties: (1) service-side QoS properties (e.g., price, popularity, etc.), which are given by the service providers and identical for different users; and (2) user-observed QoS properties (e.g., response-time, through-put, failure probability, network bandwidth, user location, etc.), which can vary widely for different users because of unpredictable Internet connections and the heterogeneous user environment. However, there is a lack of personalized QoS properties that depend on the user-oriented information (e.g., user behavior, user preference, user experience, etc.). Furthermore, methods for evaluating the prediction accuracy of different prediction approaches would benefit both cloud service providers and end users. Dynamic cloud service selection combining the QoS with context constraints would become a necessity for modeling the correlations between QoS values (e.g., time, cost, fidelity, reliability, security, etc.) and user-oriented information (e.g., user preference, user behavior and user experience, etc.). Besides dealing with QoS constraints such as time and cost, it is necessary to consider the context constraints as well to expose the system’s reasoning to a user for intelligent workflow design (Gil et al. 2011). For example, a user may want a justification for why a parameter was set to a certain value or the reason why an algorithm is not appropriate for his data management. This would involve both extending the system to record the contextual reasoning behind its decisions as well as designing the representation of such information. In addition, it is interesting to investigate the types of user satisfactory in cloud workflows. The automatic composition of cloud workflow model has been considered as one of the main concerns for the adoption of human factors in designing cloud workflows (Gil et al. 2011). The proposed roadmap of designing scientific experiment as cloud workflows would be: (1) maximizing all possible workflow compositions; (2) eliminating invalid compositions according to the user-oriented contextual information; (3) predicting the effectiveness and efficiencies of the recommended workflow model with both context and QoS constraints; and finally (4) learning from the failure of dynamic service selection and workflow recommendation by the process of incremental knowledge acquisition. Realizing elastic requirement of the users could also be an interesting and powerful direction. The design phase of cloud workflows may be heavily reliant on professional knowledge and customized preference of the specific user. Thus how to model the interactivity between the user and the system becomes a necessity for incremental knowledge acquisition (Brézillon 2005), especially when the iterative sub-process such as result analysis process is considered.

12.6

Case Study

We introduce a case study in the field of drug discovery process called “virtual screening research on avian influenza H5N1 virus”. Virtual screening is about selecting in silico the best candidate drugs acting on a given target, by docking millions of small molecules separately on the target, which is the initial step in the drug discovery

182

X. Fan

Fig. 12.5 Implementation of making contexts explicit in the design phase of cloud workflow

process (Chen and Shoichet 2009). This case study aims to find dozens of drug candidates for H5N1 virus, by docking millions of small molecules separately on H5N1 protein. Normally, describing a complete set of “all possible execution paths” during docking process might be undesirable. As a result, the strategy of incremental acquisition could enable the cloud workflow or its portions to be dynamically defined during workflow execution through the interactivity between the user and the system. The result is shown in a prototype called CxCloudFlow (Contextualized Cloud Workflow Systems). CxCloudFlow prototype was developed by an open source package Eclipse Helios Sr21 and Java Development Kit 1.6.02 . The cloud workflow model was orchestrated by ActiveBPEL engine3 . As what we discussed in Sect. 12.2, the system interactively builds a workflow model with the user in result analysis and workflow publication phase as recontextualization and decontextualization process. Figure 12.5 shows the CxCloudFlow prototype implementing our contextualized methodology in the design phase of cloud workflows. The prototype illustrates (see Fig. 12.5): (1) in the left part, the system makes available parts of contextual information while the role of the user is to select his/her choice from the possibilities (nine cloud workflows in parallel generated by Contextual Graphs in Fig. 12.5) suggested by the system; (2) in the right part, after the selection of the user and result analysis process, the system needs collaboration with the user by asking questions. For example, in right part of Fig. 12.5, system askes the question “Are you satisfied with the result?” If the answer is “Yes”, the system directs the scientist to see the final result. Otherwise, the system receives the values of contextual elements from the scientist

1

Eclipse Helios Sr2 Packages. Available via: http://www.eclipse.org/downloads/packages/release/ helios/sr2. 2 Java Development Kit 1.6.0. Available via: http://www.java.com/en/download/manual.jsp. 3 ActiveBPEL engine. Available via: http://www.activevos.com.

12


183

Fig. 12.6 The AHP model for the case study

that “NO, I need to modify the parameter of the radius of the spheres”. Then the consequent action is taken to drive the iterative process by modifying the parameters. Once satisfied, the system adds new workflow concrete model to the cloud workflow repository for the sake of sharing. Furthermore, we use a multi-criteria methodcalled the analytic hierarchy process (AHP) model (Phillips-Wrena et al. 2007) to evaluate our prototype. AHP model could incorporate both qualitative and quantitative criteria into a single metric. An advantage of the AHP model for our evaluation is that contributions of the contextualized methodology used in the system to individual criteria can be determined. We first set up the AHP model for our application (see Fig. 12.6). The goal of the evaluation is that system recommends the best cloud workflow model according to inputs from the scientists (i.e., instances of contextual elements) when they are choosing from multiple candidate models. There are four cloud workflow alternatives (C1 , C 2 , C 3 , C 4 ) for reaching the goal, and four criteria (B1 , B2 , B3 , B4 ) to be used in choosing among alternatives. Then we make comparative judgments of the criteria on single pairwise comparisons. Thus, five matrices are built: A–B, B1 –C, B2 –C, B3 –C, B4 –C. Furthermore, linear-based synthesis of priorities where alternatives are evaluated in pairs with respect to the criteria on the next level of the hierarchy, and criteria are given a priority expressed as a weight in the AHP matrix, according to the following equation: 1 (AW )i n i=1 wi n

λ=

Table 12.1 shows the maximized eigenvalue λ that we calculated from the equation. And the feature vector is also given as parameters. Then, the consistency ratio proves that the deviation of the calculation is within a minimized value. Finally, the weights of four alternatives illustrate that the recommended choice by the AHP model is C2 , which is in accord with the result generated by the CxCloudFlow prototype.

184

X. Fan

Table 12.1 Eigenvalue, feature vector and consistency ratio of five matrices Matrix

Maximized eigenvalue λ

Feature vector w

Consistency ratio

A–B

4.008

[0.230, 0.518, 0.122, 0.130]T

0.003 < 0.1

B1 –C

4.004

[0.105, 0.258, 0.362, 0.170]T

0.015 < 0.1

B2 –C

4.014

T

[0.592, 0.117, 0.092, 0.199]

0.005 < 0.1

B3 –C

4.019

[0.149, 0.058, 0.522, 0.063]T

0.007 < 0.1

4.080

T

0.003 < 0.1

B4 –C

[0.367, 0.288, 0.085, 0.260]

Weight of C2 = 0.230 × 0.592 + 0.508 × 0.117 + 0.122 × 0.092 + 0.130 × 0.199 ≈ 0.342 Weight of C3 = 0.230 × 0.149 + 0.508 × 0.058 + 0.122 × 0.522 + 0.130 × 0.063 ≈ 0.144 Weight of C4 = 0.230 × 0.367 + 0.508 × 0.288 + 0.122 × 0.085 + 0.130 × 0.260 ≈ 0.285 Weight of C1 = 0.230 × 0.105 + 0.508 × 0.258 + 0.122 × 0.362 + 0.130 × 0.170 ≈ 0.229

In summary, we use two approaches to evaluate our methodology: (1) the CxCloudFlow prototype; (2) a Multi-criteria DSS evaluation method (AHP model). The former one could be considered as a qualitative approach, while the latter one is a quantitative approach. Contextualized approach especially in design phase of cloud workflows would bring the significance in: (1) enhancing the ability of interactivity between the user and the system to improve the decision-making process for each cloud workflow; and (2) providing the assistance for the social and human preferences of end-users to represent the knowledge, reasoning and contexts of the user.

12.7

Conclusions

Scientific workflow technology has been evolving over the last decade to automating the composition and execution of complex computing and data analysis in science domain. However, the challenge for a large use of workflow is the failure in addressing both the dynamic execution environment (i.e. cloud) and the elastic requirement of users (i.e., logic of use rather than logic of functioning). Two lines of research emerged to address this problem. Upstream, researchers try to make explicit the contextualization process in scientific workflows building to facilitate the reuse of contextualized cloud workflow components or services. Downstream, cloud computing is a technology that would bring a better orchestration of workflows but support an on-demand provisioning of workflow resources. Thus, we proposed a user-oriented system called “contextualized scientific workflow in the cloud” to make the user in the center of cloud workflow orchestration and provisioning that contexts are made explicit in designing cloud workflows. The motivation is to help users to select the best cloud service, datasets and parameters from a vast amount of functionally equivalent cloud services. Thus how to construct the

12


185

best cloud workflow candidate (i.e., the combination of best services) for a specific user under a specific context remains an open issue. The common approach is to use the QoS expectation of the current user as a filter to select the ideal cloud service from the existing service catalog. However, the QoS itself ignores the role of the user. Furthermore, recent works begin to take into account the context constraints. However, they only consider the “objective” and static part of context (time, network bandwidth, location, etc.), but exclude the “subjective and cognitive” part of context, that is user-oriented context (preference, mood, level of skill, etc.). We believe that a hybrid method combining the context (user preference, user behavior, user experience, etc.) and QoS constraints (time, cost, reliability, etc.) will be a feasible approach to enable the intelligent design assistance for scientists. As with any other new paradigm, there are concerns about cloud workflow. For example, the lack of context, such as what kind of contextual reasons is attributed to the unavailability of service in the current situation. By increasing the overlapping on the three communities (i.e., workflow, context, cloud), we expect that each community will benefit from other communities to collectively reach the socio-technical perspective in designing scientific workflows in the cloud. Acknowledgments This work is supported by the grants from Natural Science Foundation of China (61300232), Natural Science Foundation of Gansu Province in China (1208RJZA278), and the Fundamental Research Funds for the Central Universities (lzujbky-2013-40).

References Brézillon, P.: Task-realization models in contextual graphs. In: Proceeding of Modeling and Using Context: 5th International and Interdisciplinary Conference (CONTEXT’05). Lecture Notes in Computer Science, vol. 3554/2005, pp. 55–68. Springer, Heidelberg (2005) Brézillon, P., Pomerol, J.-C.: Contextual knowledge sharing and cooperation in intelligent assistant systems. Le Trav. Hum. 62(3), 223–246 (1999). doi:10.1.1.33.1224 Buyya, R., Yeo, C.S., Venugopal, S., Broberg, J., Brandic, I.: Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility. Future Gener. Comput. Syst. 25(6), 599–616 (2008). doi:10.1016/j.future.2008.12.001 Chen, Y., Shoichet, B.K.: Molecular docking and ligand specificity in fragment-based inhibitor discovery. Nat. Chem. Biol. 5(5), 358–364 (2009). doi:10.1038/nchembio.155 Fan, X.: Context-oriented scientific workflow and its application. Ph.D Thesis, University Pierre and Marie Curie, France (2011) Fan, X., Zhang, R., Brézillon, P.: Contextualizing workflow in cooperative design. Proceeding of 15th International Conference on Computer Supported Cooperative Work in Design (CSCWD’11), IEEE Computer Society Press, IEEE, pp. 17–22 (2011) Fan, X., Zhang, R., Brézillon, P.: Investigating the feasibility of making contexts explicit in designing cloud workflow. Proceeding of 2013 IEEE 27th International Parallel and Distributed Processing Symposium (IPDPS’13) Workshop on CloudFlow, Boston, Massachusetts, USA, pp. 2121–2128 (2013) Gil, Y., Ratnakar, V., Jihie, K., Moody, J., Deelman, E., Gonzalez, P.A., Groth, P.: Wings: Intelligent workflow-based design of computational experiments. IEEE Intell. Syst. 26(1), 62–72 (2011). doi:10.1109/MIS.2010.9

186

X. Fan

Henricksen, K., Indulska, J.: Developing context-aware pervasive computing applications: Models and approach. J. Pervasive Mob. Comput. 2(1), 37–64 (2006). doi: 10.1109/MPRV.2003. 1203753 Kuang, L., Xia, Y., Mao, Y.: Personalized services recommendation based on context-aware QoS prediction. Proceeding of IEEE 19th International Conference on Web Services (ICWS’12), IEEE Computer Society press, IEEE, pp. 400–406 (2012) Liu, X., Yang, Y., Yuan, D., Zhang, G., Li, W., Cao, D., He, Q., Chen, J.: The design of cloud workflow systems. Springer, New York (2012). ISBN: 978–1-4614-1932–7 Phillips-Wrena, G., Morab, M., Forgionnec, G.A., Gupta, J.N.D.: An integrative evaluation framework for intelligent decision support systems. Eur. J. Oper. Res. 195(3), 642–652 (2007) doi:10.1016/j.ejor.2007.11.001 Vieira, V., Tedesco, P., Salgado, A.C., Brézillon, P.: Investigating the specifics of contextual elements management: The CEManTIKA approach. In: Kokinov, B., et al. (eds.) Modeling and Using Context (CONTEXT’07), pp. 493–506. Springer-Verlag, Berlin (LNAI 4635) (2007) WfMC: The workflow reference model. Workflow management coalition technical report. WFMCTC-1003. http://www.wfmc.org/standards/docs/tc003v11.pdf (1995). Accessed 1 Jan 2014 Yu, J., Buyya, R.: A taxonomy of workflow management systems for grid computing. J. Grid. Comput. 3(3–4), 171–200 (2005). doi:10.1.1.59.8378 Zheng, Z., Zhang, Y., Lyu, M.: Investigating QoS of real-world web services. IEEE Trans. Serv. Comput. 99, 1–10 (2012). doi:10.1109/TSC.2012.34